Виталий Толстиков пишет:

Измеряешь количество коммитов - получаешь количество коммитов, а не ускорение разработки.

Кажется очевидным? Мы тоже так думали, пока нам не попался тендер на разработку системы оценки эффективности команд. К примеру, вот какие метрики для оценки эффективности разработчиков были в тендере.

Количество новых, измененных и удаленных строк кода в продакшене
Количество коммитов за период
Количество успешных ревью кода
Эффективность коммитов: полезный код или рефакторинг
Скорость интеграции кода - время от создания мерж реквеста до мержа
Процент откатов коммитов из-за ошибок
Процент успешных сборок
Процент задач, потребовавших доработки
Процент попадания в оценку времени

Тендер мы не выиграли. Но оно и к лучшему, так как переубедить менеджмент делать как надо, а не так, как они задумали вряд ли бы получилось (судя по проработанности тендера настрой там серьезный). А помогать строить систему, от которой будет только вред, мы бы не стали.

Но зато есть отличный повод поговорить про output и outcome метрики, чем они отличаются и почему замена вторых первыми будет стоить дорого. Да и случай с тендером не единственный - попытки померить и оценить людей по кривому набору показателей нам встречаются регулярно.

Что это такое

Output метрики - это то, что команда производит:

количество деплоев/релизов в неделю
строки кода
velocity / story points закрытых задач
test coverage в процентах ... и много чего еще

Outcome метрики - это результат, который получает бизнес или пользователь:

retention
DAU / MAU
конверсия, выручка, NPS
время отклика при инциденте (MTTR)
доля фич в продукте, которыми реально пользуются
снижение числа дефектов в проде

Разница кажется очевидной, но почему-то менеджмент регулярно наступает на эти грабли, мотивируя людей работать над метриками, характеризующими внутренний процесс, а не внешний результат.

Почему вредно оценивать людей по output метрикам

Есть такой принцип - закон Гудхарта: “Как только показатель становится целью, он перестает быть хорошим показателем”. Сформулировал его британский экономист Чарльз Гудхарт еще в 1975 году, и в управлении людьми он работает просто отлично.

Если команда знает, что ее оценивают по velocity - story points начнут расти. Сами по себе, без роста реальной производительности. Если оценивают по числу деплоев - деплои участятся, пусть даже в ущерб стабильности. Если по coverage - тесты будут написаны, во что бы то ни стало.

Если же таких метрик насыпать побольше, чтобы сложнее было одной метрикой манипулировать (как в том тендере) - львиная доля энергии сотрудников будет уходить на чтобы написать побольше кода, побыстрее протолкнуть его в прод и при это закрыть побольше сторипойнтов вовремя.

И так будет происходить с любыми метриками - люди будут максимизировать то, по чему их оценивают и что влияет на их вознаграждение.

Как должно быть

Output метрики - инструмент для самих команд и руководителей. Именно команда должна отслеживать velocity, coverage, deployment frequency, время на code review — и самостоятельно решать, как менять процессы, чтобы двигаться к нужным outcome.

Пример: исследователи DORA (DevOps Research and Assessment, Google Cloud) шесть лет изучали, что реально влияет на эффективность инженерных команд. Они выделили четыре ключевые метрики: