Итак, для начала правильно установим цель.

Цель измерения продуктивности — повышение эффективности бизнеса. Правильно подобранные и мотивированные люди дают больший результат. Существенную часть расходов (а в ИТ-компаниях — бОльшую) составляет фонд оплаты труда разработчиков. Соответственно, наличие какой-то системы оценки продуктивности позволяет тим-лиду ответить на вопросы:

• Сможет ли человек после испытательного срока работать в этой команде на равных?

• Есть ли у разработчика проблемы с профессиональными навыками?

• Cправедливо ли будет поднимать сотрудника в категории (от Junior до Senior), или он просто постоянно мельтешит перед глазами руководства и поэтому получает повышение?

Когда команда растет, то появляются вопросы, на которые должен отвечать СТО:

• А растет ли общая продуктивность команды в условных значениях?

• Как меняется портрет компетенций команды?

Давайте пойдем сверху вниз и начнем разбирать метрики. Для примера буду показывать графики одной системы.

Динамика закрытия пулл-реквестов

Растет команда разработчиков, а значит растет и количество пулл-реквестов. Приведённый график неоднозначен, поскольку доподлинно известно, что команда растет, но количество пулл-реквестов почему-то не следует тренду роста. Возможно, следует проверить источник загружаемых данных на предмет корректности. Ну или СТО должен поднять панику.

Прирост кодовой базы

Кодовая база в целом растет. Ура. Но сам по себе график ничего не даст: смотрим выше на динамику пулл-реквестов (они как раз не растут). Значит, надо разбираться.

Активность разработчиков по часам и по дням недели

На первый взгляд может показаться, что график бесполезный. Можно всего лишь увидеть, что количество коммитов максимальное в среду, а самые продуктивные дни — вторник и четверг. Но обратите внимание на активность в 22.00, которая не пропадает. Есть активность разработчиков и по субботам. Это не очень хорошо, надо разбираться, кто системно выходит на переработки, потому что разработчики должны отдыхать: есть такое явление, как «выгорание», ведущее к быстрой потере сотрудника.

Безопасность вашей кодовой базы

Всё построено вокруг метрики Bus factor (BF). Возьмем первую строчку на иллюстрации — сервис CLIC. У него BF = 1,07. Другими словами, только 1 разработчик обладает знаниями по этому сервису. И если он уйдет, то вам придется потратить много времени на погружение новичков в проект. Находим все такие сервисы и делим кодовую базу с другими разработчиками компании.

Если взять среднее значение метрики BF по всем сервисам и посмотреть за более длительный период, то виден тренд на рост (что хорошо). Раньше ноября 2020 года не смотрим, это явно проблемы с загрузкой данных из источников.

Теперь давайте разберем метрики, которые будут полезны тим-лиду. Чтобы он правильно работать с метриками, тим-лид должен быть прекрасно осведомлён, чем занимается каждый его человек, максимально погружен в стек и бизнес-смысл решаемых задач.

Продуктивность разработчиков одной команды

Синяя пунктирная линия — некая медиана количества кода, создаваемого этой командой разработки. По оси Y отложены асолютные значения по месяцам. Видим, что Иванов и Петров стабильно пишут меньше кода, чем другие члены команды, а значит достойны внимания тим-лида. Причем причины могут быть вполне естественные: они просто junior-разработчики. Если так, то за ребятами надо наблюдать на дистанции полгода - год. Если количество кода растет, значит, развитие идет правильно. Кстати, обратите внимание, на левом верхнем графике сразу видно, что это senior: он пишет за всех.

Churn

Это доля строк кода, которые добавлены программистом при решении какой-нибудь задачи, но впоследствии удалены до релиза этой задачи. Метрика показывает долю работы (и времени), потраченную впустую. Она сигнализирует о том, что либо разработчик слишком мало времени тратит на обдумывание задачи и поэтому приходится переписывать, либо требования к задаче плохо формализованы.

Bus factor разработчика

Метрика показывает, в каких репозиториях этот человек является единственным контрибьютером. Потеря такого сотрудника будет для вас большой проблемой. На иллюстрации мы видим, что Иванов — единственный контрибьютер в 17 сервисах, Петров — в 11, Сидоров — в 10. Что будет после ухода Иванова, Петрова и Сидорова? Правильно, вникание новых инженеров в проект, которое может закончиться простым переписыванием и потерей времени.

На этом у меня всё. Если у вас есть какие-то свои метрики, расскажите, пожалуйста, о них в комментариях. Также интересно услышать разработчиков, которые считают, что подобные измерения контрпродуктивны.