Метрики помогают решать, какие проблемы устранять и куда направлять ресурсы. Они показывают, где работа застревает, какие изменения приносят пользу и что угрожает надёжности сервиса. Собирать данные стоит ради этих решений: чтобы быстрее выпускать полезные изменения, сокращать потери и управлять качеством и расходами.
Одного показателя недостаточно: частые релизы не гарантируют пользы для бизнеса, высокая загрузка — быстрого выполнения задач, а закрытые обращения — решённых проблем. В статье собраны общие метрики и показатели четырёх процессов: Discovery, Delivery, DevOps & Infra, техподдержки и ServiceDesk. В конце — два способа работы с метриками: регулярный контроль через дашборды и целевые улучшения через OKR.
Чтобы что: зачем собирать метрики
- Связывать работу ИТ с ценностью. Проверять, выросли ли активация, конверсия, удержание или другой целевой показатель, а не только число выполненных задач.
- Выбирать, во что инвестировать. Находить слабые места и обосновывать приоритеты: например, сначала устранить очередь на тестирование, а не увеличивать число разработчиков.
- Повышать предсказуемость. Прогнозировать сроки и объём работ по накопленным данным, замечать затянувшиеся задачи и перегрузку до срыва сроков.
- Снижать потери и стоимость ошибок. Проверять рискованные допущения до начала разработки, сокращать ожидание и переделки, не тратить месяцы на неподтверждённую идею.
- Управлять надёжностью и качеством обслуживания. Замечать снижение доступности, рост задержек и нарушения SLA. Понимать, когда нужно восстановить стабильность, а не ускорять выпуск изменений.
- Контролировать экономику. Сопоставлять расходы на инфраструктуру и обслуживание с числом заказов или других полезных операций. Отличать рост затрат из-за нагрузки от лишних расходов.
- Проверять, сработали ли улучшения. Сравнивать показатели до и после изменений. Не считать автоматизацию или реорганизацию успешной только потому, что её завершили.
- Создавать общий язык для команды и бизнеса. Обсуждать наблюдаемые факты, ограничения и компромиссы вместо споров о том, кто «недостаточно быстро работает».
Критерий полезности: у каждой метрики должны быть пользователь и назначение. Кто смотрит на показатель? Какое решение принимает? Что делает при отклонении? Сбор и проверка данных оправданы, если помогают принять решение, снизить риск или оценить результат. Если показатель ни на что не влияет, уточните его назначение, прежде чем строить график.
Общие метрики
Общие метрики применяют к нескольким процессам или ко всему пути от выбора проблемы до выпуска решения. Определения у них общие, но считать показатели нужно отдельно для разных потоков и типов работ.
Метрики потока: Kanban и Time to Market
Метрики потока Kanban подходят для любого процесса, в котором определены начало и конец работы: Discovery, Delivery, DevOps & Infra или поддержки. В руководстве по Kanban версии 2025.5 указаны четыре базовые метрики: WIP, Throughput, Work Item Age и Cycle Time. Перед измерением опишите рабочий процесс (Definition of Workflow): что считается рабочим элементом и какие события означают начало и завершение работы.
- Throughput (пропускная способность) — число завершённых рабочих элементов за единицу времени.
- Расчёт: число элементов, перешедших в статус «Готово» за период. Считайте элементы, а не баллы сложности (story points).
- Пример: за две недели завершили 12 элементов — throughput равен 6 элементов в неделю.
- Как использовать: следить за динамикой и распределением значений, прогнозировать объём работ. Небольшие задачи и крупные инициативы считайте отдельно.
- WIP (Work in Progress) — количество начатых, но ещё не завершённых элементов в выбранный момент.
- Расчёт: посчитать все элементы между согласованными точками Started и Finished.
- Пример: в работе 8 элементов при WIP-лимите 6 — WIP превышает лимит на 2 элемента. Это повод проверить перегрузку и узкое место, а не требовать от команды «ускориться».
- Work Item Age (возраст незавершённой работы) — сколько времени прошло с момента начала работы над ещё не завершённым элементом.
- Расчёт: текущая дата − дата Started; смотреть по каждой активной задаче и сравнивать с SLE.
- Пример: задача в работе 9 рабочих дней, а SLE предполагает, что 85% задач завершаются за 8 рабочих дней или быстрее. Срок превышен — проверьте, что мешает завершить задачу.
- Cycle Time (время цикла) — время от согласованного события Started до Finished для завершённых элементов.
- Расчёт: дата Finished − дата Started; анализировать распределение и перцентили, а не только среднее.
- Пример: медианный cycle time — 5 рабочих дней, 85-й перцентиль — 9 дней: половина задач завершилась за 5 дней или быстрее, а 85% — за 9 дней или быстрее.
SLE (Service Level Expectation) — прогноз срока и вероятности завершения, основанный на накопленных данных о времени цикла; это не обещание и не норматив для оценки отдельных сотрудников.
- Пример: «85% элементов этого типа завершаются за 8 рабочих дней или быстрее». Уточняйте SLE по мере накопления данных и считайте его отдельно для существенно разных типов работ.
Дополнительно можно отслеживать эффективность потока (Flow Efficiency): время активной работы ÷ общее время Cycle Time × 100%. Например, 2 рабочих дня активной работы из 8 дней общего цикла дают 25%. Показатель помогает находить ожидания и очереди. Он полезен, только если время активной работы и ожидания фиксируют достоверно; повышать его ради самого значения не стоит.
Не смешивайте определения: DORA Lead Time for Changes начинается с изменения кода и заканчивается production-деплоем; Kanban Cycle Time начинается и заканчивается между точками рабочего процесса, которые определила команда. Все метрики потока описывают работу системы, а не производительность отдельных сотрудников.
Time to Market: дополнительная сквозная метрика времени
Time to Market (TTM) — время от решения начать работу над возможностью или проблемой до первого выпуска решения для пользователей. Это дополнительный показатель рядом с метриками Kanban, а не одна из четырёх базовых метрик потока.
- Расчёт: дата первого доступного пользователям выпуска − дата принятия возможности в работу.
- Пример: работу над инициативой начали 1 марта, решение выпустили 29 марта: TTM = 28 дней. Из них, например, 7 дней занял Discovery и 21 день — Delivery.
- Как использовать: смотреть медиану по инициативам и отдельно анализировать Discovery, ожидание в очередях и Delivery. Эти этапы могут пересекаться, поэтому не всегда складываются в TTM простым сложением.
- Не путать с Cycle Time: TTM описывает путь до выхода решения на рынок, а Cycle Time — прохождение между согласованными точками конкретного рабочего процесса. Сокращать TTM ценой проверки критичных рисков не всегда полезно.
Метрики по четырём ключевым процессам
Каждый процесс использует общие метрики потока. Ниже — его собственные показатели и зона ответственности. Discovery и Delivery — два связанных процесса разработки: первый помогает выбрать и проверить решение, второй — поставить его пользователям. DevOps & Infra отвечает за эксплуатацию и инфраструктуру, техподдержка и ServiceDesk — за обращения пользователей.
Чтобы не дублировать определения, универсальные показатели описаны в разделе «Общие метрики». DORA характеризует поставку и стабильность изменений в рабочей среде, а эксплуатационные метрики — состояние сервиса независимо от причины сбоя.
Discovery: проверка проблем, гипотез и решений
Метрики Discovery отражают скорость обучения, полноту проверки рисков и качество выбора проблем и решений. Бизнесовые и продуктовые цели часто задаются через OKR: например, улучшить активацию, конверсию или удержание; Discovery помогает найти и проверить способы их достижения. Доля инициатив, достигших целевого результата после запуска, служит отложенной проверкой этих решений, но зависит также от реализации, внедрения и эксплуатации.
Для каждой проверки заранее зафиксируйте допущение, критерий достаточности данных и возможные решения: продолжить, изменить подход или остановиться.
- Время до решения (time-to-decision) — сколько проходит от регистрации гипотезы до решения, основанного на данных.
- Расчёт: дата решения − дата регистрации гипотезы; для команды лучше смотреть медиану по завершённым проверкам.
- Пример: три гипотезы проверили за 4, 7 и 13 дней. Медианное время цикла — 7 дней.
- Зачем: показывает, как быстро команда получает ответ. Ускорять цикл стоит без потери качества доказательств.
- Покрытие критических допущений — по какой доле наиболее рискованных допущений собрано достаточно данных для решения.
- Расчёт: число проверенных критических допущений ÷ общее число выбранных критических допущений × 100%.
- Пример: из 6 критических допущений команда получила надёжные данные по 4: 4 ÷ 6 × 100% = 67%.
- Важно: заранее определить, какие данные считаются достаточными: например, наблюдаемое поведение пользователей, результаты теста или технический эксперимент, а не только мнение команды.
- Распределение решений по гипотезам — сколько проверок закончилось подтверждением, изменением гипотезы, отказом или неопределённым результатом.
- Расчёт: вести количество и долю каждого исхода от числа завершённых проверок.
- Пример: из 10 проверок 3 дали данные в пользу исходной гипотезы, 2 привели к её изменению, 4 — к отказу от идеи, 1 не дала определённого ответа. Отказ от идеи до разработки может сэкономить ресурсы. Если многие проверки не дают ответа, пересмотрите их условия и критерии.
Доля инициатив, достигших целевого результата после запуска
Показывает, насколько выбор проблем и решений подтвердился реальным эффектом для пользователей или бизнеса. Это отложенная проверка качества Discovery, а не самостоятельный показатель эффективности команды: результат зависит также от Delivery, внедрения и эксплуатации.
- Расчёт: число инициатив, достигших заранее заданной цели за период измерения ÷ число запущенных инициатив с завершённым периодом измерения × 100%.
- Пример: для каждой из пяти инициатив до запуска задали цель и месяц на оценку результата. Три достигли своих целей: 3 ÷ 5 × 100% = 60%. Для одной из них целью мог быть рост конверсии с 4% до 4,4%.
- Важно: цель, источник данных и период оценки задаются до запуска. Не включайте в знаменатель инициативы, для которых период оценки ещё не закончился. Достижение целевого значения само по себе не доказывает, что именно решение вызвало изменение — по возможности используйте контрольную группу или другой подходящий способ проверки.
Покрытие критических допущений показывает полноту проверки рисков, распределение решений — характер полученных ответов, а результат после запуска — насколько выбор подтвердился на практике. Не ставьте цель «подтверждать больше гипотез» или «чаще убивать идеи»: это провоцирует подгонку экспериментов. Вместе с качеством доказательств смотрите на время до решения.
Delivery: скорость и стабильность поставки изменений
Четыре базовые метрики DORA оценивают поставку изменений как единую систему: скорость нужно рассматривать вместе со стабильностью. Метрики Kanban из подраздела «Метрики потока: Kanban и Time to Market» дополняют их, показывая очереди, незавершённую работу и время прохождения задач.
- Deployment Frequency (DF) — частота развёртываний
- Что измеряет: как часто изменения кода попадают в production. Деплой и открытие функции конечным пользователям могут происходить в разные моменты.
- Зачем: помогает оценить частоту поставки изменений. Само число развёртываний не показывает, получили ли пользователи пользу.
- Расчёт: количество развёртываний за период (день, неделя и т. д.).
- Пример: 20 production-деплоев за 10 рабочих дней — 2 деплоя в рабочий день в среднем. Деплой не обязательно означает выпуск новой функции пользователям.
- Lead Time for Changes (LT) — время от коммита до развёртывания
- Что измеряет: сколько времени проходит от внесения изменений в код (коммита) до их попадания в продакшен.
- Зачем: отражает скорость разработки и доставки результата. Короткий lead time позволяет быстро тестировать гипотезы и реагировать на запросы пользователей.
- Расчёт: время между коммитом и успешным деплоем (в часах, днях).
- Пример: коммит создан в понедельник в 10:00, изменение попало в production во вторник в 16:00: 30 часов.
- Change Failure Rate (CFR) — доля сбоев после развёртывания
- Что измеряет: процент развёртываний, которые приводят к инцидентам, ошибкам или необходимости отката.
- Зачем: показывает качество релизов и стабильность процессов. CFR помогает отслеживать стабильность изменений, но сам по себе не объясняет причины сбоев.
- Расчёт: число production-деплоев, вызвавших сбой и потребовавших вмешательства, ÷ общее число production-деплоев × 100%. Один деплой считается один раз, даже если вызвал несколько инцидентов.
- Пример: 3 из 40 production-деплоев потребовали срочного исправления или отката: 7,5%.
- Время восстановления после неудачного изменения
- Что измеряет: сколько времени нужно, чтобы восстановить сервис после сбоя, вызванного production-изменением. Время восстановления после инцидентов с любыми причинами можно отдельно отслеживать в эксплуатации.
- Зачем: показывает, как быстро команда устраняет последствия сбоя и сокращает потери пользователей.
- Расчёт: среднее время между обнаружением сбоя и восстановлением нормальной работы (в минутах, часах, днях).
- Пример: после трёх неудачных изменений восстановление заняло 20, 40 и 120 минут. Среднее — 60 минут, медиана — 40 минут; фиксируйте выбранный способ агрегации.
Источники данных и границы расчёта DORA
Источники данных для DORA: production-деплои из SCP, коммиты из Git/Devs Metrics, инциденты и проверки восстановления из Gatus Uptime Monitor (GUM).
- Deployment Frequency: считать production-деплои, отдельно от включения функций с помощью флагов (feature flags).
- Lead Time for Changes: связать коммит с первым успешным production-деплоем, в который он вошёл. Дату создания тикета не смешивать с DORA Lead Time.
- Change Failure Rate: связать неудачный production-деплой с инцидентом, откатом или срочным исправлением; одних откатов недостаточно для полного учёта.
- Время восстановления: фиксировать начало сбоя после изменения и момент фактического восстановления сервиса. Время выполнения отката — не то же самое, что время восстановления.
Как использовать DORA для улучшения поставки
- Начните с измерения. Настройте сбор данных по каждой метрике. Используйте инструменты CI/CD, системы мониторинга и баг‑трекеры, чтобы фиксировать:
- время коммитов и деплоев;
- инциденты и их причины;
- длительность восстановления.
- Сравнивайте с собственной базовой линией. Внешние бенчмарки используйте только с указанием версии отчёта и сопоставимого контекста. Пороговые значения не являются универсальными нормативами для всех команд.
- Фокусируйтесь на балансе. Не стремитесь максимизировать только скорость (DF и LT). Сопоставляйте скорость с долей неудачных изменений и временем восстановления: ускорение не должно ухудшать стабильность сервиса.
- Оптимизируйте поэтапно. Выберите 1–2 метрики, которые «проседают», и работайте над ними. Например:
- для снижения CFR — улучшите автоматизированное тестирование и код‑ревью;
- для сокращения LT — автоматизируйте пайплайны CI/CD и минимизируйте ручной труд;
- для сокращения времени восстановления — разработайте чёткие планы реагирования на инциденты.
- Делайте данные прозрачными. Делитесь метриками с командой и представителями бизнеса. Объясняйте, какие действия повлияли на результат и что предстоит проверить.
DevOps & Infra: эксплуатация и инфраструктура
Этот процесс отвечает за надёжность, производительность и стоимость эксплуатации сервисов, а также предоставление инфраструктуры. В отличие от DORA, здесь оценивается состояние сервиса независимо от причины ухудшения: код, инфраструктура, внешние зависимости или нагрузка. Поток инфраструктурных запросов дополнительно контролируется через общие Kanban-метрики из подраздела «Метрики потока: Kanban и Time to Market».
- Доступность сервиса (availability SLI) — доля успешных проверок или запросов за период.
- Расчёт: успешные проверки ÷ все проверки, которые учитываются в расчёте × 100%.
- Пример: Gatus за месяц выполнил 100 000 проверок, из них 99 720 успешны: доступность по синтетическим проверкам — 99,72%. Gatus также позволяет отслеживать доступность и время ответа.[2]
- Важно: для пользовательского сервиса по возможности считать SLI по успешным пользовательским запросам или ключевым сценариям, а не только по доступности главной страницы.
- Задержка ответа p95 — время ответа, в которое укладываются 95% запросов.
- Пример: p95 = 420 мс означает, что не менее 95% запросов обработаны за 420 мс или быстрее. Сравнивайте показатель с целевым значением и отслеживайте динамику.
- Израсходованная доля бюджета ошибок — какая доля допустимого времени недоступности уже израсходована.
- Расчёт: фактическое время недоступности ÷ допустимое время недоступности по SLO × 100%.
- Пример: при SLO 99,9% за 30-дневный месяц допустимо около 43,2 минуты недоступности. Если сервис был недоступен 18 минут, израсходовано 18 ÷ 43,2 × 100% ≈ 42% бюджета.
- Время предоставления инфраструктуры (provisioning lead time) — время от одобрения запроса на окружение до его готовности к работе.
- Расчёт: медиана времени от одобрения до доступного окружения.
- Пример: для 12 запросов медиана составила 3 часа при целевом значении 4 часа — цель выполнена.
- Стоимость инфраструктуры на единицу результата — затраты на инфраструктуру относительно полезной нагрузки сервиса.
- Расчёт: расходы на инфраструктуру за период ÷ число успешных операций за тот же период.
- Пример: 120 000 ₽ за месяц ÷ 40 000 успешно обработанных заказов = 3 ₽ на заказ.
Техподдержка и ServiceDesk: обработка и решение обращений
Этот процесс отвечает за приём, маршрутизацию и решение обращений пользователей. Оценивайте его одновременно по скорости, качеству решения и опыту пользователя; анализируйте показатели отдельно для разных приоритетов и типов обращений. Общие метрики потока из подраздела «Метрики потока: Kanban и Time to Market» помогают контролировать незавершённую работу, возраст обращений и пропускную способность; полную очередь, включая ещё не взятые в работу обращения, отслеживайте отдельно от WIP.
- Время первого ответа и соблюдение SLA — как быстро пользователь получает содержательный ответ.
- Расчёт времени: время первого ответа − время создания обращения; обычно отслеживают медиану.
- Расчёт SLA: обращения с первым ответом в пределах SLA ÷ все обращения, для которых SLA применим × 100%.
- Пример: 92 из 100 обращений получили ответ в течение установленного часа: 92% соблюдения SLA.
- Время решения и соблюдение SLA решения — как долго обращение остаётся нерешённым.
- Расчёт времени: время закрытия − время создания; показывайте медиану по приоритетам.
- Расчёт SLA: обращения, решённые в целевой срок ÷ все решённые обращения с применимым SLA × 100%.
- Пример: 90 из 100 обращений решены в установленный для их приоритета срок: 90% соблюдения SLA.
- Решение с первого контакта (FCR) — доля обращений, решённых при первом взаимодействии без повторного обращения или эскалации.
- Расчёт: обращения, решённые с первого контакта и не открытые повторно в течение выбранного периода ÷ все решённые обращения × 100%.
- Пример: 68 из 100 обращений решены с первого контакта: 68%. Период проверки повторного открытия, например 7 дней, зафиксируйте заранее.
- Доля повторно открытых обращений (reopen rate) — сигнал, что решение могло быть неполным или проблема вернулась.
- Расчёт: повторно открытые обращения ÷ все закрытые обращения × 100%.
- Пример: повторно открыли 9 из 120 закрытых обращений: 7,5%. Повторные обращения также важны при оценке автоматизации поддержки.[3]
- Удовлетворённость поддержкой (CSAT) — средняя оценка пользователей после решения обращения.
- Расчёт: сумма оценок ÷ число ответов на опрос.
- Пример: 50 пользователей дали суммарно 220 баллов по шкале 1–5: CSAT = 4,4 из 5.
Если используется самообслуживание или автоматизация, дополнительно считайте долю обращений, решённых без участия оператора: обращения, закрытые без оператора ÷ все подходящие обращения × 100%. Например, 240 из 1 000 обращений — 24%; проверяйте этот показатель вместе с reopen rate и CSAT, чтобы автоматизация не просто закрывала заявки, а действительно решала проблемы.[3]
Два типа контроля: дашборды и OKR
Дашборды и OKR отвечают на разные вопросы: «в каком состоянии процесс сейчас?» и «какое изменение результата мы хотим получить за период?». Это не два конкурирующих набора метрик: один показатель может постоянно наблюдаться на дашборде и временно входить в OKR, если его улучшение стало приоритетом.
Дашборды: регулярный контроль состояния и рабочего ритма
На дашборде отслеживают операционные показатели, динамику, распределения и отклонения. Его задача — помогать замечать проблемы и улучшать систему, а не формировать рейтинг отдельных сотрудников.[4]
Для каждой метрики зафиксируйте определение и формулу, границы измерения, источник данных, владельца, частоту обновления и правило реакции. Если нужен порог, обоснуйте его историей, риском или обязательством перед пользователем; не задавайте универсальную «норму» для всех команд.
Рекомендуемый ритм:
- Постоянно, с уведомлениями об отклонениях: доступность, задержки, расход бюджета ошибок и критические инциденты.
- Ежедневно, на встрече или письменно: WIP, возраст незавершённых задач, препятствия в работе и очередь поддержки.
- Еженедельно или раз в две недели: Throughput, распределение Cycle Time, DORA, соблюдение SLA и повторные обращения. Обсуждайте не только цифры, но и причины отклонений и следующие действия.
- Ежемесячно: показатели, которым нужно больше времени для оценки: стоимость на единицу результата, CSAT при достаточном числе ответов и результаты инициатив с завершённым периодом оценки.
Частоту подбирайте под скорость изменения сигнала. После обзора решите, что делать: продолжить наблюдение, проверить причину, устранить препятствие или провести эксперимент. Для действий назначьте ответственных.
OKR: целевое изменение результатов
OKR — не метрика, а способ задать цель и измеримые результаты на период. В ключевых результатах (Key Results, KR) фиксируют приоритетные изменения в бизнесе, продукте или процессе, а не все показатели дашборда. Для каждого KR задайте базовое и целевое значения, срок, владельца и источник данных.
Пример продуктового OKR:
- Objective: упростить новым клиентам первый запуск продукта.
- KR1: увеличить долю клиентов, завершивших запуск за неделю, с 40% до 55% к концу квартала.
- KR2: сократить медианное время до первого полезного результата с 2 дней до 4 часов к концу квартала.
Discovery проверяет возможные способы достижения этих результатов, Delivery поставляет выбранные решения; успех оценивается по изменению метрик, а не по числу интервью или выпущенных функций.
Пример процессного KR: сократить p85 Cycle Time с 12 до 8 рабочих дней к концу квартала, не ухудшая согласованный показатель качества. Автоматизация тестирования может помочь достичь KR, но сама по себе не означает, что цель достигнута.
Ритм OKR: обсуждение прогресса, рисков и следующих действий каждую неделю или раз в две недели; в конце цикла — оценка результата и разбор того, что сработало. Не меняйте определения метрик задним числом и не оптимизируйте скорость в отрыве от качества.
Как связать оба типа контроля
- Дашборд показывает устойчивое отклонение или возможность улучшения.
- Команда проверяет данные и определяет причину, а не сразу назначает целевую цифру.
- Если изменение достаточно важно, его включают в OKR; остальные показатели остаются в регулярном контроле.
- Команда проводит изменения и проверяет эффект одновременно контролируя качество и расходы.
- После завершения OKR достигнутый уровень продолжает наблюдаться на дашборде.
Так замыкается цикл: наблюдение → решение → изменение → проверка результата.
Выводы
Система метрик полезна, если помогает принимать решения и проверять их результат. Общие показатели описывают поток работ, а метрики Discovery, Delivery, DevOps & Infra и поддержки помогают найти проблему в конкретном процессе. Дашборды нужны для регулярного контроля, OKR — для работы над выбранными улучшениями.
Чек-лист на заметку
- Начинайте с вопроса «чтобы что». Сначала решение и риск, затем метрика и инструмент сбора.
- Не путайте активность с результатом. Больше задач, интервью, деплоев или закрытых обращений не означает больше ценности.
- Не дублируйте определения. Общие метрики описывайте один раз, а показатели отдельных процессов — в соответствующих разделах.
- Согласуйте определения до автоматизации. Укажите границы, сегменты, окно наблюдения и источник; не смешивайте TTM, Cycle Time и DORA Lead Time.
- Смотрите на систему и распределения. Медианы, перцентили, динамика и возраст незавершённой работы полезнее единственного среднего и рейтинга сотрудников.
- Ускоряйте работу без потери качества и контроля расходов. Ускорение не должно скрывать рост сбоев, повторных обращений или расходов.
- Разделяйте наблюдение и изменение. Регулярные показатели — на дашборде; немногие приоритетные улучшения — в OKR.
- Начинайте с небольшого рабочего набора. Используйте уже доступные данные, назначьте владельцев и регулярный обзор; расширяйте сбор, когда появляется конкретная потребность.
- Заканчивайте обзор действием. Если по метрике никто не принимает решений, пересмотрите её назначение и затраты на поддержку.
