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

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


ога… в администрировании самое оно

Мало заявок у администратора — плохо работает — надо уволить… зашибись
UFO landed and left these words here
Совершенно безобразная история! В таком случае нужно не создавать KPI в вакууме, а делать поправку на интенсивность потока обращений. Кстати, в продажах та же боль: бывает, что план не меняется и не учитывается фактор сезонности, а это гарантированно провальный коэффициент.
В моей практики было что ServiceDesk закрывал массово неразрешенные запросы с проблемами сети и Oracle DB — потому что это подрядная организация и похоже получает деньги за количество закрытых тикетов. Чтобы решить проблему самостоятельно у меня не было доступа и привелегий, а «прослойка» закрывала тикеты с прикрепленными скриншотами и логами в статусе «Can't reproduce». Вот вам и KPI!
Админа надо контролировать не количеством заявок, а простоями бизнес-процессов (потерей денег), в которые входят люди и ПО. Чем больше простоев, тем хуже админу. То есть, если доступность падает меньше заданных процентов, то зарплата админа стремительно уменьшается. С премированием немного сложней и зависит от статуса админа в компании.
Тут скорее нужен другой коэффициент — время безаварийной работы — время когда нет заявок с грифом системная ошибка.
И скорость устранения для заявок с меткой — операционная.
Я в суппорте работаю. С банковским софтом. Меня возюкали носом по KPI и говорили, что мало активности с моей стороны, вон, Вася в семь раз больше мейлов в день отправляет. Только не учли, что Вася, Женя и Петя разбирают запросы вроде «пришлите доки» и «прочитайте нам эту доку вслух» а мне передают все «репорт не генерится каждую 53ю неделю года, если снег уже растаял» и всякий упоротый неадекват, потому, что я опытный гуру. предложил инвертировать запросы между мной и остальными — ребята уговорили начальство оставить как есть. Только премии то по KPI.

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

Это касается не только KPI, но и в большей части т.н. «процессного подхода» (без которого, кстати, не пройти сертификацию по ИСО 9001, или какой там номер...)

Кто-то подсмотрел идеологию с зарубежных заводов (конвейер же!) и решил применять везде без разбора. Ну и понеслось…
Кто-то сказал, и мне понравилось: эмбиэй головного мозга.
Для этого Вас следовало вывести во вторую или даже третью линию поддержки и оценивать по другим параметрам, а не смешивать все линии в кучу.
С моей точки зрения — ошибка выстраивания службы поддержки.
Ошибка выстраивания службы поддержки? Да Вы даже не представляете!!!

Было три отдела, разрабы человек 50, внедрение где-то 40 и поддержка наверное 30. Внедрение — процесс сложный, тягомотный, сертификации и всё такое, люди со специфичным складом ума и образом жизни — проводить по два месяца за раз во всяких Киргизстанах… Сам прдукт непростой (навскидку 1200 модулей и невероятные пазлы совместимости по версиям). Руководство решило, что у поддержки и внедрения похожие задачи и можно оптимизировать(в реале не пересекается — как пример: установить линух снуля или возродить завирсённую винду). Там родилась идея, что если два отдела объединить и обозвать новым термином, то произойдёт мгновенный обмен знаниями и из 30 суппортёров + 40 внедренцев получится 70 суппортёров И(да, именно _И_) 70 внедренцев. По крайней мере перформанс от нас именно такой ожидается. Серьёзная международная корпорация, софт для фин-структур пишем.
У нас внедрение на уровне простоя сервисов. есть ответственный за сервис, к примеру электронная почта. есть система мониторинга, которая следит за работоспособностью этого сервиса. от аптайма зависит зарплата ответственного. и так по каждому сервису, в зависимости от критичности для бизнеса.
по саппорту пользователей — обработку каждого тикета должен оценить пользователь. и не важно, что заявок мало, главное их качество выполнения.
> Допустим, у сотрудников три KPI: объём продаж и дебиторка.

