Измерение разработчиков по закрытым заявкам - это новые строки кода

Мы уже были в такой ситуации. Двадцать лет назад менеджеры думали, что разгадали секрет: подсчитывай количество строк кода, написанных разработчиками, и вуаля — мгновенное измерение производительности. Это было просто, объективно и совершенно неверно. Строки кода стали программистским эквивалентом оплаты солдатам за выстреленные пули — количество важнее смысла.

И вот мы в 2026 году, совершаем ту же самую ошибку, только с новым покрытием. Мы просто заменили «строки кода» на «закрытые заявки», и все ведут себя так, будто изобрели что-то революционное. Заранее спойлер: мы ничего не изобрели. Мы используем тот же ошибочный план действий, только с новой терминологией.

Знакомый шаблон, который никто не хочет признавать

Подумайте об этом. Проблемы практически идентичны. Когда вы измеряете разработчиков по строкам кода, они пишут ненужный код. Когда вы измеряете их по количеству закрытых заявок, они закрывают ненужные заявки. Это то же самое несоответствие стимулов, только в другой оболочке.

Я наблюдал за этим в крупных и мелких компаниях. Разработчик хочет выглядеть продуктивным на аттестации, поэтому разбивает единую связную функцию на пять отдельных заявок — каждая помечена как «закрыта» к концу дня. Другой разработчик обнаруживает, что коллега из службы поддержки клиентов оценивается по количеству закрытых заявок, и внезапно на каждую законную проблему получает пренебрежительный ответ: «Просто откройте ещё одну заявку в другом отделе». Система поощряет пропускную способность, а не результаты, и всё сводится к подсчёту, а не к тому, что на самом деле произошло.

Неудобная правда? Количество закрытых заявок ничего не говорит о том, хорош ли код, решает ли он реальную проблему или волнует ли он клиентов. Разработчик может закрыть пятьдесят заявок, не создав ничего ценного. И наоборот, кто-то, решающий действительно сложную проблему, может закрыть только две заявки, но создать что-то, что существенно улучшит жизнь клиентов.

Почему мы продолжаем совершать эту ошибку

Причина почти банальна: показатели просты. Они чистые. Они помещаются на информационные панели. Они выживают в презентациях PowerPoint для руководителей, которым нужно принимать решения о численности персонала и премиях. Они дают менеджерам иллюзию объективности в том, что по своей сути является субъективным процессом — оценкой эффективности работы человека.

Но вот в чём загвоздка: то, что что-то измеримо, не означает, что это имеет значение. Мы можем измерить что угодно. Мы можем измерить, сколько раз разработчики моргают, глядя на свои клавиатуры. Это не скажет нам, кто продуктивен.

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

Но «почти» недостаточно, когда вы принимаете решения о карьере и вознаграждении людей.

Манипуляции всегда начинаются одинаково

Как только вы привязываете стимулы к закрытым заявкам, манипуляции становятся неизбежными и немедленными. Дело не в том, что разработчики злонамеренны — они просто рациональные действующие лица, реагирующие на порочные стимулы. Если меня оценивают по количеству закрытых заявок, я буду оптимизировать количество закрытых заявок. Это не недостаток характера; это физика.

Вот как это обычно происходит:

1–2 неделя: руководство объявляет о новом показателе производительности. Разработчики думают: «Хорошо, я закрою больше заявок».

3–4 неделя: амбициозные начинают разбивать сложные функции на более мелкие заявки. Больше закрытых заявок = лучшие показатели.

2 месяц: теперь все так делают. Заявки, которые раньше были одной связной единицей, становятся пятью отдельными заявками. Список невыполненных задач растёт как на дрожжах. Но цифры выглядят великолепно.

3 месяц: кто-то обнаруживает, что если закрыть заявку, даже если она на самом деле не решена, система не заметит разницы. Зачем тратить время на то, чтобы на самом деле решить проблему, если можно её закрыть и открыть новую?

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

К тому времени ущерб уже нанесён. Показатель отравил обратную связь между усилиями и результатом. Вы стимулируете видимость продуктивности, а не реальную продуктивность.

Что на самом деле имеет значение (спойлер: это сложнее)

Настоящая продуктивность разработчиков — это не число. Это система. И для измерения системы нужно подумать о том, что на самом деле создаёт ценность.

Начните с этого: результаты важнее результатов. Сколько пользователей на самом деле используют ту функцию, которую вы выпустили? Она уменьшила количество заявок в службу поддержки или увеличила их? Движется ли выручка? Это результаты. Пройденные точки историй, увеличение скорости, закрытые заявки — это результаты. Информационная панель может выглядеть красиво, пока всё рушится, если вы оптимизируете результаты, а не результаты.

Но одних результатов недостаточно, потому что они являются запаздывающими показателями. Вам нужны правильные системные показатели, чтобы диагностировать, что происходит в режиме реального времени:

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

Цикловое время отслеживает, сколько времени разработчики активно работают над кодом от первой фиксации до запуска. Более короткое цикловое время означает, что ваша команда быстрее выпускает ценность и получает обратную связь.

Частота развёртывания показывает, как часто вы успешно отправляете изменения в производство. Команды, такие как Google и GitLab, используют это, потому что это напрямую коррелирует с оперативностью и гибкостью.

Время до первого просмотра имеет значение, потому что код, находящийся в состоянии ожидания просмотра, создаёт невидимые задержки. Отслеживайте PR без просмотра более 24 часов, и вы часто обнаружите узкое место в процессе, о котором вы не знали.

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

Ни один из них не идеален. Ни один не следует использовать изолированно. Но вместе они рисуют картину того, как работает ваша реальная система разработки — не только то, насколько заняты люди.

Архитектура лучших показателей

Вот как это выглядит при правильном внедрении:

Каскад имеет значение. Процессные показатели помогают вам определить, куда на самом деле уходит время. Как только вы узнаете, где разработчики застревают (ожидание сборок, ожидание проверки кода, борьба с нестабильными тестами), вы можете это исправить. Затем, когда вы выпускаете функции, показатели результата сообщают вам, кому это интересно. Если им это интересно, и клиенты это используют, то вы создали подлинную ценность.

Показатели по закрытым заявкам полностью находятся вне этого цикла. Они не измеряют ни процесс, ни результаты. Они измеряют активность.

Что на самом деле нужно сделать, начиная с понедельника

Если ваша организация в настоящее время оценивает разработчиков по количеству закрытых заявок, вот конкретный путь вперёд:

Шаг 1: Признайте проблему

Проведите откровенную беседу со своей командой о том, почему текущий показатель не работает. Покажите им примеры того, как он создаёт порочные стимулы. Это звучит очевидно, но большинство организаций пропускают этот шаг и удивляются, почему инженеры сопротивляются изменениям. Они сопротивляются, потому что знают, что показатель неверный.

Шаг 2: Отслеживайте, что на самом деле происходит

Потратьте одну полную неделю на измерение того, как разработчики на самом деле тратят своё время. Используйте аудит календаря, журналы времени или простые таблицы с 30-минутными блоками. Вы, вероятно, обнаружите, что разработчики тратят гораздо больше времени на встречи, ожидание развёртывания и устранение заблокированной работы, чем кто-либо предполагал. Сделайте это видимым.

Шаг 3: Внедрите защищённое время

Выделите трёхчасовые зоны «без встреч» в календаре каждого разработчика и относитесь к ним так же священно, как к встречам с клиентами. Установите бюджеты прерываний, при которых разработчики могут быть прерваны только 2–3 раза в день по несрочным вопросам. Это сразу улучшит время цикла без каких-либо сложных инструментов.

Шаг 4: Измеряйте систему, а не человека

Настройте отслеживание времени выполнения заказа и времени цикла,