Продуктовые требования на этапе Discovery — это структурированный документ (артефакт), который фиксирует результат исследований и проектирования до начала технической разработки.

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

Этот документ является финальной точкой этапа Discovery/Проектирования и служит «мостом» между исследованиями и Delivery.

Роль документа

Продуктовые требования — это:

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

Назначение и роль продуктовых требований

Продуктовые требования выполняют несколько ключевых функций.

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

Во-вторых, это основа для оценки. На базе требований можно провести верхнеуровневую оценку объёма и сложности (экспресс-оценка, прикидка ресурсов) и принять решение, запускать ли разработку, сдвигать ли её или пересобирать постановку.

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

Входные данные для продуктовых требований

Продуктовые требования не пишутся «с нуля». Они собирают и консолидируют уже сделанные артефакты Discovery/Проектирования.

Основные источники:

  • Результаты исследований. Подтверждённые боли, потребности и инсайты из глубинных интервью, опросов, наблюдений, анализа поведения пользователей.

  • Продуктовый вижн. Стратегический вектор: для чего существует продукт, какую ценность он должен приносить и в каком направлении развивается.

  • Гипотезы и цели. Ожидаемое влияние на продуктовые метрики и бизнес-показатели: какие KPI/OKR должны измениться и в какую сторону.

Практический вывод

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

Структура продуктовых требований на этапе Discovery

Хорошо оформленный документ требований отвечает на четыре блока вопросов: зачем, для кого, что именно, в каких рамках. Для этого в него обычно включают следующие разделы.

Контекст и обоснование

Этот раздел отвечает на вопрос «зачем мы вообще инициируем разработку».

В него входят:

  • Описание проблемы. Конкретная формулировка боли пользователя или неэффективности текущего процесса. Здесь важно описывать реальную ситуацию, а не сразу итоговое решение.

  • Целевая аудитория. Чёткое определение сегмента: кто именно будет пользоваться решением (например, «новые пользователи, не совершившие ни одной покупки», «операторы колл-центра первой линии»).

  • Цели и метрики успеха. Какого измеримого результата ожидаем: изменение конверсии, снижение нагрузки на поддержку, рост Retention и т.д. Например: «Снижение нагрузки на колл-центр на 20% за 3 месяца после запуска».

  • Содержание работ. Краткий перечень функциональных блоков, которые планируется реализовать в рамках данной постановки (например: «онбординг-мастер», «страница FAQ», «виджет обратной связи»).

Пользовательские сценарии

Здесь функциональность описывается через поведение пользователя, а не через набор кнопок и полей.

Обязательно выделяется:

  • Основной сценарий (Happy Path). Идеальный путь пользователя от входной точки до достижения цели. Например: «Пользователь впервые заходит в приложение, проходит онбординг и совершает первую покупку».

  • Негативные и альтернативные сценарии. Что происходит, если у пользователя нет интернета, не хватает средств, он не авторизован, отменяет действие и т.п. Эти сценарии помогают заранее увидеть ограничения и особые случаи, которые сильно влияют на UX и бизнес-логику.

Ограничения

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

  • бизнеса (правила тарификации, ограничения по скидкам, политика лояльности);

  • законодательства и регуляторов;

  • особенностей предметной области.

Примеры формулировок:

  • «Пользователь не может оформить заказ на сумму менее 500 рублей».

  • «Персональные данные должны храниться и обрабатываться в соответствии с 152-ФЗ».

  • «Скидка по промокоду не суммируется с баллами программы лояльности».

Визуализация концепции

На этапе Discovery, как правило, нет финального дизайна. Вместо этого используются упрощённые визуальные артефакты, показывающие логику.

Обычно применяют:

  • Вайрфреймы и прототипы. Черно-белые или схематичные наброски экранов, отражающие состав блоков, структуру и ключевые элементы интерфейса.

  • User Flow-диаграммы. Схемы переходов между экранами/состояниями, показывающие, как пользователь двигается по системе в рамках основных сценариев.

Зачем нужны прототипы на этом этапе

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

Роль Project / Delivery Manager в работе с продуктовыми требованиями

Участие Project Manager (PjM) и Delivery Manager (DM) в подготовке продуктовых требований сильно зависит от контекста: тип компании, наличие продакта, зрелость процессов.

Ниже — три типовых сценария.

Сценарий 1. Продуктовая команда с продактом

В продуктовых командах, где есть Product Manager / Product Owner, продуктовые требования обычно готовит именно продакт (часто совместно с аналитиком).

В этом случае PjM/DM как правило не пишет продуктовые требования, но активно участвует в процессе.

Основные зоны ответственности PjM/DM:

  • Фасилитация процесса. Организация и проведение сессий груминга, обсуждений требований, синхронизаций с бизнесом и командами.

  • Контроль сроков и статуса. Отслеживание, когда требования будут готовы в достаточной степени для оценки, планирования и начала разработки.

  • Контроль полноты и непротиворечивости. Роль «первого читателя»: менеджер проверяет, что документ понятен команде, не содержит явных конфликтов и белых пятен, и поднимает вопросы при обнаружении пробелов.

  • Поддержка в детализации. При необходимости помогает зафиксировать результаты обсуждений, дописать отдельные разделы (например, критерии приёмки) в тесной связке с продактом и аналитиком.

Сценарий 2. Заказная разработка (аутсорс, веб-студия)

В аутсорс-модели и студиях у заказчика часто нет своего продакта или компетентного постановщика задач. Заказчик формулирует запрос на уровне: «Нужен интернет-магазин как у X».

В этом контексте роль PjM существенно расширяется, и он может напрямую писать требования.

Основные действия PjM:

  • выясняет у заказчика цели, ограничения, примеры референсов, бизнес-процессы;

  • собирает и структурирует «хотелки» заказчика;

  • формализует их в документ уровня Технического задания (ТЗ) или укрупнённых продуктовых требований;

  • согласовывает документ с заказчиком;

  • передаёт постановку в команду и контролирует изменения требований по ходу проекта.

Фактически PjM выступает в гибридной роли: частично продакт, частично аналитик, частично классический PM.

Сценарий 3. Стартап или небольшая команда (гибридные роли)

В небольших командах и стартапах нередко отсутствует разделение ролей на PM, продакта, аналитика. В этом случае PjM/DM выполняет весь цикл работы с требованиями.

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

  • сбор и формализация бизнес-потребностей от фаундеров и ключевых стейкхолдеров;

  • описание продуктовых требований и пользовательских сценариев;

  • подготовка простых прототипов, схем, диаграмм;

  • постановка задач в Jira/аналогах и поддержание бэклога в актуальном состоянии;

  • участие в приоритизации, оценке и планировании релизов.

Это «режим универсала», когда менеджер совмещает функции продакта, аналитика и координатора разработки.

Ключевая мысль

PjM/DM не всегда пишет продуктовые требования, но всегда отвечает за то, чтобы они были понятны, согласованы и пригодны для Delivery. В аутсорсе и стартапах менеджер часто берёт на себя и их подготовку.

Заключение

Послесловие

Создание документа с Продуктовыми требованиями — это финал этапа Discovery. Мы определили проблему, гипотезу и желаемый результат. Но если отдать этот документ разработчику прямо сейчас, у него возникнет миллион вопросов: «В какой таблице хранить данные?», «Какой протокол использовать?», «Что делать, если сервис не отвечает?».

Чтобы превратить «бизнес-хотелки» в четкую техническую инструкцию, необходим процесс глубокой проработки. Этот процесс открывает этап Delivery и называется Аналитикой.

Что дальше?

➡️ Переходим к итогам третьего блока

НазадДалее