Введение системы мотивации для ИТ-персонала — опыт компании «Атвинта» Статьи редакции

Исполнительный директор digital-агентства Илья Горбаров об устройстве и результатах новой схемы оплаты труда для разработчиков.

Илья Горбаров, исполнительный директор digital-агентства «Атвинта»

С чего всё началось

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

Во-первых, обозначили перспективы роста — карьерного и зарплатного. Кратко разберём два существующих похода.

  • Фиксированный оклад. Плюсы: стабильность (человек знает, сколько он получит в этом месяце и в следующем). Но этот плюс со временем вырождается, так как сотрудник не понимает, как повлиять на рост своей зарплаты.
  • Оплата по часам. Плюсы: прозрачность и возможность влиять на свой доход. Но эта схема имеет и минусы: она сложна для понимания сотрудников, её труднее считать в конце месяца, а также на этапе внедрения кажется, что она будет нестабильной, из-за чего сотрудник не сможет спрогнозировать свой доход.

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

Задача

  • Разработчик приходит на работу к 9:00.
  • Уходит домой в 18:00.
  • Обедает один час.

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

Из каких условий мы исходим, внедряя систему мотивации:

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

Итого: девять часов (с 9:00 до 18:00). Больше, как ни старайся, разработчик работать не может (не считая условий жёстких дедлайнов, когда он получает внутривенную капельницу из кофе).

Нельзя управлять тем, что нельзя измерить

Мы попросили наших разработчиков вести календарь и отмечать рабочее время, для этого ввели два понятия: плановые и фактические часы. Когда появляется проект, мы отмечаем плановые часы — например, 100 часов на разработку. Потом считаются фактические часы — то время, которое разработчик в действительности потратил (может быть, 120 часов). Однако оплачиваем мы только плановые часы.

Из чего складывается оплата в «Атвинте»

Зарплата

Зарплата зависит от уровня разработчика (у нас они от 3 до 20) и количества плановых часов, которые он отработал. Для подсчёта цены планового часа номер уровня умножается на 25 рублей. То есть один час разработчика десятого уровня стоит 250 рублей.

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

Премия при закрытии проекта

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

  • Если рентабельность проекта 30% и выше — примерный премиальный фонд составляет 10%.

  • Если рентабельность ниже 20% — он начинает снижаться. При этом премия менеджера тоже уменьшается, а премия команды, напротив — увеличивается.

Коэффициенты

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

Самое сложное — это оценка проектов. Для себя мы выбрали три варианта, как её провести:

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

Этапы работы

  • Техзадание, прототипы, дизайн-концепция, оценка техзадания — клиент получает точную стоимость за выполнение первого этапа и «вилку» для второго (минимум и максимум).
  • Оценка проекта.
  • Дизайн, вёрстка, программирование, тестирование, наполнение, релиз, ретроспектива.

Другие специалисты

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

Плюсы и минусы внедрения системы мотивации

Минусы:

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

Плюсы:

  • Возможность влиять на свой доход.
  • Взрослые и опытные сотрудники начинают работать усерднее, чтобы больше заработать.
  • Сотрудники заинтересованы отмечать отработанные часы, руководители при этом получают соответствующую статистику.
  • Качество работы не падает.
  • Ленивые уходят сами.

Мифы, с которыми мы столкнулись

1. Автоматизация экономит время

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

2. Разработчики сами разберутся, что делать

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

3. Для «шумных» клиентов задачи выполняются быстрее

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

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

Инструменты и процессы

  • Jira для постановки задач и учёта времени.
  • Ежедневные планёрки с разработчиками.
  • Еженедельные планёрки с менеджерами проектов.
  • Load-надстройка над Jira для планёрок.
  • «Канбан» — контроль строков и рентабельности.
  • Ganttic — планирование в будущее.
  • MPS в связке с Jira Connector.
  • ППК и ПК — контроль старта.
  • Ретроспектива.

