Система мотивации разработчиков

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

Источник изображения

Тема оценки эффективности персонала, расчетов KPI, мотивации и премирования стара, но будет жить еще долго. На форумах наталкиваемся на множество нескончаемых дискуссий и холиваров. С точки зрения оценки эффективности труда разработчиков, да и в ИТ в целом, ситуация еще сложнее — копий сломано не мало. Работа разработчика — это производство и интеллектуальный труд в тесной связке, которые оценить и измерить достаточно сложно. Плюс результат применения того или иного подхода напрямую зависит и от руководителя, и от команды, и от организации процесса — какие-то внедренные подходы работают, какие-то не работают и даже вредят.

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

• прозрачный и понятный для всех подход,
• минимум бюрократии,
• минимальная субъективность в оценках,
• открытость, честность и результативность,
• никто не в обиде.

Самое сложное — это, пожалуй, вопрос субъективности. Так или иначе, но он фигурирует практически во всех подходах – об этом ниже.

На совете “стаи” мы отобрали несколько вариантов:

1. Планирование целей и задач на отчетный период — т.е. перед началом отчетного периода (месяц или квартал) с каждым обсуждается план действий и критерии оценки по результатам — если упрощенно «Вот пять задач, сделаешь — будет премия»
2. Премирование по результатам проектов — под проектами подразумевается некий пул задач, дающий на выходе некий работающий функционал.
3. Непрерывная оценка деятельности сотрудников по различным критериям на протяжении отчетного периода.
4. Игра «Угадай мелодию» — есть задача, коллеги обсуждают, кто быстрее ее выполнит. Cделал — получил плюс к премии.
5. Так же (предложено одним из наших сотрудников по опыту прошлых работ) (тихо, шепотом)) – «Вот тебе премия, никому не говори».

Результаты выборов

Вариант 1

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

Вариант 2

Да, неплохой вариант. Нам он не подошел потому, что не все сотрудники привлекаются к значимым проектам. Плюс сложно однозначно оценить вклад каждого в тот или иной проект при командной работе. Еще одна причина отказа от такой идеи – проекты могут быть затяжными — более отчетного периода, а по нашим расчетам привязка к отчетному периоду наиболее удобна для команды.

Вариант 3

Забегу вперед, этот подход мы и выбрали, посему о всех плюсах и минусах ниже.

Вариант 4

Наверное, это даже будет работать, но только в условиях равной команды. В Calltouch у разработчиков разный опыт и зоны ответственности – поэтому нет.

Вариант 5

Тут все понятно 🙂

Как это работает

На самом деле, выбранный всеми вариант я «изобретал» еще на предыдущей работе, и он действительно работал. Почему «изобретал» в кавычках? Несмотря на то, что именно в такой форме, как мы применили в Calltouch, он мне нигде не попадался, я далек от мысли, что привнес что-то новое. Скорее это микс из подходов, о которых доводилось читать и принимать участие в разных компаниях.

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

Абстрактный пример, два сотрудника — Иванов и Петров и пул запланированных критериев:

Закрытие проектов — это кусок второго варианта. Здесь оценивается участие в завершенных проектах, формат этого участия и т.д.

Текущие задачи — работа по текущим задачам, вовлеченность (условно-субъективный показатель), сроки, реакция на блокеры и пр.
Инициатива/идеи — вроде тоже все понятно: предложенные идеи/фичи/улучшения и их реализация.
Закрытие спринтов — вовремя, с должным качеством (отсутствие ошибок или минимально допустимое количество, полноценно работающий функционал).
Ошибки/качество кода — очевидная вещь, но это уже работает в минус.
Опоздания, прогулы (если актуально) — фиксируем в последнем пункте, также в минус.

По заслугам каждого постоянно идет фиксация деятельности. Уровень оценки позволяет учесть вклад в общее дело, грубо говоря, сделанная кнопка достойна одного балла, сделанная форма – трех, а вес влияет на суммарный балл, позволяя выделять наиболее и наименее значимые направления.

По результатам отчетного периода (Q2 – второй квартал) получаем сумму баллов, умноженных на вес по каждому сотруднику.

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

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

bonus — размер бонуса,
salary — зарплата сотрудника,
persCoeff — персональный коэффициент = (сумма баллов) / (средний балл по отделу)
xLimit — коэффициент, не дающий “вылететь” за бюджет, т.е. бюджетxLimit∗(salary1∗persCoeff1+salary2∗persCoeff2+…)<=бюджет

Итого, по примеру выше:
Иванов — 11 баллов
Петров — 8 баллов
Средний балл — (11 + 8)/2 = 9.5

Кейс 1

Иванов ЗП = 100
Петров ЗП = 100
Бюджет = 10
Премия Иванов = 100*(11/9.5)*0.05 = 5.8
Премия Петров = 100*(8/9.5)*0.05 = 4.2

Кейс 2

Иванов ЗП = 100
Петров ЗП = 50
Бюджет = 10
Премия Иванов = 100*(11/9.5)*0.063 = 7.3
Премия Петров = 50*(8/9.5)*0.063 = 2.6

Какие выводы?

Безусловно, у такого подхода есть плюсы и минусы (и свои сложности).

Плюсы

Подход достаточно прост в использовании, понятен всем, статистика доступна всем в любое время. Каждый может обсудить спорные моменты “налету”, напомнить о какой-то своей заслуге — руководитель может что-то пропустить.
Можно выбирать любые варианты и количество критериев, перед каждым новым кварталом –менять критерии, их веса, тем самым акцентируя внимание подразделения на более слабые места. Если со спринтами все хорошо, можно ставить минимальный вес или убрать его вовсе И наоборот, если требуется подтянуть этот момент, можно вытянуть критерий наверх.
Присутствует поле для экспериментов. Например, можно использовать средний балл не по отделу, а по результатам предыдущих периодов каждого сотрудника, таким образом ведя некоторую аналитику и зависимость от прошлых заслуг. Можно использовать общий средний балл прошлых периодов: если в текущем он значительно снизился — это повод не вычерпывать весь премиальный бюджет, дав понять команде, что они расслабились. Или же наоборот, при его постоянном росте — повод пойти к руководству и попросить увеличить бюджет.

Минусы и сложности

Основной минус — наличие доли субъективности руководителя. Этот момент частично можно нивелировать уровнем оценки. Если есть опасения в предвзятости, можно везде принять уровень оценки “единица” и фиксировать только факты. Если таких опасений нет, диапазон можно растягивать, измеряя вклад каждого конкретного достижения сотрудника.
Очень важный момент – это оценка младших сотрудников по сравнению с профессионалами. Уровень достижений у людей с разным опытом разный, но очередная победа каждого должна быть зафиксирована. С другой стороны, их вклад для бизнеса будет не равен, поэтому в расчетах финальной премии фигурирует уровень заработной платы.
Сложность заключается в том, что руководитель должен непрерывно оценивать и фиксировать результаты сотрудников, не забывать и не забивать. Но это его служебные обязанности.