Discovery-фаза перед разработкой SaaS: зачем нужна и что включает

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

По данным Startup Genome, около 70% стартапов из исследованной выборки демонстрировали признаки преждевременного масштабирования, а 74% быстрорастущих интернет-стартапов терпели неудачу из-за масштабирования до подтверждения устойчивой бизнес-модели. Для SaaS это особенно опасно: команда может начать активно нанимать людей, строить сложную архитектуру и запускать продажи до того, как проверила реальный спрос и готовность клиентов платить.

Главная задача discovery-фазы - снизить неопределенность до того, как команда начнет писать код. На этом этапе проверяют бизнес-гипотезы, проводят интервью с пользователями, формируют MVP, фиксируют архитектурные решения и готовят реалистичную оценку проекта. Для SaaS это особенно важно: ошибка в тарифах, ролях, интеграциях или модели данных может привести к переработке продукта уже после запуска.

Что такое discovery-фаза перед разработкой SaaS?

Discovery-фаза - это предпроектный этап, на котором команда проверяет идею SaaS-продукта, уточняет аудиторию, фиксирует ключевые сценарии, оценивает технические риски и определяет состав первой версии. Проще говоря, discovery отвечает на вопрос: что именно нужно разрабатывать, чтобы продукт был нужен рынку и не потребовал полной переработки через несколько месяцев.

Для SaaS-продуктов этот этап особенно важен, потому что подписочная модель требует не разового запуска, а стабильного использования. Если продукт решает не ту проблему, неправильно считает роли и тарифы или плохо интегрируется с CRM, ERP и внешними API, ошибка быстро становится дорогой. Discovery помогает увидеть такие риски заранее и перевести идею в понятный план разработки.

Чем discovery-фаза отличается от брифинга, скоупинга и продуктовой аналитики?

Discovery-фаза отличается глубиной проверки. Брифинг собирает первичную информацию, скоупинг помогает примерно оценить объем работ, а discovery проверяет продуктовые, технические и бизнес-гипотезы до старта разработки. Продуктовая аналитика, в отличие от discovery, чаще применяется уже к работающему продукту.

Когда discovery-фаза обязательна, а когда ее можно сократить?

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

• Нет понятных показателей успеха. Команда не может ответить, по каким метрикам продукт будет считаться успешным через год.
• Есть несколько заинтересованных сторон с разными ожиданиями. Например, собственник, директор по продажам и технический директор видят продукт по-разному.
• Целевая аудитория плохо изучена. Требования строятся на предположениях, а не на интервью с пользователями.
• Есть интеграции с CRM, ERP, 1С, платежными сервисами или внешними API. Такие решения нужно учитывать в архитектуре заранее.
• Есть регуляторные или технические ограничения. Например, требования к персональным данным, ролям доступа, хранению документов или отказоустойчивости.

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

Какие риски снижает discovery-фаза?

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

Финансовые риски. Чем позже команда находит ошибку в требованиях, тем дороже ее исправлять. Если интеграция с корпоративной системой учета всплывает на финальном тестировании, приходится менять архитектуру, переносить сроки и увеличивать бюджет.

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

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

“

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

Ксения Положенцева (CEO, X Studio)

Кто участвует в discovery-фазе SaaS-проекта?

В discovery-фазе должны участвовать не только менеджер проекта и заказчик. Для SaaS нужен состав, который закрывает бизнес, пользователей, интерфейс и архитектуру. Иначе часть рисков останется за пределами анализа.

Какие этапы включает discovery-фаза?

Discovery-фаза состоит из последовательных этапов, каждый из которых снимает отдельную неопределенность: бизнесовую, пользовательскую, рыночную, функциональную или техническую. В сложных SaaS-проектах часть этапов идет параллельно, но пропускать их полностью рискованно.

