Ох уж эти метрики 🤦‍♂️ Менеджмент сегодня в значительной степени очарован возможностью оцифровать работу команд разработки. И действительно, собрав информацию только лишь из трекера задач и репозитория с кодом, можно узнать многое о работе команды, например: 👉 Время выпуска задач от взятия в работу до внедрения (Lead Time). 👉 Время выпуска фичей от идеи до клиента (Time To Market). 👉 Количество выпущенных задач за период (Throughput). 👉 Количество коммитов в репозиторий проекта за период (Commit Rate). И вот когда метрики собраны и визуализированы на графиках и дашбордах начинается самое интересное — нужно определить, как использовать эти данные. ☝️ Зачастую единственным вариантом применения этой информации, оказывается система поощрений и наказаний: поощряем за достижение KPI и наказываем на невыполнение. Вот именно такой подход и заводит ситуацию в тупик: ❗️ Как только метрики начинают влиять на уровень премий, процент повышения или другие схожие решения, то это неизбежно приводит к «подкручиванию» этих метрик под целевой уровень. ❗️ Менеджмент же в свою очередь теряет инструмент, который позволяет отслеживать реальное положение дел на местах, что по сути обесценивает процесс сбора и анализа метрик. В итоге команды продолжают работать так, как работали, а менеджмент ошибочно считает, что все хорошо, потому что метрики в порядке. Вывод Единственное для чего действительно стоит использовать метрики разработки, так это для принятия обоснованных управленческих решений по внесению изменений в процессы разработки и оценки эффективности этих изменений. В этом случае с одной стороны пропадает смысл «подкручивать» метрики, а с другой картина по метрикам всегда остается актуальной! А как применяют метрики у вас? TeamLead говорит | Александр Романов