Метрики процесса разработки софта

Ведущие подкаста Александр Ложечкин и Андрей Бреслав в прямом эфире в Лондоне обсуждают тему метрик инженерного процесса, отмечая, что это уникальный выпуск, так как они впервые видят друг друга вживую и общаются с аудиторией онлайн и в зале.

Основные проблемы и сущность метрик:

• Инженеры с естественнонаучным бэкграундом склонны к измерениям, и с ростом организации возникает желание приложить "линейку" для оценки эффективности вместо неформального общения.
• Это вызывает напряжение, так как, с одной стороны, без измерений в большой организации трудно циркулировать информация, а с другой — метрики не отражают реальность в деталях, и их рьяная интерпретация приводит к бюрократии и отрыву от реальности.
• В итоге метрики недолюбливают, но все их используют, потому что "без них никак".

Личные примеры использования метрик:

• Александр ежедневно измеряет количество пройденных шагов (минимум 10 000 с 2020 года) и отмечает, что стал "рабом этой метрики", которая, хотя и помогает больше двигаться, также вызывает фрустрацию, если шаги не учитываются (например, в аэропорту).
• Андрей также начал ходить по 10 000 шагов и добавил метрику "процента пройденных улиц" в городе, что мотивирует исследовать новые места.
• На примере пульса, который люди могут начать управлять, если им показывать его текущее значение, ведущие подчеркивают, что измерение позволяет управлять.

Зачем измерять в инженерном процессе:

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

Когда не нужно измерять:

• Когда не ясна цель измерения — это приводит к "карго-культам" и неправильной интерпретации.
• Когда метрика собирается для прямой оптимизации, особенно если она одна, так как это может привести к "захакиванию" системы и краткосрочной выгоде за счет долгосрочных проблем (например, оптимизация прибыли может убить бизнес).
• Метрики должны служить индикаторами для начала разбирательства ("у нас тренд нисходящий, давайте разберемся почему"), а не прямыми целями или основанием для мотивации. Сам факт измерения может превратить её в систему мотивации.

Примеры хороших и плохих инженерных метрик:

Плохие метрики:

• Число строк кода или число коммитов (без контекста) — бесполезны для оценки продуктивности, но резкие скачки могут быть сигналом поломки.
• Время, потраченное на каждую задачу (отчеты по часам) — приводит к тому, что разработчики пишут "8 часов на задачу" без реальной детализации; сложно реализовать, особенно для разработчиков.
• Метрика Velocity (скорость сгорания сторипоинтов) в Scrum — критикуется за субъективность сторипоинтов, превращение оценки в "хак системы" и избыточные затраты ресурсов на измерение вместо продуктивной работы.

Хорошие метрики (с оговорками):

• Время от сбоя до починки (MTTR), количество сбоев на релиз, количество звонков онколл — напрямую влияют на процесс и стоимость.
• Time to Market (от постановки фичи в разработку до попадания к пользователю) — полезно отслеживать в зоне ответственности конкретного продакт-оунера или руководителя.
• Соотношение багов, найденных пользователями, к багам, найденным тестировщиками.
• Удовлетворенность стейкхолдеров (по пятибалльной шкале) — ценный инструмент для повышения осознанности и рефлексии, хотя и субъективный.
• Распределение инвестиций по типам задач (growth, support, keep lights on) — позволяет управлять ресурсами в соответствии со стратегией компании.
• "Метрики Шрёдингера": полезны при измерении постфактум, когда люди не знают, что их измеряют (например, частота релизов). Если метрика становится известной, она начинает "геймиться".
• "Цена одного изменения": количество боли, причиненной пользователям инцидентами, делённое на количество выкаток в прод — позволяет управлять балансом между скоростью и качеством. Однако комбинация метрик может быть сложной и бесконечной.
• Процент "зеленых" билдов подряд — техническая метрика, полезная для борьбы с проблемами в CI/CD.
• "ТВ-зрители против знатоков": количество сбоев, о которых узнали из мониторинга (знатоки), против сбоев, о которых узнали от пользователей (зрители) — индикатор качества мониторинга.
• Скорость онбординга новых программистов (дни от найма до первого коммита): хороший показатель, но легко "геймится", если становится целью. Лучше использовать на уровне команды, а не всей организации.

Ключевые выводы и философские размышления:

• Геймификация: человек генетически склонен "геймить" любую метрику, как только узнает о ней. Чем сложнее метрика, тем хитрее будет гейминг.
• Закон Гудхарда: "Как только метрика становится целью, она перестаёт быть хорошей метрикой".
• Прорабский метод: вместо измерения каждого кирпича, положенного строителем, лучше спрашивать результат с "прораба", декомпозируя ответственность.
• Осознанность: важно постоянно напоминать себе, зачем вообще производятся измерения. Нельзя бороться с числом, нужно бороться за реальность.
• Запаздывание обратной связи: в больших и инерционных системах (как организации) реакция на управленческие действия может быть очень долгой, что приводит к ошибочным выводам. Нельзя "дёргать руль" постоянно.
• Упрощение реальности: метрики по своей сути упрощают реальность, что является их целью, но одновременно и источником проблем.
• ИИ и метрики: в будущем ИИ может использоваться для анализа качественной информации вместо метрик, но это вызовет сопротивление, так как объективная оценка продуктивности людей рано или поздно приведет к её использованию для оценки и мотивации.
• "Цель" Элияху Голдрата: метрики — это средство для нахождения ограничений в системе и их расширения, а не самоцель.
• Творческий процесс и метрики: в творческих областях (как R&D в IT) попытки декомпозировать метрики сверху вниз могут привести к потере талантов и снижению креативности.

В заключение, ведущие призывают применять метрики с огромной осторожностью, использовать их как инструменты для понимания и управления, а не как самоцель. Александр Ложечкин в целом склоняется к мысли, что "лучше не измерять, чем тешить себя иллюзией, что ты что-то хорошее измеряешь", хотя признаёт, что при огромной осторожности можно получить что-то хорошее.

Дополнение от меня: Очень часто вижу, что метрики действительно становятся целью, и зачастую начинают мешать, а не помогать общему делу. Бывает, что приходится работать не на благо бизнеса, а на благо бизнеса вопреки метрикам. Особенно раздражают попытки внедрения отчётности по часам в продуктовых командах, где это попросту не работает и никогда не даст объективной картины. Подобные метрики хакаются на раз-два. Именно это и подчёркивают Ложечкин и Бреслав: любая метрика, если она становится KPI, будет геймиться. Метрика — это инструмент мониторинга состояния, а не способ выдать премию. Её нужно использовать с умом. Более того, возможен и такой приём: мерить, но не раскрывать, что именно меряешь. Или раскрывать только постфактум. Иначе всё внимание уходит в попытки нарисовать правильную цифру, а не сделать правильное дело.