А давайте все-таки посчитаем 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, вашим работникам легче не станет, им станет легче, если вы поможете хотя бы на шаг придвинуться к утопичной идеи баланса между работой и их реальной жизнью.
про ненужность менеджера на проекте можно будет всерьёз поговорить тогда, когда разработчики научатся по-русски друг с другом разговаривать и задавать вопросы вовремя... ну хотя бы ЭТО научатся делать. Тогда заместо менеджера можно будет посадить дрессированную эксельку и google translate. Но пока этого нет -- менеджер дополняет отсутствующие компетенции в команде.
А про KPI... да нафиг его не надо считать! просто тогда ответ на вопросы "почему мне нельзя повысить ЗП?" или "почему это меня уволить?" ответ будет "потому!".
Вопрос о целесообразности менеджеров здесь не стоит.
Сколько вы работали на технической позиции?
Чуть больше 20ти лет. Долгое время сам был программистом, да и до сих пор нет-нет, а приходится засунуть в код свои потные ручёнки.
Однако, основной посыл был про ненужность KPI. ))
не нужен, вреден, но очень хочется