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 (влияние на бизнес).

Главная претензия к McKinsey сводилась к тому, что их фреймворк фокусируется на индивидуальных разработчиках, тогда как программная инженерия по своей природе остаётся командной деятельностью. Попытка атрибутировать продуктивность конкретному человеку разрушает сотрудничество: если метрики привязаны к индивидуальной производительности, помощь коллеге становится нерациональной, потому что время, потраченное на менторинг или 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 формулирует ту же мысль ещё проще: измеряйте, как быстро организация учится и адаптируется, а не сколько кода написал каждый инженер.