# Discovery-воркшоп для SaaS: кто участвует, что решают, что остаётся у вас

> Discovery-воркшоп должен заканчиваться решениями и документами, под которые можно финансировать разработку. Кто должен участвовать, как обычно идут дни и как отличить полезный воркшоп от спектакля.

Илья Исматов · CTO · 14 сентября 2026 г. · Продукт

Bitmason: https://bitmason.dev/ru/blog/saas-discovery-workshop/

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

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

## Зачем нужен discovery-воркшоп

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

- Для кого продукт и какую задачу он для них решает?
- Что обязательно войдёт в первый релиз, а что может подождать?
- Как он будет работать: основные сценарии, данные, интеграции, ограничения?
- Чего потребует разработка и что может пойти не так?

У SaaS-продукта с самого начала есть дополнительные вопросы: как клиенты регистрируются и платят, объединяет ли один аккаунт многих пользователей с разными ролями, от чего нужно изолировать данные каждого клиента и каких требований соответствия (compliance) ждёт целевой рынок. Они определяют архитектуру, поэтому им место в discovery, а не на втором месяце разработки.

## Кто должен быть в комнате

Воркшоп хорош ровно настолько, насколько хороши решения, которые могут принять его участники. Со стороны клиента обычно это:

- **Лицо, принимающее решения.** Основатель, владелец продукта или спонсор, который может сказать «да» или «нет» по объёму прямо на встрече. Без него каждое решение превращается в письмо вдогонку.
- **Человек, который знает пользователей.** Кто-то из продаж, поддержки или операционного отдела, кто говорит с клиентами, или основатель, который провёл первые интервью.
- **Эксперты в предметной области** для каждой сферы со своими правилами: финансы, логистика, клинические процессы.
- **Ваш техлид,** если он есть, особенно когда нужно интегрироваться с существующими системами.

Со стороны исполнителя достаточно небольшой команды: продакт или бизнес-аналитик, который ведёт сессии, senior-⁠инженер или архитектор, который оценивает реализуемость и трудоёмкость, и дизайнер, который набрасывает сценарии по ходу обсуждения. Десять человек от подрядчика в комнате говорят о продажном мероприятии, а не о воркшопе.

## Типичная повестка

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

1. **Цели и контекст.** Зачем существует продукт, как выглядит успех через год, ограничения (диапазон бюджета, срок, регулирование) и что уже решено.
2. **Пользователи и проблемы.** Основные типы пользователей, их задачи и нынешние обходные пути. Если есть пробелы, на этом этапе назначают интервью с пользователями.
3. **Пути и функции.** Ключевые пользовательские пути от начала до конца, от регистрации до момента, когда пользователь получает пользу, с функциями, привязанными к каждому шагу.
4. **Приоритизация.** Функции, распределённые по первому релизу, следующему и более поздним. Это самая трудная сессия и самая важная.
5. **Архитектура и интеграции.** Система на верхнем уровне: основные компоненты, набросок модели данных, сторонние сервисы, требования к мультитенантности и безопасности, хостинг.
6. **Риски и допущения.** Всё, на чём держится план, но что никто не доказал, и способ проверить каждое.
7. **План и оценка.** Фазы, состав команды и диапазон трудоёмкости для первого релиза.

Между сессиями команда исполнителя записывает договорённости и возвращается с набросками, вопросами и черновыми оценками. Именно при записи расплывчатое согласие превращается в нечто достаточно конкретное, чтобы с ним можно было не согласиться, и в этом весь смысл.

## Что решается

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

- Объём первого релиза, с проведённой чертой и названными пунктами под ней.
- Основной пользователь и основной путь, которому служит первый релиз.
- Модель ценообразования на том уровне, который влияет на разработку (за пользователя, за использование, с бесплатным тарифом или без), потому что биллинг затрагивает аккаунты, лимиты и данные.
- Модель мультитенантности, роли и права доступа, требования к размещению данных (data residency) и к соответствию.
- Основные технические решения: платформа, ключевые сервисы, что покупается, а что создаётся.
- Что заставит команду остановиться или сменить направление.

## С чем вы должны уйти

Решения, произнесённые вслух, забываются за неделю. Ценность воркшопа живёт в том, что записано. Ожидайте как минимум:

- **Продуктовый бриф:** проблема, пользователи, цели и критерии успеха, на нескольких страницах.
- **Объём с приоритетами:** функции первого релиза с детализацией, достаточной для оценки, и список отложенного.
- **Пользовательские пути или кликабельный прототип** основного сценария, по возможности проверенный на нескольких реальных пользователях.
- **Архитектурный набросок:** компоненты, эскиз модели данных, интеграции, подход к мультитенантности и безопасности и причины главных решений.
- **Реестр рисков** с ответственным за каждый риск и проверкой, которая его снимет.
- **План разработки и оценка:** фазы, состав команды и диапазон трудоёмкости с явно указанными допущениями.

Всё это должно принадлежать вам, в форматах, с которыми сможет работать любая грамотная команда.

## Полезный воркшоп или спектакль

Некоторые воркшопы на деле оказываются этапом продаж, замаскированным под процесс. Признаки спектакля:

- Много стикеров и энергии, но ничего не отброшено. Каждая идея доживает до объёма работ.
- На сессиях нет инженера, поэтому реализуемость и трудоёмкость угадывают потом.
- Оценка приходит одним числом без допущений.
- Прототип отшлифован, но его ни разу не показывали пользователю.
- Результаты имеют смысл, только если продукт будет строить тот же подрядчик.

Признаки полезного:

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

## С чего начать

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

Наш собственный этап анализа (discovery) устроен по этой схеме: короткий сфокусированный отрезок перед разработкой, который проверяет спрос, фиксирует объём работ и называет риски, пока с ними дёшево разобраться.

## Вопросы по статье

### Сколько длится discovery-воркшоп?

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

### Можно ли провести discovery самим, без партнёра?

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

### Кому принадлежат результаты discovery-воркшопа?

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

### А если discovery покажет, что идею нужно изменить?

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