Эпиграф. «Критика не принимается вообще, принимается только альтернативное построение. Если оно будет лучше, чем моё, тогда я приму его как более правильное»

Статья написана под впечатлением статьи Мотивация каратистов: как перестать беспокоиться о неэффективных сотрудниках?.
В статье приводится альтернативное мнение о том как можно построить систему бонусов. Частично методика опробована на своей шкуре и показала свою высокую эффективность в прикладной области (не разработка ПО).

^{картинка для привлечения внимания}

Каждая задача имеет стоимость для бизнеса (как расход) и имеет выгоду для бизнеса (как оценка прибыли, которую получит компания, если задача будет выполнена). Обычно задачи, увеличивающие прибыль, нестандартные, т.к. если бы были стандартные, то все бы делали стандартные задачи и у всех было бы всё хорошо с бизнесом в IT. Эмпирически это не так, много стартапов и даже зрелых компаний просто проваливается.
Но даже для типовых задач такая система наград будет работать плохо. Немного мыслей со смежной области. Я учился в школе и получал деньги от родителей за оценки. Домашние задания — типичный предмет сферической задачи в терминах человекочасов. Берешь условие, применяешь правила, получаешь результат. (Важное историческое примечание. Система напрочь не работает в институте)

Сравним методики для меня и той, что была в статье.

1. Есть конкретный урок на который задано задание. Его проверят и поставят оценку. За 5 я получу много. За 4 мало или ничего. За 3 и 2 будет штраф. Какая у меня есть мотивация? Есть мотивация сделать лучше всего. Есть мотивация сделать быстрее всего, потому что остаток времени я могу играть на компе.

   А какая мотивация есть при вашей системе? Во-первых, т.к. в систему внесли заведомо неправильный рычаг, я буду максимально стараться увеличить оценочные сроки выполнения. Во-вторых, есть неявная возможность откосить от задания. Она есть всегда и на работе и в школе. Указать начальству, что есть более приоритетная задача, которую ты специально придумал. Её делать и проще и быстрее, и можно не делать какую-то фигню. Даже хуже! Я могу в репозиторий внести баг. Завести его в трекере, назначить ему время, сделать его и получить баллы.

2. Есть приоритеты между предметами. За технические предметы дают больше, за гуманитарные меньше. Бизнес (в данном случае родители) очень четко поставили приоритеты в денежном эквиваленте. Поэтому я буду стараться больше над техническими предметами — всегда есть вероятность, что если я что-то недоучил, то меня это спросят. Поэтому я потрачу больше времени на перепрочтение книги по математике, а не буду читать «Войну и мир». Если я не получу 5 по математике, а получу 4, то упущенная прибыль будет большая, а если по литературе, то ситуация более безразличная. Да, я буду стремиться получить 5, но если получу 4, то не сильно расстроюсь.

   В методологии из статьи связь с бизнесом, мягко говоря, странная. Есть конкретные задачи, которые увеличат прибыль компании. Какие-то больше, какие-то меньше. У вас есть команда. Не важно кто сделает задачу — главное, что она сделана и прибыль выросла. Расходы в месяц на команду у вас примерно фиксированы, в отличие от прибыли. Как это поправить см. п.3.

3. Есть конечная оценка в табеле за период. Я могу бесконечно читерить с оценками в процессе, но если я завалю пару важных контрольных, то я потеряю ~50% прибыли т.к. где-то половину денег я получаю за текущие оценки, а половину просто за одну циферку в табеле. Потому я очень мотивирован получить конечный результат, а не промежуточный. Надо ли говорить, что этой части у вас попросту нету. Премии в конце года — вообще не о том.

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

1. Было бы неплохо если бы разработчики вместо «у-у-у, еще одна таска» или «как хорошо, что у меня нету заданий, ничего не делаю, а деньги капают», говорили «вот результат, давай дальше», «а давай сделаем продукт лучше», «а я пользовался нашим сайтом и нашёл вот такой баг» (оговорка: намеренное внесение багов персоналом очень сложно пресечь, если оно системное, но очень легко, если оно маргинальное).
2. У нас есть конкретный лид, который отвечает за направление. У него есть некоторая информация о том, что надо бизнесу и есть команда, как средство достижений целей бизнеса.
3. Важно ли сколько человек делают задание? Если 2 задания делает 2 человека, то оно занимает 1 час. Если сначала 2 человека вместе делают одно задание, а потом другое, то будет тоже 1 час. Но есть некоторая разница. Чем больше людей будут делать задание (до определенного предела), тем больше можно заметить неточностей.
4. Никто не любит, когда им занижают ЗП, но все любят, когда им доплачивают.
5. Каждая система может быть идеальной на бумаге, но может отсутствовать способ для её построения.

