---
title: "Метрики Discovery: обучение и качество решений"
description: Время до решения, покрытие критических допущений, исходы проверок и результат инициатив после запуска.
---

## Что оцениваем

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

До проверки запишите допущение, риск, критерий достаточности данных и возможные решения: продолжить, изменить вариант или остановиться. Организация параллельной работы с поставкой описана в [Dual-Track Agile](https://wpcraft.ru/kb/processes/dual-track-agile.md); общие показатели очередей — в [метриках потока](https://wpcraft.ru/kb/processes/kpi/flow-metrics.md).

## Показатели исследовательского процесса

| Показатель | Расчёт и пример | Как интерпретировать |
| --- | --- | --- |
| **Время до решения** | Дата решения на основе данных − дата регистрации гипотезы. Для проверок длиной 4, 7 и 13 дней медиана — 7 дней | Ускорение полезно, если сохраняется качество свидетельств |
| **Покрытие критических допущений** | Проверенные с достаточными данными допущения ÷ выбранные критические допущения × 100%. Четыре из шести — около 67% | Показывает полноту проверки наиболее рискованных предположений |
| **Распределение исходов** | Число и доля проверок, завершившихся поддержкой гипотезы, её изменением, отказом или неопределённостью | Помогает увидеть характер обучения и проверки, которые не дают ответа |

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

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

## Отложенная проверка: эффект после запуска

**Доля инициатив, достигших цели** = инициативы с достигнутым заранее заданным результатом ÷ запущенные инициативы с завершённым периодом оценки × 100%.

Из пяти инициатив, для которых закончился месяц наблюдения, три достигли своих целей: 60%. Инициативы, у которых окно оценки ещё не завершилось, в знаменатель не входят. До запуска зафиксируйте цель, срок оценки и источник данных.

Это проверка продуктового выбора, но результат зависит также от [Delivery](https://wpcraft.ru/kb/processes/kpi/delivery.md), внедрения и эксплуатации. Достижение целевого значения не доказывает причинность: на конверсию или удержание могли повлиять другие изменения. По возможности применяйте контрольную группу или другой подходящий способ проверки.

## Как использовать данные

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

Цели и идеи связывает [GIST](https://wpcraft.ru/kb/processes/gist-framework.md). Для первичного отбора гипотез можно использовать [матрицу Impact–Effort](https://wpcraft.ru/kb/processes/impact-effort-matrix.md), но она не измеряет качество свидетельств и не заменяет исследование. Порядок наблюдения и постановки улучшений описан в [дашбордах и OKR](https://wpcraft.ru/kb/processes/kpi/dashboards-okr.md); не превращайте реестр исследований в рейтинг сотрудников.

## Связанные материалы

- [Обзор KPI](https://wpcraft.ru/kb/processes/kpi.md) — границы метрик разных процессов.
- [Delivery и DORA](https://wpcraft.ru/kb/processes/kpi/delivery.md) — измерение поставки выбранных решений.

## Материалы и источники

- [Как измерять эффективность ИТ-процессов — WP Craft](https://wpcraft.ru/blog/kak-izmeryat-effektivnost-it-proczessov-rassmotrim-obshhie-metriki-discovery-delivery-devops-infra-servicedesk)