Метрики DORA: Мы их неправильно используем

Метрики DORA 4 взяты из книги "Accelerate", популярной книги для Инженерных лидеров.

DORA включает 4 основные метрики:

По их словам:

"Частота развертывания и Время выполнения изменений измеряют скорость работы, в то время как Процент отказов и Время восстановления услуги измеряют стабильность. И, измеряя эти значения и постоянно работая над их улучшением, команда может добиться значительно лучших бизнес-результатов."

Измерение метрик DORA само по себе не приводит к улучшению или лучшим бизнес-результатам. На это есть три причины.

Например, Время цикла и Частота развертывания показывают, как быстро небольшие части работы проходят через этапы и попадают в продакшн.

Однако это не помогает бизнесу понять насколько быстро и часто мы поставляем целиковые функции, которые потенциально должны принести ценность. Кроме того, не имеет значения, как быстро вы выпускаете работу, если вы не создаете то, что нужно бизнесу и клиентам.

Далее мы разберем какие метрики демонстрируют понятно для бизнеса результаты работы инженерных команд.

Запаздывающие индикаторы - это те на которые сходу не повлияешь.

Чтобы действительно их улучшить, необходимо измерять и улучшать дополнительный набор ведущих индикаторов, таких как размер pull request, время на код ревью и частота изменений кода (code churn).

Мы знаем что создавая дашборды чисто для менеджеров и не вовлекая разработку в процесс управления изменениями не даст реальных изменений.

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

Как инженерные команды создают ценность?

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

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

Любой ТОП менеджер или Заказчик хочет чтобы инженеры быстрее выпускали новые функции. Новые функции помогают продукту расти, делать продажи и поддерживать клиентскую лояльность — оба этих процесса переводятся в доход.

Более конкретно, я ожидаю от инженерных команд следующее:

Первые два вопроса касаются скорости и предсказуемости. Третий — о согласованности действий с бизнес-целями.

Очень важный, но недооцененный способ, которым инженерные организации приносят ценность — это выполнение обещаний. Вспомните как вам часто приходится менять даты и снижать ожидания на встречах с бизнесом. Если мы постоянно извиняемся за невыполнение обязательств или у нас много ошибок и инцидентов, влияющих на клиентов, это наносит ущерб бизнесу и лояльность бизнес от этого снижается.

Поскольку цель состоит в том, чтобы выполнять обещания и быстрее доставлять больше функций, процесс улучшения должен начинаться с наших проектов. Проекты, инициативы, эпики, функции — как бы они ни назывались в вашей организации — являются общим языком между инженерами и бизнесом.

Метрика "Распределение проектов" отвечает на вопрос: "Какой процент нашей команды работает над каждым из наших проектов?" ТОП менеджмент и бизнес любят эту метрику, потому что она быстро показывает, работают ли инженеры над тем, что важно для бизнеса.

Помните, что не имеет значения, если вы доставляете больше функций, если это не те функции, которые нужны. Вы тоже можете использовать эту метрику, так как она помогает логично аргументировать, сколько работы может выполнить ваша команда. Если вас попросят взяться за новый проект, вы сможете аргументировано на цифрах обсудить за счет снижения фокуса на какой другой проект мы возьмемся за новый, либо все же подойдем пока завершаться старые. Это также может служить [jhjitq основой для запроса на увеличение численности команды.

Метрика "Точность планирования проектов" отвечает на вопрос: "Сможем ли мы выполнить наши обещания по этому проекту?" Недавнее исследование показало, что средняя точность планирования спринтов среди 1,900 команд, использующих Scrum в 2021 году, составила 46%.

Вы никогда не сможете доставить обещанные функции за квартал, если команды, участвующие в проекте, выполняют менее половины того, что планировали каждые 2-3 недели.

Метрика "Скорость доставки новых фичей" (Lead Time) измеряет время, необходимое для превращения идеи или запроса в готовую функциональность, доступную пользователям. Эта метрика важна для оценки того, насколько быстро команда разработки может реагировать на изменения требований бизнеса и клиентов.

Метрика Lead time является ключевым показателем эффективности работы команды разработки и её способности быстро и качественно удовлетворять потребности бизнеса и клиентов.

Метрики DORA сами по себе не являются конечной целью для команды, а скорее должны интерпретироваться как прокси метрики для достижения бизнес целей.

Однако также стоит смотреть на метрики на границе бизнес и разработки, которые являются истинными показателями эффективности

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

Также главное не забывать, что за цифрами стоят люди, и что постоянное улучшение возможно только при активном участии всей команды. Важно создавать условия, в которых разработчики могут эффективно работать, вносить свой вклад и чувствовать свою значимость в достижении общих целей компании.

Используйте метрики как инструмент для понимания и оптимизации, а не как единственный критерий успеха. И помните, что самое важное — это создавать ценность для бизнеса и клиентов.