А давайте все-таки посчитаем KPI разработчика
За десять лет в программировании я ни разу не встретил расчета KPI разработчика. Бизнес буквально мечтает о введении этого показателя: следит за рынком, вводит грейды, присваивает ярлыки: Junior, Senior, Middle. Этой проблемой со мной поделился хороший товарищ, топ-менеджер международной компании, и у меня появилась следующая идея.
KPI — сугубо бизнесовый показатель. Применить его к отдельно взятому разработчику нереально. И вправду, как оценить показатель творческой деятельности? Как вообще понять, что один разработчик работает хорошо, а другой плохо с точки зрения бизнеса?
Мое решение — всего лишь теория, которую нужно подтвердить или опровергнуть. Что если оценивать не столько работу разработчика, сколько дополнительную нагрузку на бизнес в результате его работы. А конкретно: сколько ресурсов затрачивает разработчик, если выполняет свою работу недостаточно эффективно. Включая часы тестирования, аналитики, ревью и прочие затраты, которые можно посчитать.
Взгляд изнутри
Мы думаем что фича разрабатывается так:
Вот только план несколько утопичен. На деле все несколько сложнее:
Безусловно, общие время и ресурсы, затрачиваемые при разработке, зависят от каждого члена команды. Если кто-то из членов команды делает свою работу недобросовестно, то это будет видно по затраченному времени его коллег.
Если коммуникации в команде налажены, документация в порядке, а каждый специалист знает что и как делать — тогда, конечно, мы вернемся к утопичному сценарию. Но любой команде требуется время, чтобы сработаться, свои коррективы вносят ротация кадров и недостаток времени.
Идея расчета KPI для разработчика в том, чтобы считать время, которое команда тратит на работу вне минималистичной схемы. А именно повторное ревью, повторное тестирование. То есть все, что выходит за рамки линейного процесса или было отправлено назад на доработку. В отсутствии доработок и экономии на этом и есть прямой интерес бизнеса.
Считаем в деньгах
Для простоты предлагаю посчитать в деньгах. Возьмем ряд переменных:
Тогда формула будет выглядеть так:
R = (T*Ht + A*Ha + L*Hl + D*Hd) / D*Hd * 100 – 100
... и результатом ее вычисления будет процент превышения бюджета на разработку.
Пример. Разработчик потратил на задачу восемь часов. Она вернулась к нему на доработку с багами. Он два часа фиксил ошибки, лид потратил полчаса на ревью, а тестировщик еще час проверял, что все исправлено. Считаем:
(250*2 + 200*0 + 1000*0,5 + 10*500) / (10*500) * 100 – 100 = 20
Получаем процент. Компания потратила на 20% ресурсов больше, чем нужно было. Это немного, но в рамках рисков. Но если бы разработчик набросал свою фичу на коленке за два часа, перепроверять и дорабатывать пришлось бы несколько раз, цифра выросла бы в разы:
(250*6 + 200*0 + 1000*2 + (2 + 4)*500) / ( (2 + 4)*500 ) * 100 – 100 = 117
Если бы разработчик подошел к задаче ответственнее, потратил шесть часов сразу и все перепроверил — результатом формулы могло бы стать 0%. Это и называется «сработать чисто». А при текущей схеме мы потеряли 3500 у.е.
Можно вывести формулу с учетом предварительной оценки задачи, но важно помнить, что релевантность будет зависеть от множества факторов. Добавим переменных:
Re = (S / D*Hd + (Et*D – D*Hd) / D*Hd) * 100 – 100
Если добавить к предыдущему примеру оценку задачи в десять часов показатель будет равен 183, а если оценить в четыре часа — 83.
Сам алгоритм в стадии разработки. И к вам я пришел за обратной связью, взглядом со стороны, возможно, в надежде найти единомышленников. В моей компании «ЮзТехе» мне дали картбланш на тестирование теории. Я планирую подключиться к БД редмайна, вытащить оттуда историю статусов задач с трэкингом, наложить сверху вычисления и посмотреть, что получится.
Если вас заинтересовала идея, напишите об этом в комментариях, я постараюсь публиковать здесь промежуточные результаты своих тестов. А если вдруг кто захочет поучаствовать в эксперименте, милости прошу в Telegram, обсудим детали.
Как и ожидалось, коллеги по цеху заклевали =) У человека при виде трех букв рядом K, P и I - сразу в голове всплывает "Ох уж эти проклятые менеджеры, опять хотят порезать мне зарплату и пить смузи!" Я встречал разных менеджеров, большинство из них, кстати, пашет как не в себя.
Вообще KPI не про "резать зарплату", а про эффективное использование ресурсов. Бизнесу проще больше зарабатывать чем резать ФОТ на копейку демотивируя сотрудника, уж тем более в такой высококонкуретной среде как ИТ. Смотрите глубже.
Представьте, у вас достаточно большой отдел разработки. Аналитик А - пишет достаточно подробные постановки, а аналитик B - в основном крупноблочно. Разработчик X - хорошо справляется с достаточно-подробными задачами, а разработчик Y - легко разбирает бизнес-требования и грамотно реализует. C каким кого поставить? А добавьте еще пару архитекторов у которых тоже свои заморочки. Эффективность сотрудников в команде это не про зарплату а про то кому с кем работать комфортнее и в каком эффективность команды будет выше.
Есть очень разные люди. Кому-то комфортнее когда у него мягкий лид, кому-то вообще проще одному, потому что не находит общий язык с командой и так далее. А задача "коварных менеджеров" при этом так их собрать, чтобы всем было комфортно, никто не лез на hh и получал удовольствие от того что у него получается, а не когда его долбит тестировщик, или аналитик опять "написал какую-то херню".
Проблема в том,что единая команда распадается на отдельные команды со своими kpi. Их главная цель становится выполнение своего локального kpi,а не общего.
Почему вы ставите KPI целью? И уж тем более целью команды?
Потому что по ним меня будут оценивать. Значит,нужно выполнять в первую очередь свой kpi,а не соседа.
А вы боитесь оценки? Или думаете что без KPI вас никак не оценивают?
На одном проекте у меня была добрая команда фронтов, 6 человек. Каждый из них работал на "отлично", но один хорошо пилил маленькие штуки, другой лучше справлялся с логикой, третий самостоятельно запиливал большие блоки. Каждого из них я пощупал и давал те задачи с которыми он лучше справиться, что ему больше понравится.
Та же самая оценка, просто без KPI. Разница только в наличии аббревиатуры.
Нет такого понятия "Выполнять KPI", это привито продавцами чтобы мотивировать их зарплатой. В разработке такое не зайдет.
Я про это и говорю,что не надо выставлять жёсткие рамки. Кто то лучше пилит одно,кто то другое.
Ни о каких жестких рамках не идет речи.
Ключевые показатели эффективности (англ. Key Performance Indicators, KPI) — показатели деятельности подразделения (предприятия), которые помогают организации в достижении стратегических и тактических (операционных) целей. Использование ключевых показателей эффективности даёт организации возможность оценить своё состояние и помочь в оценке реализации стратегии. (с) ВикиЯ говорю о том что мы можем взять реальные данные и посчитать математикой кто в какой ситуации/команде работает эффективнее и применить в формировании команд и распределении задач.
Не можете. Вы постоянно упрощаете задачу и этим теряете главное.
а главное - это что?
Автор считает, что главное - это оценить показатель творческой деятельности и вообще понять кто как работает с точки зрения бизнеса. Наверное достаточно очевидно, что по количеству строк кода или "трудодням" творческую составляющую оценить невозможно?
Кто полезнее с точки зрения бизнеса персональным KPI тоже не оценить - у вас может куча ленивых и слабых девелоперов и один весьма сильный. С точки зрения бизнеса много чего висит на нем (поэтому у него высокий KPI), но бизнес обречен. Или хуже того, все девелоперы с высоким KPI но на телефоне хамоватая персона, а в поддержке - студенты.
Если бы все лиды были такими как вы, то есть перед тем как давать задачу, щупали на предмет предпочтений и интереса, то может и не нужны были бы никаие KPI. Правда заключается в том что найти компетентного лида, имхо, намного труднее чем сильного программиста.