Представьте, что ваша ИТ-команда полгода разрабатывала сложный продукт или его модуль. Получилось всё красиво, стильно, функционально — все довольны. И вот долгожданный релиз, но со стороны пользователей тишина. Оказалось, что им ваше детище просто не нужно. 

Эта история — классический пример того, что происходит, когда этап Discovery (исследование) подменяют домыслами, а Delivery (разработка) работает ради самого процесса, а не результата. Статистика подтверждает: около 42% стартапов и новых продуктов терпят крах именно из-за отсутствия рыночной потребности, а не из-за плохого кода. Как справедливо замечают эксперты, «лучше хоть какое-то Discovery, чем никакого».

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

Если совсем просто, то Discovery отвечает на вопрос «Делаем ли мы правильные вещи?», а Delivery — «Правильно ли мы делаем эти вещи?».

В классическом «водопадном» (Waterfall, каскадная модель) подходе к разработке эти этапы разорваны во времени: три месяца изучаем рынок, потом год пишем код. В современном Agile-мире они идут параллельно. Пока одна часть команды разрабатывает текущую функциональность, другая исследует, что будем делать дальше. Это похоже на движение поезда, когда рельсы прокладывают прямо перед носом локомотива. Джефф Паттон назвал этот подход к разработке продуктов Dual-Track Agile (двухпоточным Agile), сегодня он является стандартом для зрелых продуктовых команд.

Такой подход критически важен для любой ИТ-компании. Он страхует от ситуации, когда вы вкладываете ресурсы в функциональность, которая никому не нужна. Исследования показывают, что параллельное ведение треков может сократить Time-to-Market (время до выхода релиза) на 40−60%.

Discovery — это не «сбор требований» от заказчика и не запись пожеланий в табличку. Это итеративный процесс снижения неопределенности. На этом этапе мы не пишем строчки кода, мы ищем реальную боль пользователя и самым дешевым способом проверяем гипотезы.

Чтобы делать это наиболее эффективно, забудьте про «а давайте спросим у фокус-группы». Используйте проверенные техники, вот наиболее популярные:

1. CustDev (Customer Development): глубинные интервью, где вы не предлагаете решение, а исследуете контекст.

2. Прототипирование: лучше нарисовать экран на бумажке или в Figma и показать пяти пользователям, чем запрограммировать его и понять, что он неудобен.

3. Конкурентный анализ: часто ответ на вопрос или решение вашей проблемы уже есть у конкурентов.

Совет: введите правило «ни одной строки кода без подтверждённой гипотезы» — это дисциплинирует всю команду.

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

Отслеживать эффективность работы Delivery-команды помогают метрики. И это вовсе не количество написанного кода, здесь куда важнее бизнес-показатели и стабильность:

• Time to Market — время от принятия решения до релиза;
• Deployment Frequency — частота релизов;
• Defect Escape Rate — процент дефектов, ушедших в продакшн;
• CRR (Customer Retention Rate) — коэффициент удержания клиентов: если он упал, значит, Delivery сломал то, что было ценно.

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

Один из самых мощных и универсальных инструментов для приоритизации в Discovery — это WSJF (Weighted Shortest Job First, самые важные и простые задачи выполняются в первую очередь). Каждая задача оценивается в сторипойнтах по четырём критериям:

• бизнес-ценность (User/Business Value): насколько задача важна для пользователей или бизнеса, приносит ли она доход или пользу;
• временная критичность (Time Criticality): срочность задачи, зависит ли ценность от времени (например, нужно успеть к сезону);
• снижение рисков или создание возможностей (Risk Reduction/Opportunity Enablement): защищает ли работа от рисков, открывает ли новые возможности для бизнеса;
• размер работы/трудозатраты (Job Size/Duration): сложность, объём и время, необходимое команде для выполнения задачи.

Итоговая оценка каждой задачи (WSJF) рассчитывается по формуле: (бизнес-ценность + временная критичность + риски и возможности) / размер работы. 

То есть самый высокий приоритет у тех задач, которые несут максимум ценности при минимуме затрат времени.

Классическая проблема: аналитики и разработчики существуют в разных мирах. Первые месяцами «исследуют», вторые «сидят без работы». Или наоборот: разработку гонят, а аналитикам не дают и дня на исследования.

Решить проблему может разделение потоков работы с регулярной синхронизацией. Показателен опыт Bank of New Zealand (BNZ), Банка Новой Зеландии.

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

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

Эксперт по продукту Ант Мёрфи также подчёркивает: каждый Delivery-спринт должен включать хотя бы один цикл обратной связи от Discovery, а инсайты нужно делать видимыми для всей команды.

Чтобы понимать, что ваш продуктовый цикл работает эффективно, следите за тремя показателями:

1. Процент отказов на этапе Discovery. 30−40% гипотез должны отбрасываться или отправляться на доработку после исследований — это здоровый показатель. Если в разработку уходит 100% идей, вы либо гениальны (что маловероятно), либо ваш Discovery — профанация.

2. Время цикла (Cycle Time), от момента, когда задача попала в разработку, до момента, когда она ушла в прод. Этот промежуток времени нужно сокращать. Анализ этих метрик помогает находить «бутылочные горлышки», например, на этапе ревью или тестирования.

3. Бизнес-метрики:

• индекс потребительской лояльности (NPS) или удовлетворенности (CSAT);
• Retention Rate и Churn Rate — сколько пользователей остаются с продуктом;
• LTV (Lifetime Value, «пожизненная ценность клиента») и CAC (Customer Acquisition Cost, полная стоимость привлечения одного платящего клиента).

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

1. Сбор идей: входящий поток от пользователей, поддержки, отдела продаж,
собственной команды.

2. Приоритизация гипотез: используем наиболее подходящую модель оценки, чтобы выбрать самые перспективные для исследования.

3. Discovery-спринт (1−2 недели): глубинные интервью, прототипирование, анализ данных, чтобы подтвердить или опровергнуть гипотезу.

4. Подготовка бэклога: если гипотеза подтвердилась, то формируем чёткое техническое задание (критерии приёмки, пользовательские истории) для разработки.

5. Delivery-спринт: разработка, код-ревью, тестирование, релиз.

6. Измерение результата: смотрим на метрики. Достигли ли мы цели? Если нет — возвращаемся к третьему шагу с новыми инсайтами.

Этот подход не просто экономит деньги (проверить гипотезу прототипом в 100 раз дешевле, чем написать код и выкатить его в продакшн). Он создаёт культуру, где команда — думающий механизм, нацеленный на результат, а не на бездумный процесс.