Теперь пробуем собрать.
Примечание. Здесь я буду смешивать лида и PM до одной роли – «начальника».

1. Есть конкретный период. Пускай квартал. Есть квартальный отчет о прибыли. Это оценка работы всей фирмы и IT команды в частности. За увеличение прибыли компании полагается бонус. Всем участвующим. А вот делить бонус можно пропорционально тому как каждый участник вложился в результат. Ок. Бизнес выдаёт 10% от увеличения дохода за квартал как бонус.
2. Пускай у нас один лид. Сколько должен получить из этого лид — отдельный сложный вопрос, нужно думать. Но где-то 90% денег должна получить команда, которая всё делала. Лид напрямую влияет на то как он раздает задания и в результате на то сколько получит каждый. Его задачи: раздать задания относительно равномерно, чтобы больше можно было успеть, раздать задания так, чтобы они были сделаны максимально качественно, занять бездельников (в хорошем смысле этого слова, дело в том, что на разных этапах работы компании бездельничают разные сотрудники, это нормально и правильно не бороться с этим, а устранять узкое звено (см. Голдратт — Цель 1)).
3. И вот тут нам и нужны метрики чтобы разделить этот бонус. За этот период времени были задания, которые нужно было делать. Были люди, которые участвовали в этих заданиях. Логично, что чем больше человек участвовал — тем больше он должен получить. Но тут ИМХО необходимо сделать одну мелкую деталь, которую никто не делает. Добавить что-то вроде сигмоидальной функции для части, которая соответствует слишком большой награде. Почему это важно. Во-первых, проблема определить сколько получает лид. Тут становится ясно, что больше определённой суммы по формуле он просто не получит, потому смысл тянуть одеяло на себя всё меньше, чем больше ты тянешь его на себя, а не пропорционально. Во-вторых, есть управление риском, если в команде будет один рыцарь на белом коне, то bus factor будет стремиться к 1, а этого нужно избегать. Понимание асимптоты улучшает атмосферу. Ты не пытаешься лезть из кожи вон и перепрыгнуть выше головы, чтобы получить еще награду, соответственно ты перегораешь меньше. В конечном итоге это лучше и сотруднику, и лиду.
   
   Пример зарплаты в $, как функции от сделанной работы.
4. Кроме бонуса от увеличения прибыли нужно добавить бонус от текущей прибыли. Это важно т.к. если компания стабильна, то система попросту не будет работать. Нет примеров положительного подкрепления.
5. Некоторую фиксированную часть от бонуса жизненно необходимо сделать субъективной. Эта часть должна отражать отношение менеджера к тому как работает данный отдельный сотрудник.
6. Нового сотрудника будет достаточно сложно нанять. Если предлагать ему rate ниже рыночного + бонус, то все скажут «знаем, плавали», а если дать сразу 4k$ + бонус, то уже начальство засомневается «а не взять ли нам более эффективного менеджера». Потому должна быть плавная интеграция нового сотрудника в культуру компании. Первые 3 месяца — условный испытательный срок. Тут только fixed rate. Дальше следующие 3 месяца на сотрудника уже распространяются бонусы как и на всех. Но урезанные в 2 раза. Здесь сотрудник может ощутить силу бонусов к мотивации. После первого получения бонусов сотруднику оглашается, что вообще-то теперь он может перейти с большого fixed rate и мелкого разброса бонуса, на меньший fixed rate и больший разброс бонуса. Возможны несколько опций, обсуждается с бизнесом.
7. Хитрым раздолбаем быть не получится. Если ты делаешь постоянно по минимуму «чтобы просто получить fixed rate», то это продержится недолго. В момент когда предложат перейти с safe fixed rate, хитрый раздолбай останется на старых условиях, но это автоматически привлекает внимание непосредственного начальника. Вот такая обратная связь.
8. По построению личная неэффективность пресекается слабо. Т.е. если ты делаешь меньше чем все — ок, на этом этапе ты бездельник, но потом у тебя может быть возможность проявить себя на другом задании. Если не можешь проявить себя никак — до свидания. Если личная неэффективность перерастает в что-то большее и уже мешает части команды нормально работать (что влияет на их бонусы), тогда «до свидания» может наступить гораздо раньше.
9. Подчиненный вполне может получать больше чем его непосредственный начальник. Это нормально, более того, это позволяет карьерный рост без смены конторы или перехода на уровень некомпетентности (см. Принцип Питера)

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

Автор:

Источник