| DORA-метрика | Что сказать CEO | Красный флаг |
|---|---|---|
| Lead time for changes | «Сколько ждать от идеи до продакшена» | Рост >15–20% два месяца подряд |
| Deployment frequency | «Как часто выводим изменения пользователям» | Падение частоты при росте backlog |
| Change failure rate | «Доля релизов, после которых нужны срочные фиксы» | CFR >10–15% или рост +5 п.п. за месяц |
| Time to restore (MTTR) | «Сколько восстанавливаемся после сбоя в проде» | MTTR растёт при том же CFR |
Что такое DORA и зачем это руководству
DORA (DevOps Research and Assessment) — результат многолетних исследований связи между практиками разработки и бизнес-результатами. Четыре ключевые метрики описывают, насколько быстро и безопасно команда доставляет изменения.
Для CTO это стандартный язык. Для CEO и собственника — сырой набор аббревиатур, если не перевести. Задача executive-слоя — показать не «lead time = 12 дней», а «предсказуемость сроков снизилась на 30%, риск срыва релиза вырос».
Lead time: главная метрика для бизнеса
Lead time for changes — время от коммита (или от принятия задачи в работу) до выката в продакшен. Это ответ на вопрос CEO: «Когда мы увидим результат?»
Как переводить:
- «Lead time 8 дней» → «Новая фича доходит до пользователей за 1,5 недели».
- «Lead time вырос с 8 до 12 дней» → «Сроки выросли на 50%, предсказуемость упала».
- «Lead time стабилен 3 месяца» → «Команда предсказуема, можно планировать релизы».
Красный флаг для руководства: рост lead time два месяца подряд без объяснимой причины (новый продукт, смена стека). Это сигнал системного замедления потока.
Cycle time: внутренний инструмент CTO
Cycle time — время активной работы над задачей: от «В работе» до «Готово». Не включает ожидание в backlog, согласования с бизнесом, очереди на ревью вне активной фазы.
CEO cycle time напрямую не интересует. CTO использует его, чтобы найти узкие места: ревью, тестирование, зависимости. Если lead time растёт, а cycle time стабилен — проблема в очередях до и после активной работы. Если оба растут — поток замедляется системно.
Подробнее о разнице метрик потока — в материале «Метрики разработки для CTO».
Deployment frequency: скорость вывода
Deployment frequency — как часто команда выкатывает изменения в продакшен. Для CEO это «скорость вывода ценности пользователям».
Перевод:
- «Деплоим раз в неделю» → «Пользователи получают обновления еженедельно».
- «Частота упала с еженедельной до раз в месяц» → «Скорость вывода снизилась в 4 раза, batch size вырос — риск крупных сбоев».
Важно: высокая частота без контроля CFR — не победа, а риск. Идеал — частые небольшие релизы при низком CFR.
Change failure rate: стабильность релизов
CFR — доля деплоев, после которых требуется срочное исправление (hotfix, rollback, экстренный патч). Для CEO это «насколько стабильно мы выводим изменения».
Перевод:
- «CFR 5%» → «95% релизов проходят без срочных фиксов».
- «CFR вырос с 5% до 15%» → «Каждый седьмой релиз требует экстренного вмешательства — качество деградирует».
- «CFR 20% при еженедельных релизах» → «Каждый пятый выкат — риск для бизнеса и репутации».
CFR выше 10–15% при регулярных релизах — повод для разбора процесса: тесты, ревью, техдолг. Рост CFR при той же частоте деплоев — один из 12 сигналов риска поставки.
MTTR: время восстановления
Mean time to restore — среднее время восстановления сервиса после сбоя в продакшене. Для CEO: «сколько мы простаиваем, когда что-то ломается».
MTTR важен в связке с CFR. Высокий CFR + длинный MTTR — двойной удар: частые сбои и долгое восстановление. Низкий CFR + короткий MTTR — зрелая команда, которая быстро чинит редкие проблемы.
Как CTO представляет DORA на совете директоров
Формат отчёта на 1–2 страницы — без таблиц с сырыми цифрами:
- Предсказуемость: lead time стабилен / вырос / снизился — и что это значит для планов релизов.
- Стабильность: CFR в норме / растёт — риск для бизнеса.
- Скорость вывода: deployment frequency — как часто пользователи получают обновления.
- Риски: 2–3 команды или продуктовых потока с отклонениями — и предложенные действия.
Шаблон структуры — в материале «Шаблон отчёта CTO по разработке». Для сбора метрик из GitLab, Jira и CI в едином слое — обзор «Кабинет CTO».
Почему нельзя сравнивать команды «в лоб»
DORA-метрики имеют смысл только при единой методике. Разные определения Done, разные CI/CD-процессы, монолит vs микросервисы, разный scope — всё это делает прямое сравнение «команда A: lead time 5 дней, команда B: 15 дней» бессмысленным без контекста.
Governance-слой задаёт правила: как считать lead time, что считать деплоем, какие инциденты входят в CFR. Только тогда сравнение команд и Team Score дают управленческую ценность, а не спор о методике.
FAQ
Нужно ли CEO знать все четыре DORA-метрики?
Нет. Для руководства достаточно двух: lead time (когда ждать результат) и change failure rate (насколько стабильны релизы). Deployment frequency и MTTR важны CTO, но CEO переводятся в «скорость вывода» и «время восстановления после сбоя».
Чем cycle time отличается от lead time для бизнеса?
Lead time — от запроса до продакшена (весь путь). Cycle time — только активная работа над задачей. Для CEO важнее lead time: «когда будет готово». Cycle time помогает CTO найти узкие места внутри процесса.
Можно ли сравнивать DORA-метрики разных команд?
Только при единой методике расчёта. Разные определения Done, разные CI/CD-процессы и разный scope делают прямое сравнение бессмысленным. Нужен governance-слой с согласованными правилами.