пример brd бизнес требования

Написание документов BRD / MRD / PRD для повышения квалификации менеджеров по продукту

Умение менеджера по продукту писать документы

Вы знаете три основных документа продакт-менеджеров?
Знаете ли вы разницу между тремя основными документами для менеджеров по продукту?
На каком этапе какие документы мы будем использовать?
Какая работа необходима при написании сопутствующих документов для менеджеров по продукту?
Вы знаете, какой инструмент для менеджеров по продукту самый мощный?

7.1 Основной инструмент для продакт-менеджеров по написанию документов

7.1.1 Microsoft Office 2013

Excel (статистика данных, отчеты по данным, анализ данных, создание легенды данных, контроль выполнения)

Структура документа Excel (макет, исполнение логической структуры, цвет)
Расчет простых функций (сложение, вычитание, умножение и деление)
Организация данных (фильтрация, сортировка)
Производство значков (круговая диаграмма, столбчатая диаграмма, гистограмма, линейная диаграмма и т. Д.)

7.1.2 Microsoft Visio 2013

Инструмент блок-схемы
Инструмент диаграммы структуры информации

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

7.1.3 Axure6.5

Простая блок-схема
Прототип оружия
Примечание

Хотя Axure хорош, помните, что он всего лишь инструмент, не поддавайтесь ему.
Не впадайте в суперреализм

7.1.4 Balsamiq Mockups

Инструмент прототипа эскиза

Можете быстро построить то, что хотите
Хорошая поддержка мобильной производительности
Богат элементами
Нелегко вмешиваться в дизайн пользовательского интерфейса

7.1.5 MindManager

составление карты разума
Собирайте, обобщайте, систематизируйте идеи и идеи

7.1.6 Самое мощное оружие

2B щелкните

высокоскоростной
краткий
Чувствительный
Подходит для многих сценариев (шторм, презентация и т. Д.)

7.2 Три основных документа для менеджеров по продукту

BRD (документ с бизнес-требованиями)
MRD (документ с требованиями рынка)
PRD (документ с требованиями к продукту)

7.3 Стадия рождения, основная структура и связанные инструменты трех основных документов в жизненном цикле продукта

Бизнес-требования, шаблон, наполнение

7.4 Оглядываясь назад на BRD и MRD

BRD и MRD, иногда могут быть интегрированы в план, так как же нам выбрать?

Посмотрите на объект отчета
Посмотрите на командные привычки
Зависит от твоей привычки
Смотрите, как лидер
Примечание: это не отношения между A и B, это вопрос конкретного выбора в разных ситуациях и разных средах.

7.5 Оглядываясь назад на три основных документа

Узнайте и проясните ценность BRD для бизнеса, которую вы обнаружите
Придумайте и объясните, как достичь бизнес-целей MRD
Опишите конкретный метод реализации этого метода PRD.
Это от макро до микропроцесса
Это логичный процесс, который может выдержать тщательную проверку и постепенно улучшать и приземляться.
Это процесс от получения признания -> получения ресурсов -> выражения идей -> руководства реализацией -> выполнения

Интеллектуальная рекомендация

MongoDB Основные действия: обновление документов

Метод обновления db.collection.updateOne(, , ) db.collection.updateMany(, , ) db.collection.re.

Отображение портов VMware NAT

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

Список молнии на складном хранилище диаграммы очень прост!

1. Фоновый анализ Во время дизайна модели данных хранилища данных часто встречается дизайн следующей таблицы: Существуют некоторые таблицы данных, такие как пользовательская таблица, около 1 ми.

Интерфейс обхода Python для ранжирования ключевых слов в магазине приложений в ios

Если есть проблема, пожалуйста, ответьте автору. .

Источник: russianblogs.com

Пример brd бизнес требования

Статья Майкла Шриватсана, в которой он проливает свет на запутанную систему документов с описаниями требований к продукту. BRD, MRD, PRD, FSD, PSD, SRS, IRS. хотя последнее как-то связано с налогами, нет?

Заранее прошу прощение за возможные ошибки в переводе названий документов. Это просто невозможно! Я не знаю точных аналогов в наших документах, поэтому вынужден придумывать. По уму следовало бы заглянуть в ГОСТы и ЕСПД, чтобы выудить оттуда хотя бы правильные названия программных документов – но лень 🙂

