В разработке существуют две фундаментальные проблемы. Первая заключается в том, чтобы построить продукт правильно (качественный код, архитектура, отсутствие багов). Вторая требует построить правильный продукт (тот, который нужен людям и за который они заплатят).
Agile-фреймворки, такие как Scrum, отлично справляются с первой задачей — Delivery (поставкой). Но они почти ничего не говорят о второй — Discovery (исследовании). Product Discovery представляет собой процесс, который идет параллельно с разработкой. Его цель заключается в отделении хороших идей от плохих с минимальными затратами, прежде чем команда инженеров потратит месяцы на написание кода.
Главная задача Discovery состоит в снижении рисков. Мы не хотим узнать, что продукт никому не нужен, в день релиза. Мы хотим узнать это на этапе прототипа.
Четыре риска, которые убивают продукт
Согласно Марти Кагану (Silicon Valley Product Group), Discovery призвано ответить на четыре вопроса, которые нельзя игнорировать:
- Риск ценности (Value risk): Захотят ли пользователи это купить или использовать?
- Риск удобства (Usability risk): Смогут ли они разобраться, как этим пользоваться?
- Риск реализации (Feasibility risk): Сможем ли мы это создать с нашими технологиями и временем?
- Риск жизнеспособности (Viability risk): Подходит ли это нашему бизнесу (юридически, финансово, этически)?
Если вы пропустили Discovery и сразу начали спринты, вы играете в лотерею на деньги компании.
Различие между Discovery и Delivery
Многие команды ошибочно считают, что Discovery является просто этапом сбора требований перед стартом. В современном Agile это два параллельных потока работы (Dual Track Agile).
| Характеристика | Product Discovery (Исследование) | Product Delivery (Поставка) |
| Главная цель | Быстрое обучение и проверка гипотез. Ответ на вопрос: «Что нам делать?» | Создание качественного, масштабируемого ПО. Ответ на вопрос: «Как это сделать?» |
| Результат (Output) | Подтвержденная идея, прототип или знание о том, что идея провальна. | Готовый к релизу Инкремент продукта (код, тесты, инфраструктура). |
| Стоимость ошибки | Низкая. Выбросить прототип стоит копейки. | Высокая. Переписывать готовый код дорого и долго. |
| Ключевые активности | Интервью с пользователями, прототипирование, A/B тесты. | Кодинг, тестирование, рефакторинг, деплой. |
Product Trio: Кто занимается исследованием
В старых моделях менеджер писал ТЗ, дизайнер рисовал макеты, а разработчики просто кодили. Это путь к провалу. В продуктовом подходе за Discovery отвечает Продуктовое Трио (Product Trio).
В эту группу входят:
- Product Manager (отвечает за ценность и бизнес).
- Product Designer (отвечает за удобство).
- Lead Engineer (отвечает за техническую возможность).
Разработчик должен участвовать в Discovery с самого начала. Инженеры часто знают о возможностях технологий то, о чем бизнес даже не догадывается. Если подключить программиста только на этапе оценки задач, вы потеряете половину инновационных идей.
Continuous Discovery: Исследование как привычка
Тереза Торрес, автор концепции Continuous Discovery, утверждает: исследование не должно быть разовой акцией. Хорошие команды общаются с клиентами каждую неделю.
Это меняет структуру Бэклога. Вместо списка «хотелок» у вас появляется Дерево возможностей (Opportunity Solution Tree). Вы начинаете с бизнес-цели (например, повысить удержание), находите боли клиентов, мешающие этому, и только потом генерируете идеи решений.
Discovery позволяет команде не просто слепо выполнять задачи из Jira, а понимать контекст. Когда разработчик знает, какую проблему пользователя он решает, он принимает лучшие технические решения.
Резюме: Убивайте плохие идеи быстро
Product Discovery работает как фильтр. Его успех измеряется не количеством написанных страниц документации, а количеством идей, которые вы не стали разрабатывать, потому что вовремя поняли их бесполезность.
Самым дорогим кодом считается тот, который никому не нужен. Discovery позволяет вам ошибаться дешево и быстро, чтобы в Delivery попадали только те функции, которые гарантированно принесут успех.
Часто задаваемые вопросы (FAQ)
Это называется Dual Track Agile. В одном спринте команда может заниматься разработкой фичи А (Delivery) и параллельно проводить интервью или тестировать прототипы для фичи Б (Discovery). Это непрерывный поток, где результаты исследования питают бэклог разработки.
Желательно, чтобы каждый разработчик хотя бы раз в месяц слышал живого пользователя. Но на постоянной основе этим занимается Продуктовое Трио. Главное, чтобы Трио делилось инсайтами со всей командой, например, на Sprint Review.
Это зависит от стадии продукта, но обычно процесс занимает 10–20% времени команды. Для Product Owner’а и Дизайнера это основная работа. Для разработчиков — участие в обсуждениях и оценке прототипов.
Да, результаты Discovery часто формируют критерии готовности задачи (DoR). Если гипотеза не подтверждена, задача не должна попадать в спринт на разработку. Мы не кодим галлюцинации.
Тогда функции дизайнера (исследование удобства) ложатся на плечи Product Owner’а и фронтенд-разработчиков. Но игнорировать этот риск нельзя. Discovery является ответственностью ролей, а не должностей.