Документ бизнес-требований (BRD) — это официальный отчет, в котором описываются цели, масштаб и основные потребности проекта для согласования действий заинтересованных сторон и обеспечения успешной реализации. Он включает в себя семь частей: резюме (краткое содержание), цели проекта, масштаб проекта, бизнес-требования, ключевые заинтересованные стороны, ограничения проекта и анализ затрат и выгод. Воспользуйтесь нашим бесплатным BRD в формате PDF, копируемым реестром требований и примером маркетингового блога ниже, чтобы сформулировать бизнес-требования, согласовать порядок их проверки и превратить их в план действий.

Исследование Asana «State of Work Innovation» показало, что 83% сотрудников отмечают, что медленные процессы согласования иногда задерживают их работу. Подготовка проекта к рассмотрению начинается с предоставления заинтересованным сторонам информации, необходимой для принятия решений.

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

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

Что такое документ бизнес-требований (BRD)?

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

Семь компонентов BRD:

Резюме

Резюме

Цели проекта

Цели проекта

Масштаб проекта

Масштаб проекта

Бизнес-требования

Бизнес-требования

Ключевые заинтересованные стороны

Ключевые заинтересованные стороны

Ограничения проекта

Ограничения проекта

Анализ затрат и выгод

Анализ затрат и выгод

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

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

Согласование интересов участников: определите границы и цели проекта, чтобы все участники могли ознакомиться с одинаковыми целями.

Согласование интересов участников: определите границы и цели проекта, чтобы все участники могли ознакомиться с одинаковыми целями.

Контроль масштаба: задокументируйте то, что входит и не входит в масштаб проекта, а затем используйте это соглашение для оценки запросов в рамках процесса управления изменениями.

Контроль масштаба: задокументируйте то, что входит и не входит в масштаб проекта, а затем используйте это соглашение для оценки запросов в рамках процесса управления изменениями.

Экономия времени: начните с многоразового шаблона BRD вместо создания нового документа для каждого проекта.

Экономия времени: начните с многоразового шаблона BRD вместо создания нового документа для каждого проекта.

Обоснованные утверждения: предоставьте руководству и клиентам информацию о бизнес-целях, этапах достижения успеха и деталях, необходимых для рассмотрения ваших планов.

Обоснованные утверждения: предоставьте руководству и клиентам информацию о бизнес-целях, этапах достижения успеха и деталях, необходимых для рассмотрения ваших планов.

Бесплатный шаблон документа бизнес-требований

Шаблон документа бизнес-требований (и пример)

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

Используйте эту дополнительную запись для требований, которые требуют индивидуального рассмотрения. Скопируйте ее в свой документ или описание задачи Asana, а затем повторяйте для каждого требования. Сохраняйте ID неизменным при пересмотрах и обновляйте версию отдельно.

Поле

Ваше требование

Идентификатор и версия требования

[ID] — [версия]

Бизнес-потребность и источник

[Что нужно бизнесу, почему это важно и кто это запросил]

Формулировка требования

[Один результат или возможность, необходимые бизнесу]

Приоритет и масштаб

[Приоритет и обоснование; что включено и исключено]

Проверка и подтверждение

[Как вы будете проверять требование; где будете хранить подтверждения]

Ответственный и согласующее лицо

[Кто поддерживает требование; кто его утверждает]

Зависимости и допущения

[От чего вы зависите; что еще требует подтверждения]

История решений и изменений

[Статус, дата принятия решения, причина и затронутая работа]

Напишите BRD, с которым ваша команда сможет работать

Давайте применим шаблон BRD на практике. В этом наглядном примере технологическая компания планирует запустить маркетинговый блог через шесть недель. Майя, менеджер маркетинговых проектов, пишет BRD совместно с Лео, руководителем контент-направления, и Ниной, согласующим лицом по маркетинговым операциям.

1. Согласуйте бизнес-потребность, масштаб и критерии оценки

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

Согласно исследованию Asana и Meltwater «State of Marketing Collaboration» за 2024 год, только 30% опрошенных специалистов по маркетингу заявили, что хорошо знакомы с планами своей организации по оценке результатов. Постановка цели — это лишь один шаг; вашей команде также необходимо знать, кто отслеживает ее, какие данные они используют и когда будут их анализировать.

Майя собирает эту информацию перед заполнением семи разделов:

Компонент BRD

Пример маркетингового блога

Резюме

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

Цели проекта

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

Масштаб проекта

Запустить англоязычный блог в существующей CMS. Переведенные статьи не входят в первоначальный объем работ.

Бизнес-требования

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

Ключевые заинтересованные стороны

Майя управляет проектом, Лео руководит контентом, а Нина рассматривает требования к маркетинговым операциям.

Ограничения проекта

Запуск через шесть недель с использованием существующей CMS. Убедитесь, что у рецензентов достаточно времени для поддержки графика.

Анализ затрат и выгод

Оценить трудозатраты на создание контента, настройку CMS, отслеживание и рецензирование. Сопоставить эти затраты с ожидаемой выгодой от генерации лидов и отчетности перед утверждением инвестиций.

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

