Проектная система мотивации

Программист, который занимается разработкой нового программного обеспечения, не должен получать простой фиксированный оклад. Во-первых, это не мотивирует его уложиться в определенные сроки и создать продукт с определенными параметрами. Премия в размере 30% никак не будет стимулировать его соблюсти параметры проекта, в рамках которого он работает. Нередко сотрудник параллельно занимается и другой линейной деятельностью (в первую очередь это касается сотрудников бизнес-вертикали). И поэтому здесь возникает необходимость разделения всех сотрудников на линейных менеджеров (которые работают по сдельной схеме) и на тех, кто занимается разработкой новых продуктов, в рамках проектов. И их оплата труда должна определяться условиями конкретных проектов. Ведь обычно, несмотря на то что проект не реализуется вовремя, сотрудник продолжает получать зарплату и, как ни странно, премию. Ведь она привязана к окладу и к каким-то КПД, которые не всегда определяются точно в соответствии с КПД проектов. Такую систему необходимо менять.

Назначенный менеджер проекта должен формировать проектную команду, определять и согласовывать объем работ. Участникам проектных групп должны быть установлены тарифные ставки (например, стоимость часа их работы), а также проектный бонус, который будет выплачен при достижении КПД проекта. Менеджер проекта должен иметь возможность привлекать в проектную группу свободные человеческие ресурсы, а потенциальный участник должен быть заинтересован выполнить данную работу. В этом, по нашему мнению, кроется революционность данного решения для банковской практики: если «проектный» сотрудник отказывается от работы, он не набирает часов работы и, следовательно, не получает зарплаты. Если он работает в рамках проекта недобросовестно или некачественно, то, естественно, в следующий раз этот или другой менеджер проекта может отказаться от его услуг. Следовательно, сотрудник может попросту остаться без работы.

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

И если тот скажет, что сделает это за 8 часов (при равных других условиях, в частности в отношении качества), менеджер отдаст предпочтение второму. Естественно, что может быть сговор внутри подразделений (в данном случае — тестировщиков), однако менеджер может предложить работу по подряду внешнему или новому сотруднику. Тогда нынешним сотрудникам придется задуматься над сроками и оптимизировать их. В результате предложенная модель стимулирует к оптимизации времени и, соответственно, расходов на оплату труда.

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

Если он делает это за больший срок, он получает те же деньги. То есть если он обещал сделать работу за 10 дней, то получит оплату за 10 дней по установленной тарифной сетке, и неважно, сделал он ее за 20 дней или за 5. На практике это может привести к тому, что сотрудники будут закладывать определенный «запас прочности», раздувая таким образом срок внедрения проекта, но при реализации данной схемы на потоке эта проблема сама собой исчезнет. Еще одним моментом, который необходимо учитывать при реализации такой системы мотивации, является то, что

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

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