- PVSM.RU - https://www.pvsm.ru -
Для написания этой заметки — было затрачено:
Много денег и времени. Пожалуй, самым затратным (по нервам, времени и деньгам) был эксперимент над собственной командой, о котором мне безумно неловко вспоминать. Но об этом — ниже.
Рано или поздно, наверное, у каждого директора возникает желание платить по справедливости. За выполенную работу. И очень многие сейчас пытаются внедрять KPI (ключевые показатели эффективности). Работает так: вы, как владелец бизнеса, назначаете конкретные цели для сотрудников. Они достигают или не достигают поставленных целей в процессе работы. Тем, кто достиг — выдается плюшка (денежная премия).
Ну, логично же, что:
А вот с творческими единицами (дизайнерами, программистами) — все значительно сложнее.
Мы недавно провели опрос руководителей ведущих диджитал-агентств и веб-студий страны на тему «а как вы используете KPI по отношению к труду творческих единиц», в результате получили вот такую картинку:
Некоторые компании (15%) применяют KPI для оценки эффективности труда программистов и дизайнеров.
Около 25% компаний внедряют KPI в данный момент / встречают сопротивление внутри компании или же работают по упрощенной схеме.
Примерно 30% компаний производит оплату труда работников на основе субъективных оценок руководителей. Вернее, 30% — сознаются в этом ;-)
Не сознаются — оставшиеся 30%.
Самое интересное, что многие пытались внедрить KPI или пытаются сейчас. Причем не очень успешно. Это не значит, что «KPI плохой». Плохо приготовленную пищу — есть невозможно. Может, мы просто не умеем этот KPI готовить?
Но статистика говорит о том, что затруднения при внедрении есть у подавляющего большинства. И есть подозрение, что таки проблема у всех общая. Давайте попробуем разобраться.
Возникает вопрос: Что сильнее всего парит разработчиков при внедрении KPI?
Проведя несколько экспериментов и опросов среди коллег, мы выделили 6 основных причин:
Если посмотреть на этот список внимательно, можно обнаружить, что большая часть претензий связана с выбором, учетом, прозрачностью и адекватностью критериев.
Ну такие, которые все поймут, которые не будут никого парить, которые будет просто объяснить даже на собеседовании. И чтобы было все честно, и хотелось работать еще и еще.
В общем, давайте попробуем найти Хорошие Критерии. (Кстати, «Хорошие» — для кого?). У нас есть три ключевых пострадавших стейкхолдера: владелец студии, заказчик и разработчики.
Что может быть Хорошим Критерием с точки зрения заказчика? Обычно всё сводится к деньгам (ну либо каким-то фактическим результатам):
Однако реалии сейчас таковы, что прийти и предложить, например, дизайнеру, зависимость его ЗП от эфемерной «удовлетворенности» заказчика — это гарантированный способ остаться без дизайнера. Нужен очень серьезный кризис, чтобы эта тема начала работать. Или очень много хороших лишних дизайнеров.
ОК. Эти Критерии, Хорошие для заказчика, очевидно, не будут Хорошими для разработчика. (Я без иллюзий, сейчас можно запросто придумать еще 200 штук разных критериев, значимых для бизнеса. Пишите, обсудим в комментариях :))
Но ведь можно мерить ПРОИЗВОДИТЕЛЬНОСТЬ! Это же так просто!
Или нет? В чем ее мерить? Если бы я красил забор — то все очевидно. Но есть заковырка. В нашей отрасли много мыслящих, творческих, талантливых людей и заборы никто не красит. Давайте разберем на примере программистов. Итак, какие Хорошие Критерии оценки производительности приходят на ум?
Не надо им мешать тупыми корпоративными правилами.
Позволяет предсказать, сколько задач команда сможет набрать в следующий этап в зависимости от того, сколько она выполнила в предыдущем. Проблемы такие же, как у Фокус-фактора, плюс добавляется еще одна. Часто менеджер (особенно неопытный), почуявший, что производительность команды можно «измерить», начинает применять данный инструмент «в другую сторону». Но Velocity не может быть точным критерием, т.к. показывает, сколько времени может занять та же самая задача, выполняемая той же командой при тех же условиях. Однако после выполения задачи — команда уже поменялась: у нее появился опыт того, как именно решать конкретно эту задачу. И метрика не сработает повторно.
Мне лично очень нравится эта метрика. Одна из ключевых, которую стоит замерять и оптимизировать. Но разработчики не влияют на этот фактор напрямую. Это слишком высокоуровневая метрика. Если вы начинаете платить команде зарплату на основании того, какой у них Cycle Time, это значит, что вы как руководитель не стремитесь решить проблемы команды и разобраться в процессах, а просто переваливаете все на команду.
Попытка поставить зависимость зарплаты разработчика от высокоуровневой метрики — свидетельство менеджерской импотенции
Итак, можно ли измерить эффективность команды? Да, можно, тем более, что показателей для этого мы с вами понаписали с десяток. И еще десятка два можно придумать в комментариях. Другой вопрос — стоит ли делать зарплату разработчика зависимой от показателей? А вот это уже рискованно.
Я начинаю работать, и делаю свою работу — хорошо, потому что я профессионал и мне это интересно. Но если меня начинают гнобить дурацкими метриками — я буду оптимизировать эти дурацкие метрики. Я буду писать 1000 строчек или рисовать 10 говнодизайнов в день. И мой интерес к работе очень-очень быстро иссякнет, я буду тупо хотеть бабла. Это называется подменой внутренней мотивации — внешней.
Как-то раз «мой хороший знакомый», руководитель студии, загорелся идеей внедрить очень справедливую оплату труда, где бы учитывались куча параметров. Естественно, к делу подошли с размахом. Написали целую кучу критериев, как то:
— ежемесячный план по отработанным человеко-часам и фактически отработанному времени;
— ежеквартальный план по сбыту;
— количество подопечных и их зарплаты;
— количество позитивной коммуникации от клиентов (удовлетворенность);
— количество повторных обращений клиента с новыми проектами;
— награды на профильных конкурсах;
— отрицательная коммуникация с клиентом;
— количество багов, найденных QA;
— рост дебиторской задолженности;
— количество багов, найденных клиентом после старта проекта;
— чтение книг, написание статей.
И еще штук 20. (полезный список, забирай ;-).
Все это было сведено в одну систему. Естественно, систему нужно было сбалансировать. Поэтому в первые несколько месяцев было решено откалибровать ее на виртуальных «фантиках». Была изобретена большая доска, на которой нарисовали список сотрудников. На доске вывешивались разные «фантики» — сразу же, как только поступал платеж, заканчивался проект или происходило какое-то хорошее (или плохое) событие, которое бы в будущем влияло на зарплату.
Буквально в течение 1 часа лица сотрудников сделались сильно-сильно хмурыми. Через пару дней начались вопросы: «а почему мне меньше фантиков?» или «а почему мне не дали фантик — я же Васе помогал?».
Настроение становилось тревожным. Через неделю на оценку проектов стало уходить в 4 раза больше времени, чем уходило раньше, и каждая оценка превращалась в бесконечный спор между разработчиком и руководителем проектов. К концу месяца мало кто хотел помогать товарищу — объясняли тем, что «своей работы хватает». Вскрылось бесконечное количество ситуаций, которые невозможно было формализовать. Многие фантики выдавались по субъективным ощущениям.
Мало кто хотел работать без фантиков, напряжение росло. Производительность и мотивация — падала. Еще через месяц программу свернули. Еще через пару месяцев пропала тревожность.
Разные метрики стоит измерять и думать-думать-думать, как на них влиять. Но не переносить высокоуровневые метрики напрямую на разработчиков и дизайнеров. И еще:
«Разработчик состоит из четырех компонентов: тело, сердце, разум и душа.
1. Телу необходимы деньги и безопасность.
2. Сердцу — любовь и признание.
3. Разуму — развитие и самосовершенствование.
4. Душе — самореализация».— С. Архипенков
Уважайте других людей и давайте им возможность делать то, что им нравится )).
И совсем последнее. Есть подозрение, что каждый руководитель должен сам понять, готова ли его организация к переходу на KPI. Я надеюсь, эта небольшая подборка статей, которую нам удалось собрать — поможет в принятии верного решения.
Автор: zevvssibirix
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/15972
Ссылки в тексте:
[1] О вреде премирования: http://russian.joelonsoftware.com/Articles/IncentivePayConsideredHar.html
[2] Не мешайте мне работать: http://motivateme.ru/book/
[3] Денежная мотивация в проектах разработки ПО: http://scrumtrek.ru/img/ar-stuff/Urazbaev.MoneyMotivation.pdf
[4] Метрики в Agile: http://lib.custis.ru/%D0%9C%D0%B5%D1%82%D1%80%D0%B8%D0%BA%D0%B8_%D0%B2_Agile_(%D0%B2%D1%81%D1%82%D1%80%D0%B5%D1%87%D0%B0_AgileRussia.ru_2009-08-18)
[5] Базовые показатели ударников капиталистического труда: http://hr.prolan.ru/publications/pub-2010-03-23.html
[6] Сколько нужно платить разработчикам: http://habrahabr.ru/post/124844/
[7] Business Intelligence: http://habrahabr.ru/post/134031/http://habrahabr.ru/post/23124/
[8] Мотивация IT-специалистов: http://habrahabr.ru/post/23124/
[9] Система сбалансированных показателей как инструмент управления компанией/подразделением: http://habrahabr.ru/post/85456/
[10] Какие KPI можно измерять, если расписание и бюджет не очень важны: http://habrahabr.ru/post/135652/
[11] Показатели эффективности (KPI) для сотрудников ИТ: http://habrahabr.ru/post/22536/
[12] Мифы мотивации. Выход из тупика: http://www.ozon.ru/context/detail/id/7244740/
[13] Методы мотивации сотрудников: http://mirsovetov.ru/a/miscellaneous/employment/motivation-staff.html
[14] Пособие: как убить сотрудника пряником? Или методы мотивации: http://iomarket.com.ua/posobie-kak-ubit-sotrudnika-pryanikom-ili-metody-motivatzii/
[15] Почему программистам не платят пропорционально их продуктивности: http://habrahabr.ru/post/96140/
Нажмите здесь для печати.