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

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


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

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


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

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

  • У сотрудника был фиксированный минимум (n р.);
  • Все задачи оценивались в бальной системе, в зависимости от сложности и сроков, как правило, 1 рабочий день «стоил» 0,5 балла;
  • У сотрудника был план, в зависимости от должности (m баллов в месяц);
  • Если сотрудник не выполнял план, то он получил минимальный фикс;
  • Если сотрудник перевыполнял план (за месяц набирал M баллов), то он получал минимальный фикс + премию, рассчитанную по формуле (M-m)xZ, где Z – стоимость одного перевыполненного балла;


Например, у программиста Васи минимальный фикс 40 000р., план – 8 баллов и стоимость перевыполненного балла 4 000р. В месяце 22 рабочих дня, из которых 19 дней Вася делал проекты по оценке 0,5 балла за 1 рабочий день, а 3 дня правил баги. В таком случае зарплата Васи составит:

((19 х 0,5 + 3 х 0) – 8) х 4 000р. + 40 000р. = 46 000р.

Цифры взяты с потолка для наглядности.

У такого подхода есть ряд плюсов:
  • Васе выгодно делать проекты качественнее, чтобы потом не править баги
  • Сколько наработал, столько и получил

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


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

Цели и задачи


В ноябре 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% времени.

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


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

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

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

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


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

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

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

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


  1. Честная зарплата. Задача решена полностью и принципы сохранились;
  2. Прозрачность. Пока ни у одного сотрудника не было проблем с расчётом собственной зарплаты или схемами её начисления;
  3. Стимуляция повышения квалификации. Появилась прямая зависимость участия в сложных проектах и получения бонусов;
  4. Лояльность к студии в целом. Мы решили, что лояльность не должна покупаться и закрыли этот вопрос постоянными совместными мероприятиями;
  5. Прогнозирование зарплаты. См. п.2;
  6. Карьерный рост. Мы создали таблицу карьерного роста. Каждый сотрудник видит сколько ему ещё нужно отработать, чтобы поставить вопрос о собственном повышении;
  7. Соцсоревнования. Петя хочет получать так же, как и Вася? Пусть поработает во внеурочку и быстро получит Васин уровень;
  8. Сложность вычислений. Собственно, сложности не осталось никакой. Сотрудники заполняют ежедневно табель учёта рабочего времени (2 мин в день) и видят какую зарплату получат в конце месяца и будет ли «левел ап» минимального фикса;


