За десять лет в программировании я ни разу не встретил расчета KPI разработчика. Бизнес буквально мечтает о введении этого показателя: следит за рынком, вводит грейды, присваивает ярлыки: Junior, Senior, Middle. Этой проблемой со мной поделился хороший товарищ, топ-менеджер международной компании, и у меня появилась следующая идея.
KPI — сугубо бизнесовый показатель. Применить его к отдельно взятому разработчику нереально. И вправду, как оценить показатель творческой деятельности? Как вообще понять, что один разработчик работает хорошо, а другой плохо с точки зрения бизнеса?
Мое решение — всего лишь теория, которую нужно подтвердить или опровергнуть. Что если оценивать не столько работу разработчика, сколько дополнительную нагрузку на бизнес в результате его работы. А конкретно: сколько ресурсов затрачивает разработчик, если выполняет свою работу недостаточно эффективно. Включая часы тестирования, аналитики, ревью и прочие затраты, которые можно посчитать.
Взгляд изнутри
Мы думаем что фича разрабатывается так:
Вот только план несколько утопичен. На деле все несколько сложнее:
Безусловно, общие время и ресурсы, затрачиваемые при разработке, зависят от каждого члена команды. Если кто-то из членов команды делает свою работу недобросовестно, то это будет видно по затраченному времени его коллег.
Если коммуникации в команде налажены, документация в порядке, а каждый специалист знает что и как делать — тогда, конечно, мы вернемся к утопичному сценарию. Но любой команде требуется время, чтобы сработаться, свои коррективы вносят ротация кадров и недостаток времени.
Идея расчета KPI для разработчика в том, чтобы считать время, которое команда тратит на работу вне минималистичной схемы. А именно повторное ревью, повторное тестирование. То есть все, что выходит за рамки линейного процесса или было отправлено назад на доработку. В отсутствии доработок и экономии на этом и есть прямой интерес бизнеса.
Считаем в деньгах
Для простоты предлагаю посчитать в деньгах. Возьмем ряд переменных:
D — ставка разработчика (500);
Hd — выработка часов;
T — ставка тестировщика (250);
Ht — время повторного тестирования;
A — ставка аналитика (200);
Ha — время на разъяснения;
L — ставка лида (1000);
Hl — овертайм на ревью.
Тогда формула будет выглядеть так:
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 у.е.
Можно вывести формулу с учетом предварительной оценки задачи, но важно помнить, что релевантность будет зависеть от множества факторов. Добавим переменных:
S — общие затраты (T*Ht + A*Ha + L*Hl + D*Hd);
Et — оценка задачи.
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 таким образом - это получить на выходе полное фуфло. Даже если разработчик - это специалист своего дела, способный дать примерную оценку [новому коду], а не эникейщик, способный сделать все, но без оценки сроков.
От рядового работника и не требуется, чтобы ему было не пофиг. Он меняет свое здоровье, время, знания и умения на деньги, которые вы ему заплатите, за то, что его действия принесли вашей компании прибыль превышающую его же содержание.
Если на задачу потребовалось 7 дней, значит либо задача была сложна, либо большая, либо менеджер просчитался, но это никак не говорит о том, что разработчик плох или хорош.