Алфавитная каша

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

Сейчас мы все выросли и редко едим эту алфавитную ерунду, но практически во всех профессиях профессиональный жаргон это алфавитная каша, наводненная ТБА (трехбуквенная аббревиатура). ХЭП (хорошо это или плохо)?

Управление продуктом и аналитика продукта не исключение – особенно, когда дело касается описания требований. У нас есть BRD, MRD и PRD; у нас также есть FSD, PSD и SRS и еще много вариаций на ту же тему.

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

Вот вам смешной вопрос: сколько различных ТБА вы сможете составить, используя только заглавные буквы английского алфавита?

P.S.Если вы добрались до сюда и до сих пор не знаете, что такое ТБА – стыдитесь! Пожалуйста, перечитайте все с начала, ладно?

Аббревиатуры описаний требований

Давайте пройдемся по наиболее распространенным аббревиатурам, используемым для обозначения документов с описаниями требований:

BRD – Business Requirements Document (Бизнес требования)

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

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

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

Предположим, ваша компания разрабатывает систему управления взаимоотношений с клиентами (customer relationship management CRM).

BRD может фокусироваться на проблемах стоящих перед менеджерами по продаже – отслеживание всех сделок и возможность формирования достоверных прогнозов. Он может определять:

Перед кем стоят подобные проблемы:

Менеджеры по продаже компаний входящих в список Fortune-500

Отсутствие отслеживания статуса заказов в реальном времени
Невозможность формирования достоверных прогнозов

Создание web-ориентированного ПО для отслеживания (проведения) сделок и формирования прогнозов

MRD – Market Requirements Document (Требования рынка)

MRD фокусируется на определении требований рынка к предлагаемому новому продукту.

Если BRD определяет круг проблем и предлагает вариант их решения – то MRD более подробно описывает детали предлагаемого решения. Он может включать несколько или все нижеприведенные аспекты:

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

Чаще всего он пишется Менеджером по продукту, Менеджером по маркетингу продукта или Бизнес аналитиком совместно с Системным аналитиком.

Давайте продолжим предыдущий пример компании, разрабатывающей систему управления взаимоотношением с клиентами (customer relationship management – CRM).

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

Функциональные требования:

Должно работать под Internet Explorer (версии 6.0 и выше) и Firefox (версии 1.5 и выше)
Должно использовать SSL для обеспечения безопасности
…
Пользователь должен иметь возможность вводить данные через web-формы для: пользователей, компаний, контактов, и т.д.

Должно поддерживаться до 100.000 одновременных пользователей
…
Необходимо полное руководство пользователя на Английском, Немецком и Японском

Некоторые организации объединяют MRD и PRD в один документ и называют этот документ MRD. В этом случае MRD будет включать то, что описано в этой части и то, что описано в следующей – и может содержать более 50 страниц.

PRD – Product Requirements Document (Требования к продукту)

PRD фокусируется на определении требований к предлагаемому новому продукту.

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

В организациях, где MRD не включает детализацию требований и варианты использования, PRD закрывает эту брешь.

Обычно он пишется Менеджером по продукту, Бизнес аналитиком или Продуктовым аналитиком.

PRD может фокусироваться на детализации требований, таких как:

Форма авторизации должна включать поля для имени пользователя и пароля.
Она также должна включать ссылку «Забыли пароль?»
Страница «Контакты» должна включать поля для имени, фамилии, телефона, email и т.д.
…
Алгоритм формирования прогноза должен содержать 5-шаговый мастер, который проведет пользователя через шаги, необходимые для создания ежегодного отчета. Все шаги описаны далее…

PRD может также включать подробные варианты использования.

Некоторые организации объединяют MRD и PRD в один документ и называют этот документ MRD. В этом случае MRD будет включать то, что описано в этой части и то, что описано в предыдущей.

FSD – Functional Specifications Document (Функциональная спецификация)

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

Если MRD и PRD фокусируются на требованиях с точки зрения потребностей рынка и продукта, FSD фокусируется на определении деталей продукта, в форме, которая может быть использована разработчиками. FSD может также включать законченные скриншоты и детальное описание пользовательских интерфейсов (UI).

