Суть. Четыре метрики, описывающие, как быстро команда доставляет изменения и насколько надёжно. Ценность не в цифрах, а в том, что они дают инженерам и бизнесу общий язык: обе стороны видят, где именно теряется время.
Четыре показателя
| Метрика | Что показывает | Что за ней стоит |
|---|---|---|
| Частота поставки | Как часто изменения доходят до пользователя | Размер партии: редкие поставки означают крупные рискованные пакеты |
| Время от коммита до продакшена | Путь от готового кода до работающей функции | Обычно съедается не разработкой, а ожиданием согласований |
| Доля неудачных изменений | Какая часть поставок ломает что-то | Качество тестов и обратимость изменений |
| Время восстановления | Сколько занимает вернуть систему в строй | Готовность к откату и наблюдаемость |
Первые две — про скорость, вторые две — про устойчивость. Смотреть их нужно парой: разгон скорости ценой аварий улучшением не является.
Как читать результат
Абсолютные значения сами по себе мало что говорят: у команды, выпускающей банковское ядро, и у команды продуктового сайта они будут разными по объективным причинам. Полезно другое — динамика своей команды и разложение времени по этапам. Если восемьдесят процентов пути занимает ожидание проверки, ускорять написание кода бессмысленно.
Зачем это продавцу
Если вы продаёте инструменты разработки, наблюдаемости или безопасности, это язык вашего покупателя. Разговор «сократим время восстановления вдвое» работает принципиально иначе, чем перечисление функций: он попадает в показатель, за который человек отчитывается.
Четыре показателя
| Показатель | Что измеряет | О чём говорит бизнесу |
|---|---|---|
| Частота выпусков | Как часто изменения попадают к пользователю | Скорость получения обратной связи |
| Время от изменения до выпуска | Сколько идёт путь от кода до работы | Насколько быстро реагируем на просьбу клиента |
| Время восстановления | Как быстро чиним после сбоя | Размер ущерба при инциденте |
| Доля неудачных изменений | Как часто выпуск ломает работу | Предсказуемость обновлений |
Показатели ценны парами: первые два про скорость, вторые два про устойчивость. Улучшение одной пары за счёт другой означает, что вы не улучшили ничего.
Как внедрять
- Начните с честного измерения текущего состояния, без целей. Первые цифры почти всегда хуже ожидаемых.
- Измеряйте по командам, а не по компании: среднее скрывает и лучших, и худших.
- Ищите причину в процессе, а не в людях. Длинное время до выпуска обычно означает ручное согласование, а не медленную работу.
- Не превращайте в план. Как только показатель становится целью для отчёта, его начинают улучшать способами, не связанными с реальностью.
Где ломается
Как только по ним начинают премировать. Частоту поставки легко накрутить дроблением задач, время восстановления — тем, что инцидент просто не заводят. Это диагностический инструмент, а не система мотивации; смешение двух ролей убивает данные за квартал.
Второй частый провал — мерить только скорость и не мерить устойчивость. Через полгода команда быстрая и нестабильная, а причину ищут в людях.
Сравнивают команды между собой. Контекст разный, сравнение демотивирует и запускает игру с цифрами.
Измеряют только скорость. Частота выпусков растёт, доля неудачных изменений тоже — и общий результат ухудшается.
Данные собирают вручную. Тогда измерение прекращается через два месяца.
Самый полезный из четырёх для разговора с бизнесом — время восстановления. Оно напрямую переводится в деньги и понятно без объяснений.
Частые вопросы
Связанное
- Логика DORA в B2B-продажах — как перенести подход на управление сделками
- MLOps — те же вопросы для моделей
- Process Mining — как увидеть, где именно уходит время
Четыре показателя описывают не производительность разработчиков, а качество процесса поставки. Применение их к людям разрушает и то и другое.