Документ з бізнес-вимог (BRD) є відображенням основної ідеї проекту. Він описує цілі та завдання проекту і результати, які він призначений досягти.
Незалежно від галузі, в якій ви працюєте, вам потрібен міцний BRD, щоб керувати та узгоджувати всі дії в межах проекту. Без основного керівного документа робочий процес стає неорганізованим, і це може швидко зруйнувати ваші плани.
У цій статті буде пояснено, що таке документ з бізнес-вимог та надано кілька порад щодо написання послідовних та відповідних BRD.
Визначення документа з бізнес-вимог (BRD)
Документ з бізнес-вимог (BRD) є важливим для кожного бізнесу, оскільки він інтегрує три аспекти будь-якого програмного проекту чи бізнес-рішення. Він відповідає на три основні питання, які обов’язково виникають у ході реалізації проекту. А саме:
- Що? (яке програмне забезпечення створювати),
- Чому? (для чого його створювати),
- Як? (як це зробити).
Інакше кажучи, BRD містить філософію проекту. Говорячи мовою науки, це про:
- об’єкт бізнес-діяльності (що створювати),
- обґрунтування діяльності (чому цей проект слід реалізувати або чому компанії потрібно створювати нове програмне забезпечення, які проблеми вирішить це програмне забезпечення для користувачів та скільки прибутку воно принесе зацікавленим сторонам),
- метод (способи реалізації).
Документ – це опис майбутнього проекту. У галузі інженерії та будівництва його можна порівняти з документами передпроектного етапу (pre-FEED), які видаються перед початком великого EPC-проекту і містять змістовний опис його концепції.
Водночас, BRD є частиною загальної стратегії документації компанії. Він не повинен обмежуватися лише одним проектом. Як мінімум, він повинен бути пов’язаний з документацією, що стосується попередніх схожих проектів. Також він повинен відповідати основним політикам компанії, викладеним в інших документах. Завдяки таким зв’язкам ділова діяльність компанії виглядатиме логічною та послідовною.
До теми: BRD проти FRD
Ключові компоненти документа з бізнес-вимог
Структура вашого BRD не повинна бути жорсткою. Деякі елементи, наприклад, функціональні вимоги, є необов’язковими. Найкращі практики створення вимірюваних BRD включають наступні компоненти:
- Бізнес-цілі та завдання. Цей розділ містить інформацію про ситуацію на ринку, аналіз сильних та слабких сторін компанії, запропоноване рішення, очікуваний прибуток від інвестицій та інше.
- Обсяг проекту. Цей розділ здебільшого фокусується на результатах проекту або результатах, які отримають зацікавлені сторони після його реалізації. Він описує обсяг робіт, необхідних для досягнення цих цілей, і часто включає графік із зазначенням етапів і термінів виконання.
- Функціональні та нефункціональні вимоги. Цей розділ часто вважають необов’язковим. Деякі компанії формулюють функціональні вимоги в документі з вимог до продукту (Product Requirements Document, PRD). Він пишеться спеціально для команди розробників і містить інструкції про те, як повинен бути побудований продукт, які функції він повинен мати і як він повинен бути спроектований.
Інформація про «як» називається функціональними вимогами, оскільки вона містить опис того, як повинен працювати продукт (його функціональність). Нефункціональні вимоги більш загальні і стосуються загальних бізнес-вимог чи стратегії компанії (наприклад, чи планує компанія залишитися на старому ринку чи перейти на нові продукти).
- Припущення та залежності. Цей розділ більше схожий на прогноз. Він намагається передбачити, що відбудеться, якщо буде запущено новий програмний продукт, чи він буде відомий, чи відповідатиме очікуваним значенням ROI та інше.
- Критерії прийняття. Важливо, щоб критерії прийняття були сформульовані на початковому етапі. Формулювання критеріїв є частиною стратегічного мислення. Це схоже на те, як поставити мішень на стіну і перевірити, наскільки близькими до центру були удари
- Обмеження. Це різноманітні обмеження, які можуть утруднити або навіть зробити неможливим впровадження проекту. Це може бути все від обмежень бюджету до діяльності конкурентів або форс-мажорних подій.
- Ризики та стратегії мінімізації. Ризики можуть бути пов’язані з фінансовою сферою (ліквідність компанії на ринку), робочою силою (наявність висококваліфікованих співробітників, необхідних для створення програмного забезпечення), PR (інформаційне висвітлення продукту) та інше. Незалежно від того, якими є ризики, ви повинні розробити план їх мінімізації для найбільш вірогідних ситуацій.
З цим списком ви можете перейти до створення повного та ефективного документа з бізнес-вимог.
Створення документа з бізнес-вимог
Створення документа з бізнес-вимог зазвичай включає кілька етапів.
Збір інформації – це перший етап. Припустимо, ваша компанія планує запустити новий проект з геймдизайну на основі штучного інтелекту. Ви знаєте, що ця тема “в топі”, і хочете бути частиною цього тренду. Однак перед початком роботи вам потрібно провести масштабне дослідження ринкових тенденцій і специфічних для галузі питань, таких як мистецтво штучного інтелекту, нейронні мережі, як вони працюють і як їх можна використати в геймдизайні. Тільки після завершення фази дослідження ви зможете сформулювати основну ідею свого проекту. Це повинно бути чітко викладено у документі з бізнес-вимог. Наприклад:
Ідея полягає у створенні онлайн-середовища для геймдизайну, яке інтегрує нейронну мережу текст-зображення з інструментами для покращення (фіналізації) зображень, для подальшого використання у розробці гри.
Після завершення цього кроку можна переходити до наступного етапу процесу.
Зверніть увагу: 50 питань з співбесіди для бізнес-аналітиків (Частина 1)
Аналіз та визначення пріоритетів вимог є вирішальним. Вимоги можуть бути виведені з основної ідеї продукту. Виходячи з цієї ідеї, ваш проект потребуватиме інтеграції трьох елементів в єдину онлайн-платформу:
- нейронної мережі для перетворення тексту в зображення,
- інструментів для покращення зображення,
- інструментів для інтеграції загальних зображень у розробку гри.
Проте, ці пункти можуть здатися складними для читачів вашого документа з бізнес-вимог. Тому важливо пояснити їх простою мовою, використовуючи приклади та аналогії. Для пояснення ви можете написати наступне:
Наше нове онлайн-середовище для геймдизайну, засноване на мистецтві штучного інтелекту, буде схоже на Google Translate для художників. Художник формулюватиме ідею (запит) і отримуватиме зображення, згенероване нейронною мережею. Однак, як і переклад з GT, зображення, згенероване штучним інтелектом, може бути не ідеальним. Воно може мати недоліки, наприклад, неправильно намальовані руки або пальці. Ці недоліки потрібно виправляти. Саме тому наша платформа надає дизайнерам відповідні інструменти для покращення та вдосконалення зображень, створених штучним інтелектом, щоб користувачам не доводилося перемикатися між різними ресурсами або витрачати час на пошук інструментів.
Визначення критеріїв прийняття є наступним етапом розробки BRD. Критерії прийняття забезпечують узгодженість вимог у документі і допомагають перевірити ефективність виконаної роботи. Цю перевірку зазвичай здійснюють за допомогою набору метрик, які оцінюють ефективність реалізації проекту. Наприклад, метрики можуть визначати відсоток дефектів, що зникли (дефекти, виявлені користувачами після випуску продукту), щільність дефектів (1 дефект на 1000 рядків коду вважається «доброю» якістю), тривалість розгортання (тобто час, необхідний для випуску) та інші.
Структурування BRD – це наступний крок, який передбачає створення контенту, тобто фактично написання всього документа. У минулому це вимагало значного обсягу роботи від технічних письменників, оскільки BRD могли бути досить об’ємними. Крім того, пошук пов’язаних документів у сховищах корпоративної документації для посилань або повторного використання раніше створеного вмісту у новому BRD збільшував робоче навантаження письменника. Часто письменнику доводилося починати з нуля через неможливість знайти необхідну інформацію.
Процес перегляду та затвердження є останнім етапом створення вашого BRD
Висновок
Ви можете стверджувати, що проект може розпочатися без документа з бізнес-вимог (BRD). Ви також можете заперечувати, що комбінація Документу з вимог до ринку (MRD) та Документу з вимог до продукту (PRD) вистачає. Ці два документи визначають проект з точки зору кінцевого користувача та розробника. Але чи достатньо цього? Можливо, якщо політика вашої компанії є виключно альтруїстичною. Однак, якщо ви враховуєте не тільки користувачів і розробників, але й інші зацікавлені сторони, такі як ви (власник компанії) і акціонери, то вам знадобиться ще один документ, який детально описує відповідність проекту вашим бізнес-цілям і завданням. Документ бізнес-вимог пояснює, як проект вирішуватиме проблеми компанії та які переваги він надасть їй.
Успіхів!
Оригінальна стаття – What Is a Business Requirements Document від команди ClickHelp, переклад – Олександра Горлович, ревью – Іван Вільчавський. Оригінальні зображення зі статті.