{"id":14268,"url":"\/distributions\/14268\/click?bit=1&hash=1e3309842e8b07895e75261917827295839cd5d4d57d48f0ca524f3f535a7946","title":"\u0420\u0430\u0437\u0440\u0435\u0448\u0430\u0442\u044c \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a\u0430\u043c \u0438\u0433\u0440\u0430\u0442\u044c \u043d\u0430 \u0440\u0430\u0431\u043e\u0447\u0435\u043c \u043c\u0435\u0441\u0442\u0435 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f71e1caf-7964-5525-98be-104bb436cb54"}

Можно ли деньгами ускорить работу инженера

Эволюция системы денежной мотивации в отдельно взятой компании за десять лет.

Антон Рядинский и Алексей Стеринович. Мы много лет пытались создать прозрачную справедливую и работающую систему денежной мотивации сотрудников Алексей Стеринович

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

В статье речь пойдёт о системе денежной мотивации сотрудников в разработческой компании. Чтобы был понятен контекст, немного о нас. Мы — это компания Uniscan Research. Мы делаем наукоёмкие приборы массовым продуктом. Нас 60 человек. За год через портфель проектов проходит 30 проектов длинной в один-два месяца и два-три проекта длиной в несколько лет.

Итак, путь эволюции системы премирования.

На дворе 2009 год. Компания состоит из функциональных отделов: конструктора, электронщики, программисты, исследователи, технические писатели. У каждого отдела свой начальник, он же техлид в своей области. Про Agile мы только начинаем что-то слышать, управление портфелем проектов ручное.

Разделение доходов на оклад и премию

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

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

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

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

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

Задумывалось: премии обычно нет, а за хорошую работу она даётся. А получилось: премия есть всегда, а за косяки она отбирается. Отнять премию — это чётко негативное действие, которое большинство начальников делать не станут. Они поругают работника, но не будут выступать в роли палача.

В результате сотрудник перестаёт считать эту премию переменной частью доходов и относится к ней как к части ЗП. То есть она не работает как поощрение и не работает как наказание.

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

Диагноз: это вообще не схема, это сплошной самообман.

Прошёл год. Функциональная структура и ручное управление портфелем сохранились. Но задачи контроля финансового потока через переменную ЗП отошли на второй план. Мы начали думать больше про мотивацию.

Ежегодная премия от директора

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

Главная цель — безопасно для компании повысить средний доход сотрудников. Вторая цель — поощрить сотрудников за хорошо отработанный год.

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

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

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

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

Диагноз: премия приравнена к ЗП, как мотивация не работает.

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

Ежегодный запрос денег начальниками (вариация предыдущей схемы)

Механизм: начальник отдела в конце года шлёт запрос директору на премиальный фонд для своего отдела. Откуда берётся сумма — обычно зависит от смелости (наглости) начальника. Дальше сумма распределяется начальником среди сотрудников отдела.

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

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

Главная проблема — та же, что и в предыдущей схеме. К премии относятся как к части ЗП, и она никого ни к чему не мотивирует.

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

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

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

Диагноз: премия приравнена к ЗП, как мотивация не работает.

2012 год. Запускается канбан-система для управления портфолио. Мы осознаём, что нужно ограничивать количество начатой работы в системе и нужно как можно быстрее заканчивать проекты. Теперь мы задумались не просто про мотивацию, а мотивацию на попадание в срок.

ПМ может запросить премию у директора по окончанию проекта

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

Главная цель — привязать выплату премии по времени к окончанию проекта, чтобы была непосредственная связь результата работы и поощрения.

Главная проблема — становится выгодно работать в мелких коротких проектах, создавая тем самым непрерывный поток небольших премий. Если ты три года пахал в гигантском проекте, то у тебя есть риск, что проект зафакапится и ты не получишь премию за все три года. Мелкие проекты размывают этот риск. В итоге появляется кадровый голод в «рисковых» проектах.

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

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

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

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

Диагноз: схема сложна и субъективна, как мотивация не работает.

Делим апельсин через голосование

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

Главная цель — сделать распределение справедливым.

Проблема — люди стесняются друг друга оценивать, и всё сводится к «уравниловке». Все в среднем работали неплохо. Ну а тогда начинают терять интерес те, кто реально вваливал весь проект — им уравниловка не нужна, им нужна оценка их большого вклада, а групповая оценка это всё скрывает.

В итоге мы поощряем «серость», а не инициативу и скорость.

Диагноз: уравниловка, как мотивация не работает.

Платим премию в каждом проекте

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

