Разработчик закрыл 40 задач. А премию получил меньше коллеги. Где сломалась система?

В IT премирование выглядит просто только на презентациях.

Есть задачи. Есть сроки. Есть результат. Значит, можно взять показатели, подставить их в формулу и получить размер бонуса.

На практике всё намного веселее.

Один разработчик закрыл 40 задач. Второй — 25. Но среди этих 25 была архитектурная задача, от которой зависел весь релиз. Третий половину месяца тушил чужие проблемы и формально выполнил меньше своего плана. Четвёртый выпустил функциональность вовремя, но через неделю команда потратила столько же времени на исправление ошибок.

И кому из них платить больше?

Вот здесь обычная система «сделал больше — получил больше» начинает разваливаться.

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

В IT это особенно заметно.

Количество закрытых задач ещё ничего не говорит о ценности работы.

Количество строк кода — тем более.

Даже соблюдение сроков само по себе не всегда означает хороший результат.

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

Поэтому премирование IT-команд неизбежно становится многослойным.

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

И именно здесь ручной расчёт начинает становиться проблемой.

Очень знакомая архитектура.

Задачи сотрудников находятся в Jira или другой системе управления разработкой.

Показатели — в Excel.

Финансовый результат проекта — ещё где-то.

Размер премии считает HR или руководитель подразделения по своей таблице.

А затем начинаются вопросы.

Почему взяли именно эти данные?

Почему задача не попала в расчёт?

Почему коэффициент здесь 0,8, а там 1,1?

Почему руководитель изменил итоговый балл?

Почему фактическая премия отличается от той, которую сотрудник ожидал?

И HR оказывается в роли переводчика между системой задач, руководителем, финансами и сотрудником.

Мне кажется, если для объяснения премии человеку требуется отдельное расследование, система мотивации уже работает неправильно.

Это принципиальный момент.

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

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

Тогда премия действительно начинает влиять на поведение.

Если же сотрудник три месяца работает, а потом получает неизвестную сумму, которую кто-то когда-то рассчитал в Excel, это уже не мотивация.

Это лотерея.

Можно быстро автоматизировать плохую систему мотивации.

И получить плохую систему мотивации, которая просто работает быстрее.

Поэтому сначала я бы ответил на несколько вопросов.

Что в компании считается результатом?

Как связаны задачи сотрудника и цели команды?

Как учитывается качество?

Есть ли командная часть премии?

Может ли руководитель корректировать результат вручную и в каких случаях?

Понимает ли сотрудник формулу?

И только после этого имеет смысл переносить процесс в систему.

Главная ценность автоматизации премирования — не в том, что компьютер быстрее умножает проценты.

Excel с этим тоже прекрасно справляется.

Ценность появляется, когда данные из рабочих процессов автоматически становятся частью расчёта.

Задача закрыта.

Результат учтён.

Показатель обновился.

Руководитель видит динамику.

Сотрудник понимает, на что влияет.

А в конце периода HR не собирает вручную двадцать файлов из разных подразделений.

Есть ещё одна вещь, которая мне не нравится в системах премирования: скрытая управленческая корректировка.

Когда формально существует формула, но в конце периода руководитель всё равно может поставить сотруднику условные 70%, потому что «мне кажется, он мог лучше».

Тогда зачем вообще были показатели?

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

Но эта часть тоже должна иметь понятные правила.

Если есть корректировка — сотрудник должен понимать её причину.

Если есть экспертная оценка — должны существовать критерии.

Если есть командный коэффициент — должно быть понятно, откуда он взялся.

Прозрачность не означает, что всё нужно превращать в математику.

Она означает, что человек понимает логику решения.

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

И я их понимаю.

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

«Так исторически сложилось».

Поэтому хорошая система мотивации IT-команды должна выдерживать простой тест.

Сможет ли руководитель за пять минут объяснить сотруднику, почему тот получил именно такую премию?

Если да — система, скорее всего, жизнеспособна.

Если для ответа нужно позвать HR, финансиста и человека, который пять лет назад писал Excel-файл, пора что-то менять.

Автоматизация премирования в IT — это не история про ещё один HR-сервис.

Это попытка связать три вещи, которые долго жили отдельно:

что сотрудник сделал → какой результат получил бизнес → какое вознаграждение за это положено.

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

Появляется нормальная управленческая система.

Сотрудник понимает приоритеты. Руководитель видит результат команды. HR перестаёт собирать данные вручную. Финансы получают прогнозируемый фонд премирования.

А бизнес начинает платить не за количество активности, а за результат.

И, пожалуй, именно это здесь самое важное.

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

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