//
вы читаете...
Управление проектами

О мотивации в проектах

Исходя из определения, проект – временное предприятие. Человек же стремится к постоянству и стабильности. Система оплаты труда в  проектах, выстроенная с учетом предметной специфики и культурных особенностей компании, призвана устранить это противоречие.

Задачи стимулирования и оплаты труда в проектной деятельности различных организаций разнообразны. В проектно-ориентированной[1] компании, прежде всего, необходимо решить задачу построения системы оплаты труда участников проекта – сотрудников, выполняющих в проектах назначения.

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

От каждого по способностям, всем – по труду

Система оплаты труда разработчиков должна отвечать следующим требованиям:

  • учитывать квалификацию разработчика;
  • стимулировать разработчика выполнять работу меньшими трудозатратами;
  • учитывать качество выполняемых работ;
  • учитывать неравномерность загрузки разработчиков;
  • предоставлять руководителю проекта рычаги влияния на разработчиков.

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

Уже давно в мире разработок пришли к тому, что лучше всего для оплаты творческого труда подходит повременная оплата. Разница в квалификации разработчиков учитывается дифференцированными часовыми ставками.

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

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

Работает это так. Допустим, сотрудник имеет месячный фонд времени 168 часов. Выполнив работы на 168 часов за меньшее рабочее время (например, за 140 часов), он получает свободное время, за которое может выполнить дополнительный объем работ (на 28 человеко-часов или даже больше). Таким образом, чем выше эффективность сотрудника по сравнению с нормативом, на основании которого были определены базовые трудозатраты (БТЗ), тем больше он может заработать.

Напротив, задержки в выполнении работ невыгодны разработчику, так как ему заплатят за «закрытый» объем работ в размере базовых трудозатрат, а за время, потраченное неэффективно, разработчик получит только оклад.

На практике все усложняется. Разработчики быстро «смекают», что закрыть за месяц больше проектных часов можно не только работая эффективнее, но и договорившись о большей оценке БТЗ перед выполнением работ. К сожалению, чем сильнее позиция разработчиков по отношению к нанимателю (недостаток на рынке работников необходимой квалификации, состояние «аврала»), тем более распространена ситуация торга за величину БТЗ.

Частично проблема «торга» решается созданием нормативов трудозатрат на выполнение типичных работ. Следует, однако, иметь в виду, что процесс разработки и внутреннего согласования таких норм уже сам по себе по сути тот же торг. И если вторая сторона договоренностей (наниматель) не является специалистом в предметной области, то он рискует получить узаконенные его же распоряжением завышенные нормы трудозатрат.

Подстраховки

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

Причин возникновения подстраховок несколько.

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

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

Наконец, нельзя забывать о культурном аспекте. Как проходит рабочий день «среднего» сотрудника? Сколько времени уходит на чай-кофе, несодержательные разговоры, переключение между задачами, разбор почты, необходимое чтение профессиональной литературы и многое, многое другое – все то, что не является работой в ее привычном понимании. Значит, этот наш сотрудник работает никак не 168 часов в месяц. Но никто не станет декларировать фактические потери рабочего времени: их прячут в проектные работы. Это снова подстраховки.

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

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

Что это дает? Во-первых, сотрудники и руководство компании не «пудрят друг другу мозги». Показал необходимый процент полезной загрузки – молодец, показал все 100% – видимо, задерживался после работы или компетентнее других – зарабатывай больше. И нет абсурдной ситуации, когда разработчики показывают по 300 – 400 часов выполненных за месяц работ.

Но главное преимущество получает руководитель проекта. Подстраховками нужно пользоваться (это разумное управление рисками), но не прятать их внутрь работ, а закладывать как лаги (промежутки) между работами (рис. 1). Как видно на рисунке, общая продолжительность работ не изменилась, однако измененный план более реалистичен. И бюджет проекта не пострадал.

Рис. 1. Использование лагов между задачами в плане проекта

Рис. 1. Использование лагов между задачами в плане проекта

Таким образом, чтобы привести систему оплаты труда разработчиков в соответствие с реальностью, вы должны:

  • снизить норму полезной загрузки;
  • уменьшить нормы БТЗ («вычистив» подстраховки);
  • повысить проектные ставки (без этого уменьшить нормы БТЗ не получится – вы встретите непреодолимое сопротивление разработчиков).

