Стаття написана у співавторстві з Антоном Бабенком, Senior BA в SPD-Ukraine
Кожен IT-проєкт має свої особливості: рівень складності, кількість стейкхолдерів та їх компетентність, відкритість клієнта та інші фактори. Фаза дискавері потрібна для оцінки — чи компанія зможе виконати конкретний проєкт і вкластися в бюджет. Успішно проведений етап дискавері допомагає зрозуміти цілі продукту/рішення, отримати реалістичну оцінку та план реалізації, плюс — продати розробку.
У кожного BA своє уявлення про те, як мають виглядати артефакти на Discovery Phase. Вони можуть бути різними за формою та подачею, але головне — не формати та шаблони, а та інформація, яка в них буде закладена.
Три артефакти для бізнес-аналітика
Як у казці “Три горішки для Попелюшки” ці чарівні плоди призводять до happy end, так і артефакти зі списку нижче допомагають BA успішно обробити всю інформацію, отриману на Discovery Phase:
- Business Requirements Document.
- Use Case Diagram.
- Context Diagram.
Кожен артефакт полегшує роботу BA, допомагаючи ретельно опрацювати основні питання на дискавері-фазі.
Business Requirements Document
Business Requirements Document (BRD) — документ, в який ви вносите всю інформацію від клієнта: від бізнес-можливостей до бізнес-цілей і метрик успіху. Приклад структури BRD:
- Business Problem statement
- Business objectives
- Project scope
- Main project success/cancellation criteria
- Functionals and Non-Functional requirement
- Project costs
- Stakeholder list
- Project assumptions and constraints
- Project risks
Дискавері-фаза перш за все покликана допомогти зрозуміти: що необхідно бізнесу клієнта, що запропонувати як рішення та як це реалізувати. Тому рекомендую максимально повно заповнювати BRD і не соромитися ставити запитання замовнику.
Пам’ятайте, що клієнт не завжди розуміє, що насправді потрібно для його бізнесу, або може робити акценти на другорядних моментах. Завдання Business Analyst на фазі дискавері — «докопатися» до суті, і вже на базі цього розробити пропозицію замовнику щодо вирішення його проблеми або рекомендувати IT-компанії відмовитися від проєкту зовсім.
Use Case Diagram
Use Case Diagram (UCD) — це швидкий та наочний спосіб узагальнено представити технічні можливості майбутнього продукту. Завдяки цій діаграмі легко зрозуміти:
- Хто є потенційним користувачем вашого рішення.
- Які ролі, система прав та доступів потрібні.
- Які основні події будуть робити користувачі, що потрібно для цього.
У Use Case Diagram не обов’язково описувати найдрібніші деталі — головне охопити всі ключові use cases та ролі. На дискавері-фазі потрібно копати вшир, а не в глибину. На цьому етапі важливіше зібрати повну інформацію про весь проєкт, щоб виявити та оцінити якнайбільше потенційних ризиків, ніж досконало вивчити якусь одну область.
Це той випадок, коли краще зібрати 80% даних і розібратися в них на 20%, ніж навпаки. Інакше ви можете упустити ключових стейкхолдерів, необхідні функції та безліч інших речей. У результаті важлива інформація не буде врахована, що викличе помилки в оцінці проєкту і далі ланцюгової реакції.
Context Diagram
Context Diagram — це всі ваші потенційні інтеграції та дані, які потрібно аналізувати, перетворювати, мігрувати. У контекстну діаграму вписують усе, що оточує проєкт і може вплинути на кінцевий результат:
- потенційних користувачів;
- бізнес-процеси всередині компанії замовника;
- сторонні організації;
- особливості території розповсюдження IT-продукту;
- різні регуляції.
Контекстну діаграму можна робити на кількох рівнях: Business Context Diagram та System Context Diagram. У першому випадку в центр діаграми ми ставимо організацію/бізнес замовника, а по периметру основних контрагентів. Стрілки позначають інформацію, якою вони обмінюються з «центром».
На System Context Diagram у центрі буде не бізнес клієнта, а система, з якою ми працюємо. По периметру — інші системи, пристрої, установи, які так чи інакше взаємодіють чи повинні взаємодіяти з нашою. На стрілках позначаємо дані/інформацію, якою вони обмінюються.
Замість висновку
Кожен бізнес-аналітик може використовувати різні види та кількість артефактів, ідеального списку немає, але саме Business Requirements Document, Use Case Diagram та Context Diagram допомагають швидко та максимально чітко проаналізувати майбутній проєкт, адекватно оцінити всі ризики та у наочній формі зафіксувати отриману інформацію.
Тому, якби я опинився на безлюдному острові з проєктом у роботі і міг би вибрати лише три артефакти — ці були б фаворитами. Тільки спочатку, попросив би як бонус глосарій основних термінів, якими оперує клієнт і команда, щоб говорити із замовником однією мовою і тим самим полегшити роботу всім учасникам Discovery Phase.