Мотивация. Сделай сам

В целом, все так и происходит в отечественном бизнесе: HR не понимают, что от них хотят, (справедливости ради, не все они бездарные) представитель от бизнеса — несусветный дебил/эффективный менеджер и на выходе непрозрачная система мотивации с 30-ю KPI, от которой все ох… ют и увольняются за пару месяцев.
Из моей практики, основная проблема в подсчёте стоимости продаваемого продукта и параметров, которые в эту стоимость входят: закупка+ логистика+продажа+доставка+всякая фигня (а стоимость электричества потраченного на складе заложили в стоимость продукта? А амортизацию погрузчика? А расходы какого-либо Васи на телефонию?). Обычно тут возникает много проблем...

Методичка понятная, не хватило примеров из реальной работы: как и что настраивали, где и кто/что "отваливалось"… Может отдельную статью?

Ну, и не программистом единым; есть ещё люди "в наших селеньях", которые могут нормальные системы мотивации делать, запускать и автоматизировать.

Например, в случае с программистами можно изолировать тех.поддержку пользователей — посадить отдельного человека на эту работу.

одного из двух?

Как по идее выглядит мотивация для разных сторон?
Владелец бизнеса заинтересован в некоей субстанции, которая будет сама вынуждать работников работать больше и качественнее. В идеале, чтобы работники за бесплатно и живя на работе делали самый лучший продукт на свете.
Работники заинтересованы в повышении зарплаты и снижении усилий для этого. В идеале, чтобы платили чемодан денег в день за отсутствие на работе.
Т.е. эта некая субстанция имеет противоположные свойства для владельца бизнеса и работников.
Имхо, решение этого конфликта и есть создание эффективной системы мотивации.

За свою практику тоже повидал не мало хороших и плохих систем мотивации.
Хорошая практика:
Есть «конвейерная» монотонная работа. Возьмем, к примеру, кассира в магазине. Его задача — быстро обслужить людей. Ок, меряем скорость сканирования по чекам. Еще магазин должен быть чистым — вводим проверки и балы соблюдения стандартов. Также магазин должен получать прибыль — не вопрос, это легко измерять.
Плохая практика:
Фактически все сводится к применению тех же практик, что и к кассирам к командам разработки и это в корне не верно. Что тут обычно меряют (реальные примеры из жизни)
— Скорость решения задач — задача может быть как на 5 минут, так и на неделю. Естественно разработчики начинают усреднять — 5-ти минутную задачу делать по 2 дня.
— Выполнение планов проектов — не видел ни разу проекта, который бы шел по плану. А не вру, видел — проекты в которых сроки завышены минимум в 2 раза (опять же чтобы снять риски по мотивации)
— Количество отработанных в день часов. Естественно, все будут фигачить себе задач на 8 часов в день. Опять соврал — чтобы не спалились ставят рандомное число в пределах от 7,5 до 8,5 часов :-)
И еще несколько более запутанных комплексных показателей.

Единственная правильная мотивация для программистов это регламентный пересмотр оклада и ролей в команде согласно единственного измеримого показателя — скилов. И не нужно никакой заумной аналитики и якобы «объективных» KPI.

Ни разу не видел работающую сложную систему мотивации. Один параметр + какие-нить штрафы — идеально. Из разряда 1% с продаж + 1000 рублей за опоздание. Скользящие триады и зеленые буферы — все это работать не будет.

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

ага, как правило, это — руководители, которые быстренько вам эту систему порушат общими усилиями (а власти в данной конкретной конторе у них всяко больше, чем у одного супергероя)

В идеале система мотивации работает так:
— Сделал больше — заработал больше. Причем, это самое «больше» абсолютно прозрачно и рассчитывается открыто для сотрудника. Он заранее должен знать сколько получит сверху.
— Компания выигрывает от того, что можно отложить наем дополнительного сотрудника. Один мотивированный на 120% выработки лучше, чем двое загруженные по 60%.

Что, как правило, имеем в реальности:
— Система мотивации повышает нормативы выработки без адекватной компенсации. Зачастую, от сотрудника вообще скрыт механизм расчета премии. Вполне, могут появляться такие факторы, как: «настроение начальника», «общая ситуация в компании за расчетный период»… Т.е. работаешь больше за практически те же деньги, что в пересчете на часы, даже меньше.

KPI для программиста может быть один — эквивалентные человеко-часы. То есть у Вас есть архитектура. Каждой составной части архитектуры поставлена в соответствие трудоемкость. Кодеры разбирают составные части и реализуют их. Сумма трудоемкостей реализованных кодером подсистем и образует его KPI. Правда при такой системе может оказаться, что один программист заработал в десять раз больше другого :) Все Ваши проблемы от того, что у Вас архитектуры нет, декомпозиции задачи на подсистемы нет, спецификации подсистем нет, отсюда и невозможность трудоемкость реализации подсистем определить. Пока нет архитектуры, пока нет экспертной оценки трудоемкости реализации, споры об оценке труда программиста будут продолжаться.
Где-то читал умную вещь: единственный способ оценить KPI программиста — экспертная оценка. Т.е. нельзя управлять программистом, абстрагировавшись от задачи, которой он управляет. Поэтому оценить программиста может только эксперт, от слова experience — опыт. И только на основании своего опыта работы программистом. Тогда он может сказать, что вот этот кодер выдает крутой код и очень быстро. А этот пишет долго и некачественно. А со стороны может показаться, что первый кодер решает простые задачи, а второй — сложные.