Как измерять разработку и не скатиться в подсчёт строк кода
Четыре метрики DORA, как я их собирал без дорогих платформ и почему их нельзя вешать на конкретного человека.
Когда меня спрашивают, как измерить продуктивность разработчиков, я начинаю с того, как её измерять нельзя: строки кода, коммиты, закрытые таски, часы в трекере. Всё это меряет активность, а не результат, и мгновенно превращается в игру - люди начинают оптимизировать метрику вместо работы. Причём делают это не со зла, а совершенно естественно.
Программа DORA (исследование идёт с 2014 года, из него выросла книга Accelerate) предложила четыре метрики, которые описывают не человека, а систему доставки:
- как часто мы выкатываем в прод - deployment frequency;
- сколько проходит от коммита до прода - lead time for changes;
- какая доля релизов ломает прод - change failure rate;
- как быстро чиним после сбоя - failed deployment recovery time.
Первые две про скорость, вторые две про стабильность. И тут главный вывод исследований, ради которого стоит всё это читать: это не компромисс. Команды-лидеры одновременно быстрее и стабильнее. Логика простая - маленькие частые изменения проще проверить и проще откатить, чем один огромный релиз раз в квартал.
Этим аргументом хорошо закрывается вечное «нам надо релизить реже, чтобы было надёжнее». Данные говорят ровно наоборот.
Собрать это можно за неделю
Никакой дорогой платформы не нужно, всё берётся из того, что уже есть:
- частота деплоев - количество успешных выкаток в прод из CI;
- lead time - разница между временем коммита (
git log --format=%cI) и временем деплоя, в котором он приехал; - change failure rate - доля деплоев, за которыми пошёл откат или хотфикс. Проще всего размечать конвенцией: ветка
hotfix/*или тег; - recovery time - от инцидента до восстановления, берётся из дежурств или трекера.
Минимальный сбор - строчка в пайплайне:
curl -s -X POST "$METRICS_URL/deployments" \
-H 'Content-Type: application/json' \
-d "{\"service\":\"$CI_PROJECT_NAME\",\"sha\":\"$CI_COMMIT_SHA\",\"env\":\"prod\",\"status\":\"$STATUS\"}"
Дальше витрина в Grafana. Мы у себя строили похожую систему отчётности, и самое ценное оказалось не в дашборде, а в разговорах, которые он запускал на ретро.
Что делать с цифрами
Метрики отвечают на вопрос «где узкое место», а не «кто плохо работает».
Lead time большой, деплоев мало - ищем очередь. Обычно это ревью, ручное тестирование или согласование релиза.
Change failure rate высокий - не хватает автотестов или стенд не похож на прод.
Recovery time большой - нет быстрого отката и нормального мониторинга, о падении узнают от пользователей.
Каждый вывод превращается в конкретную инженерную задачу, и в этом вся польза.
Где это ломается
Закон Гудхарта: когда мера становится целью, она перестаёт быть мерой. Начнёшь премировать за частоту деплоев - появятся пустые деплои. Начнёшь ругать за change failure rate - инциденты просто перестанут регистрировать. Я видел оба сценария.
Поэтому три ограничения, которые я ставил жёстко:
Метрики командные, никогда не персональные. В разрезе конкретного человека - нет, и это не обсуждается.
Смотрим тренд, а не абсолют. «Стало лучше, чем месяц назад» полезнее, чем «мы в топ-квартиле» - топ-квартиль вообще не про вас, у вас другой продукт и другие ограничения.
В оценку сотрудника метрики не входят. Для этого есть performance review с другими критериями.
Отдельно любопытное наблюдение из отчёта DORA за 2024 год: рост внедрения ИИ-инструментов в командах сопровождался ухудшением показателей доставки, прежде всего стабильности. Это не аргумент против ИИ. Это аргумент за то, чтобы мерить: без метрик такие эффекты не видны вообще, а ощущение «мы стали быстрее» появляется в любом случае.
Главная ценность DORA даже не в цифрах, а в том, что разговор переезжает с людей на процесс. «Почему Вася медленно работает» - бессмысленный вопрос. «Почему изменение едет до прода девять дней» - решается за спринт.