Нюансы:

  • Исправление багов и недочётов в коде проводится либо за свой счёт, либо в зачёт идёт только 50% потраченного времени.
  • ​Важно информировать команду об оставшемся сроке проекта.
  • Нужно быть готовым к тому, что новички первое время не выполняют норму.
  • Важно обговорить чёткие правила о том, какие задачи оплачиваются, а какие — нет.
  • Бюджет на правки должен закладываться вне проектного времени.

Другие способы мотивации:

  • Бонусы для того, кто больше всех отработал в месяц (новые мониторы, кресла, технические устройства).
  • Обсуждение. Мы собираем команду и рассказываем, какие проекты были сделаны, какие показатели достигнуты. Это помогает всем выпустить накопившийся пар в формате мини-выступлений.
  • Тимбилдинг.

Применимость системы мотивации

  • Отлично подходит для простых проектов.
  • Для сложных проектов есть нюансы, связанные с тем, что необходима грамотная оценка «на берегу».
  • Совершенно не подходит для продуктовой разработки, так как здесь нужен фиксированный оклад. Продукт получит больше денег, если команда предложит больше гипотез. Мотивация в этом случае нужна другая.

Зачем это собственникам

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

Итоги:

  • Повышение производительности и рост разработки.
  • Увеличение рентабельности бизнеса.
  • Прозрачные показатели выработки.
0
38 комментариев
Написать комментарий...
Алексей Сетямин

"Исправление багов и недочётов в коде проводится либо за свой счёт, либо в зачёт идёт только 50% потраченного времени."- Что мы хотим: Разрабы делают чистый код без багов. Что получаем: баг на баге и багом прогоняет + вражда разрабов с тестерам, т.к. каждый найденный баг это жирный минус к ЗП

Ответить
Развернуть ветку
Илья Горбаров

Печально, что у вас сложилась такая ситуация в компании )

У нас — не так.

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

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

За 3 года после внедрения описанной системы, ничего из описанного не случилось. Потому, что есть команда, есть тимлид и "взрослые" разработчики, которые понимают, что писать плохо — хуже для компании и себе дороже.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Serge Arsentiev

А может раньше у них расстреливали худшего работника месяца ...

Ответить
Развернуть ветку
Илья Горбаров

Комментарии от разработчиков доставляют особое удовольствие читать.

Передам нашим ребятам, благодаря которым мы входим в 0.1% лучших компаний отрасли по рейтингу Теглайн и Ruward.

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

Ответить
Развернуть ветку
AS

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

Ответить
Развернуть ветку
Serge Arsentiev

"Волк с Уолл-стрит" задал недопустимо высокий стандарт корпоративного релакса, которого никакой IT компании никогда не достичь :(

Наложниц они обещать могут, но это будет как "девушки с обложек глянцевых журналов, которые вот-вот снимут трусы, но никогда не снимают"

Ответить
Развернуть ветку
Igor Erokhin
Когда появляется проект, мы отмечаем плановые часы — например, 100 часов на разработку. Потом считаются фактические часы — то время, которое разработчик в действительности потратил (может быть, 120 часов). Однако оплачиваем мы только плановые часы.

Ну это вообще пушка.

Ответить
Развернуть ветку
Sergey Denisov

Ага, а потом и баги за свой счёт исправлять ещё)).

Ответить
Развернуть ветку
Илья Горбаров

Я понимаю, что всем хочется максимизировать качество жизни и минимализировать при этом затраты своих ресурсов.

Но так не бывает. Есть некоторая медиана, джун делает проект дольше, тратит на него больше времени и учится. Сеньйор делает это быстрее.

Не надо забывать, что если проект сделали за 80 часов, заплатим все равно за 100.

Ответить
Развернуть ветку
Andrey Kuzmin