2. Напишите бизнес-требования для рассмотрения и утверждения

Формулируйте по одному требованию за раз, а затем решайте, как команда будет его проверять. Майя превращает фразу «Атрибутировать лиды из блога» в более конкретное утверждение: «Атрибутировать лиды, привлеченные из блога, в CRM, чтобы маркетинг мог измерить свой вклад».

Майя предлагает тест: после сдачи команда отправит десять форм и подтвердит, что каждая запись в CRM сохраняет источник блога. Это покажет, работает ли атрибуция; Нина оценит отдельную цель в 20 лидов после запуска.

Вот как Майя заполняет запись требования во время проверки BR-01:

Поле

BR-01 на проверке

Идентификатор и версия требования

BR-01, версия 2

Бизнес-потребность и источник

Маркетингу необходимо измерить вклад блога в квалифицированные лиды. Нина предоставляет требования к измерениям.

Формулировка требования

Атрибутировать сгенерированные блогом лиды в CRM, чтобы маркетинг мог измерить их вклад.

Приоритет и область

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

Проверка и подтверждение

Десять тестовых отправок сохраняют источник блога в CRM. Прикрепите тестовый контрольный список и последующие результаты к BR-01.

Владелец и согласующий

Майя ведет требование; Нина проверяет и утверждает его.

Зависимости и допущения

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

История решений и изменений

На проверке. Нина запросила систему проверки; Майя добавила CRM и тестовый контрольный список в версии 2. Запишите решение и дату Нины после проверки.

Майя также присваивает приоритеты другим требованиям:

Требование

Владелец

Приоритет

BR-01: Атрибуция лидов из блога

Майя

Обязательно

BR-02: Утверждение публикаций перед выходом

Лео

Обязательно

BR-03: Ежемесячная отчетность

Нина

Желательно

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

3. Переход от требований к рабочему процессу в Asana

Откройте шаблон BRD в Asana и адаптируйте его под свой проект. Создайте задачу для каждого требования, включите его ID в название задачи и назначьте одного владельца. Добавьте настраиваемые поля для приоритета и статуса проверки, затем впишите формулировку требования в описание задачи и объясните, как команда будет его проверять.

Это поля и примеры требований, которые вы добавляете при адаптации шаблона. Связывайте задачи по реализации с поддерживаемым ими требованием: например, «Настроить поле источника лида» — это работа, необходимая для выполнения BR-01.

4. Проверка требования и фиксация решения

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

Майя назначает Нине задачу по проверке BR-01. Нина спрашивает, какая система будет проверять атрибуцию, поэтому Майя называет CRM и прикрепляет тестовый контрольный список. Измененное требование теперь готово к принятию решения Ниной.

В этом примере Нина одобряет предложенную формулировку и метод проверки, а Майя фиксирует утвержденную версию и дату решения. Позже команда протестирует выполненную работу, а после запуска оценит эффективность лидов.

Задачи утверждения в Asana предлагают варианты «Утвердить», «Запросить изменения» и «Отклонить». Настраиваемое поле статуса проверки помогает отслеживать прогресс; оно не устанавливает права на утверждение и не мешает продолжению работы.

Когда поступает запрос на добавление переведенных публикаций, Майя регистрирует его как CR-01 и проверяет его влияние на шестинедельный дедлайн и ресурсы для проверки. Спонсор откладывает запрос на более поздний этап. Майя сохраняет область действия для английского языка и связывает решение с затрагиваемой работой, чтобы команда знала, что именно нужно поставить сейчас.

Что должен содержать документ с бизнес-требованиями?

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

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

1. Краткое содержание

Краткое содержание — это общее описание того, что представляет собой ваш проект и какова его цель. Те, у кого нет времени читать весь BRD целиком, должны понять, чего вы планируете достичь, прочитав краткое содержание.

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

2. Цели проекта

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

Перечислите цели проекта как цели SMART, чтобы убедиться, что они:

Конкретные

Конкретные

Измеримые

Измеримые

Достижимые

Достижимые

Актуальные

Актуальные

Ограниченные по времени

Ограниченные по времени

Для маркетингового блога Нина будет измерять целевой показатель в 20 квалифицированных лидов в месяц в CRM к третьему месяцу после запуска. Если результаты окажутся ниже, команда сможет просмотреть свою работу и решить, что скорректировать. Проверка атрибуции для BR-01 показывает, правильно ли записываются лиды; отслеживание цели показывает, приносит ли блог запланированные результаты.

3. Область проекта

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

Детали, которые необходимо описать в области проекта, включают:

График

График

Бюджет

Бюджет

Результаты

Результаты

Требования к проекту

Требования к проекту

Проектная команда

Проектная команда

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

4. Бизнес-требования

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

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

Например, BR-01 позволяет маркетинговой команде измерять вклад блога в лиды. Настройка поля CRM — это задача по реализации, которая поддерживает это требование. Запланированный тест с десятью отправками показывает рецензентам, как команда будет проверять атрибуцию.

5. Основные заинтересованные стороны

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

Члены команды, работающие над проектом

Члены команды, работающие над проектом

Руководители проектов, ведущие проект

