Comments
Ключевые результаты измеримы и должны быть легко оцениваемы числом (Google использует шкалу от 0 до 1.0)

Вот с этим обычно возникают проблемы.
Пример, какие численные измерения работы программиста (или отдела программирования) должны быть определены и измерены?
Пример, какие численные измерения работы программиста (или отдела программирования) должны быть определены и измерены?

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

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

Потому что смысл KPI — не вознаграждать, а мониторить :)
Это просто «спидометр в машине» и следовательно вознаграждение должно быть не «за соблюдение 60 км в час» по спидометру, а за соблюдение скоростного режима по ПДД.

Нарушил — KPI/ПДД? разбор полетов -> суд -> исправительные работы :)
Вы привели цепочку, когда на основе KPI построена мотивация/демотивация. Демотивация, тоже часть мотивации.
Со скоростью просто. Есть простой количественный показатель, легко измеряемый.
Как на складе. Обработать n посылок за смену. Или выкопать n кубометров. Легко посчитать. Легко оценить.
При нарастании сложности работ, начинаются некоторые проблемы.
Лучший вариант который я видел, оценочные суждения на основе показателей, просто попытка оценить общие тренды работ. Без упоротой привязки напрямую к мотивации/демотивации.
При попытке более точной привяки, получаются разговоры, типа:
Проект n сделали в 2 раза быстрее, оказался проще, чем планировалось.
А проект k сделали в 3 раза медленее, оказался сложнее, чем планировалось, но ребята оказались молодцы, тем, что вообще смогли сделать.
Как эти два случая уложить в KPI.
Я видел работающие показатели только на очень типовых проектах.
Шаг в сторону, все, оценки поплыли.
Но менеджеры очень любят KPI.
Лучший вариант который я видел, оценочные суждения на основе показателей, просто попытка оценить общие тренды работ. Без упоротой привязки напрямую к мотивации/демотивации.

Бинго! Именно это и есть функциональное назначение.
Грубо говоря: производительность программиста — одна функция размером 70 ..80 строк пишется 20 минут. Из этого планировали. Если вдруг обнаружилось, что у кого-то этот показатель 60 минут или 5 минут — есть смысл задаться вопросом «почему»?

По рекомендациям в КPI должны включаться те показатели, что влияют на результат и не более 5..7 штук. Глупо считать количество пробелов или табов к воде если нужно следить за тасками и их скоростью исполнения.
Во-первых, нет никакого «отдела программирования», есть команды и проекты. Например, для сервиса количественный результат может быть «50 мс@99%». Или личная цель изучения языка программирования может быть «набрать 90% на тесте по языку». Безусловно, качественные цели никто не запрещает (например, «сервис запущен для немецого языка»).
Это в вашем мире нет никаких «отделов программирования», в реальной жизни есть.
Вы путаете цели проектов (временной работы по определению) и KPI, ключевые показатели эффективности, которые больше относятся к регулярной работе.
Я ничего не путаю, я привожу конкретные примеры. OKR для «программиста» и будут ставиться на уровне проекта. Очевидно, конторам, в которых есть всего лишь «отдел программирования», нет смысла таким заниматься.
OKR — очень эффективно мотивируют!
Через полгода от введения и нескольких раундов коррекции поставленных OKR(потому что то, что видилось всем важным 3 месяца назад уже таковым быть перестало), открыл свое резюме и выбираю между достойных офферов.
Это тоже довольно таки частая история.
Когда основные потребности бизнеса покрыты, основные процессы построены, начинают высасывать из пальца новые идеи, в том числе и управленческие. Не всегда удачно.
Only those users with full accounts are able to leave comments. Log in, please.