И, видимо, третий, который и определяет итоговый размер вознаграждения, как обычно. За статью спасибо, хотя о «пользе» KPI на этом ресурсе уже дискутировали не раз (например, здесь). Тем не менее, когда читаю подобные статьи, задаюсь вопросом, раз уж компания выбрала KPI в качестве системы оценки эффективности и оперативной оценки, по какому-то недоразумению, то зачем увязывать линейно значение KPI с размером материального вознаграждения. Тем более, что в большинстве случаев в качестве системы мотивации KPI не годится, совсем.
Из личной практики:
— Руководству надоело выписывать премии разработчикам от балды, давайте сделаем систему мотивации на базе KPI
— По количеству строчек кода? (Гыгыы)
— Вот вы и займетесь подобором показателей
(прошло 2 месяца)
— Итак у нас есть показатели: количество решенных задач из таска, количество часов на проекте в периоде, количество критичных багов в релизах. Для РП количество релизов. Для тестировщиков — кол-во проверенных и пропущенных багов. Для каждого продукта свой коэффициент…
— А вот формула, линейная с коэффициентами
… день расчета зарплаты:
— По вашей формуле Вася получает премию в 4 раза больше фиксированной зарплаты!!! Что за хрень! А Серега, который пилит второй месяц важнейший для нас проект не получает нифига, потому что его задача на 3 месяца!
— нда… Так, в этот раз платим по-старинке. Формулу доработать! Пусть будет нелинейной
… прошло два месяца
— Вот новая формула.
— Арккосинус???? Квадраты?
— Нужно было сделать нелинейность, чтобы предельные значения гладко приближались к заданным пределам…
— Вот вы и будете объяснять систему мотивации сотрудникам
… прошло два месяца
— Это слишком большая задача, её нужно разбить минимум на три, а лучше на восемь
— А на эту уйдет не час, а четыре. Да, может подтвердить любой наш сотрудник
— А куда записать время, которое я потратил на оценку задач и заполение новых полей в отчете?
— Эт чо! Это не я баг пропустил а разработчик не написал что проверить! Все в переписке есть!
— Че я зря в выходные выходил, почему я получил как все?
… прошло два месяца
— Вот! Наши KPI по 90% сотрудников выполнены на 140 и более процентов! Как насчет доп. премии руководителю отдела?
— Вы охренели? Продукты как были в бете так и остались! Клиенты уже второй год ждут доработок!
— После того как половина народу ушла, очень сложно соблюдать предыдущие договоренности. Но мы ищем! Кризис же, персонала на рынке много. Правда после испытательного срока почему-то многие сами отказываются…
Отличная история, от души в душу просто. Можно делать отдельный пост, как оно происходило по порядку :-) Да, на самом деле вопрос KPI разработчикам — очень тяжёлый, особенно, если дело касается нестандартных, сложных, ресурсоёмких проектов.
Красноречивая история о попытке подменить реальные метрики для KPI — «какими есть». А так-то должно быть очевидно, что если задачи не типовые, то одну формулу вывести не удастся. А разработка формулы под каждую задачу должна быть обоснована финансово, чаще всего человеческое управление и оценка работы будет дешевле.
По мне, так как не крутись с KPI для разработки ПО — выйдет ерунда! Только демотивация и тема для зависти и склок.

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

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