Обычно он пишется Системным аналитиком, Архитектором решения или Главным разработчиком – т.е. автор обычно сам относится к разработчикам.

PSD – Product Specifications Document (Спецификация продукта)

PSD – это наименее популярная аббревиатура, но в тех организациях, которые используют эти документы, они обычно соответствуют по содержанию и объему Функциональной спецификации (Functional Specifications Document FSD) описанный выше.

SRS – Software Requirements Specification (Спецификация требований)

SRS – это еще одна не очень популярная аббревиатура. В организациях, которые используют SRS, они обычно очень похожи на то, что описывается в PRD и FSD.

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

Ответ на смешной вопрос : количество ТБА (трех буквенных аббревиатур), которые вы сможете составить, используя только заглавные буквы английского алфавита равно: 26 3 = 17576.

Вы понимаете, что это означает, да? Будьте морально готовы выучить еще 17500 ТБА касающихся описаний требований.

НВВ (ну вот и все) – наше путешествие в замечательный мир аббревиатур документов описывающих требования завершен.

Опубликовано в дневнике Michael on Product Management

команды разработки: системный аналитик, разработчики и тестировщик;

часто к ним подключается дизайнер, отвечающий за проектирование пользовательского интерфейса;

и архитектор, который помогает с проработкой архитектуры будущего решения.

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

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

И здесь возникает формализация.

Этапы формализации требований

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

Сейчас расскажу, как это происходит. Общая схема проработки требований выглядит примерно так.

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

За определение потребностей бизнеса отвечает владелец соответствующего цифрового продукта (PO). Он общается с представителями бизнеса, изучает бизнес-процессы, проводит исследование рынка и формулирует бизнес-требования к продукту. У нас они обычно выражаются в виде документа Word (BRD) и эпиков (Epics) в Jira.

BRD содержит полное описание бизнес-требований, которым должен удовлетворять цифровой продукт. На основе данного документа и с учетом принятых архитектурных паттернов архитектор (Solution Architect) разрабатывает видение (Vision) архитектуры будущего решения. Ниже — общий вид BRD как пример.

Epics представляют собой набор отдельных бизнес-требований. Команда продукта (Product Team) проводит их анализ и декомпозицию на пользовательские истории (User Stories). Ниже — пример Epics и User Stories. Справа — Sab-Tasks (о них чуть дальше).

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

Однако на данном этапе их ещё нельзя брать в работу. Требования не до конца определены.

На основе Vision для User Stories системный аналитик (SA) разрабатывает проектные решения (Specs).

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

При необходимости, для User Stories готовится дополнительный артефакт — дизайн пользовательских интерфейсов (UI). Для этого команда подключает к работе над продуктом дизайнера (Designer). Часто он ведёт разработку в Figma и помимо макетов пользовательского интерфейса готовит кликабельные прототипы для дальнейшей валидации требований. Ниже пример подобного UI.

На основе Specs и UI команда разработки (DevTeam) выполняет декомпозицию User Stories на подзадачи (Sub-Tasks) для каждого члена команды. Пример Sub-Tasks на картинке.

Таким образом, бизнес-требования и требования стейкхолдеров определены, дизайн пользовательских интерфейсов и технических решений готов, перечень подзадач для их реализации сформирован. Остаётся только выполнить оценку User Stories, приоритезировать бэклог продукта и спланировать текущий спринт.

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

Но что произойдёт, если отклониться от процесса? Об этом расскажу дальше.

Отклонение от процесса

Правила существуют, чтобы их нарушать. А процессы — чтобы от них отступать. Время от времени продуктовые команды отклоняются от описанного процесса в надежде выпустить новую фичу как можно быстрее. Тогда схема проработки требований сократится до такого состояния.

Отклонения обычно проявляются в отказе от разработки технических артефактов — Vision и/или Specs.

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

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

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

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

Отсюда мы вывели правило — любое отклонение от процесса должно быть осознанным и обоснованным.

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

Итог

Я кратко описал, как мы ведём требования к программному обеспечению. Безусловно процесс не идеален. Иногда команды от него отклоняются с целью ускорить выпуск новой фичи в бой. Однако уверен, из него можно почерпнуть что-то полезное.

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

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