Главная цель — поощрять выполнение командой обязательств в срок.

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

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

Главная проблема — если факт выплаты премии завязан на выполнении проекта в срок, то возникает очевидное желание эти сроки сильно завысить при планировании. Приходится этот момент контролировать отдельно.

Вторая проблема — выгодно работать в мелких проектах. Это уже выше рассмотрено.

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

Четвёртая проблема — если проект длился три года, то надо будет выплатить очень существенные суммы. Это может вызвать конфликт среди команд — кто-то получил за мелкий проект 10 тысяч рублей, а кто-то за гигантский — 500 тысяч рублей. Что проекты совершенно несоизмеримы в этот момент сотрудникам — будет неважно. Также дирекция может отказаться выполнять обязательства по выплатам крупных сумм.

Диагноз: больше всех платим за рутину, как мотивация не работает.

2016 год. Мы всё больше погружались в Agile-подходы. Мы сохранили функциональную структуру, сформировали более-менее постоянные команды в больших проектах и начали игры с ритмичностью. Возник UniScrum.

Платим премию каждый спринт

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

Главная цель — избежать огромных выплат сразу за несколько лет. Уменьшить разницу в рисках между коротким и длинным проектами.

Главная проблема — появляются заметные риски того, что мы заплатим премии за десять спринтов проекта, а он потом тем не менее зафакапится. Премии назад не вернёшь.

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

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

Диагноз: смысл премии непонятен членам команды, как мотивация не работает.

2018 год. В паре команд появляется честный Scrum. Мы начали сильно менять функциональную структуру компании, и начали появляться постоянные междисциплинарные команды. Цели проектов доступны командам. Ответственность и принятие решений от начальников начинают переходить в команды.

Начальник поощряет мастерство

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

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

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

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

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

Подарки от компании

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

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

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

Диагноз: если команда привыкла к механизму тринадцатой зарплате, то лучше убрать с механизма оценочную часть и превратить в подарок. Если вы понимаете зачем вы это делаете, то это работает.

Мы сейчас здесь. У нас работают последние два механизма — поощряем мастеров и дарим подарки раз в год :)

Итак, мы прошли за десять лет такой путь:

  • Годовые премии «с барского плеча». Мгновенно стало восприниматься как ЗП.
  • Годовые премии по запросу начальников. Не понравилось полной непрозрачностью и субъективностью оценок.
  • Проектные премии через ПМа. Непрозрачно и провоцирует убегать из больших проектов.
  • Делим апельсин голосованием. В этом случае демократия не сработала.
  • Проектные премии через математику. Стало прозрачнее, но большие проекты всё ещё неинтересны.
  • Премии по спринтам. Вообще всё смешалось и стало хуже.
  • Мастерство и подарки. Пока нас всё устраивает, но это не значит, что мы тут надолго задержимся. Есть нерешённая задача — мотивация топ-менеджеров. Тут дело не в премиях, но какое-то участие в прибыли требуется. Как говорит в последней книге Нассим Талеб: «Для принятия эффективных управленческих решений необходимо, чтобы у ключевых руководителей была “шкура в игре”».

В умных книжках пишут, что деньги — это гигиенический фактор. Например, об этом пишет Дэниел Пинк в книге «Драйв: что на самом деле нас мотивирует». ЗП должна быть адекватной рынку и не более того. Зарплатой можно удержать в компании либо подтолкнуть к увольнению. Но деньги не мотивируют людей делать что-то лучше или быстрее.

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

Пройти этот путь помогли практики командных ретроспектив, механизмы анализа из теории ограничений (деревья НЖЯ, поиск корневых проблем) и регулярный анализ собственных процессов и правил (что и зачем мы делаем, есть ли у этого внятная полезная цель). О том, как именно эти практики нам помогают улучшать свои процессы, я обязательно напишу отдельную статью.

При всём при этом мы понимаем, что есть ещё миллион схем денежного поощрения сотрудников. Было бы интересно послушать про них — пишите комментарии.

0
73 комментария
Написать комментарий...
Никита Цветков

Добрый день! Спасибо за интересную статью. Не совсем понял последнюю Вашу систему, так как в ней есть чье-то личное мнение за какие-то заслуги. Не вижу вот чего: я инженер, может я не очень круто общаюсь с руководством, но я хочу заработать больше. У меня есть четкая и понятная схема, что мне делать, чтобы заработать на 50 тыс. больше в этом месяце.