1. Анализ бизнес-контекста. Команда фиксирует цели, бизнес-модель, показатели успеха и карту заинтересованных сторон.
2. Исследование аудитории. Проводятся интервью с пользователями, описываются роли, задачи, боли и ключевые сценарии.
3. Конкурентный анализ. Команда изучает аналоги, модели ценообразования, отзывы пользователей и незакрытые потребности рынка.
4. Формализация требований. Требования переводятся в пользовательские истории, список функций и состав MVP.
5. Архитектура и стек. Определяются интеграции, модель данных, роли доступа, требования к безопасности и технические ограничения.
6. Прототипирование. Создается черновой прототип, который проверяет логику интерфейса и основные пользовательские сценарии.
7. Оценка сроков, бюджета и рисков. Команда готовит план разработки, реестр рисков и порядок запуска первой версии.

Какие артефакты получает заказчик?

• Документ видения продукта: проблема, аудитория, ценность и позиционирование.
• Документ бизнес-требований: цели, ограничения, приоритеты и требования заказчика.
• Пользовательские персоны и CJM: карта пути клиента и ключевые сценарии.
• Отчет по конкурентному анализу: функции конкурентов, модели оплаты, сильные и слабые стороны рынка.
• Документ технической архитектуры: стек, интеграции, данные, роли и требования к безопасности.
• Прототип: черновая визуальная логика продукта для проверки сценариев.
• Оценка проекта и план развития: сроки, этапы, зависимости и приоритеты.
• Реестр рисков: список рисков и меры по их снижению.

“

Хорошая discovery-фаза должна давать неудобные ответы. Если после нее скоуп MVP стал меньше, часть функций ушла в следующие этапы, а риски стали видимыми - это нормальный результат. Проблема не в том, что идея изменилась, а в том, если это выяснится уже после разработки.

Ксения Положенцева (CEO, X Studio)

Что такое discovery sprint и когда он подходит?

Discovery sprint - это сжатый формат discovery-фазы на 1-2 недели. Он подходит, когда нужно быстро проверить ограниченный скоуп, подготовить MVP или оценить доработку уже существующего SaaS-продукта. Для нового сложного продукта с нуля такой формат не заменяет полноценную фазу.

Стоимость discovery-фазы

Стоимость discovery-фазы зависит от сложности продукта, количества интеграций, глубины интервью и состава команды. Для российского рынка ориентир можно считать в трудозатратах: короткий формат обычно занимает 40-80 часов, полноценная фаза от 200 часов.

При ставке 3 800 /час discovery sprint может стоить от ₽ 150 000-300 000 руб, а глубокая проработка для B2B SaaS с интеграциями - от 760 000 руб. и выше. Эти суммы лучше считать не как отдельную «надбавку», а как способ снизить риск переработки продукта после старта.

Практическое правило: стоимость discovery-фазы не должна быть непропорционально высокой относительно бюджета разработки. Если предпроектный этап начинает стоить как значительная часть продукта, нужно пересмотреть его объем или перейти к сокращенному формату.

Часты ошибки на этапе discovery

Главная ошибка discovery-фазы - провести ее формально. Если команда ограничилась анкетой, одним звонком и красивым документом без интервью с пользователями, неопределенность не снизилась. Проект просто получил видимость подготовки.

• Нет интервью с реальными пользователями. Требования собираются только со слов заказчика.
• Нет технического архитектора. Архитектурные риски переносятся на этап разработки.
• Скоуп расползается. Discovery превращается в полноценный дизайн всех экранов вместо проверки логики.
• Артефакты не используются. Документы создали, но команда разработки к ним не возвращается.
• Нет критериев успеха. Участники проекта по-разному понимают, каким должен быть результат через год.

Что происходит после discovery-фазы?

После discovery-фазы возможны три сценария: переход к разработке MVP, дополнительная итерация по спорным гипотезам или отказ от разработки в текущем виде. Последний вариант не всегда означает провал. Иногда discovery показывает, что продукт лучше не строить, потому что рынок, экономика или технические ограничения делают идею слишком рискованной.

Если проект идет в разработку, артефакты discovery переходят в планирование: документ видения продукта становится ориентиром, бизнес-требования превращаются в бэклог, прототип - в основу интерфейса, а реестр рисков используется менеджером проекта на следующих этапах.