Use Case VS User Story. Выбираем подход к специфицированию требований
Георгий Савельев. Толковый бизнес-аналитик: Разработка бизнес-требований
Демотивируй правильно! / Егор Бугаенко (Zerocracy)

Рекомендуем почитать [подборка редактора блога]

Пять мифов о роботизации: как и зачем машинам делегируют рутину. Boston Dynamics не будет — мы больше про рутину: сканирование, распознавание, экономия минут и вот это всё.
Скаутинг, fast track, пилоты, инновации? Выше было про роботов, а здесь — как их внедряют. Постарались без формальностей описать этот процесс.
Ещё одна подборка книг по фронтенду. Без официальных аннотаций. Прочитали — рассказали чем интересно, и ещё цитат добавили.
Взболтать, но не смешивать: как упаковать находки исследования, миксуя JTBD, CJM и компас персон. Большое исследование.
BPMN не в теории, а на практике
«Гигиенический минимум» в работе тимлида
Как снимать логи с устройств на Android и iOS: разбираемся с инструментами

Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.

Анонс: 13 декабря пройдёт Alfa Digital Open, где будем говорить о мобильных приложениях для клиентов и сотрудников, аналитике, кроссплатформенном цифровом банкинге и работу банка в городах без отделений. Присоединяйтесь!

альфа-банк
требования к по
user story
бизнес-требования
спецификация
архитектурное решение
проектное решение

Блог компании Альфа-Банк
Анализ и проектирование систем
Управление продуктом
Подготовка технической документации

Источник: habr.com

Выявление нужд пользователей

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

Примеры начальных формулировок задач приходят ко мне самые разнообразные:

С продолжением списка первых запросов по обратной связи можно ознакомиться по этой ссылке.

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

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

Откровенно говоря, я бы предпочел понять проблему заказчика, а как ее решать, лучше, чтобы заказчик доверил мне – у меня и выбор инструментов больше. Т.е. мне больше нравится формула: от заказчика – проблема, от меня – решение.

В конечном итоге результатом выявления нужд пользователей должен стать документ, описывающий требования заказчика — BRD (Business Requirements Document) с заранее согласованной структурой, включающий в себя как описание бизнес процессов «As Is», «To Be», так и описание пользовательского интерфейса, варианты использования системы, а также тестовые сценарии, на основании которых будет приниматься программное обеспечение. BRD — основа для дальнейшей подготовки качественной документации.

Иногда и программисты, и заказчики предпочитают использовать другое название для описания задач клиента – техническое задание (ТЗ). Я не против. В самом деле, разделение документов на: BRD (Business Requirement Document), FSD (Functional Specification Document), TS (Technical Specification), — имеет смысл в крупных проектах, где есть бизнес-аналитики, системные аналитики и т.д. в нашем же случае есть я (и бизнес-аналитик, и программист — два в одном) и есть заказчик. И наша задача понять друг друга и договориться по деньгам и срокам с помощью некого контракта. И как этот контракт назвать: ТЗ или просто договор подряда – не так уж и важно. Важно расставить все точки над i.

Если же у вас нет времени и денег на «лишние телодвижения». Если ваши нужды вам предельно понятны, и у вас есть готовое ТЗ, а от исполнителя вы ожидаете фиксированную стоимость и сроки выполнения подряда, то убедитесь, как минимум в том, что в вашем ТЗ чётко определены объемы и критерии приемки работ. Если объемы работ заканчиваются фразой «и так далее», то и стоимость работ тоже будет заканчиваться фразой «и так далее».

Если вы готовы сами написать ТЗ, то вот вам шпаргалка в виде буллитов, что в BRD/FSD/ТЗ стоит упомянуть.

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

А можно ли начать работать без ТЗ? Ну, в самом деле, зачастую заказчик не знает в начале пути, что ему нужно. А в процессе приближения к решению его требования могут несколько раз кардинально поменяться. Мой ответ такой: можно. Но платить придется за отработанные часы (Time&Materials).

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

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

Если вам нужно что-то автоматизировать – пишите, обсудим и попробуем договориться. Я готов помочь не только в части программирования, но и в части обсуждения бизнес процессов, наиболее подходящих для автоматизированного управления.

Источник: www.quickwin.ru