А давайте все-таки посчитаем 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, обсудим детали.
Когда я вижу как грызутся разработчики и несут своё «очень важное мнение» в комментариях, вспоминаю еженедельные/ежемесячные встречи на которых слово вытянуть невозможно. И как только вопрос заходит, так чего же вы хотите? Чего вам не хватает? Как улучшим? И, ох уж, эта гробовая тишина...
Метрики для вас как оценка в школе по которой будут оценивать дурак или молодец. Но на самом деле, метрики помогают увидеть, где же система даёт сбой, вовремя обратить внимание на узкие места и устранить. И не как не сказать, что ты дебил и не отобрать твой кусок хлеба.
Честно сказать, я ещё не сталкивалась никогда с маразмом увольнений или лишений премий из-за метрик... А вот за хамство, подлость, длинный язык и враньё - да.
Вы удивляете, Василиса... Посмотрите за пределы IT (да что далеко ходить, даже в IT-отделах всяких неайти-заводов/корпораций уже чувствуется этот запах серы) - сколько там всякого гуано делается из-за метрик. Особенно лишения премий, втыки ,карьерные проблемы итп...
Народ совершенно обоснованно боится что это придёт и сюда, и очень этого не хочет.
Пример совершенно оголтелого маразма в эту степь - Металлургический завод ,часть крупной корпорации. Если работник уходит на больничный или берёт отгул, это отражается в метриках, у него и восходящей цепочки его начальников падает премия (которая только называется - премия, а по факту - переменная часть з/п). После таких вещей на любые упоминания о метриках будешь лить святую воду.