Мотивация IT-персонала — шаг за шагом
Как устроена оплата труда разработчиков в digital-агентстве «Атвинта». Выступление с конференции «Стачка-2017».
Дата публикации: 30.08.2017
Весной в Ульяновске прошла международная IT-конференция «Стачка-2017». В мероприятии принял участие исполнительный директор digital-агентства «Атвинта» Илья Горбаров, который рассказал, как устроена оплата труда разработчиков в компании.
Intro
Тема мотивации непростая. Разобраться в чужом опыте непросто. В рамках одного материала невозможно отразить все нюансы и тонкости. Но, прежде всего, помните, что система — это свод правил. А то, как эти правила будут выполняться, зависит от конкретных людей, традиций вашей компании и корпоративной культуры.
На данный момент схема внедрена в телекоммуникационном холдинге Good Line, где по ней работает 40 разработчиков и у нас в агентстве, где по данной схеме работает 10 разработчиков. С внедрения системы прошло уже почти 4 года, могу сказать, что она себя хорошо зарекомендовала и именно поэтому хочу поделиться с вами нашим опытом.
С чего всё началось?
Мы считаем, что мотивация — это простые и понятные правила игры. Мы хотели увеличить рентабельность, получить прозрачную схему оплаты труда сотрудников и очевидные перспективы роста и развития для людей. Мы показали и объяснили сотрудникам, по каким правилам мы предлагаем играть.
Во-первых, обозначили перспективы роста — карьерного и зарплатного. Разберём кратко два существующих похода.
-
Фиксированный оклад
Плюсы: стабильность (человек знает, сколько он получит в этом месяце и в следующем), но этот плюс со временем вырождается, так как сотрудник не знает, как повлиять на рост своей зарплаты. Премия может быть или не быть, и в одном месяце человек может быть в числе премируемых, а потом на полгода — нет.
-
Оплата по часам
Плюсы: прозрачность и возможность влиять на свой доход, но эта схема имеет и минусы. Во-первых, она сложна для понимания сотрудников, её сложнее считать в конце месяца, а также на этапе внедрения кажется, что она будет нестабильной и человек не сможет спрогнозировать свой доход.
Очень важно отметить, что любая система с прописанными правилами «хакается» особенно одарёнными сотрудниками в течение одного-двух месяцев, поэтому первое время её нужно изменять и доводить до ума.
Предлагаю решить небольшую задачку на знание особенностей разработки.
Задача
Сколько времени он потратил фактически на работу?
Ответ белым шрифтом выделите, чтобы узнать: 4–6 часов, при условии, что он не занимается ерундой, а действительно работает.
Несколько лет назад нам стало интересно сколько же программист на самом деле на работе работает: пишет код, придумывает алгоритмы, ищет решения в интернете. Мы поставили таймеры себе на компьютеры, и останавливали его, когда тупим в чате, читаем ленту новостей, курим, пьем кофе или залипаем на Хабре не по делу. Наши замеры показали четыре часа в день, но если очень постараться — выходило 6 часов.
Исходя из этого мы сформулировали следующие постулаты на которых строиться система мотивации?
-
Около шести часов продуктивного рабочего времени
-
Час на собрания, обсуждения, рабочие группы
-
Час на лень, перекуры и перекусы
-
Час на обед
Итого: 9 часов (с 9:00 до 18:00)
Больше, как ни старайся, разработчик работать не может, кроме жёстких факапов, когда он получает внутривенную капельницу из кофе.
Нельзя управлять тем, что нельзя измерить
Мы попросили наших разработчиков вести и отмечать время, ввели два понятия: плановые и фактические часы. Когда проект заходит, мы отмечаем плановые часы — например, 100 часов на разработку. Потом считаются фактические часы — то время, что разработчик потратил по факту (может быть 120 часов), но мы оплачиваем только плановые.
Возможна и другая ситуация: опытный разработчик делает быстрее, например за 80 часов. Оплату он получает все-равно по плановым часам, это стоит запомнить, позже об этом ещё пойдёт речь.
Из чего складывает зарплата в «Атвинте»?
-
Сама оплата
Зарплата также зависит от левела разработчика — у нас он от 3 до 20 (на текущий момент максимальный — 16) и количества плановых часов, которые разработчик отработал. Как считается цена планового часа — левел х 25 рублей, то есть если у разработчика 10 левел, его час стоит 250 рублей.
Примечание: 20 левел не является потолком, просто до него еще никто не дорос.
Есть условия для поднятия левела: условное — отработать 140 часов ежемесячно в течение трёх месяцев без просрочки задач, безусловное — левел растет каждые полгода при соблюдении простого условия — не косячить.
Это два разных подхода. Мы используем первый, в холдинге используют второй. После внедрения системы для дополнительной мотивации левел мог расти сначала каждый месяц на протяжении трех месяцев, потом раз в три месяца на протяжении полугода, затем раз в полгода.
Прирост левела проходит на мероприятии «level up», на котором собираются все разработчики и руководители вручают брендированные футболки с номером нового взятого левела.
-
Премия при закрытии проекта
В любом проекте премиальный фонд составляет 10% от его цены. Если проект рентабельный, то 30% получает менеджер проекта, оставшиеся 70% делятся между командой проекта. На рентабельности всё завязано, чтобы у проект-менеджеров была дополнительная мотивация.
-
Если рентабельность проекта 30% и выше — примерный премиальный фонд составляет 10%
-
Если меньше 20% рентабельность — он начинает снижаться, при этом премия менедежера начинает также снижаться, премия команды, напротив, увеличивается.
Коэффициенты
После завершения проекта всегда проходит ретроспектива, на которой проджект оглашает команде кто, по его мнению, внёс больший вклад в работу:
Примечание: Ответственность проект-менеджера за рентабельность проекта положительно повлияло на рентабельность и на понимание менеджером финансовых процессов, стоящих за работой команды.
Оценка проектов
Самое сложное — это оценка проектов. Для себя мы выбрали три варианта, как это делать:
-
На основе истории — если подобный проект уже выполнялся, то известно, как его делать. Известно время выполнения работ над каждой частью проекта. Для сайтов, все блоки вынесены в таблицу, итоговая стоимость складывается из цен блоков.
-
Экспертная оценка техлида — для проектов средней сложности, но чем сложнее проект, тем более велика вероятность, что оценка техлида может быть ошибочной, тогда применяется
-
Планинг-покер — собирается команда, заказчик и руководитель проекта, команда медитирует на декомпозицию и ТЗ, задают вопросы. В итоге для каждого этапа ставится задача в часах. Максимальный размер оцениваемой задачи стараемся делать не выше 30–40 часов, иначе риск пролететь с оценкой возрастает.
-
Ещё один вариант оценки, который мы пока не пробовали, но ничего не мешает вам это сделать — на основе велосити команды для сторипоинтов. Если вы понимаете, о чем я. ;)
Этапы работы
Основная боль аутсорс разработки — ошибка в оценке. Низкая оценка приводит к убыткам, завышенная — отталкивает клиентов. Одно дело оценить типовой проект, совсем другое — сложный веб-сервис или систему автоматизации.
Как оценивает команда, мы разобрали чуть выше. Главное, быть последовательным и не оценивать сложные проекты методом экспертной оценки директором «надо уложиться в 450.000 рублей», а простые не отдавать на оценку джунам.
Через боль и страдания мы пришли к двухэтапной схеме работы над проектами.
На входе мы можем грубо оценить проект и дать клиенту вилку минимальной и максимальной цены.
После чего мы заключаем договор и берем предоплату за первый этап, в котором:
-
Собираем аналитику
-
Пишем ТЗ
-
Делаем прототипы
-
Рисуем дизайн-концепцию.
После этого мы спокойно можем оценить командой проект уже более-менее точно, зафиксировать цену договора и приступить к работам второго этапа:
Другие специалисты
Схема мотивации отлично себя зарекомендовала и для других специальностей в нашей компании.
Плюсы и минусы внедрения такой системы
Минусы:
-
Если вы решите подобную систему внедрять, сложно преодолеть сопротивление команды, идею нужно «продать» и объяснить, что меньше никто получать не будет.
-
Будет масса негатива, и первые полгода надо регулярно встречаться и обсуждать все вопросы.
Плюсы:
-
Возможность влиять на свой доход.
-
Взрослые и опытные сотрудники начинают работать больше, чтобы заработать больше.
-
Сотрудники заинтересованы отмечать отработанные часы, руководители получают статистику, которая весьма любопытна.
-
Качество работы не падает, так как есть код ревью и подзатыльник тимлида.
-
Инфантильные лентяи, которые пишут плохой код — уходят сами. Руководители проектов, просто не хотят брать к себе в команду таких персонажей.
Не плюс и не минус:
Появляются сознательные граждане, которые «слишком много работают». Есть случаи выработки разработчиком 200 плановых часов несколько месяцев подряд. Плохо это их хорошо — решать вам. Просто имейте в виду, что мотивация может мотивировать людей работать больше.
Мифы и грабли, с которыми мы сталкивались
Миф первый — автоматизация экономит время.
На самом деле времени тратится больше, но взамен вы получите управляемость и масштабируемость в будущем. Да, теряется гибкость, но появляется предсказуемость.
Миф второй — разработчики разберутся.
Все задачи «пилят» по 4–8 часов, на несколько дней вперед. Мы считали, что разработчики сами решат, что брать, а мы их будем пинать, если будет что-то срочное. На самом деле разработчики брали самые быстрые и простые задачи. Поэтому ежедневно дежурный проджект-менеджер или менеджер текущего проекта сам ставит приоритетные задачи каждому разработчику.
Миф третий — шумному клиенту задачи делаются быстрее.
Если клиент постоянно звонит, что-то требует, поднимает панику и донимает менеджера, то хочется поскорее закончить с ним работу.
На самом деле приоритет не всегда может быть нужен этому проекту, поэтому раз в неделю проходит собрание менеджеров, которые обсуждают текущие проекты. В проектный офис заносится информация, это требует больше бюрократии, но это улучшает управляемость. Также менеджеры встречаются с руководством, обсуждаются приоритетные проекты.
Ставить приоритеты — значит управлять проектом
Не всегда дежурные менеджер видит приоритеты задач, а когда они свалены в кучу, то первыми будут выполнены самые простые или самые «горячие». Чтобы этого не случилось, приоритет определяет руководитель, а не количество шума от заказчика.
Инструменты и процессы
Jira — постановка задач и учёт времени
Ежедневные планёрки с разработчиками
Еженедельные планёрки с проджектами
Load — надстройка над Jira для планёрок
Гантик — планирование в будущее
Предпроектный комитет и проектный комитет — контроль старта и окончания проекта
Ретроспектива — крафтим опыт для всей команды
Нюансы:
-
Баги или косяки в коде — за свой счёт или 50% времени
-
Информирование команды об оставшемся сроке проекта
-
Новички первое время не выполняют норму
-
Чёткие правила расширения задач
-
Чёткие правила, где оплачиваемая задача, а где нет
-
Бюджет на правки вне проектного времени
Кроме системы мотивации, завязанной на деньги, мы мотивируем сотрудников другими способами:
-
Бонусы тому, кто больше всех отработал в месяц (новые мониторы, кресла, какие-то гаджеты);
-
Саммари (собирается команда, мы рассказываем, какие проекты были сделаны, закрыты, какие показатели достигнуты — помогает выпустить пар в формате мини-стендапа);
-
Тимбилдинг;
Применимость
-
Простые проекты — заходит отлично.
-
Сложные проекты — есть нюансы, связанные с тем, что необходима грамотная оценка «на берегу».
-
Продуктовая разработка на стадии «стартап» — совершенно не подходит, так как нужен фиксированный оклад. Нужна вовлеченность каждого и желание сделать продукт лучше, даже если из 10 попыток только 2 будут успешными. Нужно мотивировать на процесс, а не на результат.
Зачем это собственникам?
Мотивация — основа материальной модели компании, которую можно посчитать математически. Эта модель нужна для того, чтобы понимать, как влиять на показатели. Мотивация — это надолго, это позволяет привлекать интересующихся, брать лучших и всегда держать их в тонусе.
Итоги
-
Производительность и рост разработки
-
Увеличение рентабельности бизнеса
-
Прозрачные показатели выработки
PS: После прочтения материала, комментаторы делятся на два лагеря: разработчики, у которых пригорело которых статья задела за живое и управленцы. Бурная реакция разработчиков объяснима. Когда мы внедряли данную схему мотивации три с половиной года назад, нам задавали те же вопросы, были те же страхи и вообще сопротивление изменениям — неотъемлемая часть человеческой психики.
Многие комментаторы, заявляя, что «это похоже на каторгу» или «все хорошо, пока не прибежит менеджер и не попросит внести правочки, которые становятся большими», на самом деле транслируют свои боли. И пытаются «скомпилировать» систему с неправильными исходными данными.
Описанная система, да и вообще, никакая формально описанная система не раскрывает на 100% ситуацию в компании. Разные люди в одной и той же ситуации ведут себя по-разному.
Это называется культура, корпоративная культура, если можно так сказать. Поэтому, если у одних сидят инфантильные разработчики, которые костыляют, просто потому, что им лень думать и брать ответственность, а тестеры авось не заметят — это одно. А если у вас спецы, которые хотят сделать крутой проект — тестировщик потом находит крайне мало серьезных багов.
Тоже самое с менеджерами, которые прибегают и просят. Если менеджер малодушно просит втиснуть в проект маааленькую фишечку, а по ходу пьесы она становится огромной, и делает он это потому, что так проще — это плохой менеджер. Хороший менеджер при изменении скоупа или продает изменения заказчику, или почетно делегирует это аккаунту.
И все это происходит в том случае, когда нет ощущения командной работы, когда нет понимания, что проект — это результат работы всей команды. А не «я нормально нарисовал, это фронты просрали половину». Если ты нормально нарисовал — добейся того, чтобы это было реализовано так, как ты задумал. Не можешь сам — попроси менеджера, не можете с менеджером этого добиться — поставь в известность руководство.
Только синергия культуры и зафиксированных правил (назовем это мотивацией) позволяют достигать результата.
Поэтому если вы примеряете чужую мотивацию на себя, и у вас рождаются страшные образы в голове, то дело не в мотивации, а в том, что она в вашей культуре не приживется.
Комментарий: Владимир Тупоршин, генеральный директор Webasyst
|
|
Что мы только ни пробовали: премии за быстрый и качественный результат, повышение зарплаты, дополнительные дни к отпуску, интересные командировки… Ничего не работает! Сотрудники работают одинаково хорошо, посулишь ты им «мотивацию» или нет. Плохо работающих у нас в принципе нет. Команда маленькая, и все на виду. Будешь плохо работать, заметят сразу; и сам плохо работающий заметит тоже. Ему станет некомфортно, и он уйдёт. К слову сказать, за двадцать пять лет нашего бизнеса было совсем немного подобных случаев. Плохо работающих мы обычно отбраковывали сразу, на этапе приема на работу. Редкие «неудачные» кадры, которые всё-таки проходили собеседование, уходили в первый же месяц испытательного срока. А остальные, хорошо работающие, которые оставались на годы, были, видимо, в достаточной степени мотивированы предложенными условиями работы, и им большего было не надо. От каждого по способностям — каждому по условиям трудового договора! Спокойная, почти домашняя обстановка в офисе, общение на равных со всеми членами команды, отсутствие формальной иерархии «начальник—подчинённый», свободное расписание работы, стабильная зарплата, талоны в столовку, чай-кофе бесплатно, умиротворение и благодушие — сказка, а не работа! Человек, которому нужно больше, долго на такой работе не продержится. Слишком стабильно и слишком хорошо. Буквально так и сказал один из наших бывших сотрудников, придя недавно к нам в офис погостить. Он проработал у нас в своё время четыре года и сделал очень много для компании. Но он по натуре предприниматель, и его амбиции выходили далеко за рамки того, что мы могли ему предложить. Сейчас у него своё дело, и он зарабатывает гораздо больше, чем когда-то у нас. Большинство же людей удовлетворяются тем, что имеют, особенно в среде технарей и программистов. Таких людей интересная и творческая работа сама по себе уже настолько мотивирует, что им не нужны дополнительные финансовые мотивы («Что, за это ещё и деньги будут платить?!»). Ты им только подавай задачи поинтереснее, и они будут их с удовольствием решать, порой забывая о времени и пище. Процент предпринимателей в обществе невелик. И сколько таких ни мотивируй финансово, им всё будет мало — в хорошем смысле слова. Они рождены, чтобы сделать в этой жизни большее. И они обязательно уйдут это большее делать. Поэтому принимайте на работу творческих и спокойных людей, которые любят делать то, что вы им предлагаете. Ищите людей без лишних амбиций, не-предпринимателей. Предлагайте им постоянно новые и интересные задачи. Платите им стабильную зарплату, среднюю или немного выше средней в вашей индустрии. И такие сотрудники будут работать хорошо и долго. А если вы будете платить им премии или постоянно предлагать повышение зарплаты, то это мало повлияет на их производственную эффективность. |
Комментарий: Константин Нефедов, управляющий партнер digital-агентства «ДАЛЕЕ»
|
|
У меня достаточно большой бэкграунд работы в коммерческих отделах крупных интернет-компаний (Рамблер, ВИ, афиша, РБК) поэтому, мне всегда хотелось применить линейную шкалу мотивации, которая завесила бы от выполнения личного плана, и планов группы и/или компании. Лет 10 назад я вывел следующую верхнеуровневую формулу систем мотивации персонала, относящегося к продажам:
Однако, в последствии, работая в продакщне и агентском бизнесе я понял, что все мои наработки не годятся, так как люди постоянно перерабатывают. Так уж устроен агентский бизнес. Программисты в свою очередь наиболее эффективны, когда они увлечены и погружены целиком в задачу. Соответственно, нам необходима больше мотивационная стратегия, благодаря которой люди были бы максимально самомотивированы. Что у нас сейчас получается на самом деле:
Относительно того, что я увидел в статье, мне понравилась идея премиального фонда от проекта. Думаю, когда-нибудь мы это попробуем. Но в тоже время я не согласен с тем, что компания должна мотивировать сотрудника в зависимости от его чистого времени. Я считаю, что задача компании заключается в том, чтобы обеспечить максимальную утилизацию рабочего времени сотрудников. |
Комментарий: Кирилл Чистобородов, генеральный директор MINISOL
|
|
Мы стараемся в качестве мотивации финансовую составляющую свести к минимуму. В статье есть ответ на вопрос «как сделать так, чтобы люди работали больше», а меня всегда интересовал ответ на вопрос «как сделать так, чтобы люди работали лучше». Лучше для бизнеса — это эффективнее. Больше работы за то же время, либо, что более ценно — повышение качества и сложности работы без увеличения затрачиваемого времени. Да и в целом у меня другой подход. У нас 15 человек — это не корпорация с вертикалью власти и регламентами на каждое движение, у нас другой мир. У нас рыночные ЗП и люди, которых надо уговаривать или тем более заставлять работать у нас не приживаются. Сама работа должна мотивировать человека, а деньги должны быть справедливой оценкой результатов труда. Мир розовый, но у нас так. При этом мы используем почасовую схему оплаты с 2009 года, но я точно знаю, что как только это становится не схемой расчетов, а схемой мотивации, наши пути с человеком расходятся. Я был свидетелем как работа превращалась в гонку за часами с падением качества и сомнительным обоснованием часов — это особенно видно при сравнении, как людей на почасовки между собой, так и людей на почасовки и на окладе. Наши разработчки на окладе отмечают в среднем 120 часов чистого времени в месяц, то есть 5–6 часов в день. При этом в офисе находятся стандартные 9 часов. И когда появляется новый удаленщик и отмечает 12 часов за день, то невольно возникают вопросы. Равно как и 200 отмеченных часов — это 9 часов при 22 рабочих днях. Так можно отработать месяц, но дальше будет падение производительности и качества, человек не робот. Однако, стоит оговориться — в статье говорится про максимальный 16 левел и 25 рублей за левел, то есть 400 руб/час и при средней выработке 6 часов в день это 48 000 рублей для топового разработчика. У нас зарплаты совсем другие, возможно поэтому и с мотивацией все хорошо. |
Комментарий: Василий Вишняков, генеральный директор интернет-агентства Bquadro
|
|
В нашей системе мотивации мы придерживаемся классической схемы, при которой оплата делится на две части: собственно оклад и бонус за выполнение установленных показателей. У части сотрудников оплата зависит от достигнутых KPI, у кого-то есть только оклад. Ко второй группе относятся, например, дизайнеры и разработчики. Система мотивации периодически претерпевает изменения. Это связано с двумя факторами:
В целом система мотивации у нас действует уже более 10 лет. За эти годы я сделал вывод, что хорошую систему мотивации разработать можно. Но! Есть люди, которые не подчинятся мотивации, т. е. мотивация их не мотивирует. Зачастую результатом этого является обычная лень. Есть другая группа людей, которые в силу своих психологических особенностей не способны понять мотивацию. Он готовы добросовестно выполнять свою работу, но за определённый оклад, отражающий их вклад в развитие компании. В том числе именно поэтому часто у руководителей верхнего звена мотивационный процент бывает небольшим. |
Полный текст статьи читайте на CMS Magazine