tgoop.com/testing_and_life/1509
Last Update:
возвращаюсь с продолжением постов про метрики
баланс метрик: оцениваем процессы и результаты
в предыдущих постах (1, 2) я уже немного поговорила о том, как важно выбирать правильные метрики, чтобы не просто собирать цифры ради цифр, а действительно понимать, что происходит в вашем проекте. но есть одна важная тема, которую я ещё не затронула, – это баланс между метриками, которые оценивают процессы, и теми, которые оценивают результаты.
почему это важно? давайте разбираться.
если вы слишком увлечены только процессными метриками, вы можете упустить из виду главное – что вы на самом деле создаёте и насколько это ценно. да, важно знать, как идёт процесс, но если в конечном итоге приложение работает плохо или пользователи недовольны, то все эти красивые цифры теряют смысл.
с другой стороны, если фокусироваться только на результатах, вы рискуете не заметить проблемы в процессе, которые могут привести к ухудшению этих самых результатов. например, вы можете гордиться тем, что у вас высокая удовлетворенность пользователей, но если при этом ваши процессы хаотичны и плохо управляются, рано или поздно это аукнется.
вот несколько примеров того, как можно сбалансировать процессные и результативные метрики, избегая фокуса только на количестве и времени:
1. процент багов, невыпущенных в прод (процесс) + удержание пользователей (результат)
- если ваше приложение хорошо протестировано и багов в прод утекает немного, но пользователи приложением не хотят пользоваться, то стоит повнимательнее посмотреть, а чего они хотят. а если баги на проде растут, а пользователи остаются с вами, возможно, вы можете снизить требования к тестированию и увеличить, например, скорость доставки фичей.
2. уровень вовлеченности команды (процесс) + стабильность команды (результат)
- следите за тем, насколько команда вовлечена в проект: участвуют ли все в обсуждениях, предлагают ли идеи. высокий уровень вовлеченности обычно коррелирует с низкой текучестью и стабильностью команды, что в свою очередь отражается на качестве продукта. или нет, если вовлечённость сопровождается слишком высокой нагрузкой и люди, выгорая, уходят.
3. процент выполнения спринта (процесс) + качество релиза (результат)
- завершить спринт на 100% – это, конечно, здорово, но если при этом качество релиза оставляет желать лучшего, то вся эта гонка теряет смысл. важно следить за тем, чтобы спринт завершался не только вовремя, но и с достойным результатом.
4. скорость проведения регрессии (процесс) + количество багов на проде (результат)
- быстро тестировать — хорошо, но если после релиза всё равно появляются баги, нужно задуматься, насколько эффективен этот процесс и как его можно улучшить.
5. качество код-ревью (процесс) + процент отклонённых релизов на этапе тестирования (результат)
- если код-ревью проводится тщательно и качественно, это должно снижать количество ошибок, которые потом выявляются на этапе тестирования. отклонение релизов из-за серьёзных багов – хороший индикатор того, насколько качественно выполнены код-ревью.
поиск баланса между этими двумя типами метрик – это как ходьба по канату. если вы слишком сильно наклонитесь в одну сторону, можно потерять равновесие и упасть. именно поэтому так важно комбинировать метрики, которые дают вам полное представление о том, как идут дела, и при этом не забывать о конечной цели – создании качественного продукта, который нравится пользователям.
метрики процессов помогают вам отслеживать, как именно выполняется работа, а метрики результатов показывают, к чему всё это приводит. когда вы держите в голове и то, и другое, у вас есть больше шансов избежать неприятных сюрпризов на финише.
BY Тестирование и жизнь • про работу для живых людей
Share with your friend now:
tgoop.com/testing_and_life/1509