Золотой запас

Проекты наполовину (если не больше) состоят из неопределенности. Риск и изменения – природа проекта. В отношении оплаты труда это означает, что за непредвиденные в начале проекта работы, видимо, также придется платить.

Опытные руководители проектов планируют с резервами. При этом, конечно, резервы выполняют свою полезную функцию лишь в том случае, если они не спрятаны внутрь сроков и трудоемкости работ, а формируют отдельную строку в плане. Разумеется, руководство компании должно нормально воспринимать наличие в плане резервов на непредвиденные обстоятельства (и незапланированные работы в том числе).

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

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

Такой механизм можно создать, привязав оплату труда участников проекта к резерву трудозатрат. Сделать это можно так.

Как правило, даже если в проект вовлечено большое количество сотрудников, большинство из них выполняют небольшой объем работ. Львиную долю работы проделывает небольшая группа специалистов. Это – ядро команды проекта. Часть резерва трудозатрат (если он относительно велик по сравнению с базовыми трудозатратами) или даже весь резерв может быть распределен между участниками ядра команды проекта (куда, разумеется, входит и руководитель проекта). Это так называемый аккорд. Получается, что, создавая в проекте новые задачи, основные участники проекта будут «отъедать» человеко-часы у себя же и своих коллег. Руководитель проекта, который обычно авторизует добавление к плану новых задач, также не заинтересован «транжирить» резерв.

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

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

Волшебная формула

В итоге формула расчета зарплаты разработчика может выглядеть так:

 Зарплата разработчика = Оклад + Проектные + Аккорд * КРП

 При этом «Проектные» рассчитываются как произведение почасовой ставки, соответствующей квалификации разработчика[3], на базовые трудозатраты фактически выполненных работ.

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

В качестве рычага влияния на участников проекта (если других рычагов ему недостаточно) руководителю проекта может быть предоставлена возможность в конце проекта выставить членам команды «оценки за сотрудничество», от 0 до 100%, и умножить на полученные коэффициенты аккорды участников проекта. В формуле расчета зарплаты этот коэффициент обозначен как КРП (коэффициент руководителя проекта).

Проверка на прочность

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

  • учитывать квалификацию и стимулировать ее повышение;
  • сокращать непродуктивные потери времени и повышать эффективность работы;
  • связать доход сотрудников и качество выполняемых ими работ;
  • сгладить неравномерность загрузки сотрудников в проектах;
  • реализовать материальное влияние руководителя проекта на разработчиков.

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

Пример расчета проектных выплат и аккорда 

(по итогам проекта, без разбивки по месяцам)

 

Исходные данные:

Часовая ставка (одна для А, В и С) — $5/ч

Фонд трудозатрат проекта (БТЗ) – 100 ч/ч ($500)

Резерв трудозатрат – 25 ч/ч ($125)


Расчет:

Участник

Работы по базовому плану, ч/ч

Работы за счет резерва, ч/ч

Итого трудо-затраты, ч/ч

Остаток резерва, ч/ч ($)

Коэффи-циент руково-дителя проекта (КРП)

Доля в аккорде (пропорц-но трудозатратам с поправкой на КРП)

Проектные, $ (работы в ч/ч умножить на ставку)

Аккорд (доля в аккорде умножить на сумму остатка резерва), $

Итого, сумма выплат участнику проекта, $

А

50

5

55

1,0

55%

275

41,25

316,25

В

30

5

35

1,0

35%

175

26,25

201,25

С

20

0

20

0,5

10%

100

7,5

107,5

Итого

100

10

110

15 ($75)

 

100%

550

75

625


Впервые опубликовано в журнале «Финансовый директор», №10 (2009)

[1] Согласно классификации Рассела Д. Арчибальда, по типу преобладающей проектной деятельности компании подразделяются на два класса: проектно-ориентированные (зарабатывающие в проектах) и проектно-зависимые (развивающиеся в проектах и зарабатывающие на операциях).

[2] Рекомендовать конкретный уровень нормальной загрузки сложно, это зависит от специфики и сложности работы (чем сложнее работа, тем меньше нормальная продуктивная загрузка). В консалтинге это может быть 50%, в инжиниринге – 70%.

