Комментарии 52
ИМХО, к разработке неприменима система KPI. Продажи, маркетинг — да, но только не разработка.
На самом деле, чаще всего KPI используются как раз для коммерческой службы и в частности для продаж — это верный и надёжный способ оценить работника. В тестировании и администрировании тоже распространено, поскольку количественные измерения более чёткие: баги, инциденты и их статусы.
В разработке если и вводить, то с огромной осторожностью, мотивированно и уж точно не по количеству строк кода.
В разработке если и вводить, то с огромной осторожностью, мотивированно и уж точно не по количеству строк кода.
В тестировании и администрировании тоже распространено, поскольку количественные измерения более чёткие: баги, инциденты и их статусы.
ога… в администрировании самое оно
Мало заявок у администратора — плохо работает — надо уволить… зашибись
НЛО прилетело и опубликовало эту надпись здесь
Совершенно безобразная история! В таком случае нужно не создавать KPI в вакууме, а делать поправку на интенсивность потока обращений. Кстати, в продажах та же боль: бывает, что план не меняется и не учитывается фактор сезонности, а это гарантированно провальный коэффициент.
В моей практики было что ServiceDesk закрывал массово неразрешенные запросы с проблемами сети и Oracle DB — потому что это подрядная организация и похоже получает деньги за количество закрытых тикетов. Чтобы решить проблему самостоятельно у меня не было доступа и привелегий, а «прослойка» закрывала тикеты с прикрепленными скриншотами и логами в статусе «Can't reproduce». Вот вам и KPI!
Админа надо контролировать не количеством заявок, а простоями бизнес-процессов (потерей денег), в которые входят люди и ПО. Чем больше простоев, тем хуже админу. То есть, если доступность падает меньше заданных процентов, то зарплата админа стремительно уменьшается. С премированием немного сложней и зависит от статуса админа в компании.
Тут скорее нужен другой коэффициент — время безаварийной работы — время когда нет заявок с грифом системная ошибка.
И скорость устранения для заявок с меткой — операционная.
И скорость устранения для заявок с меткой — операционная.
Я в суппорте работаю. С банковским софтом. Меня возюкали носом по KPI и говорили, что мало активности с моей стороны, вон, Вася в семь раз больше мейлов в день отправляет. Только не учли, что Вася, Женя и Петя разбирают запросы вроде «пришлите доки» и «прочитайте нам эту доку вслух» а мне передают все «репорт не генерится каждую 53ю неделю года, если снег уже растаял» и всякий упоротый неадекват, потому, что я опытный гуру. предложил инвертировать запросы между мной и остальными — ребята уговорили начальство оставить как есть. Только премии то по KPI.
Вобщем всё это для тех, кто с конвеера яблоки по коробкам сортирует.
Вобщем всё это для тех, кто с конвеера яблоки по коробкам сортирует.
Или для тех, чьё руководство башкой думать не хочет…
«Вобщем всё это для тех, кто с конвеера яблоки по коробкам сортирует.» — можно я эту фразу запомню, запишу, и высеку на камне? Ну и потом использовать каждый день, конечно :)
Это касается не только KPI, но и в большей части т.н. «процессного подхода» (без которого, кстати, не пройти сертификацию по ИСО 9001, или какой там номер...)
Кто-то подсмотрел идеологию с зарубежных заводов (конвейер же!) и решил применять везде без разбора. Ну и понеслось…
Кто-то сказал, и мне понравилось: эмбиэй головного мозга.
Это касается не только KPI, но и в большей части т.н. «процессного подхода» (без которого, кстати, не пройти сертификацию по ИСО 9001, или какой там номер...)
Кто-то подсмотрел идеологию с зарубежных заводов (конвейер же!) и решил применять везде без разбора. Ну и понеслось…
Кто-то сказал, и мне понравилось: эмбиэй головного мозга.
Для этого Вас следовало вывести во вторую или даже третью линию поддержки и оценивать по другим параметрам, а не смешивать все линии в кучу.
С моей точки зрения — ошибка выстраивания службы поддержки.
С моей точки зрения — ошибка выстраивания службы поддержки.
Ошибка выстраивания службы поддержки? Да Вы даже не представляете!!!
Было три отдела, разрабы человек 50, внедрение где-то 40 и поддержка наверное 30. Внедрение — процесс сложный, тягомотный, сертификации и всё такое, люди со специфичным складом ума и образом жизни — проводить по два месяца за раз во всяких Киргизстанах… Сам прдукт непростой (навскидку 1200 модулей и невероятные пазлы совместимости по версиям). Руководство решило, что у поддержки и внедрения похожие задачи и можно оптимизировать(в реале не пересекается — как пример: установить линух снуля или возродить завирсённую винду). Там родилась идея, что если два отдела объединить и обозвать новым термином, то произойдёт мгновенный обмен знаниями и из 30 суппортёров + 40 внедренцев получится 70 суппортёров И(да, именно _И_) 70 внедренцев. По крайней мере перформанс от нас именно такой ожидается. Серьёзная международная корпорация, софт для фин-структур пишем.
Было три отдела, разрабы человек 50, внедрение где-то 40 и поддержка наверное 30. Внедрение — процесс сложный, тягомотный, сертификации и всё такое, люди со специфичным складом ума и образом жизни — проводить по два месяца за раз во всяких Киргизстанах… Сам прдукт непростой (навскидку 1200 модулей и невероятные пазлы совместимости по версиям). Руководство решило, что у поддержки и внедрения похожие задачи и можно оптимизировать(в реале не пересекается — как пример: установить линух снуля или возродить завирсённую винду). Там родилась идея, что если два отдела объединить и обозвать новым термином, то произойдёт мгновенный обмен знаниями и из 30 суппортёров + 40 внедренцев получится 70 суппортёров И(да, именно _И_) 70 внедренцев. По крайней мере перформанс от нас именно такой ожидается. Серьёзная международная корпорация, софт для фин-структур пишем.
У нас внедрение на уровне простоя сервисов. есть ответственный за сервис, к примеру электронная почта. есть система мониторинга, которая следит за работоспособностью этого сервиса. от аптайма зависит зарплата ответственного. и так по каждому сервису, в зависимости от критичности для бизнеса.
по саппорту пользователей — обработку каждого тикета должен оценить пользователь. и не важно, что заявок мало, главное их качество выполнения.
по саппорту пользователей — обработку каждого тикета должен оценить пользователь. и не важно, что заявок мало, главное их качество выполнения.
> Допустим, у сотрудников три KPI: объём продаж и дебиторка.
И, видимо, третий, который и определяет итоговый размер вознаграждения, как обычно. За статью спасибо, хотя о «пользе» KPI на этом ресурсе уже дискутировали не раз (например, здесь). Тем не менее, когда читаю подобные статьи, задаюсь вопросом, раз уж компания выбрала KPI в качестве системы оценки эффективности и оперативной оценки, по какому-то недоразумению, то зачем увязывать линейно значение KPI с размером материального вознаграждения. Тем более, что в большинстве случаев в качестве системы мотивации KPI не годится, совсем.
И, видимо, третий, который и определяет итоговый размер вознаграждения, как обычно. За статью спасибо, хотя о «пользе» KPI на этом ресурсе уже дискутировали не раз (например, здесь). Тем не менее, когда читаю подобные статьи, задаюсь вопросом, раз уж компания выбрала KPI в качестве системы оценки эффективности и оперативной оценки, по какому-то недоразумению, то зачем увязывать линейно значение KPI с размером материального вознаграждения. Тем более, что в большинстве случаев в качестве системы мотивации KPI не годится, совсем.
Из личной практики:
— Руководству надоело выписывать премии разработчикам от балды, давайте сделаем систему мотивации на базе KPI
— По количеству строчек кода? (Гыгыы)
— Вот вы и займетесь подобором показателей
(прошло 2 месяца)
— Итак у нас есть показатели: количество решенных задач из таска, количество часов на проекте в периоде, количество критичных багов в релизах. Для РП количество релизов. Для тестировщиков — кол-во проверенных и пропущенных багов. Для каждого продукта свой коэффициент…
— А вот формула, линейная с коэффициентами
… день расчета зарплаты:
— По вашей формуле Вася получает премию в 4 раза больше фиксированной зарплаты!!! Что за хрень! А Серега, который пилит второй месяц важнейший для нас проект не получает нифига, потому что его задача на 3 месяца!
— нда… Так, в этот раз платим по-старинке. Формулу доработать! Пусть будет нелинейной
… прошло два месяца
— Вот новая формула.
— Арккосинус???? Квадраты?
— Нужно было сделать нелинейность, чтобы предельные значения гладко приближались к заданным пределам…
— Вот вы и будете объяснять систему мотивации сотрудникам
… прошло два месяца
— Это слишком большая задача, её нужно разбить минимум на три, а лучше на восемь
— А на эту уйдет не час, а четыре. Да, может подтвердить любой наш сотрудник
— А куда записать время, которое я потратил на оценку задач и заполение новых полей в отчете?
— Эт чо! Это не я баг пропустил а разработчик не написал что проверить! Все в переписке есть!
— Че я зря в выходные выходил, почему я получил как все?
… прошло два месяца
— Вот! Наши KPI по 90% сотрудников выполнены на 140 и более процентов! Как насчет доп. премии руководителю отдела?
— Вы охренели? Продукты как были в бете так и остались! Клиенты уже второй год ждут доработок!
— После того как половина народу ушла, очень сложно соблюдать предыдущие договоренности. Но мы ищем! Кризис же, персонала на рынке много. Правда после испытательного срока почему-то многие сами отказываются…
— Руководству надоело выписывать премии разработчикам от балды, давайте сделаем систему мотивации на базе KPI
— По количеству строчек кода? (Гыгыы)
— Вот вы и займетесь подобором показателей
(прошло 2 месяца)
— Итак у нас есть показатели: количество решенных задач из таска, количество часов на проекте в периоде, количество критичных багов в релизах. Для РП количество релизов. Для тестировщиков — кол-во проверенных и пропущенных багов. Для каждого продукта свой коэффициент…
— А вот формула, линейная с коэффициентами
… день расчета зарплаты:
— По вашей формуле Вася получает премию в 4 раза больше фиксированной зарплаты!!! Что за хрень! А Серега, который пилит второй месяц важнейший для нас проект не получает нифига, потому что его задача на 3 месяца!
— нда… Так, в этот раз платим по-старинке. Формулу доработать! Пусть будет нелинейной
… прошло два месяца
— Вот новая формула.
— Арккосинус???? Квадраты?
— Нужно было сделать нелинейность, чтобы предельные значения гладко приближались к заданным пределам…
— Вот вы и будете объяснять систему мотивации сотрудникам
… прошло два месяца
— Это слишком большая задача, её нужно разбить минимум на три, а лучше на восемь
— А на эту уйдет не час, а четыре. Да, может подтвердить любой наш сотрудник
— А куда записать время, которое я потратил на оценку задач и заполение новых полей в отчете?
— Эт чо! Это не я баг пропустил а разработчик не написал что проверить! Все в переписке есть!
— Че я зря в выходные выходил, почему я получил как все?
… прошло два месяца
— Вот! Наши KPI по 90% сотрудников выполнены на 140 и более процентов! Как насчет доп. премии руководителю отдела?
— Вы охренели? Продукты как были в бете так и остались! Клиенты уже второй год ждут доработок!
— После того как половина народу ушла, очень сложно соблюдать предыдущие договоренности. Но мы ищем! Кризис же, персонала на рынке много. Правда после испытательного срока почему-то многие сами отказываются…
Отличная история, от души в душу просто. Можно делать отдельный пост, как оно происходило по порядку :-) Да, на самом деле вопрос KPI разработчикам — очень тяжёлый, особенно, если дело касается нестандартных, сложных, ресурсоёмких проектов.
Красноречивая история о попытке подменить реальные метрики для KPI — «какими есть». А так-то должно быть очевидно, что если задачи не типовые, то одну формулу вывести не удастся. А разработка формулы под каждую задачу должна быть обоснована финансово, чаще всего человеческое управление и оценка работы будет дешевле.
По мне, так как не крутись с KPI для разработки ПО — выйдет ерунда! Только демотивация и тема для зависти и склок.
В такой ситуации проще привязать премии к общим достижениям организации и если система работает и приносит деньги, то платить типа 13 зарплаты всем (пропорционально окладу).
В такой ситуации проще привязать премии к общим достижениям организации и если система работает и приносит деньги, то платить типа 13 зарплаты всем (пропорционально окладу).
Минус — если есть некто, кто забивает и не помогает, он будет получать ту же премию, хоть и не способствовал успеху — поскольку организация в целом — задачи выполнила.
Это вопрос зрелости и отношений внутри коллектива. Здоровая команда сразу отторгнет того кто забивает, лучше любых менеджеров и KPI.
А если процветает бюрократия и корпоративные войны которые держат таких людей, тогда вообще как возможен успех и какая система мотивации может работать для здравомыслящих и успешно работающих сотрудников!?)
А если процветает бюрократия и корпоративные войны которые держат таких людей, тогда вообще как возможен успех и какая система мотивации может работать для здравомыслящих и успешно работающих сотрудников!?)
КПИай это просто хренотень которая мешает повседневной работе, сидим и придумываем себе задачи и героически их выполняем.
смотря как настроить KPI. Если цели будут выстроены правильно и мотивация продумана, показатели KPI могут быть весьма эффективными.
Вот именно если настроить и цели поставить правильно! но в большинстве случаев это показушничество для руководства и отвлечение сил сотрудников от основной работы, в общем у нас на работе это так, да еще и целый отдел сидит зп получает. Сейчас надо на след год придумать себе КПИай, сидим и голову ломаем.
Увы, это очень распространённая практика, когда сотрудник вынужден подгонять задачи под KPI и ещё какую-нибудь еженедельную отчётность. Если такое происходит, руководитель обязан инициировать пересмотр системы мотивации. Да, я знаю, это утопия…
Система KPI не должна строиться как система наказаний или орудие возмездия
замечательные слова!
Жаль в связном их не услышали пару лет назад, ввели одну систему, и каждые два месяца вводили новую, пока в итоге не отказались, и не расформировали вообще региональный отдел техподдержки в Ростове-на-Дону (вроде осенью последних сокращают, меня сократили.)
Они ввели систему штрафов, а штрафы делились между теми сотрудниками кто работал выше нормы. правда нет штрафов — нет премий. как бы ты хорошо не работал, хоть за десятерых. А кпи показатели вообще веселые были)) главное что при разработке, никто не спрашивал у сотрудников как это и вообще возможно ли это) В итоге стек очереди до неприличия вырос, и в место пользы — вышло как всегда. Впрочем думаю связной не единственная контора, которая все реализовывает через одно место.
Они ввели систему штрафов, а штрафы делились между теми сотрудниками кто работал выше нормы. правда нет штрафов — нет премий. как бы ты хорошо не работал, хоть за десятерых. А кпи показатели вообще веселые были)) главное что при разработке, никто не спрашивал у сотрудников как это и вообще возможно ли это) В итоге стек очереди до неприличия вырос, и в место пользы — вышло как всегда. Впрочем думаю связной не единственная контора, которая все реализовывает через одно место.
В сотовой связи и сотовом ритейле KPI — отдельная песня, особенно в технической поддержке и справочной службе. Особенно опасно требовать огромного количества обработанных заявок — так можно получить ну очень плохо обработанные заявки и кучу рекламаций, жалоб и скандал.
Так, в одной компании (не сотовики, но ИТ) требовали обслуживать 80 писем в день на иностранном языке. Даже если без обеда, туалета и покурить — это 6 минут на письмо! На неродном языке. В итоге через какое-то время пошли жалобы — выяснилось, что сотрудники отвечали однообразно, из разряда «очень важно для нас». Вот так рвачка за KPI подмочила репутацию компании — негативный фидбэк традиционно пополз по форумам, обзорам, соцсетям и комментариям…
Так, в одной компании (не сотовики, но ИТ) требовали обслуживать 80 писем в день на иностранном языке. Даже если без обеда, туалета и покурить — это 6 минут на письмо! На неродном языке. В итоге через какое-то время пошли жалобы — выяснилось, что сотрудники отвечали однообразно, из разряда «очень важно для нас». Вот так рвачка за KPI подмочила репутацию компании — негативный фидбэк традиционно пополз по форумам, обзорам, соцсетям и комментариям…
В любой системе, при любом способе оценки производительности и достижений (включая, когда используют KPI) в первую очередь нужно выдержать простое правило: «правила игры» не должны меняться на ходу. На своей работе мы все ощутили все прелести подхода, когда меняются на ходу и показатели эффективности, и коэффициенты, и приоритеты показателей. Например, когда вначале говорят «учитываем количество отработанных обращений в месяц на сотрудника», и по этому показателю распределяют премию; потом говорят «нет, давайте так — кроме того нужно чтобы из них было как можно меньше инцидентов, а больше запросов»; потом учитывают трудозатраты суммарно по всем обращениям, потом — повторы инцидентов по каждому рабочему месту в неделю-месяц-(год?), потом ещё больше показателей, кроме того весьма сложно формируемых, на которые при этом сами сотрудники не могут повлиять. Я ещё понимаю, когда месяц-другой где-то в пилотном проекте, на ограниченной группе сотрудников это обкатали, и далее «правила» не менялись бы по велению левого мизинца, но когда метрики меняются порой несколько раз в месяц, а все узнают об этом уже через месяц, и часть метрик вовсе настолько мутные, что часть руководителей не понимает что к чему — вот это АД.
Кстати, вы затронули интереснейшую тему — понимание KPI руководителями. Коэффициенты должны быть понятны, прозрачны и документированы для всех. Если руководитель не может понять, что влияет на оценку, он не может наладить работу подчинённых, поскольку ему не ясны цели бизнеса.
Менять что-либо на лету в таком случае — вообще неразумно и неэтично. Думаю, в этой ситуации вполне применим правовой принцип: pacta sunt servanda, договоры должны соблюдаться.
Менять что-либо на лету в таком случае — вообще неразумно и неэтично. Думаю, в этой ситуации вполне применим правовой принцип: pacta sunt servanda, договоры должны соблюдаться.
Давным-давно предлагал руководству платить разработчикам процент с продаж продукта. Более опытные руководители мне тогда сказали, что это работать не будет, т.к. «разработчик не может повлиять на продажи».
Но мысль осталась. Не было ли у кого в практике примеров (отрицательных/положительных) такого подхода?
Но мысль осталась. Не было ли у кого в практике примеров (отрицательных/положительных) такого подхода?
У меня был. Софтверная компания, продажи по большой географической зоне. Программистам решили платить % с продаж (не KPI, а именно долю). Так вот, программисты были хорошие, а продажники сменились и стали не очень. И кризис ещё грянул по основным регионам. Продажи упали, но процент всё равно был. Закончилось всё очень сильным корпоративным раздраем и криками об очень плохих продажниках. Когда атмосфера перекалилась, разработчикам просто установили стабильное премирование и надбавку.
НЛО прилетело и опубликовало эту надпись здесь
Опцион это право в будущем выкупить долю в компании по фиксированной (обычно заниженной) цене. Нормально это можно сделать только в АО. Да и то разработчики сильно удивятся, когда окажется что компания почти не генерит чистую прибыль, либо она не распределяется среди владельцев а идет на реинвестирование. А так живут наверное 95% софтверных компаний :).
Насколько я знаю, нечто подобное у booking.com — эффективность функционала измеряется в его влиянии на кол-во заказов в минуту
Что видится навскидку — несколько вариантов:
1) Разработчики получают процент от продажной цены.
1а) Получают индивидуальные проценты, от других членов команды не зависящие (условно — Васе, Пете и Мише — по 0,5% продажной цены). Получаются драки разрабов на вхождение в дорогие проекты, при этом дешевые проекты будут наказаниями. Склоки внутри разрабов (слабые).
1б) Процент на команду. Тут начинается разборка внутри уже команды проекта с последующим ухудшением отношений между разрабами (если эта дележка идет демократично) или с ЛПР (если единолично).
В обоих вариантах разработчики а) не влияют на продажную цену, б) не интересуются, прибылен ли проект и в срок ли он сдан (а смысл интересоваться? Процент по любому будет). Продавец мог задешевить проект с целью подсадить заказчика или еще какой, что также не зависит от разрабов.
2) Разработчики получают процент от прибыли. Аналогичная ветка по дележке.
Несколько лучше — разрабам интересно уложиться в бюджет. Но есть и негативная сторона — если продавец изначально «упал» по деньгам (то есть занизил цену) — то уложиться в бюджет может просто не получиться — со всем отсюда плавно вытекающим.
В чистом виде не взлетит в обоих вариантах, на мой взгляд.
Должна быть некая комплексная система, учитывающая и прибыльность проекта, и выдерживание сроков, и удовлетворенность заказчика (вот тут может быть процент от повторной продажи тому же заказчику!), и трудоемкость.
И в любом случае между продавцами и разрабами отношения будут натянутыми — одни «хреново продают», другие «хреново работают».
В любом случае процессы внутри компании — и KPI тех же продавцов — должны быть выстроены так, чтобы не допускать перекосов типа «я продал, теперь ваша очередь выкручиваться».
1) Разработчики получают процент от продажной цены.
1а) Получают индивидуальные проценты, от других членов команды не зависящие (условно — Васе, Пете и Мише — по 0,5% продажной цены). Получаются драки разрабов на вхождение в дорогие проекты, при этом дешевые проекты будут наказаниями. Склоки внутри разрабов (слабые).
1б) Процент на команду. Тут начинается разборка внутри уже команды проекта с последующим ухудшением отношений между разрабами (если эта дележка идет демократично) или с ЛПР (если единолично).
В обоих вариантах разработчики а) не влияют на продажную цену, б) не интересуются, прибылен ли проект и в срок ли он сдан (а смысл интересоваться? Процент по любому будет). Продавец мог задешевить проект с целью подсадить заказчика или еще какой, что также не зависит от разрабов.
2) Разработчики получают процент от прибыли. Аналогичная ветка по дележке.
Несколько лучше — разрабам интересно уложиться в бюджет. Но есть и негативная сторона — если продавец изначально «упал» по деньгам (то есть занизил цену) — то уложиться в бюджет может просто не получиться — со всем отсюда плавно вытекающим.
В чистом виде не взлетит в обоих вариантах, на мой взгляд.
Должна быть некая комплексная система, учитывающая и прибыльность проекта, и выдерживание сроков, и удовлетворенность заказчика (вот тут может быть процент от повторной продажи тому же заказчику!), и трудоемкость.
И в любом случае между продавцами и разрабами отношения будут натянутыми — одни «хреново продают», другие «хреново работают».
В любом случае процессы внутри компании — и KPI тех же продавцов — должны быть выстроены так, чтобы не допускать перекосов типа «я продал, теперь ваша очередь выкручиваться».
Есть один хороший способ избежать массы проблем — ввести на всех уровнях компании табу на обсуждения своих и чужих зарплат. Не запретить приказом а ввести мягко это в корпоративную культуру. Сколько ты денег получаешь — знаешь только ты, твой руководитель да бухгалтерия. Ну возможно еще какие-то вышестоящие руководители, но не одноуровневые с тобой сотрудники.
Выглядит довольно утопично, но я сам много лет работал в такой компании. Правда, такая практика сложилась с самого основания компании, не уверен, что её можно привнести в уже существующую.
Выглядит довольно утопично, но я сам много лет работал в такой компании. Правда, такая практика сложилась с самого основания компании, не уверен, что её можно привнести в уже существующую.
Сами зарплаты или совокупные доходы при этом обсуждать и не требуется.
В компании или есть некое положение, фиксирующее логику расчета KPI разраба (и тогда плюс-минус все разрабы знают логику и понимают, как формируется их конкретная денежка — но ровно так же понимают и логику формирования премии соседей), или его нет — но тогда цели введения KPI непонятны — для разраба тогда его премия будет манной небесной (в том плане, что зависимость от его действий будет крайне туманной, а значит — премия будет непонятно что стимулирующей).
Если я догадываюсь, что участие в проекте А даст мне вдвое больше премиальных денег, чем участие в проекте Б при равных усилиях и одинаковых сроках ожидаемой выплаты премии, я начну пытаться попасть в него, конкурируя с Васей Пупкиным. И плевать мне на его зарплату.
Плюс вся эта логика (что у кого типа стимулируется, если реально введены KPI) после некоторого варения в коллективе становится более-менее видна. Если продавец входит в УКП, но при этом всячески отмазывается от решения проблем проекта уровня УКП — значит, за успешность выполнения проекта он не премируется. Ну или премируется неадекватно мало, что он предпочитает забивать на это направление деятельности.
В компании или есть некое положение, фиксирующее логику расчета KPI разраба (и тогда плюс-минус все разрабы знают логику и понимают, как формируется их конкретная денежка — но ровно так же понимают и логику формирования премии соседей), или его нет — но тогда цели введения KPI непонятны — для разраба тогда его премия будет манной небесной (в том плане, что зависимость от его действий будет крайне туманной, а значит — премия будет непонятно что стимулирующей).
Если я догадываюсь, что участие в проекте А даст мне вдвое больше премиальных денег, чем участие в проекте Б при равных усилиях и одинаковых сроках ожидаемой выплаты премии, я начну пытаться попасть в него, конкурируя с Васей Пупкиным. И плевать мне на его зарплату.
Плюс вся эта логика (что у кого типа стимулируется, если реально введены KPI) после некоторого варения в коллективе становится более-менее видна. Если продавец входит в УКП, но при этом всячески отмазывается от решения проблем проекта уровня УКП — значит, за успешность выполнения проекта он не премируется. Ну или премируется неадекватно мало, что он предпочитает забивать на это направление деятельности.
Основная причина денежного недовольства — банальная зависть и убеждения в том что я сам не хуже кого-то другого и должен поэтому получать не меньше. Исключив информацию о чужом кошельке мы по крайней мере зависть уберем.
>>В компании или есть некое положение, фиксирующее логику расчета KPI разраба
Очень просто — там есть некий параметр «мой базаовый доход» — который кроме вас никто не знает. И на него уже вешаются проценты, бонусы и штрафы. В итоге вы на «плохом» проекте можете получать больше Васи на «хорошем». И вам это известно. Точнее, не известно точно сколько :)
>>В компании или есть некое положение, фиксирующее логику расчета KPI разраба
Очень просто — там есть некий параметр «мой базаовый доход» — который кроме вас никто не знает. И на него уже вешаются проценты, бонусы и штрафы. В итоге вы на «плохом» проекте можете получать больше Васи на «хорошем». И вам это известно. Точнее, не известно точно сколько :)
Если я догадываюсь, что участие в проекте А даст мне вдвое больше премиальных денег, чем участие в проекте Б при равных усилиях и одинаковых сроках ожидаемой выплаты премии, я начну пытаться попасть в него, конкурируя с Васей Пупкиным. И плевать мне на его зарплату.Это можно считать положительным эффектом. Можно проводить внутренние конкурсы в новые команды, отбирать лучших. Будет стимул развиваться чтобы перейти в более прибыльный проект. Вам придется доказать что вы лучше подходите в проект чем Вася. Мне кажется это здоровая конкуренция.
Так я-то собираюсь не сравнивать, у кого толще пачка купюр — у меня или у Васи. А максимизировать свой доход при минимизации усилий! :)
А по поводу конкуренции — если это предусмотрено логикой процессов в компании — да не вопрос.
А вот если нет — тут могут быть серьезные засады.
Звезда поиграла в одном проекте, потом его покинула и зазвездилась в другом. А первый при этом начинает тонуть…
Если же перехода между проектами нет — то могут быть эффекты неравномерной загрузки сотрудников, что тоже не айс.
Или — приходит к нам новый заказчик, крайне перспективный, которого потом годами можно ублажать.
И чтобы прорваться через тендер мы выставили «инвестиционную» цену — чтобы выиграть и подсадить на свой продукт. Проект планово убыточный. Но ориентирован на завоевание заказчика (значит, надо сделать хорошо).
Но при этом логика расчета KPI может привести к тому, что звезды как раз на проект не попадут, а попадут штрафники, проект уедет по срокам и качеству, заказчик обидится…
Систему надо смотреть, систему целиком, а не отдельно взятый аспект. :)
А по поводу конкуренции — если это предусмотрено логикой процессов в компании — да не вопрос.
А вот если нет — тут могут быть серьезные засады.
Звезда поиграла в одном проекте, потом его покинула и зазвездилась в другом. А первый при этом начинает тонуть…
Если же перехода между проектами нет — то могут быть эффекты неравномерной загрузки сотрудников, что тоже не айс.
Или — приходит к нам новый заказчик, крайне перспективный, которого потом годами можно ублажать.
И чтобы прорваться через тендер мы выставили «инвестиционную» цену — чтобы выиграть и подсадить на свой продукт. Проект планово убыточный. Но ориентирован на завоевание заказчика (значит, надо сделать хорошо).
Но при этом логика расчета KPI может привести к тому, что звезды как раз на проект не попадут, а попадут штрафники, проект уедет по срокам и качеству, заказчик обидится…
Систему надо смотреть, систему целиком, а не отдельно взятый аспект. :)
Как только вводятся KPI для разработчиков, то ушлые программисты перестают работать и начинают играть.
Спустя N месяцев (где N от 2 до 24) 80% разрабов переходят в множество ушлых, а 20% меняют место работы.
Спустя N месяцев (где N от 2 до 24) 80% разрабов переходят в множество ушлых, а 20% меняют место работы.
В этом и состоит весь секрет.
Если в процессе «игры» разработчик будет выполнять требуемые задачи в установленные сроки — то задача решена верно. Если нет — то это косяк менеджмента.
KPI, как сказано в статье не должен быть механизмом кары, он должен быть фокусом на важных задачах.
Опять же полное отсутствие контроля, может привести к отсутствию работы.
Если в процессе «игры» разработчик будет выполнять требуемые задачи в установленные сроки — то задача решена верно. Если нет — то это косяк менеджмента.
KPI, как сказано в статье не должен быть механизмом кары, он должен быть фокусом на важных задачах.
Опять же полное отсутствие контроля, может привести к отсутствию работы.
На самом деле существует всего два способа мотивации: морковка спереди и морковка сзади. Все остальное — детали реализации.
За админство скажу и саппорт.
KPI на количество заявок — провален — быстро вступят в сговор с сотрудниками и всегда все будет отлично на бумаге)
KPI на выполнение заявок в рамках SLA — чуть более корректен, потому что SLA хоть как то инциденты учитывает по сложности.
KPI на простой, где 0 часов простоя это 100% — плохо. У вас будет запланированый простой на тех обслуживание, либо случится таки авария, которую вы решите за 4 часа не прогнув бизнес, но вам попытаются этим попенять и вы прилетите на деньги.
ЗЫ
у нас отношение в стране даже k KPI типично российское. Яркий пример ГИБДД. вы ДОЛЖНЫ за смену поймать столько то пьяных! а есали их нет?! Ну вот что делать?
У буржуев другой подход: есть аварийность на ввереном участке. Как хочешь регулируй, но смертность, аварийность должны быть в KPI. И вот тут кто как умеет) Хотите — будьте самыми злыми в городе. А может просто достаточно стоять с мигалками НА дороге, а не в кустах?)
KPI на количество заявок — провален — быстро вступят в сговор с сотрудниками и всегда все будет отлично на бумаге)
KPI на выполнение заявок в рамках SLA — чуть более корректен, потому что SLA хоть как то инциденты учитывает по сложности.
KPI на простой, где 0 часов простоя это 100% — плохо. У вас будет запланированый простой на тех обслуживание, либо случится таки авария, которую вы решите за 4 часа не прогнув бизнес, но вам попытаются этим попенять и вы прилетите на деньги.
ЗЫ
у нас отношение в стране даже k KPI типично российское. Яркий пример ГИБДД. вы ДОЛЖНЫ за смену поймать столько то пьяных! а есали их нет?! Ну вот что делать?
У буржуев другой подход: есть аварийность на ввереном участке. Как хочешь регулируй, но смертность, аварийность должны быть в KPI. И вот тут кто как умеет) Хотите — будьте самыми злыми в городе. А может просто достаточно стоять с мигалками НА дороге, а не в кустах?)
Из личного примера:
Я задаю вопрос про KPI следующего года — «KPI в примерах не используется для расчета вообще, зачем он нужен?»
Ответ — «KPI введен в формулу для будущего. Значение коэффициента по умолчанию (1) в тексте приведено»
Я задаю вопрос про KPI следующего года — «KPI в примерах не используется для расчета вообще, зачем он нужен?»
Ответ — «KPI введен в формулу для будущего. Значение коэффициента по умолчанию (1) в тексте приведено»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Система KPI в компании: как не пойти на три буквы