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

    Есть такая полезная задача — разработка систем мотивации. Я долго наблюдал за несчастными HR, которые создавали системы KPI, материальную и нематериальную мотивацию, силились поднять корпоративный дух. Мои наблюдения всегда показывали одно и то же — HR в этой работе чего-то не хватает. Вроде слова правильные говорят, и философия под их расчетами правильная лежит, но созданные ими системы мотивации не выдерживают никакой критики.

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

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

    Итогом почти всегда является «какая-нибудь» система мотивации, которая хоть что-то считает и дает хоть какое-то представление об эффективности работы людей. Но главная беда — система мотивации не приносит пользы бизнесу, потому что оценивает людей по критериям, ему не выгодным.

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

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

    Кто в современном российском бизнесе тот человек, который по сумме компетенций — лучший в перечисленных областях? Программист, кто же еще.

    За свою бытность программистом и кем-то типа ИТ-директора я руководил или участвовал в разработке десятка систем мотивации — для программистов, кладовщиков, конструкторов, снабженцев, руководителей. В разработке систем мотивации я участвовал на разных уровнях. Сначала — автоматизировал расчет показателей, которые кто-то придумал. Потом участвовал в составлении показателей, как «представитель ИТ-отдела, который понимает сложность их расчета». Когда понял, что дело не в технике расчета, а где-то выше, попробовал сделать мотивацию для своих подчиненных. Когда она принесла людям прирост в деньгах, а компании — увеличение производительности людей вдвое, меня, в тестовом режиме, отправили делать систему для кладовщиков. Когда, благодаря этой системе, исчезли проблемы с несвоевременной погрузкой/разгрузкой/комплектацией и т.п., меня стали втыкать во все проекты по разработке мотивации. На моем месте, естественно, может быть любой программист.

    За время этой работы я сделал ряд наблюдений о том, каким принципам и критериям должны удовлетворять взаимовыгодные системы мотивации. Спешу поделиться.

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

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

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

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

    Главное — продукт и его характеристики должны быть выгодны бизнесу. Вот тут, увы, вам никто особо не поможет с формулировкой продукта. Надо просто поговорить со всеми, кто причастен — в первую очередь, с внутренними потребителями, заказчиками этого продукта. Какие реальные проблемы у них возникают, и из-за какой именно характеристики (качество, сроки, своевременность и т.д.).

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

    Решил задачу, получил оценку выше 4 баллов, уложился в срок — выработка засчитана. Не выполнил одно из условий — не засчитана (или засчитана с дисконтом). Это и будет продуктом.

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

    У меня был пример с таким распараллеливанием. Был у нас директор, которому я не нравился. Я, в общем-то, никому обычно не нравился, т.к. слишком много задавал вопросов, отклонял задач и проектов, и максимально доходчиво объяснял, почему решение какой-то задачи не принесет выгоды бизнесу. Ну, была у меня мысль, что именно этим должен заниматься ИТ-директор.

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

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

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

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

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

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

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

    Если это что-то полезное, относящееся к продукту — отлично, вносим как характеристику.

    Еще вариант, когда точно решить не можете — изолировать эту обязанность, и посмотреть что будет. Например, в случае с программистами можно изолировать тех.поддержку пользователей — посадить отдельного человека на эту работу. Важно, чтобы выполнение этой обязанности всеми подряд не могло служить отговоркой («мы не сделали выработку, потому что все вместе помогали этой дуре»). При изоляции влияния не будет, и вы сможете понять как объем этой странной обязанности, так и ее пользу для бизнеса.

    Например, размазанная на всех тех.поддержка, вроде бы, занимала очень много времени. Точно никто не знал, сколько, и у кого, но ощущение у всех было, что «целый день звонят, как они уже задолбали, только сядешь, вникнешь — опять звонок». А когда тех.поддержку изолировали, оказалось, что она занимает максимум 4 часа в день у одного человека. При этом он никого из коллег не дергает, сам со всем справляется.

    Итак, вы сформулировали продукт — чего вы хотите от функции.

    Теперь нужно решить, сколько этого продукта вы хотите. Принципиально варианта два:

    1. Как можно больше (потолка нет)
    2. Не больше, чем нужно (потолок есть).

    Для продавца потолка нет. Для снабженца — обычно есть. Для инженера-конструктора — нет. Для менеджера по персоналу — есть.

    От наличия потолка зависит формула системы мотивации: сдельная или за достижение/поддержание уровня.

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

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

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

    Например, платить снабженцу процент от прибыли с продаж того, что он купил. Или платить инженеру-конструктору процент от продаж того, что он сконструировал (типа авторский процент).

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

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

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

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

    Итак, если потолка нет — определите, сколько вы платите за единицу продукта. Обычно это процент с продаж/прибыли, или некая ставка — почасовая, например. Дальше дело техники.

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

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

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

    Поэтому и рекомендую триаду — сразу менять и систему мотивации, и бизнес-процесс, и автоматизацию.

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

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

    Расценка при этом примерно равна отношению дохода человека к объему произведенного продукта. Возможно, с небольшим снижением, чтобы был стимул делать больше.

    На этом все — автоматизируете, тестируете, запускаете, следите и корректируете.

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

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

    Подробнее
    Реклама

    Комментарии 17

    • НЛО прилетело и опубликовало эту надпись здесь
        0
        Мне кажется, вываливать сумму премий в открытый доступ — плохая идея. Дружный коллектив мгновенно начинает звереть, обстановка в компании становится нездоровой.
        А так, идея с «акциями» неплохая, конечно
        0

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


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


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

          +2

          Какой продукт и в чём измеряется у самого программиста?

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

              У вас два программиста? У меня 4 было.

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

                Единственная правильная мотивация для программистов это регламентный пересмотр оклада и ролей в команде согласно единственного измеримого показателя — скилов. И не нужно никакой заумной аналитики и якобы «объективных» KPI.
                  +1
                  Еще магазин должен быть чистым — вводим проверки и балы соблюдения стандартов.
                  Оффтоп, кончено, но я представил себе бал соблюдения стандартов: Продавцы с причёсками и в корсетах, делают реверансы покупателям, грузчик во фраке изящно ведёт рохлю по проходу… Красота))
                  0
                  Ни разу не видел работающую сложную систему мотивации. Один параметр + какие-нить штрафы — идеально. Из разряда 1% с продаж + 1000 рублей за опоздание. Скользящие триады и зеленые буферы — все это работать не будет.
                    0
                    Проблема в том, что как только появляется работник, который зарабатывает достаточно, чтобы терпеть штрафы, то систему рушат ее же создатели.
                    Т.е. если найдется продажник, который зарабатывает от 100к и готов платить каждый день 1000 за опоздание, то начальство сразу же сменит правила игры.
                    +1
                    те, кто привык прятаться в общей массе, когда личный результат не измерим. Также те, кто пришел просто посидеть.
                    ага, как правило, это — руководители, которые быстренько вам эту систему порушат общими усилиями (а власти в данной конкретной конторе у них всяко больше, чем у одного супергероя)
                      +3
                      В идеале система мотивации работает так:
                      — Сделал больше — заработал больше. Причем, это самое «больше» абсолютно прозрачно и рассчитывается открыто для сотрудника. Он заранее должен знать сколько получит сверху.
                      — Компания выигрывает от того, что можно отложить наем дополнительного сотрудника. Один мотивированный на 120% выработки лучше, чем двое загруженные по 60%.

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

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

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

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

                          Самое читаемое