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

Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе за рубежом.

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

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

• Частота развертывания (Deployment Frequency)

• Время цикла (Cycle Time), иногда называемое Временем выполнения изменений (Lead Time for Changes)

• Процент отказов (Change Failure Rate)

• Среднее время восстановления (Mean Time to Restore), иногда называемое Временем восстановления услуги (Time to Restore Service)

По их словам:

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

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

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

1. Бизнес не знает, как переводить метрики DORA на понятный и значимый для них язык.

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

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

2. Метрики DORA являются запаздывающими индикаторами скорости и стабильности.

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

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

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

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

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

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

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

Переменная ценности 1: Быстрая доставка новых функций

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

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

• Можем ли мы поставлять больше ценности с тем, что у нас уже есть, с теми ресурсами?

• Можем ли мы значительно увеличить поставку ценности после инвестирования в новых инженеров?

• Доставляем ли мы то, что запросил бизнес вовремя?

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

Переменная ценности 2: Выполнение обещаний

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

Три не-DORA метрики, отлично демонстрирующие результаты инженерной работы

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

Метрика 1: Распределение проектов (Project Allocation)

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

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

Метрика 2: Точность планирования проектов (Project Planning Accuracy)

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

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

Метрика 3: Скорость доставки новых фичей (Lead time)

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

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

Заключение

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

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

• Скорость реализации новых фичей (lead time);

• Общее Velocity;

• % выполнения обещаний или точность прогноза;

• % распределения ресурсов на проекты.

Больше про метрики и практические инструменты можно узнать в рамках практических онлайн-курсов от OTUS. Переходите в каталог и выбирайте подходящее направление.

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

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

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