Что такое показатель KPI для сотрудника и как его правильно оценить Что такое kpi для сотрудника и как его правильно оценить. Владимир Завертайлов, руководитель Сибирикс: scrum-студия

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

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

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

Рано или поздно, наверное, у каждого директора возникает желание платить по справедливости. За выполенную работу. И очень многие сейчас пытаются внедрять 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. Я надеюсь, эта небольшая подборка статей, которую нам удалось собрать поможет в принятии верного решения.

Дело было так. У нас есть две основные странички в Фейсбуке: Рейтинг Рунета (здесь мы публикуем новости, связанные с нашими рейтингами и конкурсом сайтов/мобильных приложений) и CMS Magazine (основной контент - тематические статьи, исследования и кейсы). А еще есть закрытая группа CMS Magazine & Рейтинг Рунета . Она предназначена для обсуждения самых актуальных проблем и вопросов, интересующих диджитальщиков. Добавляйтесь, кстати, вдруг пригодится. Так вот. Несколько недель назад один из участников группы обратился к коллегам за отзывами и полезными материалами на тему KPI. Мол, настал момент внедрять KPI у себя, но нужны детали.

Владимир Завертайлов , руководитель Сибирикс: scrum-студия

Прошло около 4-х лет, с тех пор, как я рассказал о том, почему KPI для творческих работников - это долгоиграющий гемморой. И тема все ещё актуальна, и возможно будет актуальной пока нас всех не заменят роботы. Каждый буквально месяц (на конференциях или в личном общении или в чатиках фейсбука), нет-нет, да и спросит кто-нибудь «А как бы нам так оплату программистов или дизайнеров привязать к выработке». Добавить в KPI - высокоуровневые корпоративные цели (которые хорошо и красиво звучат, но на которые напрямую не может повлиять конкретный работник). Добавить в KPI какие-то показатели, которые тут же будут хапнуты. И сгладить это необязательность исполнения KPI («ну они же старались, давайте дадим премию!»). В эту игру играют тысячи людей.

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

Я вижу, как менеджеры крупных компаний вообще избирательно строят свой график, чтобы быть как можно меньше в рабочем доступе: прыгая с конференции на выставку, со встречи на встречу, с самолета на самолёт, лишь бы как-то дожить до пятницы, откидать дела, но не заниматься УПРАВЛЕНИЕМ. Поэтому нам так нужна система KPI. Такое искушение свалить свою управленческую некомпетентность и нежелание идти на конфликт с людьми (а он неизбежен, когда идёт делёж заработанного или нужно выдать люлей плохому работнику) на волшебную систему KPI, которая все сама разрулит.

Николай Апурин , генеральный директор ООО «АРТВЕЛЛ»

У нас система KPI - это премиальные проекты. Есть ряд проектов, которые надо сделать быстро и вчера (обычно, когда нам передает заказчик проект, где сроки уже вышли и с «карманным» подрядчиком проект утоплен, ведущий разработчик не сдал математику и вынужден отлучиться от проекта, в дверях стоит прокуратура и счетка…. И задача стоит - вчера, сделать, быстро. В лучшем случае есть ТЗ, в худшем и его нет). Мы берем такие проекты и за успешное выполнение этапов выдаем бонусы. У каждого проекта есть своя бонусная система. Тимлид одного сурового проекта успешно сдал 1 и 2 этап за 2 месяца, суммарный бонус у него получился 800 000 рублей. Но есть и стандартные фиксы % от продаж, % от допродаж, фиксированный бонус за каждый хороший отзыв от заказчика для РП и другие.

В целом система мотивации работает. Каждый ключевой сотрудник АРТВЕЛЛ, если не косячит, может с бонусов купить себе квартиру. Это наш сильное преимущество и прекрасная мотивация для всех новых сотрудников.

Роман Горевой , исполнительный директор компании ЕВРОСАЙТЫ

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

В разработке и дизайне у нас имеется KPI, основанный на ROI, но он никак не привязан к зарплате и рядовым сотрудникам не раскрывается. Разработчики и дизайнеры работают на фиксированном окладе, ни отвлекаясь на мысли «сколько же я получу денег». Для объективности ROI при оценке берётся за периоды от 6 месяцев. Рано или поздно становится понятно получает ли сотрудник достаточно или недостаточно, или ему переплачивают, соответственно, примерно раз в полгода происходит корректировка зарплаты.

В аккаунте каких-либо чётких KPI не может быть, так как здесь всё сильно зависит от «адекватности» самих клиентов. У одного аккаунт-менеджера могут превалировать «щедрые и адекватные» клиенты, у другого же могут быть прижимистые, а на ком-то могут и вовсе висеть самые тяжёлые клиенты. Если начать вводить жёсткие метрики оценки, то непростые клиенты будут либо игнорироваться, либо сливаться на молодых вновь пришедших сотрудников.

Василий Вишняков , генеральный директор интернет-агентства Bquadro

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

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

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

Алексей Волков , генеральный директор агентства Digital.Tools

Схема мотивация должна быть прозрачной. Человек должен понимать, что он получит. Мотивировать разработчика процентом от продаж - сложно, от прибыли - невозможно. Для них более простые критерии:

сдача проекта в срок,
с нужным качеством.

