Как написать BRD: руководство по бизнес-требованиям и шаблоны

BRD, или Business Requirements Document, отвечает на вопрос, который предшествует разработке продукта: почему бизнес должен инвестировать в этот проект. Он переводит бизнес-проблему в структурированное обоснование — с целями, ограничениями, затратами и ожидаемой отдачей.

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

Key insight

BRD — это документ для принятия решения. Его цель — помочь руководству сказать «да, финансируем» или «нет, не сейчас» — с достаточной доказательной базой для уверенного выбора.

Кто пишет и для кого

BRD обычно пишет бизнес-аналитик или старший продакт-менеджер — человек, который понимает и бизнес-контекст, и операционную реальность решаемой проблемы.

Key insight

Продуктовая команда читает BRD ради контекста, а не ради инструкций. BRD объясняет, почему проект важен; PRD объясняет, что строить.

Когда BRD нужен — и когда нет

BRD нужен, когда:

• Проект требует одобрения руководства или выделения бюджета
• Затронуты несколько подразделений и нужно общее обоснование
• Организация требует формальной документации для compliance или аудита
• Вы работаете с внешним подрядчиком и нужна контрактная база
• Инвестиции превышают порог, при котором «просто сделайте» — не вариант

BRD не нужен, когда:

• Команда имеет постоянный мандат на улучшения (agile-команды с OKR-автономией)
• Проект достаточно мал, чтобы PRD покрыл и «зачем», и «что»
• Стартап валидирует гипотезу — скорость важнее формального обоснования

В enterprise-среде BRD — это документ, который открывает финансирование. В стартапах его функции обычно поглощаются питч-деком, PRD или разговором с основателем.

Что содержит BRD

Стандартная структура: одиннадцать секций

Полный BRD имеет предсказуемую структуру. Каждая секция обслуживает конкретную аудиторию.

1. Executive Summary — одностраничный обзор всего документа: проблема, предлагаемое решение, ожидаемая выгода. Пишется последним, читается первым.

2. Business Objectives (SMART или OKR) — чего проект стремится достичь. SMART-цели (Specific, Measurable, Achievable, Relevant, Time-bound) — традиционный формат; некоторые организации используют OKR. В любом случае цель должна быть измеримой. «Увеличить выручку» — не бизнес-цель; «увеличить подписочную выручку на 15% за 12 месяцев» — да.

3. Current State (AS-IS) — как процесс или система работают сегодня, включая болевые точки, неэффективности и затраты. Эта секция устанавливает базовую линию, относительно которой будет измеряться влияние проекта.

4. Future State (TO-BE) — как процесс или система должны работать после завершения проекта. Разрыв между AS-IS и TO-BE определяет scope проекта.

5. Stakeholder Analysis — кого затрагивает проект, каковы их интересы и как они будут вовлечены. Стейкхолдер, не выявленный на ранней стадии, становится риском позже.

6. Business Requirements — требования высокого уровня, сформулированные на языке бизнеса, а не техническом. «Система должна обрабатывать возвраты в течение 24 часов» — бизнес-требование. «API возврата должен возвращать 200 за 500мс» — функциональное требование, ему место в FRD.

7. Cost-Benefit Analysis — сколько проект стоит (разработка, инфраструктура, обучение, альтернативные затраты) и сколько приносит (выручка, экономия, снижение рисков). Эта секция — ядро бизнес-кейса.

8. Constraints and Assumptions — бюджетные лимиты, регуляторные требования, технологические ограничения, временные рамки и допущения, на которых основан анализ.

9. Risks and Mitigation — что может пойти не так и что организация будет с этим делать. Каждый риск получает вероятность, оценку влияния и стратегию митигации.

10. Timeline and Milestones — ключевые фазы, точки принятия решений и дедлайны. Таймлайн BRD стратегический (кварталы, фазы), а не операционный (спринты, story points).

11. Glossary — определения бизнес-терминов, аббревиатур и внутреннего жаргона. BRD часто пересекает границы подразделений, и читатели из разных команд могут не разделять один и тот же словарь.

Key insight

Секции 3 и 4 (AS-IS / TO-BE) — то, что отличает BRD от PRD. PRD предполагает, что проект одобрен, и описывает продукт. BRD сравнивает текущее состояние с желаемым, чтобы обосновать, должен ли проект существовать вообще.

Вариации BRD

Не каждому проекту нужен BRD из одиннадцати секций. Формат масштабируется под решение, которое он поддерживает.

Lean BRD подходит, когда организации нужно структурированное решение, но проект не оправдывает двадцатистраничного документа.

BRD и другие requirement-документы

BRD находится в верхней части цепочки requirement-документов. В классическом подходе он следует за MRD и предшествует PRD:

MRD → BRD → PRD → FRD → SRD

Каждый документ обслуживает своё решение:

На практике полная цепочка используется в регулируемых отраслях и крупных enterprise-организациях. Большинство работает с подмножеством:

• Enterprise: BRD + PRD (BRD для одобрения, PRD для исполнения)
• Agile-команда: только PRD (бизнес-контекст встроен в PRD)
• Регулируемая отрасль: полная цепочка (MRD → BRD → PRD → FRD → SRD)
• Аутсорсинг: BRD + FRD (BRD фиксирует scope, FRD детализирует поведение)

Детальные сравнения: PRD vs BRD, PRD vs BRD vs FRD, BRD vs MRD.

Типичные ошибки

1. Написать PRD и назвать его BRD. Если документ описывает функции, пользовательские истории и макеты — это PRD, независимо от заголовка. BRD оперирует бизнес-категориями: цели, затраты, отдача и риски.

2. Размытые бизнес-цели. «Улучшить клиентский опыт» — не actionable. SMART-цели требуют точности: что улучшится, насколько и к какому сроку.

3. Отсутствие cost-benefit анализа. BRD без секции cost-benefit — это мнение, не обоснование. Руководству нужны цифры — пусть даже приблизительные — чтобы принять решение о финансировании.

4. Нет описания AS-IS. Без документирования текущего состояния у проекта нет базовой линии. Секция TO-BE становится декларацией намерений, а не измеримым улучшением.

5. Отношение к BRD как к постоянному документу. BRD описывает бизнес-кейс на момент написания. Рыночные условия, приоритеты и бюджеты меняются. Если проект охватывает несколько кварталов, BRD следует пересматривать на каждом phase gate, чтобы подтвердить, что бизнес-кейс по-прежнему актуален.

Ресурсы

• Шаблоны BRD — Standard и Lean, готовы к использованию
• Промпт-генератор BRD — создайте BRD за 15 минут с помощью ChatGPT или Claude
• Lean BRD — облегчённый формат для agile-организаций
• PRD vs BRD — когда какой выбрать
• BRD vs MRD — сравнение на стратегическом уровне
• Промпт-навигатор — подберите нужный тип документа