Как только команда становится больше двух человек, возникает желание её измерить. Обычно это заканчивается таблицей с числом закрытых задач — самой бесполезной и самой вредной из возможных.
Полезные метрики отвечают на вопрос «здоров ли наш процесс», а не «кто хорошо работает». Разница между этими двумя вопросами определяет, поможет измерение или испортит команду.
Четыре показателя доставки
Есть небольшой набор, который устойчиво связан со здоровьем инженерного процесса. Все четыре — про систему доставки, а не про людей, и все четыре снимаются автоматически из инструментов, которые у вас уже есть.
Время от готовности до продакшена. Сколько проходит от слияния изменения до момента, когда им пользуются. Показывает, насколько дорог путь наружу: ручные шаги, окна выката, согласования. Часы — здорово, недели — значит, готовая работа месяцами лежит без пользы.
Частота выкатов. Как часто вы вообще выкатываете. Редкие выкаты означают большие изменения, а большие изменения — более рискованные: сложнее ревью, труднее найти причину поломки, дороже откат. Частота — это не про скорость, это про размер порции риска.
Доля изменений, потребовавших правки после выката. Сколько выкатов закончились срочным исправлением или откатом. Прямая оценка того, насколько ваши проверки ловят проблемы до пользователя.
Время восстановления. От момента, когда что-то сломалось, до момента, когда починили. Именно этот показатель определяет, насколько больно клиенту, — и именно его чаще всего можно улучшить дешевле остальных, через наблюдаемость и инструкции для дежурного.
Первые два говорят о скорости, вторые два — о надёжности. Их часто считают противоположностями («быстро или качественно»), но на практике они улучшаются вместе: мелкие частые изменения и легче проверяются, и быстрее откатываются.
Что измерять бесполезно и вредно
Строки кода. Награждает многословие и наказывает удаление кода — самое ценное действие в старой системе.
Число закрытых задач. Зависит от того, как режут задачи, а не от того, сколько сделано. Стоит начать считать — задачи станут мельче, а работы меньше.
Скорость команды в очках как показатель. Как прогноз для планирования — полезно; как показатель, по которому оценивают, — мгновенно превращается в инфляцию оценок. Растущая скорость при неизменной пользе — это не рост, это переоценка.
Время в редакторе, число коммитов, активность в чате. Измеряют присутствие, а не результат. Побочный эффект — недоверие, которое команда считывает моментально.
Индивидуальные метрики любого рода. Это отдельный пункт, самый важный. Как только показатель становится персональным, он начинает разрушать сотрудничество: ревьюить чужое невыгодно, помогать невыгодно, брать сложное невыгодно. Команда оптимизирует то, что вы измеряете, — и делает это быстрее, чем вы ожидаете.
Простое правило: любая метрика, ставшая целью, перестаёт быть измерением. Поэтому показатели держат градусником для процесса и никогда не вешают на них премии.
Что ещё стоит смотреть регулярно
Помимо четырёх основных, полезны несколько чисел, которые прямо подсказывают, куда вкладываться:
- время до первого ответа в ревью — главный вклад в задержку готовой работы (нормы ревью);
- средний размер изменения — предсказывает и скорость ревью, и риск выката;
- доля времени на незапланированное — поддержка, инциденты, чужие просьбы; если это больше трети, планировать бессмысленно, надо чинить поток;
- число ночных подъёмов на человека — метрика системы и одновременно предвестник ухода;
- среднее время задачи по модулям — где сидит технический долг.
Всё это уже собирается вашими инструментами. Никакого отдельного учёта заводить не нужно — а если для метрики нужно, чтобы люди что-то дополнительно отмечали руками, она почти наверняка не окупится.
Как этим пользоваться
Смотреть на направление, а не на значение. Абсолютные числа мало что значат: сравнивать себя с чужой командой бессмысленно, у неё другой продукт и другая система. Значимо только своё изменение во времени.
Проверять гипотезы, а не отчитываться. Метрика полезна, когда за ней стоит вопрос: «мы ввели ограничение на размер изменения — стало ли ревью быстрее?» Число без вопроса превращается в ритуал.
Обсуждать с командой, а не о команде. Показатели открыты всем, и разговор идёт про процесс: что мешает, что попробуем. Метрики, которые лид смотрит тайно и использует в разговорах о людях, — самый быстрый способ потерять доверие.
Помнить, чего они не показывают. Ни один из этих показателей ничего не говорит о том, нужна ли пользователям сделанная работа. Быстрая доставка ненужного — это быстро потраченные деньги; за пользу отвечают метрики результата, и без них инженерные показатели легко превращаются в самолюбование.
Коротко
- Четыре показателя доставки: время до продакшена, частота выкатов, доля изменений с последующей правкой, время восстановления. Все — про систему, не про людей.
- Скорость и надёжность улучшаются вместе: мелкие частые изменения безопаснее крупных редких.
- Бесполезно и вредно: строки кода, число задач, скорость в очках как показатель, активность, любые персональные метрики.
- Метрика, ставшая целью, перестаёт быть измерением — премии на показатели не вешают.
- Смотрят направление, а не значение; за каждым числом должен стоять вопрос; обсуждают с командой, а не о команде.
- Инженерные показатели ничего не говорят о пользе сделанного — для этого нужны метрики результата.
Что почитать дальше
- Метрики результата — как измерять пользу, а не объём работы.
- Технический долг — как превратить числа в аргумент о приоритетах.
- Код-ревью в команде — где чаще всего сидит задержка готовой работы.