Разработка brd что это

Разработка brd что это

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

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

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

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

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

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

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

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

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

Источник

Русские Блоги

Что такое BRD?

Содержание документа

2. MRD является документом рыночного спроса

Документы являются «процессными» документами в ходе продуктовых проектов.

Содержание документа

Готов к работе

BRD: документ бизнес-требований (принцип одного предложения)

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

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

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

(1) с точки зрения потребностей пользователей / клиентов

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

(2) со стратегической точки зрения

Какую ценность это может принести предприятию, может ли оно приносить огромную прибыль, может ли оно по-прежнему увеличивать долю рынка, может ли оно расширить цепочку услуг или может сформировать синергетический эффект, такой как первоначальная электронная коммерция, плохая привязанность пользователей, теперь делают Сообщество шоппинга, которое позволяет пользователям не только делать покупки, но и общаться в нем, что увеличивает время пребывания пользователя. Это имеет преимущество в увеличении липкости пользователя и снижении затрат на маркетинг. Например, Didi Investment ofo, Didi Он предназначен для удовлетворения потребностей пользователей в поездках на такси. Офо предназначен для удовлетворения потребностей пользователей в поездках на короткие расстояния. Население пользователей этих двух продуктов частично совпадает, но сценарии использования дополняют друг друга. Инвестиции в Диди могут образовывать синергетический эффект.

Решение продукта заключается в том, чтобы сообщить лицу, принимающему решение, что общая структура и структура этого продукта в основном включают следующие аспекты:

Какова структура этого продукта, в форме информации, социальной формы, формы поиска или O2O.

Скажите лицу, принимающему решение, является ли бизнес ориентированным на сторону c или b, или совместимы ли b-сторона и c-сторона, кто является участниками, как сформировать замкнутый цикл и т. Д.

(3) Операционная модель

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

Насколько велика емкость рынка? Эти данные необходимо проанализировать с помощью анализа спроса и оценки толпы. Лицо, принимающее решение, примет это суждение, и в него не стоит вкладывать деньги.

Анализ конкурентов, чтобы увидеть, какие игроки на рынке, как они их решают, какие потребности удовлетворяют пользователи, какие не удовлетворяются, как насчет ввода, как насчет команд, как насчет выхода, сравните с нами Какие преимущества и недостатки

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

Где наша возможность на рынке, как найти прорыв, эта возможность может позволить нам развиваться в позиции

Источник

Путаница возникает по трем основным причинам.

Бизнес-требования часто перечислены в документе с бизнес-требованиями или BRD. Акцент в BRD делается на процессе или деятельности точного доступа к планированию и разработке требований, а не на том, как этого достичь; это обычно передается в спецификацию или документ системных требований (SRS или SRD) или другой вариант, такой как документ функциональной спецификации. Путаница между BRD и SRD может возникнуть, если не учитывать различие между бизнес-требованиями и системными требованиями. Следовательно, многие BRD фактически описывают требования к продукту, системе или программному обеспечению.

СОДЕРЖАНИЕ

Обзор

Бизнес-требования часто включают

Темы бизнес-требований

Преимущества

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

Формат

Полнота

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

Трудности

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

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

Определение потребностей бизнеса

Включает в себя следующие шаги:

Источник

Routes to finance

Как открыть кафе в России. Какие документы нужны для открытия ресторана? (Декабрь 2021).

Давайте возьмем пример: компания (мы будем называть их ZXYW LLC) решила передать свои функции учета в общий сервисный центр в США. Они начинают процесс поиска местоположения, создания служб, найма и управление сотрудниками.

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

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

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

На втором этапе БРД фактически может стать договором между двумя сторонами, формально излагая требования найма компании (ZXYW LLC в данном случае) и подрядчика, выполняющего эту работу. Ниже вы увидите подробнее о языке контракта.

Как документ бизнес-требований отличается от бизнес-плана?

Хотя оба документа могут содержать разделы того же типа (например, исполнительное резюме), намерение отличается.

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

Бизнес-план содержит общую информацию о компании и ее планах и стратегиях для получения дохода для погашения кредита.

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

Как документ бизнес-требований отличается от запроса на предложение?

Разница между двумя документами небольшая, но важная. Как правило, запрос предложений (RFP) создается с целью запроса предложений от разных поставщиков. в примере ZYXW RFP отправляется потенциальным компаниям, которые предоставляют услуги аутсорсинга, запрашивать ставки.

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

