Досить винаходити велосипед: як правильно побудувати процеси бізнес-аналізу — покроковий гайд

Від вдало побудованого процесу бізнес-аналізу на проєкті залежить вся подальша робота аналітиків та пов’язаних із ними команд. Багато хто винаходить велосипед там, де все давно перевірено іншими. У минулому я теж йшла «власним» шляхом і через це втрачала ефективність. Але коли стала дотримуватись чіткого сценарію, доволі швидко побачила позитивний результат.

У цій статті я розповім про методичне вибудовування процесів бізнес-аналізу. Спершу ця інформація може здатися занадто теоретичною. Але якщо зіставити її з реальними кейсами, то виявиться, що всі описані моменти можна легко застосовувати на практиці. Ці поради заощадять вам час і, сподіваюсь, спростять роботу.

Як виглядає процес бізнес-аналізу і коли варто його будувати

Будь-який процес — це сукупність взаємопов’язаних та взаємодіючих видів діяльності. На вході є базова інформація. На її основі виконується певна активність, а на виході з’являються результати цієї активності.

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

Розглянемо процес бізнес-аналізу детальніше:

• На вході маємо вимоги проєкту та його цілі — тобто, що нам потрібно зробити та навіщо.
• На основі цієї інформації формується бізнес-процес, і на нього безпосередньо впливають стейкхолдери.
• На виході отримуємо певні артефакти. Це висновки про те, як працювати на проєкті по кожному напрямку. Сюди відносяться плани комунікації зі стейкхолдерами, зміни вимог тощо.

Далі поговоримо про кожен вхідний пункт окремо.

Вимоги проєкту

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

До них відносяться:

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

Цілі щодо продуктивності BA-процесу

Одним із простих мірил оцінки бізнес-аналітиків є повернення до них тасків. Чим краще спеціалісти роблять свою роботу, тим рідше виникає потреба в повторному рев’ю. Щоб уникнути правок, варто розуміти основні цілі щодо продуктивності вашого бізнес-процесу, а саме:

• задоволеність стейкхолдерів;
• прогнозованість та повторюваність результатів;
• швидкий онбординг нових аналітиків;
• прозорість взаємодії для клієнта і команди.

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

Часто під стейкхолдерами мають на увазі лише замовників та розробників. Однак не лише вони впливають на побудову процесу бізнес-аналізу. На ілюстрації нижче можете побачити, як розподіляються всі види стейкхолдерів залежно від ступеня їхньої близькості до проєкту:

• Команда проєкту. Це люди, які безпосередньо займаються розробкою продукту. Сюди відносяться девелопери та всі ті, хто ухвалює рішення щодо проєкту в ході роботи над ним.
• Пов’язані підрозділи. До цієї категорії входять ті, чия робота зміниться після отримання продукту. Це можуть бути кінцеві користувачі та, наприклад, служба технічної підтримки.
• Організації або підприємства. Ця група фахівців може не стосуватися розробки і навіть не торкатися продукту, але взаємодіяти з попередньою категорією. Наприклад, це інвестори чи CTO компанії-замовника.
• Зовнішні стейкхолдери. Ці люди можуть не знати про продукт, але вони впливають на його роботу і розвиток. Наприклад, постачальники та законодавчі органи, які регулюють галузь.

Побудова процесу бізнес-аналізу — 5 основних кроків

Описані вище моменти ми отримуємо на вході в новий або вже активний проєкт. Після цього починається основна діяльність BA.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Коли ви намагаєтеся на словах пояснити «давайте робити так і так», ніколи це не працює.

Тому вкрай важливо візуалізувати свої ідеї щодо організації BA-процесу. Так ви зможете якнайкраще «продати» стейкхолдерам ваш підхід.

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

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

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

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

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

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

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

Виходи процесу бізнес-аналізу

Stakeholder Communication Plan

Цей документ важливий для подальшої роботи бізнес-аналітиків. У ньому ви докладно описуєте:

• Аналіз стейкхолдерів

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

• Правила взаємодії

Це розклад активностей, геолокація, переваги стейкхолдерів, стандарти ескалації. Про останнє скажу окремо. Уявіть, що основний для вас стейкхолдер захворів, пішов у відпустку або просто довго не відповідає. Це може зупинити всю вашу роботу. У такій ситуації план ескалації вкаже, до кого звертатися за вимогами чи апрувом. Наприклад, можете написати: «Якщо через 2 дні Чарльз не відповідає, BA пише листа Рroduct Owner».

• Потреби в комунікації

У цьому розділі описуєте, кому та яка інформація необхідна. Також тут варто вказати спосіб передачі інформації та рівень її деталізації. У моєму проєкті керівнику над Рroduct Owner достатньо було коротко написати в ClickUp суть нової фічі, а сам Рroduct Owner потребував детального опису майбутнього функціоналу.

Requirements Management Plan

Цей план є основним артефактом для бізнес-аналітика. Він поділяється на дві частини. Одна з них — статична і стосується властивостей та зберігання вимог. До неї входять:

• організація вимог;
• атрибути вимог;
• деталізація;
• трасування;
• перевикористання;
• доступ та зберігання.

Другий блок стосується управління вимогами. Він більш динамічний і включає:

• ухвалення рішень;
• управління змінами;
• пріоритезацію;
• затвердження.

У цій частині ви вказуєте, хто та як затверджує вимоги, як обробляються запити тощо. Можете описати текстом, хоча, як на мене, зручніше виглядатиме діаграма:

Оцінка ефективності процесу бізнес-аналізу

BA-процес не може бути «замороженим». Ви маєте постійно моніторити його та за необхідності вносити зміни.

Раджу пам’ятати наступне:

• кількісні метрики кращі за інші;
• зусилля зі збору метрик мають бути виправданими;
• метрики потребують інтерпретації;
• вимірювати треба процес, а не людей.

Що саме відстежувати та вимірювати залежить від конкретного проєкту. Але я для прикладу виокремлю основні категорії:

• Задоволеність стейкхолдерів

Для кожної групи зацікавлених осіб використовують свої методи оцінки задоволеності. Наприклад, для представників клієнта можна застосовувати техніки Customer Satisfaction Survey та Net Promotion Score. Розібратися із задоволеністю команд і бізнес-аналітиків допоможуть ретроспективи, Feedback 360, а також 1-2-1 із менеджером проєкту.

• Прогнозованість і повторюваність результатів

Визначте час створення артефактів певного розміру, кількість циклів рев’ю, кількість Change Request та горизонт беклогу. Наприклад, якщо 10 разів перевіряється одна й та сама фіча, то в процесі є проблеми. У такому разі може знадобитися додатковий крок для демо вимог із командою.

• Швидкий онбординг

Розрахуйте час входження нових бізнес-аналітиків до проєкту: від знайомства з ним до апруву першого артефакту. Також зважайте на кількість циклів рев’ю вимог через кожні кілька місяців.

• Прозорість взаємодії

Оцінка цієї категорії складається з кількості блокуючих питань у поточному спринті, часу простою при очікуванні відповіді та результатів перевірки Health Check.

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