[Чего не видят метрики DORA: честный взгляд технического директора]

Важное примечание перед началом:

Моя команда использует Enji в продакшене; примеры в этой статье основаны на этой установке.

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

Чтобы быть честным: я не отвергаю их. Частота деплоев, время прохождения изменений, процент неудачных изменений, время восстановления сервиса и (в обновленной версии фреймворка) надежность — все это законные индикаторы здоровья конвейера. Они измеряют, насколько эффективно работает механизм поставки. Долгое время они оставались единственным более-менее объективным взглядом на производительность команды, и во многих организациях так до сих пор.

Проблема, с которой я постоянно сталкивался: команда может демонстрировать отличные показатели DORA, и при этом тихо накапливать структурные проблемы, которые не проявятся, пока не уйдет старший инженер, не напишет недовольный клиент или релиз, который должен был занять две недели, не затянется на девять.

Разграничение, к которому я пришел: даже хорошее состояние пайплайна не гарантирует устойчивости поставки. Состояние пайплайна — это то, что измеряет DORA: скорость и надежность пути от коммита до продакшена. Устойчивость поставки — нечто более широкое. Это все, что определяет, действительно ли инженерная команда создает ценность в долгосрочной перспективе.

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

• Точность оценок снижается от квартала к кварталу, а не от спринта к спринту — именно там и живёт тренд.
• Доля переработок медленно растёт, особенно сосредоточенная в конкретных модулях или потоках — диагностический сигнал, для которого у DORA нет категории.
• Вариация времени цикла расширяется в конкретных областях, обнажая трения, которые среднее значение полностью скрывает.
• Соотношение багов и фич смещается по мере того, как поддержка начинает вытеснять разработку.
• Глубина ревью снижается с ростом объема, и ревьюеры начинают расставлять приоритеты, а не проводить полноценные ревью.

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

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

Я пришел к такому разграничению:

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

А то, что Enji называет "delivery intelligence" смотрит вперед: это практика отслеживания сигналов, которые предупреждают о проблемах до того, как те стали очевидны.

На практике это означает отслеживание иного набора вопросов наряду со стандартными метриками пайплайна.

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

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

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

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

Абстрактно это звучит убедительно. Но что это означает в ежедневной работе лучше показать на конкретном примере.

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

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

Адаптация к роли важнее, чем кажется. Инженер, тратящий 80% времени на код, должен получать принципиально иную оценку, чем деливери-менеджер, проводящий 70% времени на встречах. Система, которая это не учитывает, выдает цифры, вводящие в заблуждение. Дашборд взвешивает активности по функции — поэтому оценки отражают реальные паттерны, а не допущение, что у всех одинаковая работа.

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

Это один из двух инструментов, изменивших мою работу. Второй решает другую проблему, и я недооценивал ее годами.

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

PM Агент сокращает это до меньше минуты. Я спрашиваю: "Каков статус рефакторинга модуля аутентификации и где блокеры?" — и получаю ответ, собранный из тикетов Jira, последних коммитов, комментариев к PR и стендап-логов. На понятном языке, со ссылками на источники.

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

Практический эффект: теперь я проверяю состояние проектов ежедневно, а не дважды в неделю. Дрейф объема я улавливаю в среднем на неделю раньше.

Важное уточнение: PM Агент не заменяет суждение. Я по-прежнему сам решаю, что делать с информацией. Синтез автоматизирован, но решение остается за мной.

До появления этих инструментов мои презентации для совета были инженерными презентациями: метрики DORA, процент выполнения спринтов, тренды output. Технически точно, но практически бессмысленно для нетехнической аудитории. На вопросы совета это не отвечало: мы на верном пути? Мы эффективно тратим деньги? Где риски?

Изменилось то, что появились метрики на деловом языке, получаемые напрямую из инженерных данных:

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

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

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

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

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

Границу я теперь держу четко:

• Паттерн в данных → задача инструмента. Зафиксировать, обнажить, измерить отклонение от нормы.
• Что паттерн означает → моя задача. Разговор, суждение, решение об эскалации.
• Оценки на основе исторических данных → отправная точка, не истина. Уверенно неверные числа опаснее признанной неопределённости.
• Кросс-инструментальный синтез → проверять перед отправкой клиенту. Паттерны уровня портфолио надежны. Детали отдельных тикетов — точечная проверка перед отчетом.

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