Discovery-фаза: что это и зачем за неё платить

Discovery-фаза — это короткий этап перед разработкой, на котором команда вместе с заказчиком разбирает задачу, пользователей и ограничения и превращает идею в описанные сценарии, прототипы и обоснованную оценку. За неё платят, чтобы не платить больше потом: ошибка, найденная на бумаге, стоит часы, а найденная в готовом коде — недели.

Разберём, что входит в discovery, что вы получаете на выходе и когда этот этап можно пропустить.

Что такое discovery-фаза и зачем она нужна?

Discovery-фаза — это исследование и проектирование продукта до начала программирования. Её цель — ответить на вопросы, от которых зависит всё остальное: что именно строим, для кого, в каком объёме на первый релиз и сколько это будет стоить.

Без discovery эти вопросы всё равно решаются, только в процессе разработки и дороже:

• команда начинает писать код по неполным требованиям и переделывает его после первых демо;
• оценка «на глаз» расходится с реальностью, и бюджет пересматривается посреди проекта;
• интеграции с внешними системами оказываются сложнее, чем казалось, когда половина продукта уже готова;
• в первую версию попадает то, без чего можно было запуститься, а важное откладывается.

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

Что входит в discovery?

В discovery входят интервью с заказчиком и пользователями, описание ролей и сценариев, проектирование данных и интеграций, прототипы ключевых экранов и оценка разработки. Конкретный состав зависит от продукта, но результат всегда один — понятный план первого релиза.

Активность	Что делаем	Результат
Интервью	Разговоры с заказчиком, будущими пользователями, службами	Цели, метрики, процессы «как сейчас»
Сценарии и роли	Описываем, кто и что делает в системе	Список сценариев с критериями приёмки
Приоритизация	Отделяем обязательное для запуска от второй версии	Состав MVP и бэклог на потом
Проектирование	Модель данных, интеграции, технические риски	Архитектурная схема, выбор стека
Прототипы	Кликабельные макеты ключевых экранов	Прототип, который можно показать пользователям
Оценка	Считаем разработку по сценариям	Смета с вилкой и план по этапам

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

Фото: Unsplash

Сколько длится и стоит discovery?

Discovery для типичного веб-продукта у нас занимает от двух до четырёх недель, а по стоимости составляет около 10–15% от бюджета первой версии — это ориентир студии, а не норма. Для небольшого сайта этап укладывается в несколько встреч, для продукта с десятком ролей и интеграций может занять больше месяца.

От чего зависит длительность:

1. Число ролей пользователей и сценариев.
2. Количество интеграций с внешними системами и качество их документации.
3. Насколько быстро заказчик отвечает на вопросы и принимает решения.
4. Нужна ли проверка прототипа на реальных пользователях.

Та же доля на аналитику и проектирование есть в нашей разбивке сметы MVP: это не дополнительные расходы, а часть работы, которая всё равно будет сделана — вопрос лишь в том, до кода или во время.

Почему discovery лучше оплачивать отдельно

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

Что заказчик получает на выходе?

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

Типичный комплект:

• описание продукта, целей и метрик успеха;
• роли и сценарии с критериями приёмки;
• кликабельный прототип ключевых экранов;
• модель данных и схема интеграций;
• рекомендации по стеку и инфраструктуре с обоснованием;
• состав первого релиза и бэклог следующих;
• смета с вилкой и план работ по этапам.

Когда discovery можно пропустить?

Discovery можно пропустить или сократить, когда задача уже хорошо описана и понятна: есть актуальное ТЗ, продукт развивается по устоявшемуся процессу или речь идёт о небольшом сайте без сложной логики. Пропускать его ради экономии, когда требования сырые, — плохая идея.

Когда этап действительно не нужен:

• доработка существующего продукта, где команда знает систему и бизнес;
• лендинг или корпоративный сайт по готовой структуре и макетам;
• у заказчика есть собственная аналитика и подробные, проверенные требования.

Когда без него рискованно:

• новый продукт, где пока есть только идея и несколько экранов в голове;
• много интеграций или нестандартная бизнес-логика;
• несколько заинтересованных сторон с разными ожиданиями;
• бюджет ограничен, и важно точно понять, что войдёт в первую версию.

Если вы выбираете подрядчика, discovery — удобный пробный этап: по нему видно, как команда задаёт вопросы и держит сроки. Об этом подробнее в статье как выбрать подрядчика для разработки.

Коротко

• Discovery превращает идею в сценарии, прототипы и обоснованную оценку до начала кода.
• Типичная длительность — 2–4 недели, доля в бюджете первой версии — около 10–15% (ориентир студии).
• Результат принадлежит заказчику: с ним можно пойти к любой команде.
• Пропускать этап можно, только если требования уже подробные и проверенные.
• Discovery — лучший пробный этап для проверки подрядчика.