105,7
рейтинг
27 сентября 2012 в 08:28

Управление → KPI, или пособие по командному самоубийству

Для написания этой заметки  было затрачено:

  • 68338 километров на поездки.
  • 72 человеко-часа на почтовую переписку.
  • 423 человеко-часа на эксперименты с коллективом в 30 человек.
  • 88 часов на подготовку докладов и выступления на конференциях.
  • 17 чашек кофе на беседу с мудрыми людьми на афтепати.
  • Порядка 25 часов на набор этого текста и правку багов в нем :).
  • До смерти замученный копирайтер, который был вынужден разбирать мои черновики, аудиозаписи и вообще ему спасибо.


Много денег и времени. Пожалуй, самым затратным (по нервам, времени и деньгам) был эксперимент над собственной командой, о котором мне безумно неловко вспоминать. Но об этом — ниже.

Рано или поздно, наверное, у каждого директора возникает желание платить по справедливости. За выполенную работу. И очень многие сейчас пытаются внедрять KPI (ключевые показатели эффективности). Работает так: вы, как владелец бизнеса, назначаете конкретные цели для сотрудников. Они достигают или не достигают поставленных целей в процессе работы. Тем, кто достиг — выдается плюшка (денежная премия).

Смысл такого подхода: платить по справедливости. На сколько наработал — столько и получил. Это честно, это логично, это — прекрасно!



Ну, логично же, что:

  • Продажникам  нужно назначать процент с оборота. Волки должны быть голодными. (Да, есть альтернативное мнение, что применить такой подход — значит «обложить себя дополнительным налогом». Но как по мне — тут все справедливо :-)).
  • Офисному планктону — ставить оклад. Стабильность для них — ооочень важное условие существования.


А вот с творческими единицами (дизайнерами, программистами) — все значительно сложнее.

Мы недавно провели опрос руководителей ведущих диджитал-агентств и веб-студий страны на тему «а как вы используете KPI по отношению к труду творческих единиц», в результате получили вот такую картинку:



Некоторые компании (15%) применяют KPI для оценки эффективности труда программистов и дизайнеров.

Около 25% компаний внедряют KPI в данный момент / встречают сопротивление внутри компании или же работают по упрощенной схеме.

Примерно 30% компаний производит оплату труда работников на основе субъективных оценок руководителей. Вернее, 30%  сознаются в этом ;-)
Не сознаются  оставшиеся 30%.


Самое интересное, что многие пытались внедрить KPI или пытаются сейчас. Причем не очень успешно. Это не значит, что «KPI плохой». Плохо приготовленную пищу  есть невозможно. Может, мы просто не умеем этот KPI готовить?

Но статистика говорит о том, что затруднения при внедрении есть у подавляющего большинства. И есть подозрение, что таки проблема у всех общая. Давайте попробуем разобраться.

Первое, с чем придется столкнуться при внедрении KPI — сопротивление коллектива



Возникает вопрос: что сильнее всего парит разработчиков при внедрении KPI?

Проведя несколько экспериментов и опросов среди коллег, мы выделили 6 основных причин:

  1. Боязнь новизны. Все тотально боятся нововведений, думая, что станет хуже (меньше денег, больше работы и т.п.).
  2. Непрозрачная схема. Используя схему материальной компенсации со множеством параметров, мы повышаем риск того, что работники ее не поймут. Людей бесит и демотивирует, когда они не понимают, как именно им достигать наилучших результатов или почему они вдруг получили меньше денег.
  3. «А че так много?». Да, такое тоже бывает. Если схема построена таким образом, что результат этого месяца появится только через два-три. «В этом месяце я работал хуже, а получил больше. Значит, в прошлый раз мне недодали. Руководство — идиоты, ничего не понимают в моей работе!»
  4. ЧСВ работника. Практически нереально попасть в самоощущение человека и выдать ему «справедливый» бонус.
  5. Неполная зависимость достижения критерия от работника. От дизайнера, например, не совсем зависит, будет ли продан нарисованный им дизайн или придется делать 50 правок.
  6. Отчеты. Не знаю никого, кто любит писать отчеты, проставлять затраченное время, обещать «точные сроки».


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

ОК. Значит, нужно просто придумать Хорошие Критерии!



Ну такие, которые все поймут, которые не будут никого парить, которые будет просто объяснить даже на собеседовании. И чтобы было все честно, и хотелось работать еще и еще.

В общем, давайте попробуем найти Хорошие Критерии. (Кстати, «Хорошие» — для кого?). У нас есть три ключевых пострадавших стейкхолдера: владелец студии, заказчик и разработчики.

Что может быть Хорошим Критерием с точки зрения заказчика? Обычно всё сводится к деньгам (ну либо каким-то фактическим результатам):

  • ROI — грубо говоря, это «отдача от финансовых вливаний». Выведенный экономистами показатель не совсем применим к разработчикам: ведь они не могут контролировать отдачу от своей работы и на ходу измерять ее в деньгах. То есть не могут напрямую влиять на показатель.
  • Низкая стоимость фичи. Для заказчика выгодно иметь низкую стоимость фичи. А для разработчика это — разрыв шаблона («Как это так: я получаю больше денег за то, что дешево работаю?»).
  • Степень удовлетворенности. Не знаю, как ее считать, но если учитывать, что люди хотят счастья или хотя бы меньше париться (© Дмитрий Сатин), то можно предложить даже вот такую формулу:




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

  • Дата релиза. Вроде бы все логично: сдаем проект вовремя — получаем много денег, сдаем досрочно — получаем еще больше денег. Показатель годный, но имеет уже обозначенную проблему: не всё зависит от разработчика. Затык по срокам чаще всего возникает с клиенто-менеджерской стороны. (Отсюда справедливое: «Почему я должен терять в зарплате, хотя это менеджер не выбил с заказчика контент?»).


ОК. Эти Критерии, Хорошие для заказчика, очевидно, не будут Хорошими для разработчика. (Я без иллюзий, сейчас можно запросто придумать еще 200 штук разных критериев, значимых для бизнеса. Пишите, обсудим в комментариях :))

Но ведь можно мерить ПРОИЗВОДИТЕЛЬНОСТЬ! Это же так просто!

Или нет? В чем ее мерить? Если бы я красил забор — то все очевидно. Но есть заковырка. В нашей отрасли много мыслящих, творческих, талантливых людей и заборы никто не красит. Давайте разберем на примере программистов. Итак, какие Хорошие Критерии оценки производительности приходят на ум?

  • KSLOC. Знаете, что это? А что такое индусский код — знаете? Внедрите — узнаете. KSLOC — это количество тысяч строк кода. Если вы привязываете этот показатель к зарплате, то ждите тыщи строк копипасты. Один мой знакомый получил выполенный заказ где-то в Бангалоре — php-скрипт, всего за десять долларов, но на целых 20 Mбайт. И он работал!
  • Количество какого-то дерьма в час (WTF/h). Количество нарисованных страниц в день, количество реализованных фич в час и т.д. Вроде бы нормальная метрика — что-то можно реально подсчитать и использовать для раздачи плюшек. Однако возникает проблема, аналогичная предыдущему пункту: падение качества в ущерб количеству, рост технологического долга. Мотивация, интерес, удовлетворенность — всё стремительно падает вниз. Как результат, текучка и низкая квалификация.
  • Количество багов. Чем меньше багов — тем больше платим. Все логично, не правда ли? На самом деле  нет. В вашей студии внедрен багтрекер? Если да — забудьте. Ваши тестировщики очень скоро договорятся с вашими программистами о том, сколько багов писать, а сколько — нет, чтобы это было не в ущерб обеим сторонам.
  • Переработки. «Если ты задерживаешься на работе — ты плохо работаешь». Тоже ведь логично? Боремся с переработками, например, отключаем электричество после 18:00. Однако тут нужно помнить, что психология разработчика в корне отличается от психологии офисного планктона: если он сидит до вечера, значит, ему интересно (и это надо поощрять).