Для некоторых «работяг» можно дополнительно внедрять доплату за сверухрочную работу, особенно если для них интересен сам по себе процесс. Для менеджеров и продажников лучше в проценте от оборота. Директора по продажам - процентом от прибыли. Если проект не рентабелен - не продаю проект. Если проект стал нерентабельным в процессе работы: убытки компании и повод сделать выводы. У продажника у нас небольшой фикс и % от продаж услуг. Фикс - чтобы не умереть с голоду, процент - хороший. Таким образом, если он не продает ничего, он чувствует, что мало заработал, а если продает хорошо - он будет в шоколаде. Менеджеры по продажам не ищут клиентов, еле-еле успевают обрабатывать входящие заявки.

Дмитрий Логинов , директор дизайн-студии и интернет-агентства «Четвёртый Рим»

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

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

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

Ольга Баранцева , генеральный директор интернет-компании R52.RU

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

Сложность возникает сразу при разработке «Хороших Критериев» (© В. Завертайлов) - они должны быть понятны, объективны, справедливы и измеримы. А с этим как раз и проблема. С точки зрения производительности художник-портретист Незнайка значительно эффективнее Рафаэля или Веласкеса.

На наш взгляд задуматься о внедрении KPI необходимо, если:

интернет-компания занимается в основном потоковым производством стандартных или шаблонных решений;
в компании более 20-30 специалистов одного профиля, например, РНР-программистов;
при наличии филиалов, удаленных офисов и команд для формализации контроля над ними.

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

Дмитрий Афанасьев , основатель DIAFAN.CMS

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

Sp-force-hide { display: none;}.sp-form { display: block; background: rgba(247, 247, 247, 1); padding: 25px; width: 800px; max-width: 100%; border-radius: 0px; -moz-border-radius: 0px; -webkit-border-radius: 0px; border-color: #dddddd; border-style: solid; border-width: 13px; font-family: Arial, "Helvetica Neue", sans-serif; background-repeat: no-repeat; background-position: center; background-size: auto;}.sp-form input { display: inline-block; opacity: 1; visibility: visible;}.sp-form .sp-form-fields-wrapper { margin: 0 auto; width: 750px;}.sp-form .sp-form-control { background: rgba(255, 255, 255, 1); border-color: rgba(217, 217, 217, 1); border-style: solid; border-width: 1px; font-size: 15px; padding-left: 8.75px; padding-right: 8.75px; border-radius: 0px; -moz-border-radius: 0px; -webkit-border-radius: 0px; height: 35px; width: 100%;}.sp-form .sp-field label { color: #444444; font-size: 14px; font-style: normal; font-weight: bold;}.sp-form .sp-button { border-radius: 25px; -moz-border-radius: 25px; -webkit-border-radius: 25px; background-color: #ef002b; color: #ffffff; width: 100%; font-weight: 700; font-style: normal; font-family: Arial, sans-serif; box-shadow: none; -moz-box-shadow: none; -webkit-box-shadow: none;}.sp-form .sp-button-container { text-align: center; width: auto;}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

KPI вообще отличная штука, но как только речь заходит о его внедрении в творческих коллективах, сразу возникают вопросы и сомнения. Действительно, можно ли объективно оценить работу, когда ее результат по сути своей абстрактен, когда это просто некая творческая концепция? Можно, считают в художественно-производственной студии ART4you и в доказательство рассказывают о том, как внедряли в работу KPI для дизайнеров.

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

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

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

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

Так что сотрудники взялись за создание собственной системы KPI. Важнее всего было сформулировать критерии для анализа творческой составляющей дизайнерской работы.

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

Через несколько месяцев начали внедрять систему на практике. Стартовали с четырех критериев оценки и стали плавно наращивать их количество.

Сейчас труд дизайнеров оценивается по следующим параметрам:

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

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

«Когда KPI разрабатывали и внедряли, мы сразу договорились, что это не конституция и не священная корова, а открытая для постоянной модернизации система. Что-то мы убирали из перечня критериев, что-то добавляли, постоянно шла работа, и наконец мы пришли к стройной, объективной версии», - говорит Андрей Кокеев.

Вообще эта коллегиальность и стала своеобразной фишкой той системы KPI, которая была создана. Она позволила не только сделать систему максимально прозрачной, но и отказаться от компьютерной программы, что является несомненным плюсом, так как это экономия средств и времени. Каждый месяц дизайнеры и руководство просто собираются вместе для того, чтобы оценить проделанную работу. Дизайнеров в студии много, работы много, собрания длятся два-три часа. Долго, но все довольны, потому что каждый может высказаться о своей работе и о чужой тоже: дизайнерские задачи прописаны в CRM Bitrix и доступны для всех пользователей.

«На сегодняшний день у нас в студии очень эффективная система KPI для дизайнеров, - подводит итоги Андрей Кокеев. - Она максимально прозрачная и обсуждаемая. Сотрудники не просто видят оценку своей работы, они сами ее ставят. Коллектив дизайнеров доволен, и управлять им легко».

Советы от ART4you:

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

Когда мы только начинали бизнес и у меня не получалось придумать KPI для разработчиков, я пошёл советоваться к своему знакомому - строителю Виктору Неваре, основателю Центра модульного строительства. Я спросил у него: «Виктор, у тебя, наверное, всё по формулам? Заштукатурил метр стенки - получи какое-то количество денег?» Он ответил: «Если бы мы так работали, то сразу бы разорились».

Конечно, KPI у него тоже есть, но принимает работы прораб. Он колупнёт стену ногтем, увидит, что шпаклёвка отваливается, и скажет: «Переделывай, а деньги за материал я из твоей зарплаты вычту!» И рабочий знает, что прораба не обмануть, поэтому он сразу всё делает качественно. При этом прораб прикрывает своих перед начальством, справедливо раздаёт премии и поможет, если что.

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

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