Сначала мы обратились к самому очевидному и признанному в индустрии фреймворку DORA — DevOps Research and Assessment. 

DORA — исследовательский проект, который измеряет эффективность и качество процесса поставки ПО: от написания кода до его работы у пользователя. Этот фреймворк можно рассмотреть как базис, с которого стоит начинать любую оценку delivery-процессов.

 Цель DORA — дать командам объективные данные, чтобы понимать:

• скорость поставки изменений;
• стабильность релизов;
• направление усилий по улучшению delivery-процессов.

С 2024 года DORA включает 5 ключевых метрик, разделенных на два блока.

Блок Throughput содержит метрики пропускной способности:

• Lead Time for Changes — время от коммита до поставки в продакшен;
• Deployment Frequency — частота релизов;
• Failed Deployment Recovery Time — время восстановления после сбоя релиза (ранее MTTR).

Блок Stability содержит метрики, характеризующие стабильность:

• Change Failure Rate — доля релизов, вызывающих инциденты;
• Deployment Rework Rate — частота необходимости переработки релизов.необходимости переработки релизов.

Мы поняли, что метрик DORA мало, потому что нужно учесть больше аспектов, связанных с деливери-процессами. Со временем мы обратились к другому фреймворку — SPACE, разработанному в Microsoft в 2021 году. В отличие от DORA SPACE оценивает команды по пяти измерениям.

Ключевое отличие SPACE в том, что он выходит за рамки технических метрик и учитывает человеческий фактор: 

• уровень удовлетворенности разработчиков; 
• возможности для роста; 
• качество взаимодействия в команде.

Если DORA — оценка конвейера, то SPACE — оценка и конвейера, и людей на этом конвейере.

Метрики, которые мы рассматривали, были верхнеуровневыми. Когда они отклонялись, нам нужно было понимать, из-за чего это происходило. Так мы дошли до изучения Developer Experience (DevEx), который ориентирован на опыт разработчика.

DevEx оценивает продуктивность через три ключевых аспекта:

• когнитивную нагрузку (Cognitive Load) — то, насколько сложно понимать и изменять код;
• цикл обратной связи (Feedback Loop) — как быстро разработчик получает ответ от системы (тесты, CI, ревью);
• состояние потока (Flow State) — насколько часто разработчик погружается в работу без перерывов. 

DevEx помогает понять, насколько комфортно и эффективно разработчику работать в текущих условиях.

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

На верхнем уровне находятся метрики DORA, объективные и количественные. На нижнем — метрики DevEx, субъективные и качественные. Связующие элементы — метрики, которые пересекаются. Например, время code-review влияет и на DORA, и на DevEx.

Структура называется «дерево», но из-за сильного пересечения метрик она скорее напоминает сеть.

SPACE не встроен напрямую в дерево, а реализован через регулярные опросы. Мы проводим опросы разработчиков каждые полгода, чтобы узнать:

• об удовлетворенности кодовой базой;
• качестве процессов ревью;
• эффективности взаимодействия в команде;
• удобстве инструментов;
• влиянии AI-ассистентов (например, GitHub Copilot).

Наши опросы не параллельный процесс, а помощь дереву метрик. Они дополняют картину: с одной стороны — объективные цифры, с другой — мнение разработчиков.

Чаще всего цифры и мнение подтверждают друг друга. Например, если разработчики жалуются на долгое ревью, то и метрики DORA будут плохими. Если жалуются на перегрузку ревьюеров, будет высокий load на ревьюеров.

Создание схемы — только начало. Главный вызов — сбор и обработка данных. Наши метрики собираются из множества источников:

• из GitLab для сбора данных о коммитах, пул-реквестов, CI/CD;
• трекера задач;
• системы мониторинга логов для расчета времени восстановления;
• платформы обработки инцидентов для оценки инцидентов;
• Messenger и коммуникационных инструментов для анализа взаимодействия внутри команд.

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

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

Есть три ключевые причины для работы с метриками. 

Объективная оценка процессов. Многие компании чувствуют, что происходит, но не видят данных.

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

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

Масштабируемость. Когда команда растет, невозможно держать все в голове. 

Дерево метрик помогает:

• отслеживать процессы в разрезе команд, репозиториев, продуктов;
• сравнивать разные подразделения;
• выявлять лучшие практики и зоны роста. 

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

Оценка влияния изменений, например внедрения AI. Как понять, помогает ли AI на самом деле? Улучшает ли он продуктивность? Снижает ли когнитивную нагрузку? Ускоряет ли циклы обратной связи? Без метрик — никак. Только имея стабильные, измеряемые показатели до внедрения, можно оценить эффект до и после.

Например, улучшился ли Lead Time for Changes после запуска AI-ревьюера? Снизилась ли когнитивная нагрузка у разработчиков, которые используют AI-подсказки?

Уменьшилось ли количество ошибок в пул-реквестах?

Мы включили в опросы SPACE вопросы об AI, чтобы получить более полную оценку его использования: 

— Помогает ли AI? 

— Насколько доверяют рекомендациям AI? 

— Ускоряет ли AI работу?

Так мы получаем не только цифры, но и контекст.

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