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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что решается

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

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

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

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

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

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

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

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

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

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

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

С чего начать

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

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