Желание измерить производительность разработчиков понятно. Инженерная функция дорогая, результат часто нематериален, а CEO и руководителям хочется видеть, становится ли команда эффективнее.
Проблема начинается, когда сложную систему пытаются свести к одной простой цифре.
Строки кода измеряют количество строк кода
Больше кода не означает больше пользы. Иногда лучший инженерный результат — удалить старый код, упростить решение или вообще не писать новую систему.
То же касается количества commits, pull requests или закрытых задач. Все эти показатели могут быть полезны для понимания процесса, но становятся опасными, когда превращаются в персональный KPI.
Люди быстро учатся производить то, что измеряется.
Количество задач тоже легко обмануть
Если команда оценивается по числу закрытых tickets, большие задачи начинают дробиться, сложные проблемы становятся невыгодными, а помощь коллегам вообще перестаёт выглядеть продуктивной.
Инженер, который потратил день и помог трём командам избежать неправильного решения, может выглядеть хуже человека, закрывшего пять маленьких задач.
Система измерения начинает наказывать именно ту работу, которая делает организацию сильнее.
Смотрите на поток работы команды
Полезнее измерять не то, насколько занят отдельный человек, а насколько хорошо работа проходит через систему.
Как долго изменение идёт от решения до production? Где оно ждёт? Сколько времени уходит на исправление дефектов и повторную работу? Насколько часто релизы создают проблемы? Как быстро команда восстанавливается после ошибки?
Эти вопросы помогают искать системные ограничения вместо виноватого разработчика.
Связывайте инженерные показатели с результатом
Высокая скорость релизов сама по себе не цель, если пользователям не становится лучше. Низкое число дефектов тоже может означать не качество, а просто отсутствие изменений.
Хорошая система метрик обычно сочетает несколько уровней: способность команды доставлять изменения, качество и устойчивость результата, влияние на продукт или бизнес.
Одна метрика редко может рассказать всю историю.
Не используйте командную метрику как рейтинг людей
Особенно опасный шаг — взять показатель, который имеет смысл на уровне команды, и использовать его для сравнения отдельных инженеров.
Разработка — совместная работа. Сильный senior может писать меньше кода, потому что занимается архитектурой, review, сложными расследованиями и развитием других. Его вклад специально делает остальных продуктивнее.
Если система оценки этого не видит, она будет постепенно выталкивать именно таких людей.
AI делает старые метрики ещё бессмысленнее
Когда код можно генерировать быстрее, объём произведённого текста становится ещё слабее связан с качеством инженерного результата.
Теперь ещё важнее становятся постановка задачи, выбор архитектуры, review, тестирование, способность увидеть риск и решить, что вообще не нужно строить.
Ускорение набора кода не превращает плохое решение в хорошее. Оно только позволяет получить его быстрее.
Измеряйте систему, обсуждайте человека
Для управления инженерной организацией нужны данные. Но персональная оценка сильного специалиста всё равно требует контекста: какие задачи он решает, как влияет на команду, насколько сложные решения способен принимать, что становится лучше вокруг него.
Метрика должна помогать задавать правильные вопросы. Как только она начинает автоматически отвечать на вопрос «кто хороший разработчик», почти наверняка измеряется уже не то.