Метрики производительности команды разработки
Измерение производительности разработчиков - сложная задача. Есть различные метрики для оценки качества разработки, качественные и количественные, по уровням, также есть готовые подходы и системы. Как правило многие привыкли ориентироваться на простые и доступные показатели, ориентированные на время цикла разработки и пропускную способность, не всегда очевидны в их применимости, и вообще, лучше их избегать при постановке KPI разработчикам, это может сильно демотивировать команду без какого-либо профита.
Как бы ни были ценны данные о производительности разработчиков, они могут нанести вред организации при неправильном использовании “черного списка” метрик:
• Отработанное время
• Строки кода
• Исправленные ошибки и выполненные задачи
• Количество коммитов
• Количество Pull-запросов
• Отгруженные функции
• Метрики активности на рабочей машине и тд…
Это все слишком простые показатели, не учитывающий опыт разработчиков, результаты и контекста бизнеса. Они не только не дают по-настоящему полезной информации, но и могут привести к непредвиденным последствиям, например, к тому, что руководители пойдут на неадекватные компромиссы. Например, оптимизация времени выполнения поставки или частоты развертывания, что может привести к заметному снижению качества. Сосредоточение на одной метрике или слишком простом наборе метрик также может легко стимулировать плохие практики; например, в случае измерения коммитов разработчики могут чаще вносить небольшие изменения, стремясь обмануть систему.
Чтобы использовать достаточно тонкую систему измерения производительности разработчиков, важно понимать три типа показателей, которые необходимо отслеживать: показатели на системном уровне, на уровне команды и на индивидуальном уровне.
Разработка является командной сложной творческой работой, которую не просто и неправильно оценивать метриками одного уровня. Учитывая, что бизнес живой организм, задачи меняются, то и система метрик так же должна быть гибкой, с постоянным пересмотром. Необходимы более тонкие и всесторонние измерения, либо использование известных подходов, таких как DORA, SPACE, GSM или DevEx. Далее рассмотрим что и на каких уровнях стоит оценивать, а пока вопросы “на подумать”:
❓Какие показатели и для чего вы используете?
❓Какую информацию вы хотите получить и почему эта информация ценна?
❓Какой показатель был бы более мотивирующим, полезным, без лудомании?
Чтобы использовать достаточно тонкую систему измерения производительности разработчиков, важно учитывать три типа показателей:
1. Системный уровень. На системном уровне отслеживаются показатели, связанные с эффективностью работы всей организации или проекта, такие как время выхода на рынок, затраты на разработку, удовлетворенность клиентов и тд. Например, частота поставок является отличным показателем для оценки систем или команд, она зависит от того, выполняют ли все члены команды свои задачи, и, следовательно, не является полезным способом отслеживания индивидуальной производительности, эти метрики могут дать четкое представление об определенных результатах, но не о том, оптимизирована ли организация.
2. Уровень команды: отслеживаются показатели, связанные с эффективностью работы группы сотрудников, например, среднее время решения задач командой, доля просроченных заявок, оценка удовлетворенности клиентов. Эти метрики помогают понять, насколько эффективно работает команда и где есть возможности для улучшения.
3. Индивидуальный уровень: анализируются показатели каждого сотрудника, такие как количество закрытых задач/историй, среднее время решения, качество обработки заявок. Это позволяет выявить лучших сотрудников, определить области для развития и разработать индивидуальные планы обучения и мотивации.
Для оценки производительности разработки могут добавить полезных метрик такие фреймворки, как DORA и SPACE. Они представляют собой два разных подхода к измерению и улучшению эффективности работы команд разработчиков.
DORA фокусируется на четырех ключевых показателях: время подготовки изменений, частота деплоя, среднее время восстановления и коэффициент отказов после изменений. Эти метрики помогают оценить скорость и стабильность работы команды. названный в честь команды разработчиков DevOps в Google по исследованиям и оценке. Это самое близкое к стандарту, что есть в технологическом секторе, и оно отлично подходит для измерения результатов. Когда показатель DORA показывает неудовлетворительный результат, это сигнал к расследованию того, что пошло не так, что часто может потребовать длительного отслеживания.
SPACE, в свою очередь, предлагает более комплексный подход, рассматривающий пять аспектов: удовлетворенность и благополучие сотрудников, производительность, активность, сотрудничество и коммуникацию, а также эффективность и поток работы. SPACE подчеркивает важность не только количественных, но и качественных аспектов работы команды, таких как удовлетворенность сотрудников и качество коммуникации. Объединение этих подходов может дать более полную картину состояния команды и помочь выявить потенциальные проблемы и точки роста. Например, анализ данных DORA может показать, что команда испытывает трудности с частотой деплоя, в то время как анализ данных SPACE может выявить, что причиной этого является недостаточное сотрудничество между членами команды. Таким образом, комбинируя эти методы, можно получить более глубокое понимание ситуации и разработать более эффективные стратегии улучшения производительности.
В отчете McKinsey добавлено то, что называется “показателями производительности, ориентированными на возможности”, которые включают затраты времени на внутренний/внешний цикл, индекс скорости разработки, анализ вклада и оценку возможностей талантов. Затем все эти показатели объединяются в структуру, которая далее подразделяет измерения на системный, командный и индивидуальный уровни.