А давайте все-таки посчитаем 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, обсудим детали.
Пока батраки-технари несут на своих пальцах, стучащих по клавам, в светлое будущее компанию, написывая мегабайты кода, садя зрение и кривя спину, эффективные менеджеры отогнув мизинчик, попивая кофеёк, расположив свои чресла на удобных кожаных креслах спорят о kpi работников и в особенности о коэффициентах в формуле, быть ли 1е-2 в числителе или в знаменателе. Вопрос сложный, так просто к нему не подойти.
"...планирую подключиться к БД редмайна, вытащить оттуда историю статусов задач с трэкингом, наложить сверху вычисления и посмотреть, что получится". Вы даже можете сосчитать это все на адронном коллайдере, попивая махито и строя глазки симпатичным девицам, но получится из этого только то, что если вы в правильном свете представите свое исследование, то начальник похлопает вас по плечу и даже может подергает за щечку, поздравив при этом, что хлеб свой отработали не зря.
Порой бывает кнопку прикрутить нелинейно отражается на времени работы и трудозатратах всей команды в целом.
Как вариант, предлагаю, под названием "А давайте все-таки посчитаем KPI разработчика", написать мелким шрифтом "Проблемы топ-менеджеров международных компании - это Junior, Senior, Middle.".
Согласитесь, от расчета kpi, вашим работникам легче не станет, им станет легче, если вы поможете хотя бы на шаг придвинуться к утопичной идеи баланса между работой и их реальной жизнью.
Для работника может и без разницы, стоила ли фича в итоге сто часов работы или шесть. Но для бизнеса разница огромная. Просто разработчики редко думают о пользе для бизнеса. А вы тут ругаете человека за то, что он - думает об этом.
По вашему - работнику пофиг - переделывалась ли задача три раза по неделе или была сделана сразу в один заход но за 7 рабочих дней например.
Он всё равно ту же самую зарпоату получит.
А для компании есть разница - каждый месяц откручивать несколько лямов на щарплаты налоги. И получать либо в несколько раз меньге либо в несколько раз больше доставленных в прод задач.
Просто за счет того, что кто то взял и взглянул на процесс системно.
Вот за это "эффективные менеджеры" и получают свои деньги.
Господи,да вы задолбали! Откуда разработчик может знать, сколько времени займет у него создание нового кода?!
А вдруг, там откроются новые обстоятельства и придется переписывать всю нижележащую подсистему, так как она не справляется с нагрузкой, например.
Программирование все ещё не ремесленничество. И не кручение гаек одинаковых из смены в смену. Что за индустриальный подход в постиндустриальную эру?!
Программирование это почти как научная работа: тоже непонятно что в итоге получится .
Из опыта. Новый код не начинается с повторного изучения языка, фреймворка или апи. Если вы рисовали уже диалоговые окошки или коннектились к базе данных, то можете оценить сколько это займет. И сколько таких мелких задач в одной большой. И да, только идиоты с кпи наперевес будут считать, что эта оценка окончательная и новые вводные на нее никак не влияют. Переписывание подсистемы в кпи же не посчитать - поэтому просто будут игнорировать.
Комментарий удален модератором
Разве я писал, что не работал с большими проектами? Я прекрасно знаю как большие проекты выглядят изнутри на собственном опыте. И то, что оценку разработчиков нужно умножать на пи я тоже знаю. Но это не значит что разрабочик не может оценить, сколько у него времени займет СОЗДАНИЕ НОВОГО кода. В больших проектах требуется сопровождать СТАРЫЙ код, вникая, порой, в извращенную логику предыдущих писателей и дописывая или переписывая их код. В таких проектах оценки сроков мало чего стоят.
Я прекрасно знаю, какой стресс вызывает у разработчика необходимость ответа на вопрос "сколько времени у тебя займет реализация этого всего". В том числе и по реакции на мой предыдущий ответ :) Это же сразу накладывает ответственность за соблюдение этого срока и при высокой вероятности продолбить дедлайн снижает оценку, самооценку и денежную компенсацию (ты же сам назвал сколько времени тебе надо?).
Но возвращаясь к теме - речь идет о KPI с желанием подставить какие-то цифры в какие-то формулы. Я как раз утверждаю, что считать KPI таким образом - это получить на выходе полное фуфло. Даже если разработчик - это специалист своего дела, способный дать примерную оценку [новому коду], а не эникейщик, способный сделать все, но без оценки сроков.