замечательные слова!
Жаль в связном их не услышали пару лет назад, ввели одну систему, и каждые два месяца вводили новую, пока в итоге не отказались, и не расформировали вообще региональный отдел техподдержки в Ростове-на-Дону (вроде осенью последних сокращают, меня сократили.)
Они ввели систему штрафов, а штрафы делились между теми сотрудниками кто работал выше нормы. правда нет штрафов — нет премий. как бы ты хорошо не работал, хоть за десятерых. А кпи показатели вообще веселые были)) главное что при разработке, никто не спрашивал у сотрудников как это и вообще возможно ли это) В итоге стек очереди до неприличия вырос, и в место пользы — вышло как всегда. Впрочем думаю связной не единственная контора, которая все реализовывает через одно место.
В сотовой связи и сотовом ритейле KPI — отдельная песня, особенно в технической поддержке и справочной службе. Особенно опасно требовать огромного количества обработанных заявок — так можно получить ну очень плохо обработанные заявки и кучу рекламаций, жалоб и скандал.
Так, в одной компании (не сотовики, но ИТ) требовали обслуживать 80 писем в день на иностранном языке. Даже если без обеда, туалета и покурить — это 6 минут на письмо! На неродном языке. В итоге через какое-то время пошли жалобы — выяснилось, что сотрудники отвечали однообразно, из разряда «очень важно для нас». Вот так рвачка за KPI подмочила репутацию компании — негативный фидбэк традиционно пополз по форумам, обзорам, соцсетям и комментариям…
В любой системе, при любом способе оценки производительности и достижений (включая, когда используют KPI) в первую очередь нужно выдержать простое правило: «правила игры» не должны меняться на ходу. На своей работе мы все ощутили все прелести подхода, когда меняются на ходу и показатели эффективности, и коэффициенты, и приоритеты показателей. Например, когда вначале говорят «учитываем количество отработанных обращений в месяц на сотрудника», и по этому показателю распределяют премию; потом говорят «нет, давайте так — кроме того нужно чтобы из них было как можно меньше инцидентов, а больше запросов»; потом учитывают трудозатраты суммарно по всем обращениям, потом — повторы инцидентов по каждому рабочему месту в неделю-месяц-(год?), потом ещё больше показателей, кроме того весьма сложно формируемых, на которые при этом сами сотрудники не могут повлиять. Я ещё понимаю, когда месяц-другой где-то в пилотном проекте, на ограниченной группе сотрудников это обкатали, и далее «правила» не менялись бы по велению левого мизинца, но когда метрики меняются порой несколько раз в месяц, а все узнают об этом уже через месяц, и часть метрик вовсе настолько мутные, что часть руководителей не понимает что к чему — вот это АД.
Кстати, вы затронули интереснейшую тему — понимание KPI руководителями. Коэффициенты должны быть понятны, прозрачны и документированы для всех. Если руководитель не может понять, что влияет на оценку, он не может наладить работу подчинённых, поскольку ему не ясны цели бизнеса.
Менять что-либо на лету в таком случае — вообще неразумно и неэтично. Думаю, в этой ситуации вполне применим правовой принцип: pacta sunt servanda, договоры должны соблюдаться.
Не только руководители, но и рядовые сотрудники должны понимать из чего складывается их доход. Иначе это вечный повод для недовольства.
Давным-давно предлагал руководству платить разработчикам процент с продаж продукта. Более опытные руководители мне тогда сказали, что это работать не будет, т.к. «разработчик не может повлиять на продажи».
Но мысль осталась. Не было ли у кого в практике примеров (отрицательных/положительных) такого подхода?
У меня был. Софтверная компания, продажи по большой географической зоне. Программистам решили платить % с продаж (не KPI, а именно долю). Так вот, программисты были хорошие, а продажники сменились и стали не очень. И кризис ещё грянул по основным регионам. Продажи упали, но процент всё равно был. Закончилось всё очень сильным корпоративным раздраем и криками об очень плохих продажниках. Когда атмосфера перекалилась, разработчикам просто установили стабильное премирование и надбавку.
Общепринято опционы предлагать, что в принципе похоже на то, что вы хотите. Главное для меня — разработчика, чтобы этот процент был «сверху» зарплаты, а не «внутри» нее.
Опцион это право в будущем выкупить долю в компании по фиксированной (обычно заниженной) цене. Нормально это можно сделать только в АО. Да и то разработчики сильно удивятся, когда окажется что компания почти не генерит чистую прибыль, либо она не распределяется среди владельцев а идет на реинвестирование. А так живут наверное 95% софтверных компаний :).
Можно свой велосипед придумать. Опцион на получение годовой прибыли, или типа того.
Насколько я знаю, нечто подобное у booking.com — эффективность функционала измеряется в его влиянии на кол-во заказов в минуту
С любым подходом от «общего результата» непонятно как быть с тестировщиками или вспомогательными разработчиками которые пишут автотесты, или поддерживают CI. Их труд может дать результаты через продолжительное время.
KPI — на команду. Команде отдаётся какой-то сервис. А дальше — как хочешь крутись, команда.
В реальных компаниях есть подразделения, которые работают на много проектов. Либо отдельные люди шарятся между проектами. И вообще матричную структуру пока никто не отменял.
Что видится навскидку — несколько вариантов:
1) Разработчики получают процент от продажной цены.
1а) Получают индивидуальные проценты, от других членов команды не зависящие (условно — Васе, Пете и Мише — по 0,5% продажной цены). Получаются драки разрабов на вхождение в дорогие проекты, при этом дешевые проекты будут наказаниями. Склоки внутри разрабов (слабые).
1б) Процент на команду. Тут начинается разборка внутри уже команды проекта с последующим ухудшением отношений между разрабами (если эта дележка идет демократично) или с ЛПР (если единолично).
В обоих вариантах разработчики а) не влияют на продажную цену, б) не интересуются, прибылен ли проект и в срок ли он сдан (а смысл интересоваться? Процент по любому будет). Продавец мог задешевить проект с целью подсадить заказчика или еще какой, что также не зависит от разрабов.
2) Разработчики получают процент от прибыли. Аналогичная ветка по дележке.
Несколько лучше — разрабам интересно уложиться в бюджет. Но есть и негативная сторона — если продавец изначально «упал» по деньгам (то есть занизил цену) — то уложиться в бюджет может просто не получиться — со всем отсюда плавно вытекающим.

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

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

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

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

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

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