Перечитал вас, посмотрел повнимательней чем именно вы занимаетесь, и в принципе стало понятней, что именно вызывает в вашей статье зуд. У вас проекты, которые проще эстимейтятся, работа лучше формализуется с более явными KPI и прямо скажем требуемый технический уровень для её выполнения не high end, соответственно и требования к людям проще => легче с заполнением вакансий. Столкнись ваши программисты с работой, где точный эстимейтинг невозможен по определению самой работы, плюс уровень входа в проект 2-3 месяца минимум из-за большой базы легаси и бизнеса - картинка была бы кардинально другая.

Ответить
Развернуть ветку
Николай Давыдов

" Для подсчёта цены планового часа номер уровня умножается на 25 рублей" - т.е. максимальная часовая ставка(если не брать коэффициенты, которые ИМХО в 80% случаев будут понижающими) 500р или около 8 долларов? Аттракцион невиданной щедрости! :)

"Бонусы для того, кто больше всех отработал в месяц (новые мониторы, кресла, технические устройства)." - т.е. нормальные рабочие инструменты вы даете только "передовикам производства"?

Ответить
Развернуть ветку
Илья Горбаров

Если вам бы при такой системе понижали — это не значит, что у нас понижают )

Уровень зарплаты разный в разных городах нашей страны.

Премии составляют до 100% средней ЗП в месяц.

Ответить
Развернуть ветку
Andrey Kuzmin

Ждём через 2 года бодрого доклада, что из этой охинеи выжило и какая текучка в компании.

Ответить
Развернуть ветку
Илья Горбаров

После внедрения описанной системы прошло 3 года, передаем привет. Полет нормальный.

Средний срок работы разработчиков у нас в компании 3.5 года. А у вас какой?

Большинство людей, примерно 80%, которые от нас уходят — делают это в связи с переездом в другой город, а не по какой либо другой, воображаемой вами причине )

Ответить
Развернуть ветку
Олег Дергилёв

Потогонка детектед

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Илья Горбаров

Много комментаторов почему-то транслируют свои боли, кто вам сказал, что они у нас с вами одинаковые?

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

Поймите простую мысль, что описанная система, да и вообще никакая формально описанная система не описывает на 100% ситуацию в компании. Разные люди в одной и той же ситуации ведут себя по разному.

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

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

И все это происходит в том случае, когда нет ощущения командной работы, когда нет понимания, что проект — это результат работы всей команды. А не "я нормально нарисовал, это фронты просрали половину". Если ты нормально нарисовал — добейся того, чтобы это было реализовано так как ты задумал. Не можешь сам — попроси менеджера, не можете с менеджером этого добиться — поставь в известность руководство.

Только синергия культуры и зафиксированных правил (назовем это мотивацией) — позволяют достигать результата.

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

А у нас она действует уже 3 года. И единственная "проблема" — это люди которые слишком много работают. Но это показатель мотивации и серьезного отношения к жизни. Если вы хотите мало платить, но чтобы все работали много — может быть каторга у вас?

Ответить
Развернуть ветку
робот Вертер

Кстати 6 часов - это оооочень много, урежьте осетра до 4 часов - будет самое оно

Ответить
Развернуть ветку
робот Вертер

Знаю одну известную контору, где от почасовой зп сотрудникам отказались так как спецы стали стараться работать сверхурочно и по выходным и у них стала "слишком высокая" зарплата ))

Ответить
Развернуть ветку
Konstantin Kiselev

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

Ответить
Развернуть ветку
Кирилл Фим

как только неучи не измываются над специалистами
надо срочно гуглу/майкрософту/эплу предложить такую стратегию

Ответить
Развернуть ветку
Saint_Byte

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

Ответить
Развернуть ветку
Илья Горбаров

Я сам долгое время программировал, когда хочется — можно и 10 часов в день. Зависит от желания, мотивации и задачи, над которой работаешь.

Ответить
Развернуть ветку
Saint_Byte

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

Ответить
Развернуть ветку
Илья Горбаров

Вам виднее.

Ответить
Развернуть ветку
Илья Горбаров