Когда создается RFP, у него есть крайний срок и требования к подаче заявок. Ставки оцениваются после истечения срока.

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

В некотором смысле документ бизнес-требований аналогичен другим типам бизнес-предложений. BRD должен включать:

Сводная инструкция обычно записывается после завершения BRD.

2. Цели проекта. Эти цели должны быть в формате SMART; конкретные, измеримые, достижимые, реалистичные и ограниченные по времени.

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

5. Финансовые отчеты. Финансовая отчетность необходима для общего представления о влиянии проекта на баланс компании и ее доход за определенный период времени.

Конечно, о том, как компания будет финансировать проект, важно также обсудить здесь.

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

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

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

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

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

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

Как подготовить (или не подготовить) ваше резюме моделирования

Как делают новые модели резюме без какого-либо опыта моделирования? Узнайте, как подготовить (или не подготовить) ваше резюме моделирования

Как подготовить свой бизнес к рождественскому сезону

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

Описывает отпуск по налогу с продаж и как вы могут подготовить ваш бизнес к празднику налогового отпуска в вашем штате и сообщить о продажах праздничных продаж.

Источник

Записки ИТ-многостоночника

Архитектурный и технический консалтинг во внедрении и разработке ПО. Системный бизнес анализ и дизайн

Метка: BRD

Минутка размышлений о ТЗ, больших и малых..

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

Итак, посыл состоит в следующем (вольная интерпретация своими словами, за деталями — велком по ссылке): чтобы повысить качество ИС государственных органов (речь в общем-то о порталах в составе электронного правительства, но, думаю, можно отнести ко всей деятельности по государственной автоматизации), необходимо повышать качество сбора требований и формируемого ТЗ, делать его детальным и всеобъемлющим, чтобы сразу было видно, что получится, и вообще — применять всякие UX-дизайны, варианты использования и прочие стильные, модные, молодежные методики.

Справедливости ради стоит отметить, что редкий заказчик сейчас допустит формирование верхнеуровневых или недостаточно детализированных требований, допускающих неоднозначное трактование. Даже при наличии 100% гарантии того, что разработчик требований будет в дальнейшем выполнять работы по созданию ИС и «если чего-то не написал в ТЗ явно, то все равно понял, что нужно делать», заказчик захочет получить гарантию, что разработчик требований и ИС в дальнейшем понял именно то, что хотел заказчик. Требования с уровнем детализации «выше среднего» для этой цели подходят как нельзя лучше. В случае, когда исполнителем работ по данному ТЗ может (хотя бы теоретически) отличаться от разработчика ТЗ, это и так очевидно. Поэтому в целом с посылом статьи я согласен, однако есть ряд «но…»:

В голову сразу приходит как минимум:

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

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

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

В международной практике эта задача решается довольно эффективно. Как правило, существует как минимум два документа этой стадии работ — Business Requirements Document (Бизнес-требования) и Functional Requirements Specification (функциональные требования)/Software Requirements Specifications (спецификации)/User Story/и т.д.

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

FRS/SRS/US или любой другой частный документ с требованиями может (могут) создаваться итеративно, стихийно, «водопадно» или в рамках любых совместимых методик разработки систем и жизненных циклов. В рамках этих работ аналитик управляет рисками изменения требований, детализирует требования, предполагаемые технические решения и вообще всячески спускается на уровни, которые глубоко неинтересны всем лицам в листе утверждения, но действительно важны для понимания, как система будет удовлетворять уже определенные верхнеуровневые бизнес-требования (потребности бизнеса), как она будет построена, как будет работать и как вообще с этим жить.

В отечественной практике нечто подобное конечно тоже есть (пруф). Готов спорить, что большинство любителей воспринимать ТЗ как документ, утверждаемый и визируемый всеми, включая самого-главного-начальника-управления-по-управлению-всеми-управлениями, не готовы аргументировать, зачем существует этап сбора требований к созданию АС, где присутствует сбор исходных данных и сбор требований пользователей (это в 90 году. ), а также этап разработки концепции АС перед разработкой и утверждением ТЗ.

А общих выводов или морали не будет. Замечу, что с выявлением неразрешимых (иногда) противоречий в классических подходах к разработке ИС я все лояльнее отношусь к ранее негативно воспринимаемым мной гибким и итеративным методикам.

Источник