Теорія побудови процесів бізнес-аналізу давно описана. Але як перенести ці знання у практичну площину? Досвідом ділиться Анна-Марія Чміль, Business Analyst у NIX. 

Для наочності у цьому матеріалі є посилання на реальний проєкт експертки. Цей кейс стосується модернізації сайту для фрилансерів, над яким працювало кілька команд. Тож гайда підкріпляти теоретичні знання BA практикою. 

1. Визначення очікувань

Домовимося одразу: йдеться про очікування не до продукту, а саме до процесу. На старті треба розуміти, як ми будемо спілкуватися, описувати та затверджувати зміни. Для цього визначте:

• Роль бізнес-аналітиків

Першочергове завдання — зрозуміти бачення стейкхолдерами завдань BA. У моєму проєкті було троє бізнес-аналітиків. Наша команда займалася фронтендом, тому я описувала лише цю частину продукту. Зовнішня команда займалася бекендом, відповідно їх BA описував бек. Аналітик на боці клієнта писав вимоги для нас обох.

• Очікування щодо документації

Необхідно з’ясувати, де фіксувати вимоги, у якому форматі та з якою структурою. У нас замовник хотів збирати вимоги у ClickUp, але цей інструмент не підійшов. Програма хороша для нотаток, але писати вимоги за звичними стандартами в ній незручно. Шукаючи оптимальне рішення, ми зі стейкхолдерами порівняли їхні та наші темплейти. Вони виявилися схожими, відмінності були лише в назвах та додаткових секціях. Я уточнювала необхідність буквально кожної деталі темплейту. В результаті ми визначили перелік потрібних документів та їх формат. У ClickUp ми залишили невелику частину із пріоритезацією, оскільки там є тікети. Основні вимоги вирішили писати у Confluence на стороні третьої команди.

• Очікування щодо комунікації

Бізнес-аналітикам важливо розібратися, з ким і що вони мають обговорювати. Мені потрібно було вести комунікацію з обома аналітиками та з Product Owner.

2. Визначення результатів діяльності

Після того, як ви з’ясували очікування стейкхолдерів, визначте бажані результати роботи бізнес-аналітиків. Ідеться про конкретні артефакти, формати та шаблони. До них належать:

• Вимоги — бізнесові та (не)функціональні. 
• Road Map — графічний огляд цілей та результатів проєкту, представлених на часовій шкалі; має бути простим і зрозумілим.
• Визначення пріоритетів — хто та як визначає пріоритети й згідно чого.
• Release Notes — це може бути написання реліз-ноутсів за певним форматом, затвердженим клієнтом.
• Demo Notes — тут можна вказувати, як проходять ваші демо, хто їх проводить, що має бути зафіксовано після зустрічей; варто прописати, чи очікуєте ви на зауваження одразу після демо або під час обговорення.

3. Визначення типів сесій із командою та клієнтом

Вони поділяються на дві групи:

• сесії, які проводять бізнес-аналітики: інформаційні зустрічі, грумінги тощо;
• сесії, в яких аналітики мають брати участь: планінг, демо, спринт рев’ю тощо.

На цьому етапі проговоріть технічні деталі проведення заходів. Як часто вони відбуватимуться, у якому порядку, на якій платформі проходитимуть онлайн-зустрічі.

4. Презентація підходу

Коли ви намагаєтеся на словах пояснити «робімо так і так», це ніколи не працює. Щоб  якнайкраще «продати» стейкхолдерам ваш підхід, візуалізуйте свої ідеї щодо організації BA-процесу. Іншими словами, підготуйте презентацію.

Існує багато варіантів оформлення презентації. Наприклад, у своєму проєкті я зробила невеликий покроковий опис. Одна з його частин наведена на ілюстрації.

При отриманні запиту ми в першу чергу з’ясовуємо, чи торкається він поточного бекенду. Якщо так, то ці зміни описує Ксенія, аналітикиня із зовнішньої команди. Якщо відповідь «ні», тоді їх описую я.

Також у своїй презентації я показала ролі всіх аналітиків. Спочатку Рroduct Owner вважав, що вимог від Чарльза, BA на боці замовника, достатньо для старту розробки. Але ні. На схемі я розмежувала сферу відповідальності усіх фахівців. Чарльз визначає бізнес- та юзер-вимоги, а ми з Ксенією — системні.

 

Мені важливо було показати процес обробки створених Чарльзом вимог. Вони не могли йти одразу до розробників. Спочатку їх обробляють бізнес-аналітики. При цьому у процесі задіяний UX/UI-експерт, який робив на основі підготовлених вимог мокапи для оновленого сайту.

 

Ці схеми допомогли нам зі стейкхолдерами затвердити спільні очікування щодо організації роботи, розподілу обов’язків, форматів артефактів та мітингів.

Пам’ятайте: як би чудово ви не розібрали процес, замовнику він може не підійти. Саме для цього потрібно разом обговорити всі деталі запропонованих вами схем співпраці. Якщо стейкхолдери щось відкинуть, матеріали доведеться змінити. Тому поставтеся до «продажної» презентації як до драфту. Спочатку затверджуєте його і тільки потім переходите до формалізації процесу бізнес-аналітики.

5. Формалізація

Фінішний етап — підсумовуємо всі напрацювання. В ідеалі рекомендую зробити для висновків окрему сторінку на Confluence. Там ви зможете описати процес спілкування у вашому проєкті, які у кого ролі та обов’язки, як відбувається затвердження змін тощо. Це буде прозоро для вас, команди та клієнта. Наполегливо раджу формалізувати та затвердити такий документ з усіма учасниками процесу. Апрув від клієнта позбавить вас можливих непорозумінь у майбутньому.

Описана схема побудови BA-процесу допоможе значно підвищити продуктивність команди. Ви зможете уникнути багатьох спірних питань під час спілкування з колегами та замовником. Звісно, цей сценарій ви можете оптимізувати під особливості вашого проєкту. Тим самим зробивши свою роботу більш комфортною.