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

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

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

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

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

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

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

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

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

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

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

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

Порог снова повысили

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

Руководитель отвечал примерно:

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

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

Он добавил:

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

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

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

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

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

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

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

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

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

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

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

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

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

Оригинал статьи опубликован в Telegram-канале @tsymbaldev.