Специалист: BRD и MRD

Как описать продукт и релиз так, чтобы бизнес, маркетинг и разработка понимали друг друга.

Когда нужен BRD

• Новый продукт/направление, крупная инвестиция.
• Нужно согласовать зачем и что на горизонте 6–12 месяцев.
• Стейкхолдеры от бизнеса и техники хотят один документ.

Структура BRD (краткая)

1. Контекст и цель (проблема, метрика, гипотеза ценности).
2. Пользователи и сегменты, JTBD.
3. Высокоуровневые сценарии / эпики.
4. Ограничения (регуляторика, безопасность, бюджет, сроки).
5. KPI/метрики успеха.
6. Риски и допущения.

Когда нужен MRD

• Подготовка выпуска/релиза: «что войдёт в версию».
• Важны ценность для рынка, позиционирование и зависимости.
• Маркетинг, продажи, поддержка хотят вовремя материалы.

Структура MRD (краткая)

1. Целевая аудитория и позиционирование релиза.
2. Фичи релиза (эпики/истории) + приоритет.
3. Дифференциаторы: чем релиз лучше альтернатив.
4. План выпуска: дата, каналы, what’s new, go-to-market.
5. Измерение успеха: метрики релиза, сигнал отмены.
6. Риски и план работы с ними.

Приоритизация для BRD/MRD

• RICE (Reach/Impact/Confidence/Effort) — для сравнения фич релиза.
• Kano — базовые/ожидаемые/восхищающие.
• MoSCoW — Must/Should/Could/Won’t, полезно для MVP.

Связка с backlog’ом

• BRD даёт эпики и ограничения.
• MRD закрепляет, что идёт в ближайший релиз.
• В таск-трекере: эпики → истории → задачи; ссылки на BRD/MRD.

Советы

• Держите BRD на 5–7 страниц: плотный текст, схемы, таблицы.
• В MRD делайте одну страницу «что нового» и одну — «что меряем».
• Обновляйте версии: BRD v1.1 (дата) и changelog в начале файла.

---

Last update: November 18, 2025