Так я-то собираюсь не сравнивать, у кого толще пачка купюр — у меня или у Васи. А максимизировать свой доход при минимизации усилий! :)

А по поводу конкуренции — если это предусмотрено логикой процессов в компании — да не вопрос.
А вот если нет — тут могут быть серьезные засады.
Звезда поиграла в одном проекте, потом его покинула и зазвездилась в другом. А первый при этом начинает тонуть…
Если же перехода между проектами нет — то могут быть эффекты неравномерной загрузки сотрудников, что тоже не айс.

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

Систему надо смотреть, систему целиком, а не отдельно взятый аспект. :)
Безусловно, «багов» в любой такой системе будет достаточно, но на то и нужны руководители чтобы директивно в ручном режиме разруливать проблемы, а потом отвечать, если что-то пошло не так. За это им и платят неплохо :)
Это в теории. :)

В ряде мест начальники нужны для того чтобы проблемы — прятать.
Как только вводятся KPI для разработчиков, то ушлые программисты перестают работать и начинают играть.
Спустя N месяцев (где N от 2 до 24) 80% разрабов переходят в множество ушлых, а 20% меняют место работы.
В этом и состоит весь секрет.
Если в процессе «игры» разработчик будет выполнять требуемые задачи в установленные сроки — то задача решена верно. Если нет — то это косяк менеджмента.
KPI, как сказано в статье не должен быть механизмом кары, он должен быть фокусом на важных задачах.
Опять же полное отсутствие контроля, может привести к отсутствию работы.
На самом деле существует всего два способа мотивации: морковка спереди и морковка сзади. Все остальное — детали реализации.
За админство скажу и саппорт.
KPI на количество заявок — провален — быстро вступят в сговор с сотрудниками и всегда все будет отлично на бумаге)
KPI на выполнение заявок в рамках SLA — чуть более корректен, потому что SLA хоть как то инциденты учитывает по сложности.
KPI на простой, где 0 часов простоя это 100% — плохо. У вас будет запланированый простой на тех обслуживание, либо случится таки авария, которую вы решите за 4 часа не прогнув бизнес, но вам попытаются этим попенять и вы прилетите на деньги.

ЗЫ
у нас отношение в стране даже k KPI типично российское. Яркий пример ГИБДД. вы ДОЛЖНЫ за смену поймать столько то пьяных! а есали их нет?! Ну вот что делать?
У буржуев другой подход: есть аварийность на ввереном участке. Как хочешь регулируй, но смертность, аварийность должны быть в KPI. И вот тут кто как умеет) Хотите — будьте самыми злыми в городе. А может просто достаточно стоять с мигалками НА дороге, а не в кустах?)
Из личного примера:
Я задаю вопрос про KPI следующего года — «KPI в примерах не используется для расчета вообще, зачем он нужен?»
Ответ — «KPI введен в формулу для будущего. Значение коэффициента по умолчанию (1) в тексте приведено»
Only those users with full accounts are able to leave comments. Log in, please.