О том, как мы выбирали систему мотивации для разработчиков Calltouch, рассказывает руководитель разработки Роман Хохлов.
Источник изображения
Тема оценки эффективности персонала, расчетов KPI, мотивации и премирования стара, но будет жить еще долго. На форумах наталкиваемся на множество нескончаемых дискуссий и холиваров. С точки зрения оценки эффективности труда разработчиков, да и в ИТ в целом, ситуация еще сложнее — копий сломано не мало. Работа разработчика — это производство и интеллектуальный труд в тесной связке, которые оценить и измерить достаточно сложно. Плюс результат применения того или иного подхода напрямую зависит и от руководителя, и от команды, и от организации процесса — какие-то внедренные подходы работают, какие-то не работают и даже вредят.
Когда команда Calltouch выбирала путь, по которому нам пойти, то решили отталкиваться от простых и очевидных вещей:
Самое сложное — это, пожалуй, вопрос субъективности. Так или иначе, но он фигурирует практически во всех подходах – об этом ниже.
На совете “стаи” мы отобрали несколько вариантов:
Этот вариант неплох: есть план, есть оговоренные критерии. Но главный минус в том, что во-первых, он охватывает не такой большой спектр вопросов, как хотелось бы, во-вторых, в мире Agile, когда приоритеты могут поменяться уже завтра, такой подход приведет к отработке сотрудником оговоренных целей ради премии, и прикрытию глаз на более важные новые внезапные задачи.
Да, неплохой вариант. Нам он не подошел потому, что не все сотрудники привлекаются к значимым проектам. Плюс сложно однозначно оценить вклад каждого в тот или иной проект при командной работе. Еще одна причина отказа от такой идеи – проекты могут быть затяжными — более отчетного периода, а по нашим расчетам привязка к отчетному периоду наиболее удобна для команды.
Забегу вперед, этот подход мы и выбрали, посему о всех плюсах и минусах ниже.
Наверное, это даже будет работать, но только в условиях равной команды. В Calltouch у разработчиков разный опыт и зоны ответственности – поэтому нет.
Тут все понятно :)
На самом деле, выбранный всеми вариант я «изобретал» еще на предыдущей работе, и он действительно работал. Почему «изобретал» в кавычках? Несмотря на то, что именно в такой форме, как мы применили в Calltouch, он мне нигде не попадался, я далек от мысли, что привнес что-то новое. Скорее это микс из подходов, о которых доводилось читать и принимать участие в разных компаниях.
Итак, в начале отчетного периода определяем набор критериев оценки. Далее на всех этапах – каждый день, каждый час, фиксируются заслуги сотрудников по каждому направлению.
Абстрактный пример, два сотрудника — Иванов и Петров и пул запланированных критериев:
Закрытие проектов — это кусок второго варианта. Здесь оценивается участие в завершенных проектах, формат этого участия и т.д.
Текущие задачи — работа по текущим задачам, вовлеченность (условно-субъективный показатель), сроки, реакция на блокеры и пр.
Инициатива/идеи — вроде тоже все понятно: предложенные идеи/фичи/улучшения и их реализация.
Закрытие спринтов — вовремя, с должным качеством (отсутствие ошибок или минимально допустимое количество, полноценно работающий функционал).
Ошибки/качество кода — очевидная вещь, но это уже работает в минус.
Опоздания, прогулы (если актуально) — фиксируем в последнем пункте, также в минус.
По заслугам каждого постоянно идет фиксация деятельности. Уровень оценки позволяет учесть вклад в общее дело, грубо говоря, сделанная кнопка достойна одного балла, сделанная форма – трех, а вес влияет на суммарный балл, позволяя выделять наиболее и наименее значимые направления.
По результатам отчетного периода (Q2 – второй квартал) получаем сумму баллов, умноженных на вес по каждому сотруднику.
Что с этим делать дальше? Это поле для экспериментов: мы получили некий результат вклада каждого в абстрактных баллах.
Простейший вариант распоряжения этими баллами, который взяли на вооружение, это расчет премии, исходя из общего премиального бюджета по нехитрой формуле — размер бонуса,
— зарплата сотрудника,
— персональный коэффициент = (сумма баллов) / (средний балл по отделу)
— коэффициент, не дающий “вылететь” за бюджет, т.е.
Итого, по примеру выше:
Иванов — 11 баллов
Петров — 8 баллов
Средний балл — (11 + 8)/2 = 9.5
Иванов ЗП = 100
Петров ЗП = 100
Бюджет = 10
Премия Иванов = 100*(11/9.5)*0.05 = 5.8
Премия Петров = 100*(8/9.5)*0.05 = 4.2
Иванов ЗП = 100
Петров ЗП = 50
Бюджет = 10
Премия Иванов = 100*(11/9.5)*0.063 = 7.3
Премия Петров = 50*(8/9.5)*0.063 = 2.6
Безусловно, у такого подхода есть плюсы и минусы (и свои сложности).
Подход достаточно прост в использовании, понятен всем, статистика доступна всем в любое время. Каждый может обсудить спорные моменты “налету”, напомнить о какой-то своей заслуге — руководитель может что-то пропустить.
Можно выбирать любые варианты и количество критериев, перед каждым новым кварталом –менять критерии, их веса, тем самым акцентируя внимание подразделения на более слабые места. Если со спринтами все хорошо, можно ставить минимальный вес или убрать его вовсе И наоборот, если требуется подтянуть этот момент, можно вытянуть критерий наверх.
Присутствует поле для экспериментов. Например, можно использовать средний балл не по отделу, а по результатам предыдущих периодов каждого сотрудника, таким образом ведя некоторую аналитику и зависимость от прошлых заслуг. Можно использовать общий средний балл прошлых периодов: если в текущем он значительно снизился — это повод не вычерпывать весь премиальный бюджет, дав понять команде, что они расслабились. Или же наоборот, при его постоянном росте — повод пойти к руководству и попросить увеличить бюджет.
Основной минус — наличие доли субъективности руководителя. Этот момент частично можно нивелировать уровнем оценки. Если есть опасения в предвзятости, можно везде принять уровень оценки “единица” и фиксировать только факты. Если таких опасений нет, диапазон можно растягивать, измеряя вклад каждого конкретного достижения сотрудника.
Очень важный момент – это оценка младших сотрудников по сравнению с профессионалами. Уровень достижений у людей с разным опытом разный, но очередная победа каждого должна быть зафиксирована. С другой стороны, их вклад для бизнеса будет не равен, поэтому в расчетах финальной премии фигурирует уровень заработной платы.
Сложность заключается в том, что руководитель должен непрерывно оценивать и фиксировать результаты сотрудников, не забывать и не забивать. Но это его служебные обязанности.
Источник изображения
Тема оценки эффективности персонала, расчетов KPI, мотивации и премирования стара, но будет жить еще долго. На форумах наталкиваемся на множество нескончаемых дискуссий и холиваров. С точки зрения оценки эффективности труда разработчиков, да и в ИТ в целом, ситуация еще сложнее — копий сломано не мало. Работа разработчика — это производство и интеллектуальный труд в тесной связке, которые оценить и измерить достаточно сложно. Плюс результат применения того или иного подхода напрямую зависит и от руководителя, и от команды, и от организации процесса — какие-то внедренные подходы работают, какие-то не работают и даже вредят.
Когда команда Calltouch выбирала путь, по которому нам пойти, то решили отталкиваться от простых и очевидных вещей:
- прозрачный и понятный для всех подход,
- минимум бюрократии,
- минимальная субъективность в оценках,
- открытость, честность и результативность,
- никто не в обиде.
Самое сложное — это, пожалуй, вопрос субъективности. Так или иначе, но он фигурирует практически во всех подходах – об этом ниже.
На совете “стаи” мы отобрали несколько вариантов:
- Планирование целей и задач на отчетный период — т.е. перед началом отчетного периода (месяц или квартал) с каждым обсуждается план действий и критерии оценки по результатам — если упрощенно «Вот пять задач, сделаешь — будет премия»
- Премирование по результатам проектов — под проектами подразумевается некий пул задач, дающий на выходе некий работающий функционал.
- Непрерывная оценка деятельности сотрудников по различным критериям на протяжении отчетного периода.
- Игра «Угадай мелодию» — есть задача, коллеги обсуждают, кто быстрее ее выполнит. Cделал — получил плюс к премии.
- Так же (предложено одним из наших сотрудников по опыту прошлых работ) (тихо, шепотом)) – «Вот тебе премия, никому не говори».
Результаты выборов
Вариант 1
Этот вариант неплох: есть план, есть оговоренные критерии. Но главный минус в том, что во-первых, он охватывает не такой большой спектр вопросов, как хотелось бы, во-вторых, в мире Agile, когда приоритеты могут поменяться уже завтра, такой подход приведет к отработке сотрудником оговоренных целей ради премии, и прикрытию глаз на более важные новые внезапные задачи.
Вариант 2
Да, неплохой вариант. Нам он не подошел потому, что не все сотрудники привлекаются к значимым проектам. Плюс сложно однозначно оценить вклад каждого в тот или иной проект при командной работе. Еще одна причина отказа от такой идеи – проекты могут быть затяжными — более отчетного периода, а по нашим расчетам привязка к отчетному периоду наиболее удобна для команды.
Вариант 3
Забегу вперед, этот подход мы и выбрали, посему о всех плюсах и минусах ниже.
Вариант 4
Наверное, это даже будет работать, но только в условиях равной команды. В Calltouch у разработчиков разный опыт и зоны ответственности – поэтому нет.
Вариант 5
Тут все понятно :)
Как это работает
На самом деле, выбранный всеми вариант я «изобретал» еще на предыдущей работе, и он действительно работал. Почему «изобретал» в кавычках? Несмотря на то, что именно в такой форме, как мы применили в Calltouch, он мне нигде не попадался, я далек от мысли, что привнес что-то новое. Скорее это микс из подходов, о которых доводилось читать и принимать участие в разных компаниях.
Итак, в начале отчетного периода определяем набор критериев оценки. Далее на всех этапах – каждый день, каждый час, фиксируются заслуги сотрудников по каждому направлению.
Абстрактный пример, два сотрудника — Иванов и Петров и пул запланированных критериев:
Закрытие проектов — это кусок второго варианта. Здесь оценивается участие в завершенных проектах, формат этого участия и т.д.
Текущие задачи — работа по текущим задачам, вовлеченность (условно-субъективный показатель), сроки, реакция на блокеры и пр.
Инициатива/идеи — вроде тоже все понятно: предложенные идеи/фичи/улучшения и их реализация.
Закрытие спринтов — вовремя, с должным качеством (отсутствие ошибок или минимально допустимое количество, полноценно работающий функционал).
Ошибки/качество кода — очевидная вещь, но это уже работает в минус.
Опоздания, прогулы (если актуально) — фиксируем в последнем пункте, также в минус.
По заслугам каждого постоянно идет фиксация деятельности. Уровень оценки позволяет учесть вклад в общее дело, грубо говоря, сделанная кнопка достойна одного балла, сделанная форма – трех, а вес влияет на суммарный балл, позволяя выделять наиболее и наименее значимые направления.
По результатам отчетного периода (Q2 – второй квартал) получаем сумму баллов, умноженных на вес по каждому сотруднику.
Что с этим делать дальше? Это поле для экспериментов: мы получили некий результат вклада каждого в абстрактных баллах.
Простейший вариант распоряжения этими баллами, который взяли на вооружение, это расчет премии, исходя из общего премиального бюджета по нехитрой формуле — размер бонуса,
— зарплата сотрудника,
— персональный коэффициент = (сумма баллов) / (средний балл по отделу)
— коэффициент, не дающий “вылететь” за бюджет, т.е.
Итого, по примеру выше:
Иванов — 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
Какие выводы?
Безусловно, у такого подхода есть плюсы и минусы (и свои сложности).
Плюсы
Подход достаточно прост в использовании, понятен всем, статистика доступна всем в любое время. Каждый может обсудить спорные моменты “налету”, напомнить о какой-то своей заслуге — руководитель может что-то пропустить.
Можно выбирать любые варианты и количество критериев, перед каждым новым кварталом –менять критерии, их веса, тем самым акцентируя внимание подразделения на более слабые места. Если со спринтами все хорошо, можно ставить минимальный вес или убрать его вовсе И наоборот, если требуется подтянуть этот момент, можно вытянуть критерий наверх.
Присутствует поле для экспериментов. Например, можно использовать средний балл не по отделу, а по результатам предыдущих периодов каждого сотрудника, таким образом ведя некоторую аналитику и зависимость от прошлых заслуг. Можно использовать общий средний балл прошлых периодов: если в текущем он значительно снизился — это повод не вычерпывать весь премиальный бюджет, дав понять команде, что они расслабились. Или же наоборот, при его постоянном росте — повод пойти к руководству и попросить увеличить бюджет.
Минусы и сложности
Основной минус — наличие доли субъективности руководителя. Этот момент частично можно нивелировать уровнем оценки. Если есть опасения в предвзятости, можно везде принять уровень оценки “единица” и фиксировать только факты. Если таких опасений нет, диапазон можно растягивать, измеряя вклад каждого конкретного достижения сотрудника.
Очень важный момент – это оценка младших сотрудников по сравнению с профессионалами. Уровень достижений у людей с разным опытом разный, но очередная победа каждого должна быть зафиксирована. С другой стороны, их вклад для бизнеса будет не равен, поэтому в расчетах финальной премии фигурирует уровень заработной платы.
Сложность заключается в том, что руководитель должен непрерывно оценивать и фиксировать результаты сотрудников, не забывать и не забивать. Но это его служебные обязанности.
Harr
Управление процессами в малых группах — уравнение с большим количеством неизвестных.
Вес, как я понял, в вашей системе влияет только на тип задачи. Как тогда быть со разницей в сложности похожих по типу задач? Например, если одну кнопку нужно делать 1 час, другую — 5 часов. Ошибки тоже бывают разные. Не будет ли такого, что сотрудник начнёт намеренно выполнять больше мелких или простых задач, чтобы казаться по этой системе оценки успешнее?CalltouchForever Автор
Вес влияет на метрику, суть, группу схожих оцениваемых факторов.
А уже в рамках каждой метрики оценивается вклад и именно здесь учитывается сложность задач, критичность ошибок и т.п.
В приведенном примере оценки от 1 до 3, можно двигать диапазон под каждую команду, под каждую метрику.
Если мы ставим цель посчитать количество закрытых задач (что, конечно, так себе метрика)и человеку нравится пачками закрывать именно простые задачи — хорошо, оцениваем их в 1 балл, а сложные в 10 и т.д.
Harr
Не поймите неправильно. Объясню своё личное, субъективное мнение по вопросу. С чем сталкивался лично при реализации подобных систем учёта производительности труда:
1. Большое количество всевозможных типов задач, вопросов и т.п.
Если ваш работник не сферический конь в вакууме — он будет решать параллельно много вопросов, которые упорно не захотят вписываться в систему оценки. Физически не хватит времени учесть все факторы. Приходится какими-то группами задач жертвовать. Что по разным причинам не получится делать оптимально.
2. Если у вас не одинаковые задачи каждый день — их список будет постоянно меняться, дополняться. Формула расчёта будет постоянно меняться. Люди не будут понимать, к чему им стремиться. А когда от этого зависит ещё и их заработок — будут нервничать (хоть и не показывать этого первое время).
Всё это будет шатать команду изнутри. Подобные проблемы могут возникать даже в крупных коллективах, где список рабочих вопросов более-менее повторяется с какой-то периодичностью.
Решения могу предложить два:
1. Сделать систему более гибкой, чтобы она могла быстро приспосабливаться к изменению специфики и списка задач.
2. Нанять грамотного руководителя, который сможет за счёт своего опыта лично решать вопросы, связанные с мотивацией, более точно и уместно.
Не стоит полагаться и передавать всю ответственность по учёту выполненных задач на одного человека, какой бы он ни был хороший работник. Человеческий фактор в любом случае будет иметь место, иногда — с неприятными последствиями.
ncix
Я пожалуй продулирую свой старый комментарий к похожей истории
ApeCoder
О вреде премирования
maslyaev
Расскажите, как вы считаете KPI, и я расскажу, от чего сдохнет ваша контора.
(Это я не про конкретно ваш кейс. Эту фразу я произношу каждый раз, когда заходит разговор про KPI)
Человеческую деятельность невозможно выразить скалярной величиной. Ничью. Ни деятельность уборщицы, ни деятельность продавщицы, ни комбайнёра, ни таксиста, ни как в нашем случае программиста. Понять это невозможно, поэтому предлагается просто запомнить. Если одним единственным скаляром невозможно выразить такую банальную штуку как вектор на плоскости (потому что нужно два скаляра), то как вообще людям приходит в голову этой штукой выражать деятельность живого человека, бесконечную в своём многообразии вариантов и последствий?
Какую формулу ни высосать из пальца, при столкновении с реальностью окажется, что:
а). Есть такие, чья работа хуже ядерной войны, но по формальному критерию они в шоколаде.
б). И такие, на ком всё держится, но по формуле они хоть тоже в коричневом, но запах не тот.
Игра в формализованный KPI — чёткий сигнал сотрудникам, что их задача теперь не выпуск суперского продукта и не удовлетворённость заказчиков, а вот эта циферка. Есть типажи, на которых такая подмена цели не сказывается никак (они всё равно всю дорогу работали исключительно ради денег), но всю остальную публику такие вещи мощно дезориентируют.
Goury
Угу.
И самое главное тут то, что хорошие программисты обязательно являются очень умными личностями.
Именно поэтому никакие измерения показателей хороших программистов ни к чему хорошему привести не могут в принципе.
Мораль: за хорошую работу программисту надо зарплату назначать адекватную.
А премии надо давать в виде доли в компании за изобретательскую деятельность.
maslyaev
Типа того. Просто и без этих замороченных манагерских глупостей.
zloddey
Очередная система де-мотивации разработчиков. Добавлю к изложенной выше критике один очень важный момент.
Все подобные системы KPI измеряют "производительность" каждого разработчика индивидуально. А между тем, разработка софта, особенно по гибким методологиям, — это командная работа. Каждый член команды должен знать, что его действия будут поощряться, если они направлены на достижение общего успеха.
А теперь представим программиста, который взял себе задачу на день, но вместо работы над ней был вынужден большую часть дня помогать другим коллегам. У одного сложный баг вылез, и надо подумать в две головы, другой попросил код отревьювить, третьему нужна консультация по архитектуре системы,… и т.п. Помогал ли программист своей команде достичь общей цели? Да. Скажется ли это положительно на его KPI? Нет. По предложенной табличке выходит, что он целый день гонял балду.
Вот таким индивидуальным KPI вы ставите своих разработчиков перед дилеммой: или они получают "хорошую оценку", или делают правильное дело. Возможен только один вариант из двух! Если он выбирает оценку, то помощи команде от него будет мало. Если выбирает "правильное дело", то будет постоянно демотивирован своей незаслуженно низкой оценкой.
То есть, вы собственноручно гробите командный дух. Лучше всего будет прекратить баловаться с KPI и сфокусироваться на том, что более важно, — бизнес-целях и метриках.
ggo
Тут многие высказывают недовольство таким подходом по стимулированию (назовем это так) ит-персонала.
Организации, как и любые другие субъекты, проходят по своему жизненному циклу.
Где-то вначале своего пути, они маленькие (не в смысле роста, а в смысле развития) и незрелые. Ближе к концу, они матерые и ответственные.
На каждом этапе работает свои методы и подходы, и не работают другие.
Точно также как с человеком. Глупо мотивировать 5-летнего ребенка аналогично тому, как 40-летнего мужика.
В начале своего пути, организация может мотивировать людей упомянутым выше способом. И это реально работает. И работает хорошо.
Потом, когда организация нарастит мышцы (опять же, в смысле своего развития), поймет что лучше мотивировать через результат. Но это будет потом.
CalltouchForever Автор
Все так, давний холивар. KPI – это один из инструментов для отражения развития, достижений и слабых сторон сотрудников, которые можно/нужно подтянуть. Использовать это исключительно как рабочий инструмент руководителя или же раскрыть карты или привязать к нему премиальную составляющую или часть ЗП — все тот же холиварный вопрос.
Кому-то важен результат, кому то процесс. Результат всегда можно измерить и для уборщиц, и для продавцов, и для программистов. Есть люди радеющие за результат, есть наслаждающиеся процессом. Процесс измерить сложно и не нужно, ибо сам по себе процесс без результата бизнесу не интересен.
Не всем комфортно работать в условиях открытости и прозрачности, факт. Большинство, подчеркну, большинство больших девелоперских компаний задействуют подходы оценки эффективности работников, и они успешны на рынке, они не загибаются и туда стоят очереди кандидатов. Это тоже факт.
Нет черного и белого, есть золотая середина.
zloddey
Многие, если не большинство, знаменитых рок-музыкантов долгое время употребляли наркотики, и это не мешало им выпускать популярные альбомы и зарабатывать миллионы долларов. Посмотрите на роллингов — эти проспиртованные обнюханные старикашки до сих пор готовы задать перцу! Их опыту не желаете последовать?
CalltouchForever Автор
Вы акцентируете внимание на деталях, вытянутых из общей картины. Но аллегория интересная.
Для достижения успеха вообще часто приходится чем-то жертвовать. Если их все устраивает, устраивает их поклонников, при этом они достигли большого успеха, почему нет? Я не думаю, что они сильно расстраиваются от осознания, что некоторая группа публики считает их обдолбанными старикашками.
Продолжая образ, есть альтернативный вариант. Можно поигрывать для души раз в неделю на репетиционной базе, периодически концертируя в местном рок-клубе. Вот вырисовывается разница между результатом и процессом.
Уж куда более творческая профессия, нежели музыкант. Но Вы ее сами измерили — в проданных пластинках, заработанных деньгах и признании. Командная работа у Роллингов? Конечно. Менялся состав с годами? Конечно. Мы и каждого музыканта измерим — в умении держать ровно 16 на скорости 200, нежелании участвовать в алко/нарко-оргиях и т.д.