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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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