[3] Исключение составляет случай, когда высококвалифицированный разработчик выполняет простую работу, не требующую его высокой квалификации. Тогда целесообразнее оплачивать работу по меньшей ставке, соответствующей сложности работы.

Реклама

About Виктор Степанов

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

Обсуждение

17 thoughts on “О мотивации в проектах

  1. Добрый день! На сайте e-xecutive.ru читала Ваш обзор по рынку труда, оттуда вышла на Ваш блог и эту статью. Посмотрела расчеты. И честно говоря не поняла, как Вы расчитали Доля в трудозатратах с поправкой на КРП (откуда такие значения процентов???). 55 от 110 — это 50%, а 35 от 110 — это 32%. Также расчет Аккорда тоже остался туманным. Вы ведь его определили, как: Аккорд рассчитывается как доля в резерве трудозатрат, оставшемся к концу проекта. Но к концу проекта согласно условию в резерве 240 часов еще остается… Как же у Вам тогда 41,25 получилось? Разъясните, пожалуйста, еще раз технологию Ваших расчетов. Заранее спасибо!

    Posted by an | Август 5, 2011, 09:57
    • Здравствуйте! Спасибо за замечание.
      В условия задачи закралась досадная ошибка: фонд трудозатрат и резерв трудозатрат на старте проекта составляют не 1000 и 250 часов, а 100 и 25 часов соответственно. В остальном расчеты в таблице верные. Для облегчения понимания я переименовал некоторые поля таблицы и дополнил ее итоговой колонкой. Теперь все сходится. Остались ли у Вас вопросы?

      Posted by Виктор Степанов | Август 25, 2011, 13:18
  2. Виктор, я правильно понял, КПР нужен для распределения остатка резерва между участниками или участником (если проект выполняет один сотрудник)? Ставится он перед началом проекта. Это говорит участнику, сделаешь работу раньше (т.е КПР=1 (100%)) — получишь премию (резерв от проекта), сделаешь работу поздно или просрочишь его (КПР меньше 1 (или 0)) — ничего не получишь.

    Posted by Антон | Март 27, 2012, 15:24
    • Антон, вы правильно поняли, что КРП, выставленные руководителем проекта другим участникам проекта, прямо влияют на то, какую часть остатка резерва получит каждых из этих участников. Однако устанавливать КРП только в зависимости от выполнения сроков — значит использовать КРП не на полную катушку. Кроме того, сам резерв трудозатрат — это не просто премия, это инструмент влияния на участников проекта, получающих «проектные» (разработчики, консультанты и др.), чтобы они не «перебирали» человеко-часы, генерирую новые и новые задачи в проекте.

      Posted by Виктор Степанов | Март 28, 2012, 10:24
  3. Итого трудозатраты, ч/ч = 72

    Остаток резерва, ч/ч ($) = 8

    Коэффициент руководителя проекта (КРП) = 1

    Доля в аккорде (пропорцно трудозатратам с поправкой на КРП, %) = 72%

    Доля в аккорде (пропорцно трудозатратам с поправкой на КРП, %) рассчитывается так: «Итого трудозатраты» * «Коэффициент руководителя проекта»? Т.е: 72*1=72, так?

    Posted by Антон | Март 27, 2012, 15:31
    • Антон, я не уловил, сколько участников проекта в вашем примере. Если один — доля в аккорде тоже 1 (100%). Если несколько человек — то доля каждого меньше 1 (<100%). Дальше применяется поправка на КРП.

      Posted by Виктор Степанов | Март 28, 2012, 10:28
  4. Виктор, эта схема оплаты труда уже где-нибудь работает?

    Posted by Антон | Март 28, 2012, 07:12
    • Да, Антон. Эта система проверена годами работы в консалтинговой компании, в которой я работал ранее, и в инжиниринговой компании, у моего клиента. Есть и другие примеры, но я в этом не участвовал, и ссылаться не буду.

      Posted by Виктор Степанов | Март 28, 2012, 10:29
  5. Виктор, спасибо за быстрые ответы. Но все равно не могу понять как считается «Доля в аккорде». Давайте разберем Ваш пример.

    Первый комментарий:
    55 от 110 – это 50%, а 35 от 110 – это 32%. (точнее: 31,818)

    дополню 3-его участника: 20 от 110 — это 18,1818%

    Так считается?

    Posted by Антон | Март 28, 2012, 11:07
    • Антон, вы все правильно поняли. Теперь, если КРП у всех участников 1 (100%), то все получат долю резерва в пропорциях, которые вы указали. Если у кого-то ниже — то он получает меньше. Спорный вопрос, отдавать ли недополученные этим участником проекта деньги другим участникам. Пожалуй, лучше их не выплачивать никому.

      Posted by Виктор Степанов | Март 28, 2012, 19:20
  6. Виктор, можете еще посоветовать книги которые раскрывают данный расчет по оплате труда проектной организации.

    Posted by Антон | Март 28, 2012, 13:05
  7. Виктор, «Рис. 1. Использование лагов между задачами в плане проекта» — как называется программа управления планирование проектами? Подскажите какую лучше скачать (купить).

    Posted by Антон | Апрель 4, 2012, 08:07
    • Антон,
      приведенный пример сделан в программе Microsoft Project.
      Сейчас выбор программ очень большой. Все зависит от особенностей вашей ситуации: внешние проекты или внутренние, как много у вас проектов и требуется ли обобщенная аналитика по всему портфелю, хотите ли вы только планировать проект и отслеживать его выполнение, либо также общаться с другими участниками проекта через систему, загружать в проектную область документы и т.д.
      MS Project — широко распространенная система, и у вас не будет проблем с чтением файлов планов зарубежными участниками проектов.
      С другой стороны, сейчас все более популярны «облачные» системы (планы проектов и документация хранятся в Интернете). Посмотрите системы Мегаплан и Clarizen.

      Posted by Виктор Степанов | Апрель 4, 2012, 11:24
  8. Спасибо, Виктор.

    Posted by Антон | Апрель 4, 2012, 14:24
  9. Добрый день,
    не совсем понял что будет сдерживать участников проекта чтобы «не проедать» резерв? За проедание резерва он ведь также будет получать те же самые 5 долларов за час дополнительных работ… Возьмем участника А — по базовому плану он получит за 50 часов = 250 долларов и за счет резерва за 5 часов — 25 долларов…Проедая резерв он еще и увеличивает свою долю в аккордном остатке)) Не вижу никаких преимуществ в данной системе)

    Posted by Алексей | Июль 21, 2015, 11:04
    • Алексей, добрый день,
      на самом деле резерв — не холодильник на кухне, чтобы каждый свободно к нему подходил и брал, сколько хочет. Резервом распоряжается руководитель проекта. Поскольку в предложенной системе резерв также выполняет функцию премиального фонда (на финише) проекта, то для команды расходование резерва не проходит незаметно. Другими словами, манипуляции с целью увеличения заработка одного конкретного участника проекта, мягко говоря, затруднительны.
      И не будем забывать о главном — компания (заказчик) при такой системе в любом случае не потратит на проект больше, чем планировала.

      Posted by Виктор Степанов | Июль 21, 2015, 11:43

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Ищете ответы?

business-models CIGS CIGSlim pmbok PMO velcom Базовый курс управления проектами Изовак Инвестиционный меморандум КСУП Обучение действием базовый курс бизнес-ангел бизнес-модели бизнес-модель бизнес-обучение бизнес-план венчур венчурный бизнес заказчик инвестиции инвестор интересы исследование команда проекта коммуникации консалтинг корпоративная система управления проектами кризис куратор маркетинг меморандум миф мотивация обоснование проекта обучение руководителей проектов отзыв отчеты письма план проекта подрядчик портфель проектов принцип раскрытия программа продажа бизнеса проект проект-менеджер проектно-зависимый проектно-ориентированный проектное управление проектный офис проектный подход прямые инвестиции результаты проекта риск риск-менеджмент роль рынок труда связи семинар скрытый клиент совмещение ролей солнечная энергетика спонсор стартап стейкхолдеры стимулирование стратегический инвестор стратегический портфель стратегия тренинг управление проектами управление рисками финансовый инвестор эксперт
%d такие блоггеры, как: