BRD, MRD, PRD, FSD и прочие ТБА
Статья Майкла Шриватсана, в которой он проливает свет на запутанную систему документов с описаниями требований к продукту. BRD, MRD, PRD, FSD, PSD, SRS, IRS... хотя последнее как-то связано с налогами, нет?
Заранее прошу прощение за возможные ошибки в переводе названий документов. Это просто невозможно! Я не знаю точных аналогов в наших документах, поэтому вынужден придумывать. По уму следовало бы заглянуть в ГОСТы и ЕСПД, чтобы выудить оттуда хотя бы правильные названия программных документов – но лень :-)
Алфавитная каша
Если вы похожи на меня, то вы выросли в окружении всевозможной алфавитной еды – алфавитные хлопья, алфавитные печенья, алфавитный суп, и много всякой другой еды в форме букв алфавита. Я полагаю, большинству из нас она на самом деле нравилась – или наоборот по настоящему не нравилась. Не знаю, к какой именно группе относитесь вы – но в любом случае вы ее ели.
Сейчас мы все выросли и редко едим эту алфавитную ерунду, но практически во всех профессиях профессиональный жаргон это алфавитная каша, наводненная ТБА (трехбуквенная аббревиатура). ХЭП (хорошо это или плохо)?
Управление продуктом и аналитика продукта не исключение – особенно, когда дело касается описания требований. У нас есть BRD, MRD и PRD; у нас также есть FSD, PSD и SRS и еще много вариаций на ту же тему.
И, как будто этого мало, так еще все организации используют эти аббревиатуры по-разному. То, что в одной организации называется MRD, в другой называют PRD. Иногда я не могу сдержать смех, когда вижу очередную ТБА. Как говорится, дайте нам шанс, а уж мы то постараемся!
Вот вам смешной вопрос: сколько различных ТБА вы сможете составить, используя только заглавные буквы английского алфавита?
P.S.Если вы добрались до сюда и до сих пор не знаете, что такое ТБА – стыдитесь! Пожалуйста, перечитайте все с начала, ладно?
Аббревиатуры описаний требований
Давайте пройдемся по наиболее распространенным аббревиатурам, используемым для обозначения документов с описаниями требований:
BRD
MRD
PRD
FSD
PSD
SRS
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 закрывает эту брешь.
Обычно он пишется Менеджером по продукту, Бизнес аналитиком или Продуктовым аналитиком.
Пример:
Давайте продолжим предыдущий пример компании, разрабатывающей систему управления взаимоотношением с клиентами (customer relationship management – CRM).
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.
По поводу качества перевода – я перевожу так, как умею, стараясь донести смысл.