Что такое шаблон документ бизнес-требований (BRD) и когда он пишется
29 ноября 2024
Договариваться «на берегу» и фиксировать договоренности — важнейшая бизнес-практика, которую стоит освоить и заказчикам, и исполнителям. BRD (Business Requirements Document) — это документ, который описывает бизнес-потребности и цели проекта. С ним легче управлять ожиданиями, устанавливать стандарты, отмечать стадии проекта и успешно воплощать его в жизнь. В этой статье мы обобщили наш опыт о том, когда писать документ бизнес-требований и как заложить в нём максимальную пользу для обеих сторон.
Что такое BRD и что он может включать
BRD (Business Requirements Document) — это документ, который описывает бизнес-потребности и цели проекта, а также определяет, как программное обеспечение или система должны помочь их достичь. Он служит основой для дальнейшей разработки проекта, обеспечивая понимание бизнес-задач и ожидаемых результатов со стороны заказчика и разработчиков. Другими словами, этот документ используется для установления и документирования функциональных и нефункциональных требований, целей и ожиданий заказчика.
Структура и наполнение BRD меняются в зависимости от проекта, но обычно он включает следующие обязательные пункты.
Структура и наполнение BRD меняются в зависимости от проекта, но обычно он включает следующие обязательные пункты.
•
Информация о компании, отрасли, целевой аудитории и конкурентах.
•
Обзор проекта, его цели и контекст.
•
Описание проблемы, которую решает проект.
•
Определение целей проекта и конкретных задач, которые необходимо выполнить.
•
Функциональные требования (функции продукта, необходимые для достижения целей).
•
Нефункциональные требования (к производительности, безопасности, надежности и другим характеристикам продукта).
•
Показателеи, по которым будет оцениваться успех проекта.
•
Описание потенциальных рисков и способов их минимизации.
BRD является важным инструментом коммуникации между заказчиком и разработчиками, обеспечивая четкое понимание бизнес-целей и ожидаемых результатов проекта.
Цели, задачи и особенности BRD
Особенность BRD (Business Requirements Document), которая отличает его от технического задания или спецификации — то, что он описывает бизнес-потребности и цели проекта или продукта именно с точки зрения бизнеса. BRD определяет, ЧТО должно быть разработано, а не КАК это должно быть сделано.
Цели BRD:
Цели BRD:
•
Определить бизнес-проблему, которую решает проект.
•
Сформулировать цели и ожидаемые результаты проекта.
•
Описать ключевые функции и характеристики системы/продукта.
•
Установить критерии успеха проекта.
•
Обеспечить понимание бизнес-потребностей всех заинтересованных сторон.
Основная «миссия» BRD — это внесение ясности и избавление от расплывчатых и неоднозначных трактовок задачи. С ним ко всем участникам процесса приходит четкое понимание бизнес-потребностей, прозрачность в порядке действий и понимание о планировании бюджета. Но всё это происходит только в том случае, если документ правильно написан и согласован с исполнителем.
Общие советы, как писать BRD
Прежде чем приступить к пошаговой инструкции, дадим несколько советов: они помогут не только правильно настроиться перед составлением BRD, но и заполнить возможные пробелы в брифе или в другой информации о проекте.
•
Будьте конкретными и измеримыми. Говорите на языке цифр; формулируйте цели и задачи, используя измеримые величины. Например, не «увеличить долю рынка», а «довести долю рынка до 5%»; не «обновить дизайн сайта», а «повысить конверсии в два раза» или «добавить раздел с указанными функциями».
•
Определите ключевые цели. Каждый проект, достаточно сложный, чтобы удостоиться BRD, имеет несколько целей. Важно выделить главную и сосредоточиться на ней.
•
Цели должны быть связаны с бизнес-стратегией и направлены на результат. Например: «занять 5% рынка», а не «улучшить позиционирование».
•
Укажите контекст и ожидания. Например: «Сейчас доля компании на рынке оценивается, по разным подсчётам, от 2 до 3,5%. Ожидается, что мы выполним точную оценку и увеличим долю рынка до 5%».
•
Обсудите формат BRD с командой проекта или заказчиком чтобы убедиться что всё необходимые аспекты учтены.
•
Заложите достаточно времени на написание, поскольку BRD — это большой документ.
Если у вас есть все необходимые данные, чтобы написать документ бизнес-требований в соответствии с этими советами, самое время перейти к практике.
Пошаговый план написания BRD
Структура документа может меняться в зависимости от проекта. Но мы собрали основные пункты, которые в том или ином виде есть в каждом документе бизнес-требований, и добавили к ним главные тезисы.
•
Введение. Цель и ожидаемые результаты проекта или продукта. Заинтересованные стороны и их роли. Контекст и область применения проекта или продукта
•
Описание текущей ситуации. Какие проблемы существуют в компании и как цифровой продукт должен их решить.
•
Функциональные требования. Описывают, ЧТО должен делать цифровой продукт. Это конкретные функции и действия, которые продукт должен выполнять, чтобы удовлетворить потребности пользователей. Например, «пользователь должен иметь возможность зарегистрироваться», «система должна отправлять уведомления о новых заказах».
•
Нефункциональные требования. Определяют, КАК продукт должен выполнять свои функции. Они касаются характеристик продукта, таких как производительность, безопасность, удобство использования и надежность. Например, «время отклика системы не должно превышать 2 секунды», «система должна иметь двойную аутентификацию для входа».
•
Требования к данным. Например, особый порядок защиты информации.
•
Риски и ограничения. Например, невозможность интегрироваться с зарубежными сервисами.
•
План реализации.
•
Оценка проекта: предполагаемая стоимость и затраты времени.
•
Приложения (могут включать макеты, прототипы, детальное описание бизнес-процессов, но это не обязательный пункт).
•
Согласование и утверждение.
Возможные ошибки при формировании BRD
В этом разделе мы собрали типичные ошибки, которые делают при составлении документа бизнес-требований. Если ваш BRD уже готов, внимательно прочтите список: возможно, он подскажет, как можно улучшить документ.
Ошибочно сформирован запрос. Например, неправильно определена целевая аудитория сайта.
Мало данных про интеграции. Эта проблема часто возникает при разработке электронных сервисов. Заказчик не понимает или не поясняет, откуда должны поступать данные в его систему. Также случается, что не проведено исследование, возможны ли интеграции технически и какие есть проблемы.
Не прописана ролевая модель. Не описаны классы пользователей, их доступы (какие именно данные им видны в системе), пути входа.
Не детализировано функциональное задание. Когда разработчик начинает погружаться в детали, выясняется, что бизнес-процессов и взаимосвязей на самом деле гораздо больше, чем указано в изначальном ТЗ, и все их нужно учитывать, чтобы получить необходимый функционал.
Не учтены все расходы или риски. Абсолютно всё учесть невозможно, но стоит к этому стремиться. Если BRD написано очень обобщенно и не учитывает детали бизнес-процессов, велика вероятность, что всё в итоге пойдет не по плану.
Ошибочно сформирован запрос. Например, неправильно определена целевая аудитория сайта.
Мало данных про интеграции. Эта проблема часто возникает при разработке электронных сервисов. Заказчик не понимает или не поясняет, откуда должны поступать данные в его систему. Также случается, что не проведено исследование, возможны ли интеграции технически и какие есть проблемы.
Не прописана ролевая модель. Не описаны классы пользователей, их доступы (какие именно данные им видны в системе), пути входа.
Не детализировано функциональное задание. Когда разработчик начинает погружаться в детали, выясняется, что бизнес-процессов и взаимосвязей на самом деле гораздо больше, чем указано в изначальном ТЗ, и все их нужно учитывать, чтобы получить необходимый функционал.
Не учтены все расходы или риски. Абсолютно всё учесть невозможно, но стоит к этому стремиться. Если BRD написано очень обобщенно и не учитывает детали бизнес-процессов, велика вероятность, что всё в итоге пойдет не по плану.
Как мы обычно составляем BRD: история с примером
Разработка документа бизнес-требований — это сложный процесс, который предполагает несколько раундов переговоров и много уточняющих вопросов от каждой из сторон. Расскажем про сложности, которые могут возникнуть при составлении BRD, на примере реального проекта из практики Uplab.
К нам обратилась крупная компания, чтобы создать внутренний сервис для объединения различных потоков данных. Вот что было указано в основных требованиях.
К нам обратилась крупная компания, чтобы создать внутренний сервис для объединения различных потоков данных. Вот что было указано в основных требованиях.
•
Оцифровка финансовых показателей.
•
Отображение проектной деятельности компании.
•
Предоставление доступа к отчетной финансовой информации для внешний пользователей.
•
Создание электронной отчетности.
В техническом задании (ТЗ) заказчик обозначил ключевые показатели, которые должны быть доступны в сервисе. Эти данные должны были продемонстрировать состояние каждого предприятия компании и прогресс проектов. Однако первоначальное ТЗ не содержало детализированной информации о каждом показателе и механизмах их формирования. Не было указано, из чего чего формируются показатели и как эти данные попадут в систему. Особой сложностью стало то, что в составе компании-заказчика было множество дочерних предприятий, и для каждого из них нам нужно было обеспечить загрузку данных.
В процессе работы возникли следующие вопросы:
В процессе работы возникли следующие вопросы:
•
Как и откуда планируется получение данных?
•
С какими системами и сервисами будет происходить интеграция?
•
Будет ли у разработчиков доступ к данным напрямую?
•
Есть ли определенный перечень объектов?
•
Как организована авторизация пользователей в системе?
•
Какова ролевая модель? Сколько будет ролей и какие права доступа у каждой из них?
Наша задача как разработчика — грамотно сформулировать нужные вопросы в самом начале и направить клиента в детальное описание, которые необходимо зафиксировать полученные ответы в документе бизнес-требований. Это позволит предоставить эффективное решение, а также рассчитать его стоимость и сроки реализации. Ведь только сам клиент глубоко понимает свой бизнес и цели.
Обсудив все эти вопросы на встрече с клиентом мы смогли оценить сроки и стоимость разработки сервиса, а впоследствии и разработать подробный документ бизнес-требований.
Обсудив все эти вопросы на встрече с клиентом мы смогли оценить сроки и стоимость разработки сервиса, а впоследствии и разработать подробный документ бизнес-требований.
Комментарии к статье
Комментарии: 0