Разработчик закрыл 40 задач. Почему это ещё не значит, что ему положена максимальная премия

На днях попалось свежее исследование «Хабр Карьеры» по зарплатам в IT.

И цифры интересные.

В первой половине 2026 года медианная зарплата IT-специалистов выросла на 4%. А у разработчиков — всего на 1%.

После нескольких лет зарплатной гонки рынок явно становится спокойнее.

И мне кажется, именно сейчас особенно интересным становится другой вопрос:

если мы уже не можем бесконечно повышать оклады, как платить за результат так, чтобы сотрудники считали это справедливым, а бизнес понимал, за что отдаёт деньги?

Вот здесь начинается самое сложное.

Представим двух разработчиков.

Первый за квартал закрыл 40 задач.

Второй — 18.

Кому дать большую премию?

Кажется, ответ очевиден.

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

А третий сотрудник вообще выполнил только половину своего плана, потому что две недели вытаскивал production после чужой ошибки.

Именно поэтому я с осторожностью отношусь к попыткам превратить премирование IT-команд в простую арифметику.

Количество выполненных задач ещё не равно результату.

В IT-компаниях часто вижу примерно одну и ту же конструкцию.

Задачи живут в таск-трекере.

Цели — где-нибудь отдельно.

Показатели сотрудников — в таблицах руководителей.

А премию HR в конце квартала собирает из всего этого практически вручную.

И тут начинается настоящее приключение.

Задачу перенесли.

Приоритет изменился.

Вес показателя поменяли.

Сотрудника подключили к другому проекту.

Руководитель решил скорректировать результат.

Через три месяца уже никто толком не помнит, почему итоговая премия получилась именно такой.

А сотрудник задаёт вполне логичный вопрос:

И начинается археология Excel.

Для меня это вообще главный тест системы мотивации.

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

вот твои задачи;

вот их вес;

вот что изменилось в течение периода;

вот фактический результат;

вот коэффициент;

вот итоговая сумма.

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

Проблема в системе.

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

Здесь тоже легко попасть в ловушку.

Можно интегрировать таск-трекер с HR-системой и автоматически считать количество выполненных задач.

Технически — автоматизация состоялась.

Управленчески — ничего не изменилось.

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

задача → ожидаемый результат → выполнение → оценка → правила премирования → вознаграждение.

Причём система должна переживать реальную жизнь.

А в реальной IT-разработке задачи меняются.

Приоритеты двигаются.

Проекты переносятся.

Одни задачи отменяются, другие внезапно становятся критическими.

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

Иначе мы просто переносим хаос из Excel в красивый интерфейс.

Есть противоположная крайность.

Компания строит прекрасную систему KPI, но оставляет руководителю возможность в конце периода поставить любой коэффициент.

Сотрудник выполнил показатели на 95%.

Руководитель ставит 0,7.

Почему?

«Ну, по ощущениям мог лучше».

Если человеческая оценка нужна — пусть остаётся. Не всё в работе разработчика можно измерить цифрами.

Но у неё должны быть критерии.

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

Субъективность полностью убрать невозможно. Непрозрачность — вполне.

Это ещё одна вещь, которую часто забывают.

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

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

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

что от него ожидают;

что уже выполнено;

где есть отставание;

каким сейчас выглядит прогноз премии.

Тогда вознаграждение перестаёт быть сюрпризом.

И становится инструментом управления результативностью.

Рост зарплат разработчиков замедляется. Но это не означает, что вопрос мотивации становится менее важным.

Скорее наоборот.

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

за какой именно результат мы готовы платить больше?

И это, на мой взгляд, гораздо более здоровая дискуссия.

Не «сколько задач сделал разработчик».

А какую ценность создал.

Не «сколько часов работал».

А что изменилось для продукта и бизнеса.

Не «какую премию захотел дать руководитель».

А почему именно такую сумму сотрудник получил.

Вот тогда автоматизация премирования становится не способом быстрее посчитать деньги.

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

Я бы здесь не искал универсальную формулу — в IT её просто нет. Гораздо полезнее смотреть, как эту связку строят в реальных компаниях: что берут из рабочих систем, где оставляют экспертную оценку и как переживают изменение задач посреди периода.

Кстати, сейчас эта тема довольно вовремя появилась и в профессиональной повестке. Я периодически смотрю подобные практические разборы.

А систему премирования я бы проверил одним вопросом:

Если нет — возможно, автоматизировать нужно уже не расчёт.

А логику.