Портал №1 по управлению цифровыми
и информационными технологиями

BRD. Как написать идеальный документ

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

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

Ключевые элементы документа бизнес-требований

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

Версионирование

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

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

Краткое изложение

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

Цели проекта

Изложите цели и задачи проекта, подробно описывая, что будет достигнуто в результате работы. Если проект поддерживает бизнес-процессы или потоки, это должно быть описано здесь.

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

Формулировка потребностей

Описание потребностей должно быть убедительным. Это — основной смысл проекта. Воспринимайте формулировку потребностей как обоснование, которое должно убедить заинтересованных лиц в правильности идеи и придать мотивацию команде проекта.

Объем проекта

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

 

Стейкхолдеры

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

Финансовый отчет и анализ экономической эффективности

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

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

 

График, сроки и основные этапы

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

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

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

 

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

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

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

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

 

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

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

 

Лучшие практики работы с документацией по бизнес-требованиям

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

  • Получите вклад и перспективы. Представьте документ бизнес-требований на экспертную оценку.
  • Установите разумные сроки. Дважды и трижды проверьте даты и сроки, чтобы убедиться, что они достижимы: лучше завысить оценку и выполнить работу раньше, чем срывать сроки.
  • Предусмотрите время для исследований. Если необходимо привлечь подрядчиков или поставщиков, убедитесь, что время и затраты на это включены. Если исследование необходимого поставщика или стороннего продукта является частью проекта, определите это как риск, который необходимо снизить в случае, если подходящее решение не будет найдено, займет больше времени, чем ожидалось, или превысит бюджетные ассигнования.
  • Помните о нормативных требованиях. Не забудьте учесть все нормативные и законодательные акты, которые могут повлиять на проект.
  • Подробно опишите необходимые технологии. Включите подробную информацию об инструментах и технологиях, которые будут использоваться и применяться.
  • Запланируйте постоянную поддержку. Если ваш проект потребует постоянного обслуживания и поддержки после внедрения, укажите план поддержки, перечислите мероприятия и лиц, которые будут задействованы.
  • Оставьте время для документации. Помните, что документирование должно быть частью любого проекта. Необходимо включить мероприятия, отведя время на подготовку документации и учебных материалов.
  • Будьте гибкими. Будьте открыты для определения и изменения функциональных требований, но помните о том, что изменения могут повлиять на другие виды деятельности, временные рамки или сроки.

Ограничения документов бизнес-требований

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

  • Не всегда нужно знать, как что-то делается. Функциональные требования должны отвечать на вопросы «что» и «почему», но не «как». Хотя это различие может показаться тонким, знание того, как разработчик выполнит ту или иную задачу, выходит за рамки этих документов.
  • Не оставляйте вопросы без ответа. Документы бизнес-требований всегда должны отвечать на вопросы, а не задавать их. Если есть вопросы, которые нужно задать, или неизвестные, которые нужно исследовать, сделайте это во время создания документа, а затем включите в него результаты.
  • Включите всю предысторию и детали. Каждый документ бизнес-требований должен быть самостоятельным. Предположите, что все, кто его читает, понятия не имеют о том, что происходило в прошлых проектах. Если есть детали, которые необходимо включить для контекста, включите их, но убедитесь, что они уместны и необходимы.
  • Планируйте задержки. Хотя немногие документы по бизнес-требованиям включают раздел по снижению рисков, целесообразно найти способы определения областей, где сроки или деятельность могут быть нарушены и каким образом. Эмпирическим правилом является добавление 20-процентного буфера времени для управления неопределенностью, но корректируйте его по мере необходимости и необходимости.

Документация вдохновляет на командную работу

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

Оригинал статьи

«Управление проектами на основе PRINCE2»
Аккредитованный сертификационный учебный курс

Добавить комментарий

Ваш адрес email не будет опубликован.

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM