BRD, MRD, PRD, FSD и прочие ТБА

Статья Майкла Шриватсана, в которой он проливает свет на запутанную систему документов с описаниями требований к продукту. 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 типов документов, описывающих требования, расшифрованные и разжеванные. Только хочу вас предостеречь – все организации по-разному используют эти документы. Каждая организация определяет, какие документы создавать и что именно в них описывать, в зависимости от своих нужд.

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

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

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

Опубликовано в дневнике Michael on Product Management & Marketing 19 августа 2006.

По поводу качества перевода – я перевожу так, как умею, стараясь донести смысл.

Google Sites

Report abuse