В нашей сфере люди работают в основном потому, что им это интересно.

Не надо им мешать тупыми корпоративными правилами.

  • Focus Factor. Эта метрика пришла к нам из любимого мною скрама. Показывает, сколько задача должна была занять в идеале, а сколько вышло в итоге. «Концентрация» команды над проектом. Можно ли платить деньги на основе этого критерия? Вполне, но, если ваши менеджеры — не «технари», то программисты будут сознательно завышать оценки по времени, сводя к минимуму свои собственные риски. Следствие такого подхода — растягиваются сроки, заказчик негодует (или покупает не у вас). Да, и каждая планерка будет превращаться в склоки и споры за 10 минут.
  • Velocity. Тоже из скрама. Пресловутая «производительность». Тут довольно неочевидно, гуманитарии могут пропустить абзац.




Позволяет предсказать, сколько задач команда сможет набрать в следующий этап в зависимости от того, сколько она выполнила в предыдущем. Проблемы такие же, как у фокус-фактора, плюс добавляется еще одна. Часто менеджер (особенно неопытный), почуявший, что производительность команды можно «измерить», начинает применять данный инструмент «в другую сторону». Но Velocity не может быть точным критерием, т.к. показывает, сколько времени может занять та же самая задача, выполняемая той же командой при тех же условиях. Однако после выполения задачи  команда уже поменялась: у нее появился опыт того, как именно решать конкретно эту задачу. И метрика не сработает повторно.

  • Cycle time. Насколько быстро проходит время с того момента, как возникла идея реализовать фичу на проекте, до того момента, как она была сделана.


Мне лично очень нравится эта метрика. Одна из ключевых, которую стоит замерять и оптимизировать. Но разработчики не влияют на этот фактор напрямую. Это слишком высокоуровневая метрика. Если вы начинаете платить команде зарплату на основании того, какой у них Cycle Time, это значит, что вы как руководитель не стремитесь решить проблемы команды и разобраться в процессах, а просто переваливаете все на команду.

Попытка поставить зависимость зарплаты разработчика от высокоуровневой метрики — свидетельство менеджерской импотенции

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



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




История одного безумия



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

— ежемесячный план по отработанным человеко-часам и фактически отработанному времени;

— ежеквартальный план по сбыту;

— количество подопечных и их зарплаты;

— количество позитивной коммуникации от клиентов (удовлетворенность);

— количество повторных обращений клиента с новыми проектами;

— награды на профильных конкурсах;

— отрицательная коммуникация с клиентом;

— количество багов, найденных QA;

— рост дебиторской задолженности;

— количество багов, найденных клиентом после старта проекта;

— чтение книг, написание статей.

И еще штук 20. (полезный список, забирай ;-)).

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

Буквально в течение 1 часа лица сотрудников сделались сильно-сильно хмурыми. Через пару дней начались вопросы: «а почему мне меньше фантиков?» или «а почему мне не дали фантик — я же Васе помогал?».

Настроение становилось тревожным. Через неделю на оценку проектов стало уходить в 4 раза больше времени, чем уходило раньше, и каждая оценка превращалась в бесконечный спор между разработчиком и руководителем проектов. К концу месяца мало кто хотел помогать товарищу — объясняли тем, что «своей работы хватает». Вскрылось бесконечное количество ситуаций, которые невозможно было формализовать. Многие фантики выдавались по субъективным ощущениям.

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




В качестве вывода:



Разные метрики стоит измерять и думать-думать-думать, как на них влиять. Но не переносить высокоуровневые метрики напрямую на разработчиков и дизайнеров. И еще.

«Разработчик состоит из четырех компонентов: тело, сердце, разум и душа.

1. Телу необходимы деньги и безопасность.
2. Сердцу — любовь и признание.
3. Разуму — развитие и самосовершенствование.
4. Душе — самореализация».

С. Архипенков


Уважайте других людей и давайте им возможность делать то, что им нравится )).

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

  1. О вреде премирования (Джоэл Спольски).
  2. Не мешайте мне работать (Стас Давыдов).
  3. Денежная мотивация в проектах разработки ПО (Асхат Уразбаев).
  4. Метрики в Agile (встреча AgileRussia.ru 2009-08-18).
  5. Базовые показатели ударников капиталистического труда (Лариса Харахинова).
  6. Сколько нужно платить разработчикам (Хабрахабр, перевод).
  7. Business Intelligence (Хабрахабр, В. П. Савчук).
  8. Мотивация IT-специалистов (Хабрахабр).
  9. Система сбалансированных показателей как инструмент управления компанией/подразделением (Хабрахабр).
  10. Какие KPI можно измерять, если расписание и бюджет не очень важны (Хабрахабр).
  11. Показатели эффективности (KPI) для сотрудников ИТ (Хабрахабр).
  12. Мифы мотивации. Выход из тупика (Райнхард Шпренгер).
  13. Методы мотивации сотрудников (Юлия Лаврик).
  14. Пособие: как убить сотрудника пряником? Или методы мотивации (Валентин Поляков).
  15. Почему программистам не платят пропорционально их продуктивности (Хабрахабр, перевод).
Владимир Завертайлов @zevvssibirix
карма
125,0
рейтинг 105,7
Главный бармалей
Реклама помогает поддерживать и развивать наши сервисы

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

Самое читаемое Управление

