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

Руководители сталкиваются с непростыми вопросами, когда пытаются ввести систему оплаты для дизайнеров и программистов на основе KPI. А ведь в таких компаниях, как маркетинговые агентства и софтверные фирмы – это основной контингент сотрудников …

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

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

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

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

Некоторые компании (15%) применяют KPI для оценки эффективности труда программистов и дизайнеров.
Около 25% компаний внедряют KPI в данный момент / встречают сопротивление внутри компании или же работают по упрощенной схеме.
Примерно 30% компаний производит оплату труда работников на основе субъективных оценок руководителей. Вернее, 30% сознаются в этом 😉
Не сознаются оставшиеся 30%.

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

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

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

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

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

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

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

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

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.

Автор: В. Завертайлов