KPI разработчика vs KPI разработки. Евгения Фирсова

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

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

Буду считать, что пользу от доклада вы получите не только, если вы возьмете что-то практическое, но и если решите, что вам это не надо.

Первая мысль при получении задания придумать KPI для отдела – мне не доверяют. Но из этого можно извлечь пользу.

Я узнала про себя много интересного, когда начала разбираться с тем, что такое KPI и как его учесть для себя.

По KPI удобно распределять бонусы. Цифры должны что-то значить, вести за собой какие-то последствия.

27 критериев разных типов – от сложности до дисциплины.

У них нет количественных оценок, так как задачи очень разные. И задачи выполняются те, которые даны. Повлиять на то разработчик не может.

У каждого критерия есть вес в баллах, так как все-таки это разные по важности вещи.

Не больше 2-х минут в день на ведение, не больше 15 минут в квартал на подсчет. Метрику не должно быть считать сложнее, чем выгода от нее.

Если кто-то ушел в минус – то это становится точкой 0. И считается для всех в процентах от идеального. И в соответствии с  этим процентом распределяется премия.

Как только человек знает не только критерии, но и баллы, он думает не о работе, а о баллах. Что плохо, потому что баллы могут меняться, и задачу за 0.5 .баллов все равно надо делать.

KPI разработчика – не применим для оценки отдела.

Между командами и отделами отношения становятся более формализуемыми.

Нулевой уровень: Выполняем поставленные задачи в сроки с приемлемым качеством.

Зачем наша команда нужна компании? Для чего мы работаем?

Это дает право влиять на задачи, за которые мы отвечаем.

Качество работы влияет на качество результата, но не сразу.

Оценивается не количество, или хотя бы не только количество, очень разные задачи по важности и сложности.

Взаимная оценка команд по итогам периода. Фиксирование не совсем своей работы.

Решение не должно приниматься в интересах KPI!

Буду думать. Как минимум, критерии оценки обдумаю.


Записи, похожие на KPI разработчика vs KPI разработки. Евгения Фирсова:
разработка сайта