Ответил выше, сразу и на ваш комментарий )

Ответить
Развернуть ветку
Винни Пух

Тоже практикую почасовую оплату с фиксацией времени в коммитах. Но минимальная ставка 500 рублей в час для мидла. А тут выходит максимальная 500 =)

Ответить
Развернуть ветку
Максим Лунин

У вас очень хороший подход. Согласен почти во всем. Когда мы проводили собственный анализ по системе мотивации (https://rovertask.com/ru/blog/management/motivation) - мы тоже обсуждали актуальные проблемы с IT-руководителями. Кардинальных подходов, как мы поняли два - как у вас, гибкая и четкая структура оплат и премий по каждому специалисту, бонусы по итогам месяца и прочее... Либо мотивация, заложенная в самом проекте без четкой систематизации. Где люди работают из-за собственного интереса, без влияния материальных поощрений (да-да, такое есть).

Ответить
Развернуть ветку
Serge Arsentiev

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

Хочешь, сам пили систему, и получай $5 000 в месяц, хочешь привлекай 3-5 программеров и тестеров, как хочешь, так и выкручивайся.

P.S. Система была в те времена, когда $2000 в месяц была запредельно высокой зарплатой, а средняя у квалифицированного программера $500-$800.

P.PS. Система вводила систему единоначалия - бесполезно было входить в особые отношения с HR, или немножко спать с секретаршей генерального, или там быть сыном уважаемого человека - поскольку твою зп определял только руководитель проекта, и он же отвечал перед начальством за его прогресс и отчитывался.

Ответить
Развернуть ветку
Максим Лунин

Интересная история)

Ответить
Развернуть ветку
Илья Горбаров

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

Все правильно говорите. Есть две парадигмы — аутсорс и продуктовая разработка.

В аутсорсе можно устанавливать связь часов и денег, т.к. часы это, по-сути, ваш товар. И можно мотивировать на результат. Чем он лучше, быстрее и качественнее — тем больше можно заплатить за его достижение. Конкуренция среди разработчиков, так же может быть плюсом.

А в продуктовой разработке — это строго противопоказано. Там ценны идеи, предложения, попытки сделать лучше. Зачастую такие попытки заканчиваются неудачей в 7 из 10 случаев. И какая-либо мотивация, заточенная на успех (результат) отобьет желание пробовать. Это смерть для проекта.

Поэтому и выходит, что продуктовая разработка — оплата только за процесс. А в аутсорсе — логичнее платить за результат.

Ответить
Развернуть ветку
Kirill Samogulov

мотивация - вчерашний день, будущее - геймификация

Ответить
Развернуть ветку
Serge Arsentiev

Да хоть гейфикация.

Смысл-то один - вместо денег навешать вымпелов "Ударник кап. труда", дипломов "Лучшая сука породы", и в особо продвинутых компаниях - подарочных сертификатов аффилированных Интернет магазинов.

Ответить
Развернуть ветку
Andrey Harchenko

Каким образом и кем оцениваются К1 (сложность) и К3 (качество)?

Ответить
Развернуть ветку
Илья Горбаров

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

Качество оценивается на основе количества багов, кодревью и рекомендации тимлида.

Ответить
Развернуть ветку
Andrey Harchenko

Спасибо за ответ. Еще один вопрос - если я правильно понял, у вас 100% outsource. Если заказчик, что-то хочет изменить в backlog - возможно-ли это?

Ответить
Развернуть ветку
Александр Иванов

Наверное я хотел бы поработать у Вас, именно в этой схеме(для опыта), но точно не больше 6 месяцев.

Ответить
Развернуть ветку
Илья Горбаров

Аппетит приходит во время еды, пишите на [email protected] ;)

Ответить
Развернуть ветку
Максим Лунин

Хотя, конечно, программисты с опытом и стажем должны получать больше 500 рублей в час)) Это же очевидно))

Ответить
Развернуть ветку
35 комментариев
Раскрывать всегда