Короткий ответ:да, Discovery — командная работа. Продукт-менеджер формулирует цель и ожидаемый эффект, но именно участие бизнес-аналитика (BA) и системного аналитика (SA) превращает идею в проверяемую и реализуемую гипотезу. Без их вклада легко получить «красивую концепцию», которая рассыпается на интеграциях, данных или критериях успеха.
Что такое Discovery?
Discovery — это не мозговой штурм. Это цикл: понять проблему, оценить ценность, очертить границы решения и проверить реализуемость в текущих ограничениях. На выходе у команды появляется общий язык: четкая формулировка зачем, видение что именно делаем в первой волне, как поймем успех и где риски. После такого Discovery разработка стартует спокойно: ожидания синхронизированы, метрики ясны, «подводные камни» названы.
Почему это больше, чем задача продакта
Роль продакта — держать курс на ценность и приоритеты. Но:
- BA превращает цели в правила и сценарии, снимает противоречия между стейкхолдерами, формулирует критерии приемки так, чтобы ими можно было реально управлять.
- SA проверяет реальность: где брать события и данные, какие лимиты у API, что потребует изменять в архитектуре, какие NFR критичны (скорость, надежность, безопасность).
Вместе они «заземляют» гипотезу: убирают туман вокруг требований и сразу показывают технические и процессные ограничения. Экономия — недели итераций и десятки процентов переработок.
Как делят роли?
В начале чаще говорит продакт: приносит проблему и целевую метрику («просадка повторных покупок», «медленная онбординг-конверсия»). Дальше в игру входит BA — задает неудобные вопросы, собирает факты и оформляет смысл в понятные рамки. Параллельно SA быстро «прозванивает» ландшафт: данные, интеграции, ограничения. Дизайнер накидывает черновые потоки «как будет», чтобы все видели одну картинку. Архитектор/техлид смотрит, не рушим ли существующую систему, и предлагает аккуратный путь. Разработчик делает короткие спайки, закрывая неизвестности. PM-проект держит ритм, сроки и риски. QA заранее думает, как все это проверять.
Когда каждый сделал свою часть, команда собирается и фиксирует договоренности: какие сценарии идут в первую волну, что откладываем, какими сигналами меряем эффект.
Что именно каждый приносит на стол?
- Product Manager — цель, метрика, приоритеты релиза; отвечает за «почему это важно сейчас».
- Business Analyst — процессы «как есть/как будет», бизнес-правила, критерии приемки на уровне ценности, границы и исключения.
- System Analyst — карта систем и данных, проверка доступности событий/API, риски интеграций, ключевые NFR.
- Designer — понятные пользовательские пути и состояния (включая негативные), чтобы обсуждение шло не абстрактно.
- Architect/Tech Lead — интеграционный стиль, влияние на архитектуру, путь минимальных изменений.
- Developer — быстрые прототипы/спайки, оценки реалистичности.
- Project Manager — синхронизация зависимостей, ресурс/срок, единый список рисков.
- QA — проверяемость гипотез: что и как будем доказывать на демо и в метриках.
Кто ведет Discovery? (спойлер - зависит от контекста)
Если проблема размыта и стейкхолдеров много, логично, чтобы ведущим был BA вместе с продактом: нужна фасилитация и формализация правил. Если узкое место — интеграции, данные, производительность, естественно, что ведет SA с архитектором. Когда это продуктовый эксперимент на понятной базе, рулит продакт, а BA/SA подключаются точечно. Ключевое — не путать «ведет» и «владеет»: владелец результата всегда команда.
Кейс: напоминания об избранном в e-commerce
Сигнал: пользователи добавляют в избранное и не возвращаются.
Гипотеза: мягкие напоминания помогут поднять возвраты и повторные покупки.
Как шел Discovery:
- Продакт донес цель и метрику: растим конверсию из возвратов.
- BA поговорил с клиентами и саппортом, уточнил причины «не вернулся», сформулировал правила: не слать, если товара нет; не чаще 1 раза в 48 часов; уважаем отписку.
- SA проверил данные: есть ли событие «добавил в избранное», работает ли витрина наличия, какие лимиты у рассылочного сервиса. Вытащил риски и NFR по частоте.
- Дизайнер показал путь «получил письмо → вернулся → увидел контекст», добавил состояния «нет в наличии».
- Техлид/разработчик сделал спайк: можно ли собрать сегменты за приемлемое время, как поведет себя очередь событий.
- QA описал, как будем проверить потоки и идемпотентность.
Итог Discovery: цель и ориентир по метрике, правила и границы первой волны, подтвержденная реализуемость, список рисков, план эксперимента и наблюдаемости (события/дашборд/алерты). Команда уверенно перешла к проектированию.
Почему «только продакт» — рискованно
Когда Discovery остается у одного продакта, чаще всего всплывает одно из четырех:
- Оптимизм без данных: «идея классная», но нужных событий нет или API не тянет.
- Расползание границ: команда «дорасширяет» решение и теряет фокус первой волны.
- Непроверяемая ценность: «сделать удобнее» невозможно принять и масштабировать.
- Поздние NFR-сюрпризы: перф, доступность, безопасность всплывают у релиза.
Как договориться в команде: простой RACI
- Responsible (исполнители): PM + BA + SA (совместно ведут Discovery-поток).
- Accountable (ответственный за итог): PM (за бизнес-результат Discovery).
- Consulted (консультанты): Designer, Architect/Tech Lead, QA, Legal/Compliance.
- Informed (в курсе): Стейкхолдеры, поддержка, продажи.
Зафиксируйте это один раз — и договоренность перестанет быть «вопросом веры».
Что считается «готово к реализации» после Discovery
Команда отвечает «да» на шесть вопросов:
- Понятно, какую проблему решаем и какой эффект хотим (есть целевая метрика).
- Согласованы границы первой волны и критерии успеха.
- Есть пользовательские сценарии и состояния, включая негативные.
- Проверены данные и интеграции, обозначены риски и неизвестности.
- Описан план наблюдаемости: события, дашборд, алерты.
- Есть черновая оценка сложности и план релиза.
Если чего-то из этого нет — это не повод «идти в разработку как-нибудь», а сигнал продолжить Discovery.
Discovery — это место, где встречаются ценность (PM), управляемые правила и границы (БА) и реализуемость/безопасность (СА). Когда роли работают в связке, команда получает понятный Definition of Ready и двигается к разработке без лишних сюрпризов. Делать Discovery «в одиночку» — дорого и нервно. Делать Discovery вместе — значит поставлять ценность быстрее, предсказуемее и спокойнее.
Полезные ссылки
- Курс «Бизнес-аналитик в IT» на Stepik — структурированный старт, шаблоны и практика с проверкой артефактов автором курса + спец предложение для присоединившихся по ссылке ниже, скидка 25%.
Реклама. Семенов А.Д. ИНН 645503942344
- Telegram-канал «Аналитика в IT» — полезные статьи, шаблоны, чек-листы и разборы из реальных задач. Канал будет полезен аналитикам, продактам и тем, кто только начинает свой путь в IT. [ссылка на канал]