HR-Journal.ru :: IT-отрасль: Геймификация в области оплаты труда
закрыть Х
Мы в соцсетях

Во всех наших группах мы делимся интересными постами, шутим и раздаём прочие вкусности ;)

Добро пожаловать!!!

Логин:

Пароль:

Регистрация
Забыли пароль?

IT-отрасль: Геймификация в области оплаты труда

© 11.07.2013
Денис Гордиенко, директор Bright Studio

Мотивация IT-специалистов – тема отдельная и весьма непростая – как для больших IT-компаний, так и для небольших веб-студий. В этой отрасли даже проверенные временем системы мотивации действуют не всегда предсказуемо (подробнее: KPI или пособие по командному самоубийству, Эффективен ли KPI для творческих профессий?) Ниже – ещё один рассказ о попытке найти идеальную систему мотивации для программистов – и о том, к чему это привело;)

Давай сыграем на твою зарплату

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

С чего всё начиналось

Я думаю, что стоит начать с более серьёзного вопроса, который периодически возникает в любой студии, а в интернете переходит в холивар: «Фикс или сдельщина?»

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

Не буду перечислять самые первые системы начисления оплаты, т.к. они больше похожи на офисный фриланс, что не удивительно, потому что первые 1 — 1,5 года мы брали заказы в основном именно с фриланса. Затем положение дел изменилось, и потребовалось изменить подход к зарплате. Последняя модель, которую мы использовали, выглядела следующим образом:

  1. У сотрудника был фиксированный минимум (N рублей).

  2. Все задачи оценивались в балльной системе, в зависимости от сложности и сроков. Как правило, 1 рабочий день «стоил» 0,5 балла.

  3. У сотрудника был план, который зависел от должности (m баллов в месяц).

  4. Если сотрудник не выполнял план, то он получал минимальный фикс.

  5. Если сотрудник перевыполнял план (за месяц набирал 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р.

Для наглядности цифры взяты «с потолка».

У такого подхода есть ряд плюсов:

  1. Васе выгодно делать проекты качественнее, чтобы потом не править баги.

  2. Сколько Вася наработает, столько и получит.

Но есть и ряд минусов:

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

  2. Программист Петя — второкурсник института, а у Васи — стаж 10 лет, но минимальный фикс у них один и тот же.

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

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

Цели и задачи

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

  1. Честная зарплата. Самая важная задача. Сотрудник должен получать столько тенге, сколько он реально заработал.

  2. Прозрачность. При расчете зарплаты ни в коем случае не должно быть эффекта чёрной коробки.

  3. Система должна стимулировать сотрудников повышать свою квалификацию.

  4. Лояльность к студии в целом.

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

  6. Карьерный рост. Должно быть чёткое понимание, когда и при каких условиях человек может претендовать на повышение.

  7. Соцсоревнование и сравнение длины мастерства.

Теоретическая модель

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

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

«Получается что-то вроде RPG: наработал на 20 баллов — получи 3-й уровень и минимальный фикс 15 000 р., наработал на 100 — 10-йуровень и 30 000».

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

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

Этот бонус за скорость действует при выполнении до указанного срока (например, на схеме ниже показано, что при выполнении проекта на 15% раньше дедлайна начисляется 15% бонус к итоговой сумме баллов по проекту). Либо же, если дедлайн сорван более чем на 20%, из итоговой суммы вычитаются 20%. Если дедлайн сорван менее чем на 20%, то коэффициент не применяется (эти 20% закладываются в дедлайн, который озвучивается заказчику).

 

Для понимания рассмотрим несколько примеров.

  1. Васе нужно сделать саппортную задачу, которую он оценил в 12 часов

    Вася получит: (12/8)*0,5 = 0,75 балла


    Здесь всё просто — сколько времени потратил, столько баллов получил.

  2. Васе нужно сверстать сложные макеты сайта для лояльного заказчика, и он вместо 100 рабочих часов укладывается в 83.

    Вася получит: (100/8) * 0,5 * 1,05 (сложность) * 1 (лояльность) * 1,17 (время) = 7,68 балла


    В этом случае сначала высчитывается стандартное количество баллов (100/8)*0,5 = 6,25 и делается поправка на сложность и сдачу раньше срока. Т.к. клиент проблем не доставляет, то коэффициент равен единице.

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

    Вася получит: (100/8) * 0,5 * 1,05 (сложность) * 1,15 (лояльность) * 0,8 (время) = 6,04 балла


    Здесь клиент доставил Васе много проблем при согласовании, и Вася, расстроившись, наделал кучу багов, тем самым сорвав сроки дедлайна более чем на 20%. Хоть Вася и получил надбавку и за сложность, и за неадекватность заказчика, сорванный дедлайн сильно уменьшил количество баллов.

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

Вася получит: (100/8) * 0,5 * 1 (сложность) * 1,07 (лояльность) * 1 (время) = 6,69 балла


В этом случае для Васи нет никакой сложности, заказчик не очень сильно тиранит Васю, и Вася уложился в «запасные» 20% времени.

От теории к практике

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

В конце апреля мы проанализировали всю информацию и фидбек от сотрудников, и на планёрке руководства студии было решено, что всё это... полная фигня.J Собственно, сама идея на бумаге всем понравилась: она решала все цели, которые были поставлены, но на оценку и вычисление коэффициентов мы тратили просто непозволительную кучу времени — даже с учётом того, что большинство операций было запрограммировано. Кроме того, была проблема в оценке сложности и лояльности заказчика. «На сколько процентов „ТухлоРыбСнаб» лояльнее „ДыроШин“? А почему?»

Ещё одна важная проблема — срыв дедлайна свыше 20%. Экономически логика верная: «Сорвал сроки? Получай штраф!» Но фактически человек и так морально измотан этим проектом (дедлайны не просто так срываются), а если это ещё и скажется на его зарплате, то настрой на дальнейшую работу будет ниже плинтуса, а это студии невыгодно.

Всё не так плохо

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

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

Остаётся вопрос — как считать опыт новых сотрудников, которых мы устраиваем к себе в компанию? Нечестно было бы ставить им «0», если человек уже опытный и готов решать сложные задачи. Мы решили пойти по самому простому пути: после месяца испытательного срока тех. директор или арт-директор будут устанавливать стартовый уровень нового сотрудника, опираясь на свои субъективные предположения.

Возвращаясь к изначальным задачам

  1. Честная зарплата. Задача решена полностью и принципы сохранились.

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

  3. Стимуляция повышения квалификации. Появилась прямая зависимость между участием в сложных проектах и получением бонусов.

  4. Лояльность к студии в целом. Мы решили, что лояльность не должна покупаться, и закрыли этот вопрос постоянными совместными мероприятиями.

  5. Прогнозирование зарплаты. См. п.2

  6. Карьерный рост. Мы создали таблицу карьерного роста. Каждый сотрудник видит, сколько ему ещё нужно отработать, чтобы поставить вопрос о собственном повышении.

  7. Соцсоревнования. Петя хочет получать так же, как и Вася? Пусть поработает внеурочно и быстро получит Васин уровень.

  8. Сложность вычислений. Собственно, сложности не осталось никакой. Сотрудники заполняют ежедневно табель учёта рабочего времени (2 минуты в день) и видят, какую зарплату они получат в конце месяца, и будет ли «левел ап» минимального фикса.

Хотелось бы услышать фидбек по предложенной схеме. Как в ваших студиях работают геймификация, KPI?

условия копирования

Дорогой HR-Journal, потрудись сообщать мне о новых статьях ;)

Комментарии

Новые обсуждения

04.12 15:14 Лана72
Повестка в суд (0)

03.12 00:59 publicmd
Подарок шефу на Новый Год (7)

30.11 20:52 Raket
Анкета при приеме на работу (1)

30.11 18:49 EKG1987
Помощь новичку (0)

Все

Комментарии

Ваш баннер на этом месте