Vanity Metrics и антипаттерны измерения

Закон Гудхарта в разработке

Экономист Чарльз Гудхарт в 1975 году сформулировал принцип, ставший спустя полвека головной болью инженерных менеджеров: «Когда метрика становится целью, она перестаёт быть хорошей метрикой». В разработке закон срабатывает с пугающей надёжностью. Привязали строки кода к оценке производительности — разработчики начали писать многословный код и избегать рефакторинга. Стали считать PR — люди дробят одно логичное изменение на пять, нагружая ревьюеров. Любая метрика становится токсичной в момент, когда от неё зависит зарплата или карьерный рост конкретного человека.

Каталог опасных метрик

Строки кода (LoC)

Самая старая и вредная метрика индивидуальной продуктивности. Опытный разработчик удаляет 500 строк дублирующегося кода и заменяет их 50 строками чистой абстракции — выглядит «менее продуктивным», чем джуниор, который копипастит одну и ту же логику в десять файлов. LoC наказывает за рефакторинг и поощряет раздувание кодовой базы.

Количество коммитов и PR

Число коммитов измеряет привычки работы с git, а не продуктивность. Один разработчик делает атомарные коммиты на каждое изменение, другой коммитит раз в день. Оба бывают одинаково продуктивны. Количество PR страдает той же болезнью: поощряет дробление работы ради числа, а не логичной декомпозиции. DORA-метрики намеренно измеряют delivery pipeline, а не активность отдельных разработчиков, чтобы избежать этой ловушки.

Velocity (story points за спринт)

Story points придумали для относительной оценки сложности внутри одной команды. Когда менеджеры начинают сравнивать velocity между командами или требовать её роста квартал к кварталу, команды реагируют предсказуемо — инфлируют оценки. Задача, которая вчера стоила 3 поинта, сегодня получает 5. Velocity растёт на бумаге, реальная пропускная способность не меняется.

Время на review

Требование «ревью за 24 часа» без учёта качества приводит к rubber-stamping: ревьюер ставит approve, не вникая в код, чтобы уложиться в SLA. Качество code review (см. инструменты и тулчейны) падает, метрика показывает зелёный свет.

Скандал McKinsey

В августе 2023 года McKinsey опубликовали статью «Yes, you can measure software developer productivity» с системой измерения индивидуальной продуктивности разработчиков. Статья вызвала масштабную реакцию индустрии. Gergely Orosz (The Pragmatic Engineer) и Kent Beck написали развёрнутый ответ с указанием на фундаментальную ошибку подхода: почти все предложенные McKinsey метрики измеряют effort (усилие) и output (выход), но не outcome (результат для пользователя) и не impact (влияние на бизнес).

Главная претензия — фреймворк фокусируется на индивидуальных разработчиках, тогда как программная инженерия по природе командная деятельность. Атрибуция продуктивности конкретному человеку разрушает сотрудничество: если метрики привязаны к индивидуальной производительности, помощь коллеге становится нерациональной — время на менторинг или pair programming не отражается в «личных» числах. SPACE Framework выделяет три уровня анализа (индивидуальный, командный и организационный) и настаивает: метрики с разных уровней нельзя смешивать.

Как отличить полезную метрику от vanity metric

Несколько практических фильтров помогают оценить метрику до её попадания на дашборд:

Привязана ли метрика к решению? Полезная метрика подсказывает действие. «CI-пайплайн стал на 40% медленнее за месяц» ведёт к расследованию конкретных шагов. «Команда написала 12 000 строк кода» — никуда.

Можно ли её игрофицировать без последствий? Если разработчик улучшает метрику без улучшения реального результата, это vanity metric. Lead Time из DORA сложно игрофицировать в одиночку: чтобы его сократить, нужно чинить узкие места в pipeline.

Измеряет индивида или систему? Метрики системного здоровья (deployment frequency, MTTR, build time) безопаснее метрик индивидуальной активности (коммиты, PR, строки кода): стимулируют командную работу над процессами, а не соревнование между людьми.

Используется для сравнения команд? Даже хорошая метрика становится вредной, когда менеджмент ранжирует команды по ней: контексты команд различаются настолько, что прямое сравнение создаёт ложные выводы и провоцирует гонку за числами.

Что делать вместо vanity metrics

Orosz и Beck предлагают фокусироваться на outcomes: «Доставляет ли каждая команда хотя бы одну фичу, полезную для пользователей, каждую неделю?», «Достигает ли команда бизнес-целей, которые сама на себя взяла?» Эти вопросы не закрываются манипуляциями с числами — ответ виден в продукте. Dan North в разборе статьи McKinsey формулирует то же проще: измеряйте, как быстро организация учится и адаптируется, а не сколько кода написал каждый инженер.