Комментарии (119)

  • +34
    Не люблю руководителей, которые болеют KPI. Они сами до конца не верят в свои системы и постоянно подкручивают разные параметры, глядя на конечные зарплаты. В итоге при прочих равных, зарплата остаётся в пределах рынка, даже если ты упахиваешься по самое не могу.
    А больше всего демотивирует то, что перед тобой то морковка, то надкусанное яблоко, то ничего, то хлыст сзади, то виртуальная возможность повышения, то медаль с грамотой.
    Начитаются, тренингов напроходят, а потом с шашкой наголо меняют то, что с пеной у рта доказывали три месяца назад.
    • +4
      Справедливо. KPI — суть эксперимент, направленный на выработку условных рефлексов у испытуемых. Хорошо подходят для роботов и ограниченного числа людей некоторых типов.
      • 0
        Не совсем согласен, только отчасти.

        Любые изменения в продукте/программе/сайте должны иметь KPI действия. Например, по моему опыту, перестановка одной кнопки в коммерческом продукте дало дополнительную прибыль в размере $200 в день, итого 6 000$ в месяц. Разве это не KPI? Эффективность то возросла.
        • +2
          Есть, однако, типы изменений, которые не дают очевидного на первый взгляд или легко измеримого коммерческого результата. Например, всевозможные системные работы, рефакторинги и т.п. Я сталкивался с ситуацией, когда начальство не давало делать подобные работы, именно мотивируя отсутствием видимой коммерческой пользы. Результат, увы, предсказуем :(
          • 0
            Тогда просто глупо применяет KPI к таким изменениям. Разве багфиксинг можно оценить в %, долларах или в рублях!
            • 0
              Тут вопрос такой: о каком применении идёт речь? Если о применении для оценки производительности программиста, то невозможно оценивать одни действия и не оценивать другие, результат будет бессмысленным и непредсказуемым. Ну, чтоб далеко за примером не ходить, я в прошлом месяце занимался разными изменениями в системах монетизации нашей игры, и коммерческий эффект был очевиден. А этот месяц я почти весь потратил на коренные изменения структур данных, которые (изменения) должны в будущем предотвратить серьёзные проблемы с базой данных. Но это в будущем, а пока эффекта — ноль целых ноль десятых.
              • 0
                это как раз случай из цикла «Программист решает, неизвестными вам методами, проблемы о которых вы не подозревали» измерить с помощью KPI невозможно. Нельзя внести в план, нельзя запланировать время которое будет на это потрачено. С одной стороны, «надо было сразу нормально делать», с другой код без ошибок не пишет вообще никто…
        • +1
          Не однократно сталкивался с ситуацией, когда за плевую доработку в одну строчку мне начислляли 100% KPI, а тяжелая, рутинная работа по предотвращению пока еще не проявивших себя проблем, вобще не попадала в оценку эффективности. Реально не однократно возникали мысли, действительно все запустить на столько, чтобы проблемы стали очевидны, и лишь тогда их героически решать и получать за то заслуженное вознаграждение.

          Надо помнить еще и закон Паретто — 20%усилий делают 80% результата. Система мотивации, построенная на оценке результирующей эффективности демотивирует делать 80% работы, дающих лишь 20% результата.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Согласен, что дело в руководителе. Руководитель получил теоретический опыт и пытается внедрить на практике. И, я больше уверен, что с первого раза мало у кого получается сделать наиболее сбалансированную систему. Вот так отрезать — не работайте у таких — это не верно. Тот же руководитель (если человек грамотный), должен оценивать ситуацию не только со своей стороны, но и со стороны подчиненного.
        Если же у руководителя не получается, то почему бы не попробовать самому продумать как лучше организовать систему оценок и обсудить с тем же руководством? Каждый смотрит со своей колокольни! И в споре можно родить вполне рабочий вариант!
        Самое главное, чтобы была одна цель — повышение заинтересованности в качественном продукте, а не снижение ЗП у руководителя любой ценой, а у работника повышение ЗП любой ценой.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            А одно другому не мешает!
            Грамотно составленная мотивация даст дополнительный заряд энергии продуктивным и заинтересованным работникам — тем самым заработав на них, и позволит выявить лентяев, снизив им ЗП, и сэкономив на них.
            Не думаю, что сотрудник, который отдается делу со всей душой, доволен тем, что у него ЗП одинаковая с лентяем.
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                Я немного не понял сравнение. Можно еще один пример, но ближе к теме статьи?
                • НЛО прилетело и опубликовало эту надпись здесь
                  • +1
                    >У одного широко известного владельца дизайн-студии дизайнер может получить премию даже за непринятую клиентом работу.

                    Еще, одному известному владельцу дизайн-студии очень выгодно создавать подобные мифы.
                    • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      KPI — это объективные метрики эффективности работы. И они очень важны для руководителя. Только вот почему-то в 90% случаев на KPI завязывается зарплата, с закономерным итогом.
  • +10
    После первого абзаца ожидал опыта реального внедрения подобной системы, получилось опять: «KPI для разработчиков лишний геморрой». Вся проблема в смещении фокуса с работы, на эффективность увеличения коэффициента. Человек не может каждый месяц одинаково хорошо работать (весеннее обострение, летнее отпускное настроение, зимняя спячка и т.д.), а зарплату хочется получать стабильную. Когда к этому прибавляется возможность получить больше «чуть-чуть» больше поработав в конечном итоге приходим к варианту 1. Человек не может каждый месяц увеличивать свою эффективность до бесконечности и 2. в конечном итоге наступает момент когда «я пашу — а мне платят не столько сколько я ожидал», приходит разочарование и апатия. Грубо говоря при выходе на пик эффективности человек считает теперь этот пик своей «заслуженной-стабильной зарплатой» и все неизбежные падения ниже этого уровня воспринимаются как «наказание».
  • +6
    После первого абзаца ожидал опыта реального внедрения подобной системы

    А разве «пособие по командному самоубийству» в заголовке не утверждает обратного?
  • +4
    Может, у меня сформировалось неправильное мнение относительно подобных методик, но мне кажется, во все это руководители начинают «играть», когда просто не могут ничего другого сделать. Мне как работнику не хочется видеть никаких фантиков, не хочется тратить лишнее время на то, чтобы поиграть с менеджерами в очередную оценку сроков. Если руководство не может оценить работу сотрудников без всего этого фарса, то, может, пора менять руководство? Все же просто на самом деле: нанимайте грамотных работников, заинтересованных в своей работе. Да, никто не станет упахиваться до издыхания, чтобы удовлетворить ваше желание как начальника закончить побыстрее, сдать проект пораньше, но оно и не надо. Важно, чтобы каждый сотрудник постоянно имел уровень мотивации выше нуля, а для этого не нужно никаких оценок.
    • +3
      Имхо, KPI — это удел менеджеров среднего звена. Топ-менедженту обычно важна общая эффективность, улучшение качества продукта и (как следствие) снижение расходов (да-да, качественный код снижает расходы) при увеличении доходов (ну и понятно, что он при всех остальных равных увеличивает доходы за счёт повышения стабильности и, как следствие, увеличению удовлетворённости клиента).

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

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

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

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

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

      Итог очевиден.
  • +2
    Спасибо за проделанный труд.
  • +5
    Пора создавать партию борцов против количественного измерения эффективности работы работников творческих профессий :)
    (ПБПКИЭРРТП)

    Если взять две мои же статьи (Способы оценки эффективности работника и Вавилонская башня менеджмента), да сложить их в кучу, то можно сделать несколько простых выводов
    1. Если руководство компании пытается считать эффективность работников любым способом, кроме подчета разницы между доходами и затратами, то грош цена такому руководству. Любые количетсвенные показатели кроме денег не имеют для них аболютно никакого смысла. Приведу простой пример. Есть команда из 5 человек. Совокупные расходы на оплату их труда составляют $15K. Продажа продукта X приносит $30K. Пусть прочие расходы равны $10K. Прибыль составит 30 — 15 — 10 = 5. Как добиться прибыли в 15К? Вариантов всего три: сократить расходы на 10К, увеличить доход до 40К или сократить расходы на 5 и увеличить доход на 5. Сокращение расходов равно увольнению сотрудников. Это снижает интеллектуальную «силу» (потенциал) компании на рынке. Повышение доходности на продукте X можно не достигнуть, так как рынок насыщен. Но зато можно написать продукт Y, который может дать доход не 30К, а 100К. И какая тогда разница, насколько именно эффективен работник? Да, собственно, никакой.
    2. Производственный менеджмент должен уметь оценивать расходы и находить способы их оптимизации. Например, некоторыми вполне примитивными условиями написания кода (соглашение о написании кода, принцип устойчивости кода, построение конструкторов) можно добиться весьма впечатляющего повышения эффективности труда без создания стресса для работника. Однако, в большинстве случаев, ПМ преследует свои собственные корыстные цели, а не цели компании. Ему важно сохранить свое место в компании любой ценой.
  • +4
    у хорошего руководителя субъективая оценка более объективна, чем KPI.
    KPI надо применять только к самому руководителю.
    • +13
      У хорошего руководителя субъективная оценка более объективна, чем объективная. Потому что в теории между теорией и практикой отличий нет, но на практике они есть. Да и вообще в действительности всё не так, как на самом деле.
      • 0
        Вы мысль выразили очень правильно и точно, но, если в читаться в то, что Вы написали, то возникает легкий ступор от игры слов ;)
      • +2
        Хотел бы посмотреть на ваш код. Вроде и работает, а разобраться — мозг сломаешь)
      • +1
        Точнее, на практике различия между теорией и практикой намного больше, чем в теории.
      • 0
        Согласен с вами. При наличии толкового руководителя и KPI не нужны, т.к. такой чеовек знает своих подчинённых настолько, чтобы платить им по справедливости и мотивировать их, исходя из множества факторов, которые нереально выразить в виде формулы. Бестолковым же руководителям никакие показатели не помогут.
        • 0
          Интересно, что все подразумевают под словами «толковый руководитель»?
          Неужели вы думаете, что толковые руководители действуют только «на интуитиве», у любого толкового руководителя — в голове и собираются те самые метрики о которых сейчас идет речь (метрики по которым он судит — о вкладе каждого сотрудника в проект и необходимости дополнительной мотивации) — только эти метрики не формализованы и учитывают психологический контекст сотрудников.

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

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

          Теперь уже не мое мнение, а мнение Патрика Ленсиони «Три признака унылой работы» (название книги звучит пошло, но идеи там раскрываются — интересные, советую):
          Для того чтобы человек чувствовал себя «удовлетворенным от работы», необходимо:
          — сотрудник должен знать социальный контекст коллектива в котором он работает (вы должны быть на короткой ноге, чтобы не создавалось ощущение «чужих» или «не в своей тарелке» или «вокруг одни враги»);
          сотрудник должен уметь оценивать свою работу, только наличие оценок сможет позволить сотруднику увидеть прогресс/результат (а получение результата — приносит удовольствие);
          — сотрудник должен знать, на чьи жизни он оказывает влияние своей работой (результатами своей работы), это позволит делать не просто продукт, а продукт для «кого-то».
          Заключение: один из признаков, это оценка своей работы (а именно личная метрика по которой ты оцениваешь успешность своих усилий)…

          От метрик никуда не деться, эти метрики в нас — просто мало кто их формулирует…
          • 0
            По-моему, вы достаточно точно раскрыли понятие «толкового руководителя». Ему действительно не обязательно выписывать формулы и считать показатели по ним — у него всё в голове, и психологический фактор также учтён.
            • 0
              Видимо не достаточно точно =)
              Я хотел сказать, что хороший руководитель имеет «метрики» — не обязательно в голове (в большинстве случаев они даже документируют их и это верно — нет смысла держать в голове то что в общем-то трудно удержать). Но идея KPI — это позволить сотруднику, знать — какими метриками его оценивает руководить — чтобы «мотивировать» работника на развитие в тех либо иных направлениях (все зависит от KPI) — ведь KPI в первую очередь «мотиватор» и не обязательно денежный, а уже во вторую очередь коэффициент в формуле (хотя я не сторонник того, что KPI это только коэффициент — это просто показатель на который может влиять сотрудник и так-же ориентироваться на него).
              Следовательно — разработка KPI полезна как сотруднику (и необходимо чтобы он принял участие в его формулировке, т.к. будет знать что принимал участие — и это будет именно «его оценочный параметр»), так и менеджеру — для понимания что внесена прозрачность и зарплата как и другие блага не зависят от чего-то «магического», а могут быть отрегулированы.

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

              В сфере IT строить зарплату только на основе KPI — плохо (да и не только в сфере IT), мое мнение — что KPI это все же инструмент для «премирования/поощрения» и «отражения прогресса развития/улучшения» профессиональных навыков сотрудника и вносимого им вклада в проект. Следовательно — он не отменяет стабильной составляющей, но позволяет — либо увеличивать эту стабильную составляющую либо получать кратковременные бонусы (все зависит от подвязки KPI к успешности проекта, в случае IT). Причем — внедрение KPI в командах, именно в командах — где работа ведется над проектами которые «растут» и в которых есть «командные цели» — надо иметь однозначный «механизм» связывающий рост проекта (в том числе ответственности работника) и рост благосостояния и комфорта на рабочем месте — команды/сотрудников (членов команды). В общем — вопрос в том, хочется ли «прозрачности» в части премирования — или хочется зависеть от «неизвестных обстоятельств».
              Поэтому я думаю что полезен даже сам процесс создания KPI, который позволит сотрудникам участвовать в честности мотивационной политики, проблемы именно в том — что в большинстве случаев KPI спускаются на «голову» — от третьих сторон…
  • –1
    На мой взгляд, такие системы внедряют руководители, ничего не понимающие в работе своих подчиненных — они думают, что у сотрудников нет контроля, что сотрудники «целыми днями ничего не делают».
    Руководители хотят получить четкий контроль — вот и вводят критерии, которые они смогут оценить самостоятельно (посчитать количество строк кода, посчитать время и пр.).

    Мне нравится система, предложенная Лебедевым — оценивать сотрудника по количеству единиц смысла.
    Ведь единицы смысла генерируют не только дизайнеры, но и программисты — грамотный руководитель может оценить, тянет та или иная «фича» или работа на единицу смысла или нет. Например сдал ты сайт-визитку, 0,3 единицы смысла тебе начислили.

    Если это не визитка, а полноценный интернет-магазин, с прикрученной системой оплаты, социальными плюшками, удобной админкой и пр. — держи целую единицу смысла. И по таким единицам оценивать и давать бонусы и плюшки.
    • +2
      Слишком субъективное определение единицы смысла. Бессмысленная единица смысла. Опять всё упирается в субъективную оценку руководителем.
      • 0
        Опять же если у тебя получается сделать сайт-визитку за 1 день, а магазин за 7 дней, то будешь клепать эти визитки и перестанешь развиваться разносторонне, не дурак же отказываться от возможности заработать больше.
  • +5
    Хочу фантик
  • 0
    Меня вот все мучает вопрос, если ввести другой критерий (больше подходит для проектов с конечной стоимостью продукта):
    По ВЫПЛАТЕ клиентом, комманда получает бонус, распределением Х% от полученной прибыли, в соответствии с уровнем своей ЗП (если есть оклад). В теории, которая как обычно далека от практики — это может внутренне мотивировать комманду, сделать лучше и сдать быстрее, помогать товарищу, и пинать лентяев. А поскольку схема проста как кирпич, уменьшается кол-во спорных/демотивирующих моментов… Может есть у кого опыт?
    • 0
      У вас тут же будет стоять очередь на повышение ЗП. Технологий премирования может быть много. Иногда отсутствие премирования может быть лучшим вариантом, чем избирательное премирование. Если вы хотите повысить продуктивность, то наймите человека, который это сделает. Плохих работников не бывает, бывыет неэффективное управление.
      • 0
        В маленьких конторах, да — плохого работника просто держать не станут. Но в больших корпорация проще отсидеться на месте. Да, он может делать продукт качественно, но, он лентяй, и пока его не «пнешь», он не полетит. А постоянно «пинать» — пиналка сломается.
        • 0
          Пинать лодыря — самое неэффективное заняние для менеджера. Не понимаю, зачем тратить силы на преодоление лени отдельных индивидуумов?
          • +1
            Поразмыслив, пожалуй, соглашусь теперь, с выражением "Плохих работников не бывает, бывыет неэффективное управление.", т.к. управленец не смог найти ту ниточку, чтобы его подчиненный был хорошо, а пошел по самому легкому пути.
            • 0
              *был хорош
  • 0
    >Cycle time. Насколько быстро проходит время с того момента, как возникла идея реализовать фичу на проекте, до того момента, как она была сделана.

    Абсолютно согласен. С той разницей, что оценивается не время от идеи (идей заведомо больше), а от того момента, как фича попала в бэклог.

    Плюс, показатель разбивается по этапам. Одно дело — время до показа на внутреннем демо, другое — до релиза (обычно минимум в 2 раза дольше).
  • +1
    Конечно, примитивные метрики (строки кода. кол-во багов и пр.) ни к чему хорошему, к сожалению, не приведут. Пока оценку труда девелопера полностью алгоритмизировать не удалось.

    Однако опытный PM (умеющий писать код) может оценить на основании своего опыта: посмотреть, сколько занимали времени похожие по сложности разработки. Есть даже усредненный метод оценки на основании «функциональных точек». Опять таки, оценка будет далеко не точной, сильно основанной на интуиции.

    Получается, золотая жила заказчика — это технически подкованный менеджер, который реально сможет оценить когда девелопер работает, а когда заниматеся ерундизмом или просто отсиживает часы. Ну или найти увлеченных разработчиков, которым менеджер не нужен — тогда все будет на доверии (это более высокий уровень).
    • 0
      Похожесть не имеет никакого значения для оценки сложности. Потому что визуально похожий результат может потребовать в три раза большего количества времени на доработку каких-то вещей, тестирование или выявление багов. Но в целом согласен, хороший производственный менеджер редко ошибается в оценках
  • +8
    Впечатление такое, что все директора стараются максимально сокращать все расходы, особенно расходы на зарплату сотрудников. На собеседованях обещают залотые горы, но на практике приходится рубиться за каждый рубль, даже за ту сумму которую обещали на собеседовании. Внезапно оказывается, что налоги ты платишь сам (хотя этот момнет обсуждался на собеседовании, надо все документально фиксировать чтоли), что премии есть, но никто их за последние 4 года не видел. Обещают, что платят всем про справедливости и своевременно повышают зарплату при росте квалификации и т.п. Обещают что если сотрудник приносит больше денег, то и платят ему больше. На практике все не так. Фиг кому повышают зарплату, пока человек сам не пришел с жестим требованием или заявлением. Рост квалификации и опыта обычно тоже никак не сказывается, или зарплата изменяется на 5%, и то почле того как сам пришел и потребовал.

    Соответственно все эти дурацкие критерии, воспринимаются как способ не платить сотрудник у даже и ту зарплату, которая у него есть сейчас. Дак почему воспринимаются, собсно обычно это так и есть.
    • +2
      Точно!
      Они делают вид, что платят, мы делаем вид, что работаем.
      • 0
        Делаете себе же хуже. Если компания не может ничего продать, то откуда она возьмет средства для оплаты труда? Если вы не согласны с «политикой партии», то лучше уволиться и найти компанию с более стабильным финансовым положением. Если хотите помочь компании, то огласите это на всеобщих сборах, что вы готовы поработать в долг, опишите условия возврата и процент вознаграждения в договоре с руководством, подпишите его и спокойно разойдитесь без лишней нервотрепки.
    • +4
      В маленьких поспаниях трудно держать уровень прибыльности постоянным, постоянные изменения на рынке сильнее трепают такие конторы. Редкий руководитель понимает, что добавление работников или из смена негативно сказывается на эффективности работы предприятия в целом. Во все рассчеты стоит принимать время адаптации или обучения работника, которое, в зависимости от сложности проектов, будет занимать от трех месяцев до года. Коллектив должен сработаться, притереться друг к другу. Но это никто не берет в рассчет. Я долго боролся за последовательный найм работников на работу, чтобы каждый из них получал в начале как можно больше внимания, хотя от меня требовали набирать сразу отделами, чуть ли не по 10 человек. Аргументация была проста как двери и на словах казалась очень эффективной. Мы нанимаем 10 человек, они нам за три месяца пишут продукт, мы его продаем, и окупаем все, каждый покупает себе по персональному остову. Реальность такова, что нанять 10 человек сразу не получится, как и не получится их организовать за три месяца в эффективную команду, как и написать продукт, который потом можно будет только выкинуть. Но все уже купили себе по острову.

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

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

      Если хотите действительно понять, почему вы третий год сидите без повышения, то пойдите к руководству и спросите. Узнайте, какие планы компании, что намечается на ближайшие пол года, какие трудности она испытывает сейчас.
      • 0
        Только от роста компании линейный персонал плюшек зачастую не получит, хоть компания росла с заработанных вами денег.
        Так что общее правило — если вам не нравится уровень оплаты, просто ищите компанию с более выгодными условиями.
        На мой взгляд, ситуации могло бы помочь выдача части зарплаты акциями компании. Но в России, вроде, это не распространено.
        • 0
          В стартапах — вполне. Зачастую выдаются опционы. Наверное, это тоже палка о двух концах. Ведь теперь это уже не просто продукт, за который тебе платят. Это твой продукт. И многие решения руководства принимаются намного более болезненно. Зато если решения красивые, а перспективы радужные, то производительность и качество работы будет очень высоким.
          • 0
            Производительность труда слабо связана с перспективами, решениями и прочим. Она зависит от настроя, отвественности, общего психологического настроя
    • 0
      Меня больше беспокоят компании, в которых думают, что всё, что нужно — много платить.
  • 0
    Простите за занудство, но это уже проходили больше 20-ти лет назад и в русском языке есть аналог KPI = коэффициент трудового участия.
    • 0
      КТУ это про другое, идите в словарь. KPI можно было бы перевести как КПЭ
      • 0
        ну так приминительно к членам комнады это именно этот термин
  • +1
    То ли у Спольски, то ли у Де Марко же был рецепт: у каждого участника своя ставка, которая определяется индивидуальна, а по итогам успешных проектов эта ставка поднимается всем участникам команды. Степень её роста может зависеть от коммерческой успешности проекта: чем больше заработали на проекте, тем выше поднять ставку участникам команды. Наказания же вообще неэффективны: если вас не устраивает работник, откажитесь от его услуг.

    Вывод кратко: имеет смысл только поощрение в виде мотивированного роста ставки заработной платы.

    Естественно, это правило применимо в чистом виде только для проектного подхода и постоянного штата сотрудников.

    В целом с фрилансерами по факту реализуется тот же принцип: фрилансер договаривается с заказчиком о цене за работу целиком, а не за отдельные её «показатели», то есть за результат. И чем лучший результат показывает фрилансер, тем лучше у него репутация и портфолио, и тем большую цену он может запросить в следующий раз.
    • 0
      Моральное удовлетворение от каждого последующего увеличения уровня ЗП падает даже не по экспоненте. Достигая определенного уровня оплаты, эффективность работника мало того, что слабо стимулируется, но и уменьшается, и дальнейшее увеличение суммы идет только во вред.
      • +1
        Ну, это не отменяет других методов поощрения команды, таких как участие в конференциях, отпуска и прочее.
        Как бы то ни было, именно размер постоянного дохода является мерилом успеха в современном капиталистическом мире.

        Насчёт «дальнейшее увеличение суммы идет только во вред» — это глупость. Если сумма растёт постепенно, то никакого вреда не будет. Вот если вы вместо 20 000 руб. начинаете платить 200 000, то это может иметь шоковый эффект и на некоторое время выведет сотрудника из строя, но если этот путь от 20 до 200 был пройден хотя бы за год, и при этом сотрудник явно повысил квалификацию и продемонстрировал достижения — то не вижу проблем.
        • +2
          Это не глупость. Для обеспечения каких-то потребностей человека вполне хватает некой суммы. Первое время человек насыщается, пытаясь получить все то, о чем он мечтал. Потом голод потребления несколько утихает. И вот тут начинается другой процесс — целование себя в задницу и попытка завести знакомства не с теми нищебродами, с которыми он работал раньше. Меняется круг общения, привычки, и голод потребления переходит на новый уровень. Как его утолить? Пойти и потребовать зарплату повыше. Какая, по вашему мнению, должна быть прибавка к 200 000? Десять тысяч? Двадцать тысяч? Пятдесят? Семдесят пять? Если вы дадите 10, то работник это будет расценивать как акт неуважения к его величеству. А пропорциональный рост при таких суммах может быть абсолютно экономически неэффективным для компании. Далее, огромный разрыв между ЗП сотрудников будет стимулировать неудовлетворенность в коллективе.

          Потом, время работника и его физические и умственные способности конечны. Он не сможет бесконечно показывать рост эффективности, а значит, после какого-то уровня, надбавка к ЗП будет идти «за выслугу лет», а не за реальные показатели. Получается эдакая переоценка специалиста, которая лишает работника реальных аргументов в пользу повышения уровня оплаты труда, а переводит их в разряд воображаемой эффективности. И вот тут начинаются психологические игры, которые приводят к конфликтным ситуациям (не между людьми а внутренним), что потом ведет к увольнению или депрессиям.
          • 0
            Не то чтобы я возражаю вашему тезису, но не могу найти в нём конструктивной части.

            Вы предлагаете никогда не повышать зарплату выше некоего порога? То есть вот сотрудник должен знать, что с данного момента он достиг финансового потолка в моей фирме, и пусть довольствуется другими плюшками? Какими именно? Что вы предлагаете взамен?
            • +2
              Взамен? А вы уверены, что человек что-то еще будет требовать взамен?
              Возьмите пирамиду Маслоу

              Человек удовлетворил свои базовые потребности, чувствует себя в безопасности, удовлетворил потребность в обществе, и теперь ему остается взять следующий рубеж — потребность в уважении и признании. Вы можете дать людям именно это.
              • 0
                Согласен с вами отчасти: не считаю, что этим должно всё исчерпываться. Поощрение более высокого уровня пирамиды Маслоу должно сочетаться с хотя бы минимальным развитием поощрения более низких уровней.

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

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

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

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

                  Поверьте, людям приятно, когда на них смотрят как на инопланетян :)
              • 0
                Что-то я не слыхал, чтобы на уважение и признание можно было прикупить, к примеру, квартиру.
        • 0
          А нафига вообще работать, если получаешь мнго денег?
          • 0
            Потому что платят их не за красивые глаза, а за результат труда, который можно продать
  • 0
    Статья хорошая. Но ИМХО маловато источников, объясняющих фундаментальные причины — по сути, только «Мифы мотивации».
    Поэтому очень советую книгу Daniel Pink — «Drive» — популярно и на сочетании исследований и практических примеров излагает теорию самоопределения, которая и объясняет, почему KPI и любая внешняя мотивация в целом вредны для любой работы (в долгосрочной перспективе), а для творческой/не алгоритмизуемой — вредны с момента внедрения.
  • 0
    Т.е., по всей видимости, субъективное мнение руководителя всё же остаётся самым надёжным критерием?
  • +8
    интересно, мне казалось, что у параметра WTF/h несколько иное общепринятое значение
  • +2
    Существует только два вида мотивации: морковка спереди и морковка сзади.
  • 0
    По моему, чтобы решить все противоречия достаточно убрать связь между зарплатой работника и KPIs работника.
    • +4
      А ещё лучше так: сделать зарплату менеджера зависимой от KPI его подчинённых ))
      А рядовые работники пусть спокойно работают на повышение.
      • –1
        Разве что в качестве шутки) Начальник тоже когда-то был человеком, зачем его так подставлять?:)
        • 0
          Почему это подставлять? Такая практика тоже есть. Это мотивирует менеджера не просто сидеть на месте и контролировать, а внедрять, изобретать и улучшать, развиваться самому и его подчиненным! В чем и заключается его работа!
          • 0
            Не соглашусь. Всё-таки, руководитель лишь косвенно влияет на показатели сотрудника.
            «внедрять, изобретать и улучшать, развиваться самому и его подчиненным» — очень аккуратным надо быть, на бумаге всё правильно, но на практике это не самые главные качества для менеджера, я считаю.
  • 0
    Если кто-то не может измерить эффективность — то это проблема его, а не KPI

    ну и вообще, не можешь сам, обратись к опытным людям.
    • +1
      Точно, придет консультант, за пару часов в деталях разберется в бизнесе, еще за парочку изучит всю команду, и напишет на доске универсальную формулу которая будет работать в любых ситуациях неограниченное время. Ах да, еще пара тренингов, чтобы те кто нужно поверили в чудо-формулу.
      • 0
        почему за 2?

        Как Вы думаете, сколько нужно времени чтобы сделать сайт для компании? тож наверно не 2 часа. Почему внедрение KPI будет быстрее?
        • +1
          Ну я утрировал немного, чтобы показать абсурдность ситуации. Назовите реальные средние цифры. Вообще, как я понимаю вы этим занимаетесь? У вас есть успешный опыт внедрения KPI при соблюдении следующих условий?
          — работники из IT сферы
          — они работают на проекте командой
          — команда не менее 4 человек
          — проекты достаточно длительны, ну от 3 человеко-месяцев, и нестандартные. т.е. по количеству склепаных типовых решений не посчитаешь

          Под успешным я понимаю:
          — Это реально работатет
          — Работники довольны, что система была внедрена (ну допустим 90%)
          — Работники мотивированы ей (прирост производительности существенный)
          — Качество продуктов не упало а улучшилось, сроки не затягиваются, работники не манипулируют фомулой умышленно, чтобы повысить доход (пример из статьи про договорившихся тестировшиках и программистах).
          • –1
            Нет, я конкретно ЭТИМ не занимаюсь. Я работаю в компании где используется KPI

            Кстати, с чего Вы взяли, что работники должны быть «довольны»?

            Довольны будут те, у кого хорошие результаты (и премии), недовольны те — у кого плохие.

            Реальные сроки внедрения, минимум 3 месяца и еще 3 на проверку. А так и в течении года надо проверять «как оно работает».

            И да, эффективность системы мерится приростом в деньгах у компании.
            • +1
              «Нет, я конкретно ЭТИМ не занимаюсь» — хм, ну значит ошибся, вы так рекомендовали консультантов, вот я и подумал.

              «Довольны будут те, у кого хорошие результаты (и премии), недовольны те — у кого плохие.» — Еще раз, мы говорим о командной работе. Если 2 человека в команде довольны, мотивированы и делают продукт хорошо, а 8 недовольны и это недовольство влияет на их работу, продукт будет плохой, или эффективность команды крайне низкой (так как эти 2 будут тратить все свое время чтобы контролировать остальных, не дать им загубить продукт, code review и т.д.). Плюс напряжение в команде снижает ее эффективность и качество работы катастрофически. Если наоборот, в команде 2 лодыря и 8 хороших, то может лучше сократить комадну до размера 8 человек? Ну я привел крайние примеры, с четким разделением. Понимаю что в реальности все более размазано. Ну тогда это тоже создает напряжение в команде, кто-то получает чуть больше, а у тех кто чуть меньше недовольство растет.

              Я все же воспринимаю KPI как систему призванную мотивировать, про справедливость я писал тут в комментариях, много и подробно.

              Я не спорю что для продавцов в магазине или маркетологов применим KPI. У них в большинстве случаев результаты явно видны и четко персонализированы.

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

              Ну и если вы вкратце опишете вашу систему KPI которая работает в перечисленных мной чуть выше условиях, быду благодарен. Думаю не только я. Потому что судя по моему личному опыту, этой статье со всеми комментариями, и многим другим статьям, работающей, четко формализированной, и персонализированной (т.е. премии даются не команде, а считаются для конкретных людей), системы KPI для данных условий нет, и лучшее что можно сделать, вообще ее не запускать для таких работников, а мотивировать другими способами.
              • 0
                Это да, если при внедрении явно неэффективной системы управления разработчиками вы получаете позитивный эффект, то скорее всего вам стоит начать набирать реально эффективных менеджеров.
              • 0
                Причем тут кадровые вопросы. Вы без внедрения KPI не можете оценить эффективность работников? И уволить плохих.

                Да, KPI предназначена для мотивации людей делать то, что нужно компании.

                Вопрос экономии вообще не стоит. KPI используют в первую очередь для определения размера премии.

                И да, понятие «справедливость» строго индивидуально и субъективно. При KPI достигается некая справедлиовсть с точки зрения компании.
                • 0
                  «Причем тут кадровые вопросы» — вы моральную обстановку в команде, ее эффективность, и мотивированность каждого сотрудника назваете кадровыми вопросами? Или я вас неверно понял?

                  «И да, понятие «справедливость» строго индивидуально и субъективно. При KPI достигается некая справедлиовсть с точки зрения компании. » — ну и толку компании от такой справедливости. Компании нужно: минимизировать расходы, увеличить доходы. Ну если честно, грубо и кратко. На все это «с точки зрения компании» и направлены мотивации, определение размера зарплаты и пр. Справедливость сдесь причем? Работникам компании от «справедливости с точки зрения компании» ни холодно ни жарко, она у них своя, у каждого. Т.е. мотивирующего фактора нет, от такой справедливости. Минимизация расходов (за счет зарплат и выделения премий только «достойным») — ну вы говорите что этот вопрос не стоит.

                  Ну разве что те кто управляют этой KPI системой могут ощущать глубокое чувство удовлетворения от того что «все справедливо» и показывать формулы недовольным работникам. Ну а толку, с точки зрения компании то?

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

                  Ну и хотелось бы все же получить ответ на вопрос заданный раньше " У вас есть успешный опыт внедрения KPI при соблюдении следующих условий?".
              • 0
                Я не спорю что для продавцов в магазине или маркетологов применим KPI


                Вот даже сейчас было смешно.

                Бывали в магазинах, где консультант в зале, увидев, что вы движетесь с уже выбранными покупками, хватает вас под локоть и красиво ведёт к кассе? У него KPI. Отследить, что он вам как-то помогал, невозможно — ну не записи же с камер проверять. Балл в KPI ему падает, когда он подводит вас в кассе.

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

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

                От чего у них зависит KPI? Нет, я знаю одну очень крупную компанию, где KPI PMM (product marketing manager) зависел от доли на рынке — при том, что PMM был чуть ли не последним человеком, который на эту долю реально влиял.

                Сделаете KPI по количеству фич в продуктах? Ну, есть прекрасная история про LG и WebOS, как там корейские менеджеры наперегонки бежали, лишь бы впихнуть что-то своё в очередной релиз — и с учётом корейского менталитета последствия были более печальные, чем забавные, хотя и забавные тоже, конечно. По объёму публикуемой рекламы? Ваш бюджет начнут сливать как из брандспойта. По ROI от этой рекламы? Узнаете очень много нового о том, как можно красиво оценить её эффективность — хотите, например, расчёт ROI от пресс-конференции как суммарную стоимость размещения заказных статей во всех СМИ, которые по итогам вашей прессухи написали о вас новость? Реальная история, между прочим.

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

                Обычная эволюция, ничего личного. Всегда в итоге выбирает наименее энергозатратный путь.
                • 0
                  Тьфу, не заметил, что тема 2012 года.

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

              Что Вы делаете для того, чтобы получить лайк? Делаете красивое фото или пишете интересный текст. Что Вы делаете для «респект!» в коммьюнити программистов? Реализуете красивое решение какой-нибудь старой задачи или придумываете что-нибудь новое.

              Разговоры о приоритетности з/п ведут те, кто ни разу не видел ничего open source'ного. И я не говорю о крупных проектах, которые косвенно зарабатывают много денег, предоставляя сам продукт бесплатно. Я говорю об обычных программистах, заполняющих своими решениями github, bitbucket и т.п.
              • +1
                Да-да. Я хотел бы посмотреть на человека, который отказывается от годового бонуса (4-5 его окладов). Жирный наверно. Троль :)
                • 0
                  Я бы хотел посмотреть на человека, который не получил в один прекрасный момент этот самый бонус.
                  • 0
                    Обычно он догадывается что не получит. KPI же открыты.
                    • 0
                      И начнет винить в этом кого угодно и что угодно, но не свое отношение к работе.
                      • 0
                        И уволится. И компания избавится от плохого сотрудника. Да. я это видел.

                        • 0
                          Он может быть не плохим. У него просто может быть конфликт с ПМ'ом. Но цифры ведь говорят сами за себя, верно?
                          • 0
                            А может и не быть. Вы пишете роман?

                            Какая связь между KPI и конфликтом?
                            • 0
                              Это пример того, что в оценке эффективности нельзя брать только цифры.
                              • 0
                                Я где то это утверждал?
                  • 0
                    А я бы еще посмотрел и на других людей в компании, которые работали, но вот в модель подсчета KPI плохо уложились, и не получили такого бонуса. Ой что будет!
  • 0
    ИМХО критерии оценки должны быть формализованы и… закрыты.
    Наличие цифр + субъективная оценка руководителя дает в среднем лучше результат чем открытая формальная система или чисто субъективная система.
  • +1
    Мне кажется большая часть этой KPI болезни, из-за подмены понятий:
    1. «Смысл такого подхода: платить по справедливости» — отлично, что такое справедливость? Субьективное чувство, на которое влиет чуть ли не погода на улице. Ну нет обьективной справедливости, нету. Значит и универсальный способ ее измерения не придумать, сколько бы сложным он не был, все равно кому-то в какой-то период времени она покажется несправедливой.
    2. Мотивация — вот от этого уже стоит плясать. Со справедливостью связь вроде очевидная, работник который считает что ему платят по справедливости мотивирован работать больше, чтобы больше получить (по справедливости). Но если смотрим пункт первый, то понимаем, что во многих случаях не работает это. Не буду делить на внутренюю и внешнюю, упоминать пирамиду маслоу и прочую полезную заумь. Что есть у работника (касательно работы): доход, рабочее окружение, коллектив, проект, отношение к компании. Вроде все.

    Доход — зарплата должна соответствовать рыночной стоимости работника, не справедливости, а стоимости, сколько он смог бы получать если бы перешел в другую компанию. Зарплата должна удерживать работника, и финансово его удовлетворять. Все. Премии — нафик. Кто хочет нестабильного (но возможно большего) дохода на который он может влиять, идут во фриланс, собственный бизнес и т.д. IT работники тоже любят кушать, но работают за интерес, т.е. премией сильно и постоянно не мотивируешь, а вкусно кушать должна обеспечить зарплата. Премии всегда непонятны и несправедливы, к ним привыкают, их обрезают при финансовых трудностях, а люди к ним уже привыкли, ну про это уже много говорили. Меня как программиста премии деньгами никогда не мотивировали. Так же холодно я относился и к их отсутствию. Халявные деньги, не больше. Хотя знаю много примеров, когда откладывание премии вызывало негатив, и ни одного, когда премия реально людей на трудовой подвиг толкала.

    Рабочее окружение, отношение к компании, коллектив, комфорт короче — если есть «лишние» деньги на премии, купите команде хорошие стулья, стол бильярдный поставте, ну мысль понятна думаю. Можно телефоны всем подарить (была недавно статья про Yahoo). Так же эти деньги можно потратить на тимбилдинг (корпоративчики, от больших до совсем мелких). Оно, как мне кажется поприятнее и больше добавит любви к компании чем та же сумма на карточку (сколько там упадет на карточку людям, от одного бильярдного стола или корпоратива). В компании должно быть приятно работать, это лучше мотивирует чем премии, но в ужасных условиях.

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

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

    Все это конечно про IT специалистов.
    Длинновато как то получилось.
    А автору спасибо, все по полочкам так разгромили.
    • 0
      Мне премии нравятся в виде 13-ой зарплаты всем. Это такая некая инверсия контроля. Стабильная плюшка типа оплаты спортзала или бесплатных обедов, повышающая общую удовлетворённость компанией, в которой ты работаешь.

      Разговоры о деньгах обычно сухие и безэмоциональные. Намного больше позитива ведётся при обсуждении условий работы. И когда кто-то говорит, что у них в офисе есть кикер, мягкий диван, душ, удобные кресла, офигенные компы, бесплатные обеды и пятничные пьянки, то хочется бросить нафиг всё и пойти работать именно туда. Потому что при всей твоей красивой з/п живётся тебе, прямо скажем, некомфортно — по ночам спится плохо, на работу едешь с унылой миной, на самой работе делаешь непонятно что непонятно с кем. А хочется в комфортных условиях в дружном коллективе делать хорошие вещи за достойную (но не вызывающую ЧСВ, ещё больше осложняющего жизнь) зарплату.
      • –1
        А в чем смысл 13 зарплаты всем? Просто приятный обязательный бонус перед новым годом? Ну а так как он обязательный, то быстро перестет восприниматся как приятный, просто как обычный. Т.е. ситуация как с обязательными квартальными премиями, если она больше предыдущей — небольшая радость, если та же — никаких эмоций, если хоть чуть меньше — ощущение что деньги недоплатили, если не выплатили вообще или затянули — сильный негатив. Т.е. единственный выход (чтобы это как то влияло) постоянно их повышать — что бред. Имхо, лучше на эти деньги (13 зарплата) предоставить людям дополнительные 2 недели отпуска с отпускными, улучшить офис, или весь год финансировать выезды на природу и другие корпоративчики и пятничные пьянки.

        Ну в данном случае это теория, я просто никогда с этой 13 зарплатой не работал, может она реально каждый год обарачивается приятым сюрпризом, ну и опять же эффект, что халявные деньги не пару сотен но много раз, а сразу хорошая сумма.
        • 0
          Лучше перед отпуском давать бонусные отпускные.
  • –3
    Уважаемый автор, ваша статья полностью справедлива для случая «менеджер плохой, а разработчик творец и всегда молодец».
    Но если, разработчик — безответственный и пофигистический, то ему нужны показатели KPI или ему пора на выход.
    • 0
      Ему пора на выход. Показатели ему в любом случае не нужны. Безответственный пофигистический сотрудник потратит 1-2 часа в день на подведение своего безделья под максимально достижимый в его условиях KPI и по всем отчётам вдруг станет полезной единицей.
  • 0
    На прошлом проекте был KPI состоящий из кучи параметров. Там такой project manager был — могучий повелитель Excel'я. В табличках всё было красиво, но с реальностью коррелировало слабо, поэтому выливалось иногда в реальную жесть. Поэтому я с автором статьи категорически согласен.
    • 0
      Не помню, чтобы мы с Вами работали. Вероятно, Вы ушли из компании до того, как я в неё устроился? :)
      • 0
        Я вообще-то о прошлом проекте в своей компании писал. С Вами мы не работали, и в вашей компании тоже. Прошу прощения если мой комментарий каким-то образом ввёл Вас в заблуждение.
        • 0
          Это была ирония по поводу распространённости такой ситуации :)
          • 0
            Аааа… чего-то я туплю сегодня, извините. На да, ситуация распространенная. Мне кажется причина здесь в том, что менеджеры просто боятся брать на себя ответственность за такой нестабильный и непредсказуемый процесс разработки/дизайна/подставить нужное. Поэтому придумывают кучу «объективных» критериев, потом берут от них тьму всяких производных, потом из этих производных лепят какие-то сведённые «главные» критерии… это всё конечно не работает, зато у менеджера есть успокаивающее чувство что он контролирует весь процесс — хотя на самом деле он контролирует только табличку Excel у себя в ноутбуке. Причем когда что-то идёт не так, не в соответствии с табличкой, менеджер вместо того что бы выкинуть эту табличку нафиг начинает гнобить исполнителей — они плохие, всё не так сделали, «не влезли в KPI». Беда-печаль короче.
            • 0
              Я думаю причина здесь не в страхе. Просто так много полезной зауми вылито и выливается на их мозги что начинается этот чудо процесс поиска бизнес-процессов. Какая-то святая вера в них, этакий silver bullet который применим везде и сделает жизнь всех лучше, стоит только подождать пока все откалибруем.

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

              Если менеджер не забывает что все эти чудо-формулы всего-лишь инструмент и постоянно помнит о цели, ради чего все это начиналось и для чего предназначалось, циферки будут для него всего-лишь показателем, и он будет знать насколько они обьективны, стоит ли их улучшать или может вообще отказатся и взять другой инструмент. И никогда не будет опиратся только на циферки в excel.
  • 0
    Все выше описанное прочитать интересно, но очень много подмен понятий.

    А самое главное, когда я (сам я бывший программист.) вижу возгласы «KPI не для меня», «как можно измерить творчество» — я это приравниваю к «Я не хочу нести никакую ответственность ни за что, ни за хорошую ни уж тем более за плохую работу». Результат или есть или нет.

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

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

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

    Деньги платит или клиент, или материнская компания, или государство, или другое более эффективное подразделение, чью маржу кушет менее эффективное.

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

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

    Есть процесс, а есть результат.

    KPI и любые схожие подходы в попытке посчитать справедливовть — подходит для людей результата, кому правда или ее поиск режет глаза — это люди процесса.
    • 0
      Поделитесь методикой обьективного и справедливого рассчета результата каждого человека в команде, при условии что они работают командой, часто работают над одной и той же задачей совместно?

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

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

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

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

        Нет универсальной методики люди у всех разные работают. А про эксперименты — делайте их с головой — или в вашем понимании эксперимент = платить меньше? ну дак это не так.
        • 0
          Как часто переформировывались команды? Какой средний размер команды и длительность проекта? Если это конечно не секретные данные. Просто на долгосрочных проектах, введение нового человека это уже беда, куча времени на изучение проекта тратится. А уже переформирование команды, вообще мрак. На краткосрочных, ну возможно, хотя я считаю что команда это сработавшаяся группа людей работающая над проектом, при постоянном переформировании сработатся вряд ли толком успеешь.

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

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

          Ну и я немного не понял, команды именно осваивали бюджет, т.е. зарплату не платили а команда распределяла деньги за проект внутри себя? Или как понимать «забирая новые и новые бюджеты после успешного завершения проекта»?
        • 0
          Думаю это очень хороший метод — оценивать работу не сотрудника, а группы/команды. Поскольку команда способна к самоорганизации на том уровне, который расписать и просчитать нереально. Спасибо за идею.
  • 0
    Самая большая проблема с введением KPI — это «обратный эффект». Вместо того, чтобы работать по принципу «делай что должен», работники начинают подстраиваться под коэффициенты. Цель становится не делать работу хорошо, а делать работу так, чтобы получать хорошие коэффициенты.
    А спланировать коэффициенты в веб-девелопменте (это все-таки не продажи и не конвеер) очень сложно и шанс при формальном подходе действуя по «лекалам» наказать невиновных и поощрить недостойных очень высок, а это моментально дает обратный эффект демотивации.

    Пример из реальной жизни — знакомые разработчики писали систему, заказчик говорит, все, конечно, хорошо работает, но вот размер exe как-то подозрительно мал. Наверное, все сделано плохо. Итог: «оки» и в следующий раз ему выдали уже в два раза больший файл, полученный включением в проект бесполезного, но весьма объемного файла. Показатели достигнуты? Да. Результат такой был нужен? Сомневаюсь.

    Уверен, что KPI — полезная система, но пока не слышал ни одного рецепта в веб-разработке, который бы мне захотелось применить у себя. Встречаются какие-то дикие — количество пройденных тестов, количество багов, прибыль по каждому сотруднику, и даже (omg!) количество строк кода — это все, по моему, какой-то дикий ужас.
    Наверное можно внедрить какую-то первоначальную схему и итерационно оптимизировать, но на себе эксперементировать не хотелось бы.

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

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