Естественно, нет однозначного ответа на этот вопрос, и всё зависит от бизнес-процессов в студии, а иногда и от мировоззрения руководителя. Ещё на ранних этапах развития студии я решил, что у нас будет сдельщина, т.к. «кто больше работает — тот больше ест». До сих пор мне кажется, что это наиболее веский аргумент в пользу гибкой зарплаты.
Не буду перечислять самые первые системы начисления оплаты, т.к. они больше похожи на офисный фриланс, что не удивительно, потому что первые 1 — 1,5 года мы брали заказы в основном именно с фриланса. Затем положение дел изменилось, и потребовалось изменить подход к зарплате. Последняя модель, которую мы использовали, выглядела следующим образом:
- У сотрудника был фиксированный минимум (N рублей).
- Все задачи оценивались в балльной системе, в зависимости от сложности и сроков. Как правило, 1 рабочий день «стоил» 0,5 балла.
- У сотрудника был план, который зависел от должности (m баллов в месяц).
- Если сотрудник не выполнял план, то он получал минимальный фикс.
- Если сотрудник перевыполнял план (за месяц набирал M баллов), то он получал минимальный фикс + премию, рассчитанную по формуле: (M-m) x Z, где Z — стоимость одного перевыполненного балла.
Например, у программиста Васи минимальный фикс — 40 000 р., план — 8 баллов, стоимость перевыполненного балла — 4 000р. В месяце — 22 рабочих дня, из которых 19 дней Вася делал проекты по оценке 0,5 балла за 1 рабочий день, а 3 дня правил баги. В таком случае зарплата Васи составит:
((19x0,5 + 3x0) - 8) х 4 000р. + 40 000р. = 46 000р.
Для наглядности цифры взяты «с потолка».
У такого подхода есть ряд плюсов:
- Васе выгодно делать проекты качественнее, чтобы потом не править баги.
- Сколько Вася наработает, столько и получит.
Но есть и ряд минусов:
- Пришёл программист Петя, который работает медленнее Васи и при этом получает как минимум такую же зарплату.
- Программист Петя — второкурсник института, а у Васи — стаж 10 лет, но минимальный фикс у них один и тот же.
- Петя не заинтересован в собственном развитии и участии в более сложных проектах, т.к. проект будет сложнее, а зарплата — та же.
«В итоге получается, что, хотя зарплата и зависит от выработки, но профессиональный рост сотрудников никак не стимулируется, и сотрудники явно разного профессионального уровня имеют один и тот же минимальный фикс».
Цели и задачи
В ноябре 2012-го года я решил оптимизировать систему начисления зарплаты и ранжировать по важности те цели, которые должны быть достигнуты после её внедрения.
- Честная зарплата. Самая важная задача. Сотрудник должен получать столько тенге, сколько он реально заработал.
- Прозрачность. При расчете зарплаты ни в коем случае не должно быть эффекта чёрной коробки.
- Система должна стимулировать сотрудников повышать свою квалификацию.
- Лояльность к студии в целом.
- Прогнозирование зарплаты. Одной из «болячек» первых систем было следующее: сотрудник в один месяц мог сорвать куш, а в другой — «сосать лапу».
- Карьерный рост. Должно быть чёткое понимание, когда и при каких условиях человек может претендовать на повышение.
- Соцсоревнование и сравнение длины мастерства.
Теоретическая модель
Прописав для себя эти цели, я смирился с тем фактом, что система расчета будет очень громоздкой в плане вычислений, поэтому добавилась восьмая задача — максимально отойти от ручного вычисления и автоматизировать всё, что только можно.
Минимальный фикс. Логично предположить, что чем больше стаж у сотрудника, тем более эффективна его работа, и тем более он ценен для студии (бывают и исключения, но в целом зависимость прямо пропорциональная). Нам осталось только посчитать, насколько Вася эффективнее Пети, и какая у них должна быть разница в минимальном фиксе. Я подошёл к этому вопросу, основываясь на том, что вся выполненная работа оценивается у нас в баллах, а значит, количество всей выполненной работы того или иного сотрудника можно посчитать.
«Получается что-то вроде RPG: наработал на 20 баллов — получи 3-й уровень и минимальный фикс 15 000 р., наработал на 100 — 10-й уровень и 30 000».
Премия и коэффициенты. В целом система нормы на месяц должна была остаться прежней, однако нужно ввести соответствующие коэффициенты, которые бы стимулировали работу в сложных проектах и способствовали выполнению задач до дедлайна. Для оценки я разделил проекты на собственно проектные (разработка дизайна сайта) и саппортные мелочи (нарисовать статичный баннер), а также выделил следующие коэффициенты:
|
|
Проектные |
Проектные |
|
Оценка выполнения |
Предварительная 0 — ∞ |
По факту |
|
Сложность |
1 — 1,05 |
1 |
|
Лояльность заказчика |
1 — 1,15 |
1 |
|
Скорость выполнения |
+ |
- |
Таким образом, проектные задачи оцениваются до реального исполнения, а саппортные — по факту выполнения, из расчета 0,5 баллов за рабочий день. У проектных могут быть добавлены коэффициенты (надбавки) за сложность и проблемы во взаимопонимании с заказчиком, а также действует бонус за скорость.
| Этот бонус за скорость действует при выполнении до указанного срока (например, на схеме ниже показано, что при выполнении проекта на 15% раньше дедлайна начисляется 15% бонус к итоговой сумме баллов по проекту). Либо же, если дедлайн сорван более чем на 20%, из итоговой суммы вычитаются 20%. Если дедлайн сорван менее чем на 20%, то коэффициент не применяется (эти 20% закладываются в дедлайн, который озвучивается заказчику). |
|
|
Для понимания рассмотрим несколько примеров.
-
Васе нужно сделать саппортную задачу, которую он оценил в 12 часов
Вася получит: (12/8)*0,5 = 0,75 балла
Здесь всё просто — сколько времени потратил, столько баллов получил.
-
Васе нужно сверстать сложные макеты сайта для лояльного заказчика, и он вместо 100 рабочих часов укладывается в 83.
Вася получит: (100/8) * 0,5 * 1,05 (сложность) * 1 (лояльность) * 1,17 (время) = 7,68 балла
В этом случае сначала высчитывается стандартное количество баллов (100/8)*0,5 = 6,25 и делается поправка на сложность и сдачу раньше срока. Т.к. клиент проблем не доставляет, то коэффициент равен единице.
-
Васе нужно сверстать сложные макеты сайта для очень придирчивого заказчика, и вместо 100 рабочих часов он, срывая дедлайн, делает за 127.
Вася получит: (100/8) * 0,5 * 1,05 (сложность) * 1,15 (лояльность) * 0,8 (время) = 6,04 балла
Здесь клиент доставил Васе много проблем при согласовании, и Вася, расстроившись, наделал кучу багов, тем самым сорвав сроки дедлайна более чем на 20%. Хоть Вася и получил надбавку и за сложность, и за неадекватность заказчика, сорванный дедлайн сильно уменьшил количество баллов.
-
Васе нужно сверстать простые макеты сайта для стандартного заказчика, и он вместо 100 рабочих часов тратит 113.
Вася получит: (100/8) * 0,5 * 1 (сложность) * 1,07 (лояльность) * 1 (время) = 6,69 балла
В этом случае для Васи нет никакой сложности, заказчик не очень сильно тиранит Васю, и Вася уложился в «запасные» 20% времени.
От теории к практике
Система получилась очень громоздкой, однако всю логику удалось запрограммировать в Excel, оставалось только вносить исходные данные. Мы взяли на тестирование 4 месяца — с января по апрель. Суть тестирования заключалась в том, что фактически зарплата начислялась по старинке, но параллельно вёлся лог расчетов и по новой системе.
В конце апреля мы проанализировали всю информацию и фидбек от сотрудников, и на планёрке руководства студии было решено, что всё это... полная фигня.J Собственно, сама идея на бумаге всем понравилась: она решала все цели, которые были поставлены, но на оценку и вычисление коэффициентов мы тратили просто непозволительную кучу времени — даже с учётом того, что большинство операций было запрограммировано. Кроме того, была проблема в оценке сложности и лояльности заказчика. «На сколько процентов „ТухлоРыбСнаб“ лояльнее „ДыроШин“? А почему?»
Ещё одна важная проблема — срыв дедлайна свыше 20%. Экономически логика верная: «Сорвал сроки? Получай штраф!» Но фактически человек и так морально измотан этим проектом (дедлайны не просто так срываются), а если это ещё и скажется на его зарплате, то настрой на дальнейшую работу будет ниже плинтуса, а это студии невыгодно.
Всё не так плохо
Несмотря на то, что целиком систему мы не запустили, из неё был взят один очень важный момент — расчет фикса в зависимости от опыта. Сейчас у каждого сотрудника есть собственный уровень, собственное количество отработанных баллов, и он сам может прикинуть, сколько ему нужно выполнить работы, чтобы повысить себе зарплату.
Кроме того, мы решили, что каждый рабочий день (вне зависимости от сложности текущего проекта) будет оцениваться в 0,5 балла, а если сотрудник ведёт явно тяжёлый проект, то после завершения проекта можно его стимулировать дополнительной премией / выходным / подарком / грамотой и т.д.
Остаётся вопрос — как считать опыт новых сотрудников, которых мы устраиваем к себе в компанию? Нечестно было бы ставить им «0», если человек уже опытный и готов решать сложные задачи. Мы решили пойти по самому простому пути: после месяца испытательного срока тех. директор или арт-директор будут устанавливать стартовый уровень нового сотрудника, опираясь на свои субъективные предположения.
Возвращаясь к изначальным задачам
- Честная зарплата. Задача решена полностью и принципы сохранились.
- Прозрачность. Пока ни у одного сотрудника не было проблем с расчётом собственной зарплаты или схемами её начисления.
- Стимуляция повышения квалификации. Появилась прямая зависимость между участием в сложных проектах и получением бонусов.
- Лояльность к студии в целом. Мы решили, что лояльность не должна покупаться, и закрыли этот вопрос постоянными совместными мероприятиями.
- Прогнозирование зарплаты. См. п.2
- Карьерный рост. Мы создали таблицу карьерного роста. Каждый сотрудник видит, сколько ему ещё нужно отработать, чтобы поставить вопрос о собственном повышении.
- Соцсоревнования. Петя хочет получать так же, как и Вася? Пусть поработает внеурочно и быстро получит Васин уровень.
- Сложность вычислений. Собственно, сложности не осталось никакой. Сотрудники заполняют ежедневно табель учёта рабочего времени (2 минуты в день) и видят, какую зарплату они получат в конце месяца, и будет ли «левел ап» минимального фикса.
Хотелось бы услышать фидбек по предложенной схеме. Как в ваших студиях работают KPI?
Денис Гордиенко, cmsmagazine.ru