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

По итогам квартала считали процент выполненного плана: какая доля задач из планов спринтов дошла до продакшена. Начинали с 75%, дальше порог планировали поднимать шагами по 5% и в идеале дойти до 95–100%. Если команда достигала порога, премию получали все.

Логика была понятной: процент показывал предсказуемость команды, то есть можно ли верить планам спринтов и обещанным срокам. Явного критерия при этом не было, что именно считать выполненной задачей и насколько один разработчик может влиять на общий процент. Сложности начались, когда тот же процент стал единственным условием личной премии.

Первые два квартала

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

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

За первые два квартала команда выполнила примерно 83% плана. Точную цифру я уже не помню, но премию нам выплатили. По отчёту всё выглядело хорошо, хотя часть результата держалась на переработках.

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

Для продукта такая задача действительно не завершена. Но как основание для премии этот процент смешивал работу разработчика с загрузкой QA, изменением требований и другими зависимостями, которыми он не управлял.

Общая цифра начала работать против команды

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

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

Чем больше людей делили одну цифру, тем меньше в ней было видно каждого. Это одна из сторон эффекта Рингельмана. Один из опытных разработчиков в какой-то момент сказал:

Вертел я этот план. Буду спокойно заниматься своими задачами.

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

Порог подняли до 90%

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

Руководитель отвечал:

Ты лид и отвечаешь за результат команды.

Я соглашался, что лид влияет на результат всей команды. При этом часть разработчиков не находилась в моём прямом подчинении, а загрузку QA, количество клиентских инцидентов и работу других команд я не мог изменить самостоятельно. Мы по-разному оценивали, насколько этих возможностей достаточно для роста с 83% до 90%.

Он добавил:

У продажников же есть общий план.

Сравнение с продажами помогало объяснить идею общей цели, но системы различались. У каждого сотрудника отдела продаж был личный план, премия зависела от его результата, а у руководителя дополнительно учитывался результат команды. В разработке одну общую цифру использовали для премии каждого участника, хотя доведение задачи до продакшена зависело сразу от разработчиков, QA, требований и внешних команд.

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

Аргументы не сработали. Нового порога мы не достигли, и предположение про потолок в 85% оказалось верным. Через некоторое время премию почти перестали получать, в том числе люди, которые много работали и регулярно перерабатывали.

Сильнее всего это ударило по тем, кто и тянул план: нагрузка осталась прежней, а премия исчезла. Мотивация начала падать. Мы несколько раз обсуждали систему на performance review, но заметно она не изменилась и просуществовала около полутора лет.

Почему система не дала ожидаемого эффекта

Метрика процесса стала оценкой человека

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

Новый порог не подкрепили изменениями

Порог поднимали от достигнутого: команда сразу сделала 83%, поэтому ступени 80% и 85% пропустили и следующим ориентиром стали 90%. При этом времени у неё не прибавилось, QA не разгрузился, а инцидентов не стало меньше.

Если 83% уже получились благодаря переработкам, новый порог в 90% сам по себе не заставит команду работать быстрее. Он лишь закрепит переработки как привычный способ выполнить план.

Одна цифра скрывала причины переносов

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

Метрика начала менять поведение

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

Что я сделал бы сейчас

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

План не стоит повышать автоматически. Переход от 83% к 90% должен опираться на конкретное изменение: меньше инцидентов, быстрее тестирование, понятнее требования или меньше внешних блокировок.

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

Сам по себе процент выполненного плана не был бесполезным. Он перестал помогать, когда его связали с деньгами и ожиданием постоянного роста. Если хочется поднять результат с 83% до 90%, сначала нужно изменить систему, которая этот результат создаёт. Иначе меняется только число в таблице.