Продуктивность разработки
Тот, кто научится правильно измерять продуктивность разработчиков, точно станет миллионером. Особенно на текущем рынке труда, где кандидаты просто называют случайные пятизначные числа желаемой зарплаты. Есть несколько вендорских платных решений, но они не получили распространения. Никто не ставит такую систему по умолчанию, как, например, CI/CD. Давайте посмотрим на возможные подходы к измерению продуктивности и поговорим об этом в комментариях.
Итак, для начала правильно установим цель.
Цель измерения продуктивности — повышение эффективности бизнеса. Правильно подобранные и мотивированные люди дают больший результат. Существенную часть расходов (а в ИТ-компаниях — бОльшую) составляет фонд оплаты труда разработчиков. Соответственно, наличие какой-то системы оценки продуктивности позволяет тим-лиду ответить на вопросы:
Сможет ли человек после испытательного срока работать в этой команде на равных?
Есть ли у разработчика проблемы с профессиональными навыками?
Cправедливо ли будет поднимать сотрудника в категории (от Junior до Senior), или он просто постоянно мельтешит перед глазами руководства и поэтому получает повышение?
Когда команда растет, то появляются вопросы, на которые должен отвечать СТО:
А растет ли общая продуктивность команды в условных значениях?
Как меняется портрет компетенций команды?
Давайте пойдем сверху вниз и начнем разбирать метрики. Для примера буду показывать графики одной системы.
Динамика закрытия пулл-реквестов
Растет команда разработчиков, а значит растет и количество пулл-реквестов. Приведённый график неоднозначен, поскольку доподлинно известно, что команда растет, но количество пулл-реквестов почему-то не следует тренду роста. Возможно, следует проверить источник загружаемых данных на предмет корректности. Ну или СТО должен поднять панику.
Прирост кодовой базы
Кодовая база в целом растет. Ура. Но сам по себе график ничего не даст: смотрим выше на динамику пулл-реквестов (они как раз не растут). Значит, надо разбираться.
Активность разработчиков по часам и по дням недели
На первый взгляд может показаться, что график бесполезный. Можно всего лишь увидеть, что количество коммитов максимальное в среду, а самые продуктивные дни — вторник и четверг. Но обратите внимание на активность в 22.00, которая не пропадает. Есть активность разработчиков и по субботам. Это не очень хорошо, надо разбираться, кто системно выходит на переработки, потому что разработчики должны отдыхать: есть такое явление, как «выгорание», ведущее к быстрой потере сотрудника.
Безопасность вашей кодовой базы
Всё построено вокруг метрики Bus factor (BF). Возьмем первую строчку на иллюстрации — сервис CLIC. У него BF = 1,07. Другими словами, только 1 разработчик обладает знаниями по этому сервису. И если он уйдет, то вам придется потратить много времени на погружение новичков в проект. Находим все такие сервисы и делим кодовую базу с другими разработчиками компании.
Если взять среднее значение метрики BF по всем сервисам и посмотреть за более длительный период, то виден тренд на рост (что хорошо). Раньше ноября 2020 года не смотрим, это явно проблемы с загрузкой данных из источников.
Теперь давайте разберем метрики, которые будут полезны тим-лиду. Чтобы он правильно работать с метриками, тим-лид должен быть прекрасно осведомлён, чем занимается каждый его человек, максимально погружен в стек и бизнес-смысл решаемых задач.
Продуктивность разработчиков одной команды
Синяя пунктирная линия — некая медиана количества кода, создаваемого этой командой разработки. По оси Y отложены асолютные значения по месяцам. Видим, что Иванов и Петров стабильно пишут меньше кода, чем другие члены команды, а значит достойны внимания тим-лида. Причем причины могут быть вполне естественные: они просто junior-разработчики. Если так, то за ребятами надо наблюдать на дистанции полгода — год. Если количество кода растет, значит, развитие идет правильно. Кстати, обратите внимание, на левом верхнем графике сразу видно, что это senior: он пишет за всех.
Churn
Это доля строк кода, которые добавлены программистом при решении какой-нибудь задачи, но впоследствии удалены до релиза этой задачи. Метрика показывает долю работы (и времени), потраченную впустую. Она сигнализирует о том, что либо разработчик слишком мало времени тратит на обдумывание задачи и поэтому приходится переписывать, либо требования к задаче плохо формализованы.
Bus factor разработчика
Метрика показывает, в каких репозиториях этот человек является единственным контрибьютером. Потеря такого сотрудника будет для вас большой проблемой. На иллюстрации мы видим, что Иванов — единственный контрибьютер в 17 сервисах, Петров — в 11, Сидоров — в 10. Что будет после ухода Иванова, Петрова и Сидорова? Правильно, вникание новых инженеров в проект, которое может закончиться простым переписыванием и потерей времени.
На этом у меня всё. Если у вас есть какие-то свои метрики, расскажите, пожалуйста, о них в комментариях. Также интересно услышать разработчиков, которые считают, что подобные измерения контрпродуктивны.