Хотелось бы услышать фидбек о предложенной схеме. Как в ваших студиях работает геймификация, KPI?
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 11

    –2
    Отличная статья. =) KPI где-то так и считаем =)

    Предложение автору: оставь свои контакты, может PM-ом возьмут сразу в один из проектов. Мышление правильное =)image
      +2
      Вроде направление интересное, со сведением всего к количеству баллов.
      Но получилась не совсем геймификация.

      Это аккордно-премиальная система + штрафы. Пусть и с прозрачной системой расчетов, выраженная в баллах.

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

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

      Заставлял всегда фиксировать время, но никогда не использовал в качестве оргвыводов. Просто чтобы знать затраты.
      Иначе начинается высиживание часов и атомарные отчеты в стиле «крутил гайку №5» и «делал рефакторинг».

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

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

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

        0
        Это аккордно-премиальная система + штрафы.

        От штрафов и дополнительных коэффициентов мы отказались, т.к. страдает общая мотивация.

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

        В целом согласен. Изначально в проекте системы я предполагал такие ачивки. Но ещё до запуска в тестирование столкнулся с тем, что часть сотрудников вообще не играли в РПГ, а часть не любит подобный жанр. Кроме того, при собеседовании многих может испугать настолько далёкий от стандартов подход. Пример ачивок:
        За переработку
        За активность в подготовке корпоративов
        За минимум багов / претензий от клиентов
        За помощь стажёрам
        За инициативные предложения (которым я дал зелёный свет)
        Придумать можно многое и материальную составляющую назначить в зависимости от приоритетов компании. Хотели даже в CRM изменить профиль сотрудника в стиле:
        image
        Но всё упёрлось в сложность адаптации.

        0
        Очень интересная статья. Большое спасибо автору за ее публикацию. Тема численной оценки труда разработчиков меня сейчас интересует особенно сильно, и чужой опыт очень полезен. Есть ряд вопросов, которые хотел бы уточнить:

        Как вы добиваетесь и проверяете достоверность отчетов по времени? Кто и как расставляет баллы сложности на задания/проекты? Насколько справедливой коллектив считает эту оценку? Сколько времени занимает процедура оценки задач? А сколько — подсчета итогов?

        И самое главное: как масштабируется эта система при росте команды до 3-4-5 команд? Все предыдущие вопросы интересуют в большей степени именно в этом ключе.
          +1
          Как вы добиваетесь и проверяете достоверность отчетов по времени?

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

          — Толян, сколько готово страниц по агрегату?
          — 1,5
          — А сколько времени потрачено?
          — 37
          — Чё там совсем ***?
          — Да не, со слайдерами на главной долго ***. Потом с формами на странице стилей. Сейчас о компании наполовину сделал, там тоже слайдер.
          — Когда планируешь закончить если у тебя не будет отвлекающих задач
          — Пока дедлайн к среде сохраняется. Другие страницы простые. Если не буду успевать, дома поработаю. У меня учёба закончилась.

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

          Кто и как расставляет баллы сложности на задания/проекты?

          Предполагалось, что это будет делать непосредственный руководитель при согласовании с сотрудником, которому будет поручен проект. Например:
          — Вась ты за 48 часов проект N заверстаешь?
          — Нет, там Макс замудрил с картой присутствия.
          — Давай тогда 56.
          — Ок

          От оценки сложности и адекватности заказчика мы отказались как раз из-за субъективности этих параметров. Об этом я писал в статье.

          Насколько справедливой коллектив считает эту оценку?

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

          Сколько времени занимает процедура оценки задач?

          Сложно сказать, т.к. это зависит от самих задач. У нас при оценке разработки сайта по адекватному ТЗ уходит суммарно 0,5 -1,5 часа. Я думаю, что у всех компаний есть собственные механизмы оценки трудозатрат. Нужно ориентироваться именно на них, т.к. людям так будет проще, а значит оценка точнее.

          А сколько — подсчета итогов?

          0 мин. Из табеля автоматически распределяется время по задачам, на которые оно тратилось. Так по каждому сотруднику. Мне остаётся зайти и посмотреть диаграмму Ганта по задачам, сопоставить оценочное время и реально затраченное по завершённым проектам, ну и самое интересное — сделать соответствующие выводы.

          как масштабируется эта система при росте команды до 3-4-5 команд?

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

          У нас немного иная схема, и у нас нет ПМов и сейлсов (это тема для отдельной статьи). Поэтому контроль за табелями произвожу я. Учёт табелей 8 сотрудников занимает примерно 3 часа 1 раз в месяц.
          0
          Какие-то мудреные схемы… зачем придумывать велосипед… оклад+ежемесячная премия 100%. Накосячил — минус 50% премии, сильно накосячил — минус вся премия. А если проект сдал вовремя, прибыли принес много, то можно и дополнительную премию выдать.
            0
            А разве это заслуга разработчика что проект принёс много денег? Вот что вовремя запущен — то да. А деньги — это заслуга продавцов и всех из направления BezDev'а.

            Насчёт накосячил — разработчик может не согласиться что это его вина. И тогда всё скатывается к авторитаризму, где где решения принимаются лично руководителем, и теряется прозрачность и предсказуемость системы.
              0
              разработчик может не согласиться

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

              А разве руководитель не для того существует на проекте чтобы принимать решения? Или вы считаете что группа друзей-товарищей без лидера будет работать предсказуемо и прозрачно? Все будут вовремя делать дела, никто не будет лениться и все будут выкладываться для общего дела? Если такие товарищества существуют, то им наверно и зарплата не нужна…
                0
                А деньги — это заслуга продавцов

                Т.е. если разработчики сделают недопроект, то хороший продавец всё равно продаст его? Тогда можно пойти в ближайший университет, набрать студентов последних курсов, дать им ТЗ, когда они что-то сделают послать одного из студентов на рынок, чтобы он привел продавца арбузов, чтобы тот продал ваш продукт. Утрирую конечно, но прибыль во многом зависит и от разработчиков.
                  +1
                  Вы утрируете, а многие компании именно так и поступают. Особенно в регионах, особенно в низком ценовом сегменте.
                0
                Как я уже писал в статье, от большинства «замудрёностей» мы как раз отказались во время тестирования. По факту остались как раз те же самые оклад (зависящий от выработки сотрудника за всю историю работы в компании) и премия (зависящая от выработки в отчётный месяц).

              Only users with full accounts can post comments. Log in, please.