Руководители проектов, ведущие проект

Руководители, утверждающие проект

Руководители, утверждающие проект

Клиенты, на которых влияет готовый проект

Клиенты, на которых влияет готовый проект

Укажите имя, роль и обязанности каждого участника. Определите, кто поддерживает каждое требование, кто предоставляет экспертные знания и кто его утверждает. В примере с блогом Майя владеет требованием BR-01, Лео предоставляет знания о контенте, а Нина проверяет требование к измерениям.

Исследование Asana показало, что компании с более высокой производительностью склонны использовать координацию для передачи информации, передачи задач и планирования проектов. Для вашего BRD примените эту идею на практике, согласовав, кто предоставляет информацию, кто поддерживает документ и кто принимает решения.

6. Ограничения проекта

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

Ознакомьтесь с этими ограничениями и связанными с ними элементами планирования:

Риски проекта

Риски проекта

Доступность команды

Доступность команды

Ресурсы

Ресурсы

Зависимости проекта

Зависимости проекта

Сроки

Сроки

Бюджет проекта

Бюджет проекта

Различайте фиксированные ограничения и то, что вам еще предстоит исследовать. Шестинедельный дедлайн блога и существующая CMS являются ограничениями. Зависимость — это работа, от которой зависит проект, например настройка связи формы с CRM. Майе необходимо подтвердить доступность рецензентов; недостаток ресурсов может задержать график.

7. Анализ затрат и выгод

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

Чтобы выполнить анализ затрат и выгод:

Опишите все затраты, связанные с вашим проектом

Опишите все затраты, связанные с вашим проектом

Объясните связанные с этим выгоды

Объясните связанные с этим выгоды

Укажите общую ожидаемую стоимость вашего проекта

Укажите общую ожидаемую стоимость вашего проекта

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

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

Бесплатный шаблон документа бизнес-требований

В чем разница между бизнес-требованиями и функциональными требованиями?

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

Для блога бизнесу необходимо измерить свой вклад в привлечение квалифицированных лидов. Сопутствующее функциональное требование заключается в сохранении значения источника блога при создании записи в CRM из отправленной формы. Настройка и тестирование этого поля являются задачей реализации.

Документ бизнес-требований (BRD)

Документ функциональных требований (FRD)

Объясняет, чего должен достичь проект

Описывает поведение, которое должно поддерживать решение

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

Подробное описание требуемого поведения

Фокусируется на бизнес-целях и содержании

Фокусируется на поведении системы и функциональности

Создается на ранних этапах планирования проекта

Разрабатывается на основе бизнес-потребностей и уточняется в ходе проверок

Помимо функциональных требований, существуют:

Пользовательские требования: они описывают то, что пользователи должны сделать с помощью готового решения.

Пользовательские требования: они описывают то, что пользователи должны сделать с помощью готового решения.

Требования к продукту: они описывают назначение продукта, функции и ожидаемое поведение.

Требования к продукту: они описывают назначение продукта, функции и ожидаемое поведение.

Нефункциональные требования: они определяют качества решения, такие как производительность, надежность, доступность или безопасность.

Нефункциональные требования: они определяют качества решения, такие как производительность, надежность, доступность или безопасность.

Создайте черновик BRD с помощью ИИ

ИИ может помочь вам подготовить проект документа для рассмотрения заинтересованными сторонами. В Indeed аналитические команды используют AI Studio для составления уставов проектов и технических требований в комментариях. Старшие менеджеры технических программ затем проверяют содержание.

Для примера с блогом Майя могла предоставить согласованный запрос и контекст проекта со следующей инструкцией: «Используйте только предоставленный контекст. Составьте черновик бизнес-потребности и требований, а недостающие факты перечислите в виде открытых вопросов. Не придумывайте цели и не утверждайте черновик». После этого Майя проверяет каждое утверждение перед рассмотрением заинтересованными сторонами.

Чтобы использовать этот подход в AI Studio, настройте рабочий процесс и действие вывода, например добавление комментария, следуя инструкциям AI Studio.

Как DIRECTV и loanDepot связывают бизнес-требования

Как только ваша команда согласует требования, ей понадобится способ воплотить эти решения в жизнь. Эти примеры с клиентами демонстрируют практики, которые вы можете адаптировать при претворении BRD в жизнь.

DIRECTV: сопоставление запросов с бизнес-приоритетами

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

Примените этот подход к вашему BRD, зафиксировав, какому бизнес-приоритету соответствует требование и почему оно входит в утвержденный объем. Когда поступает новый запрос, рецензенты могут сравнить его с теми же приоритетами.

Прочитайте историю успеха DIRECTV →

loanDepot: хранение записей об утверждении вместе с работой

Команда HR Technology в loanDepot заменила электронную почту и устные согласования шаблонными задачами по запросам. Для запроса группы безопасности Workday команда хранит заметки, скриншоты, подзадачи и записи об утверждении, настройке и производстве в одном месте.

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

Прочитайте историю успеха loanDepot →

Назначьте для каждого бизнес-требования владельца и следующий шаг

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

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

Бесплатный шаблон документа бизнес-требований