Хотел рассказать про свою мотивацию в компании, а так же минусы, которые в ней вижу, все перекликается с темой обсуждения.
Есть минимальная ЗП и квартальный бонус за выполненные закрытые проекты. Проект, у него есть стоимость сметы и проектная маржа. У каждого члена команды (менеджера, инженера, строителя и т.д.) есть свой % от маржи. На момент запуска, ты заранее знаешь какие деньги получишь, если все будет ок (на фото в приложении). Все довольно прозрачно и понятно.
Однако! Как говорилось в статье, проекты могут идти и по несколько лет, в течение которых ты живешь на одну печальную ЗП в надежде на огромный бонус после закрытия. Если произойдет факап и деньги не придут (мы сами накосячили, заказчик тупо не платит, контора заказчика обанкротилась, вариаций много), то ты оказываешься в *опе =)) Маленькие проекты не дают, так как ты полностью погружен в большой. Просто ЗП повысить не могут и не будут, так как это невыгодно дирекции компании.
По итогу, делать кучу мелких проектов выгоднее, не желе крутой большой перспективный и интересный проект, деньги за который неизвестно когда будут и будут ли вообще. Так же в этой системе ты не застрахован от косяков людей из своей команды, которым просто может быть плевать на бонусы, живут только на ЗП и ни к чему не стремятся, и так сойдет!

Что можете порекомендовать в этом случае? =) Проходили ли такое? Спасибо заранее!

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

Не получается отредактировать.

Хочется такой схемы, чтобы было как можно меньше человеческого фактора. Все процессы описаны, все косяки понятны (накосячил - заплати со своего бонуса), а так же все пряники ясны, если выполнил все в срок и без ошибок. Инженер приложил сверх усилия, заказал все быстро и в срок, получил свои деньги. От остальных отделов не хочется быть в зависимости, может даже выплаты поэтапные (хотя у Вас этот вариант не прокатил). Что можете порекомендовать в этом случае? =) Проходили ли такое? Спасибо заранее!

Ответить
Развернуть ветку
Алексей Стеринович
Автор

Если я верно понял, то у вас в компании комбинация проектных премий и KPI. По нашему опыту и то, и другое толком не работает.
По идее ваш начальник должен вам рассказать чему вы должны обучиться, что должны изменить в своей работе, чтобы вам повысили зп на 50 000. Тут премия вообще не при чем.
Наша текущая схема подразумевает выплату премии за конкретное событие, а не по завершению проекта. Она субъективна, но мы пытаемся привязать премию по времени к действию сотрудника, которое на наш взгляд достойно поощрения. Мы не оцениваем всю команду, не оцениваем весь проект, а хвалим за конкретное действие.
Как улучшить вашу схему - не знаю :) в статье как раз описано, что мы ушли от проектных премий из-за тех проблем что вы описали.

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

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

Ответить
Развернуть ветку
Алексей Стеринович
Автор

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

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

Логика руководства: "ребята, есть минимальная ЗП, ее хватает на покушать и оплатить квартиру. Хотите больше - без проблем, отлично продавайте, проектируйте и стройте объекты, будет бонус, все довольны. Если вы косячите - у вас есть минимальная зп, а бонуса может и не быть".
Если нам просто увеличат ЗП, то у компании будет риск попасть в финансовую яму, так как деньги за проекты будут идти долго, а ЗП надо платить каждый месяц. Так же у сотрудников с ЗП выше рынка будет осутствовать мотивация делать все быстрее и лучше (зачем, если деньги и так капают на карточку 5 и 20 числа). Получается какая-то круговая порука. Если у Вас есть такие же проектные продажи в несколько лет, совсем не понимаю, как работает Ваша нынешняя схема.

Ответить
Развернуть ветку
Алексей Стеринович
Автор

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

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

Понял, спасибо за ответы =))

Ответить
Развернуть ветку
Алексей Стеринович
Автор

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

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

А разве не так должно быть? Компания отлично работает, с проектов идут деньги, команда мотивирована на прямой результат, т.е. на закрытие проекта и премию с него. Растет качество и доход, так как растет премия с проектов.
Если проекты не самые успешные, либо иные другие причины, как же руководству обеспечивать высокий уровень ЗП?

Ответить
Развернуть ветку
Алексей Стеринович
Автор

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

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

Эту часть окончательно понял, у меня в компании сейчас совсем другая схема) А по вашей последней схеме, что Вы делаете, если кто-то совершает ошибку, из-за чего приходится в итоге тратить больше денег на проект?

Ответить
Развернуть ветку
Алексей Стеринович
Автор

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

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