Як будувати BA-процеси - Частина 1: Основи
- Юлія Тимошенко
- 15 лип.
- Читати 7 хв
Практичні уроки з реальних проєктів - без перетворення аналізу на бюрократію
Вступ
Бізнес-аналітики часто опиняються в ситуаціях, коли від них очікують не лише виконання аналізу, а й визначення того, як саме цей аналіз має відбуватися.
Зазвичай це трапляється з двох причин:
· На проєкті раніше не було BA взагалі - і вимоги готувалися неформально продакт-овнером, проєктними менеджерами, розробниками або бізнес-стейкхолдерами.
· Певний BA-процес може існувати, але він більше не працює: занадто нечіткий, занадто складний, фрагментований або просто відірваний від реальності.
В обох ситуаціях симптоми зазвичай схожі: незрозумілий опис тікетів, приховані залежності, відкладені рішення, розповзання скоупу та купа змарнованого часу на уточнення. Команди часто намагаються вирішити ці проблеми, додаючи ще більшу кількість документації, але сама документація рідко “лікує” справжню причину. Якщо процеси комунікації, валідації, пріоритизації та обробки змін слабкі, то навіть найкрасивіше написані вимоги не врятують делівері.
Мені доводилося будувати або перебудовувати BA-процеси в дуже різних середовищах: мультивендорних сетапах, кросплатформних продуктових командах, а також на проєктах, де аналіз існував лише на етапі передпроєктного аналізу (discovery), а потім зникав саме в той момент, коли команда його найбільше потребувала. Контексти були різні, але висновок завжди той самий:
Хороший BA-процес має робити роботу команди простішою, а не просто формалізувати її.
Ця стаття - про те, як побудувати BA-процеси практично: що варто включати, які типові патерни існують, як адаптувати їх до різних моделей поставки (delivery) та що робити, якщо ви хочете, щоб процес був корисним, а не теоретичним.
📖 Структура статті:
Це Частина 1 із двох. Частина 1 охоплює основи - що означають BA-процеси, чому їх часто потрібно будувати з нуля, які бувають патерни і що має входити до процесу. Частина 2 присвячена тому, як їх насправді будувати, як адаптувати наявний процес, практичним порадам і типовим помилкам.
Що насправді означають BA-процеси
Коли люди говорять про BA-процеси, вони часто зводять їх до стандартів документування. Насправді, BA-процеси значно ширші. Вони визначають, як формується розуміння бізнес-потреб, як воно уточнюється, перетворюється на готові границі проєкту (scope) і як керувати ними протягом усього процесу реалізації.
На практиці BA-процеси зазвичай включають:
● розуміння бізнес-проблеми або можливості;
● ідентифікацію стейкхолдерів;
● виявлення вимог;
● аналіз і структурування інформації;
● документування вимог у правильному форматі;
● валідацію розуміння;
● підтримку пріоритизації;
● допомогу команді під час реалізації;
● управління змінами у вимогах;
● підтримку видимості рішень і залежностей.
Ця відмінність важлива, тому що проблема багатьох проєктів не в тому, що "немає вимог". Проблема в тому, що немає послідовного шляху від запиту до реалізації.
Наприклад, на одному з моїх проєктів в комунальній сфері (utilities) команда складалася з мобільного, веб-, бекенд- та інтеграційного напрямків (streams) . Ззовні здавалося, що вимоги існують, бо є тікети з описом змін. Насправді ж продакт-овнер з боку клієнта часто створював тікети з дуже обмеженими деталями, фронтенд-робота залежала від бекенд-ендпоінтів, які не були готові заздалегідь, а ще зовнішня дизайн-команда готувала дизайни, які часто були складні в реалізації і не обговорювалися з розробниками. Тобто, проблема була не у відсутності активності. Проблема була у відсутності аналітичного процесу, який міг би координувати роботу команди розробки на ранніх етапах.
І це важливо:
BA-процес - це не про "записати всі вимоги". Це про створення системи, яка дозволяє команді розуміти, узгоджувати й постачати продукт.
Чому BA-процеси часто доводиться будувати з нуля
Є кілька типових ситуацій, коли побудова BA-процесів з нуля стає необхідністю.
Перша - коли раніше не було виділеної ролі BA. У таких випадках аналітична робота зазвичай розподілена між кількома людьми. Продакт-овнери створюють тікети, PM'и стежать за границями проєкту, розробники з'ясовують бізнес-правила напряму, а стейкхолдери діляться очікуваннями на зустрічах. Деякий час це може працювати - особливо в невеликих командах, на початкових етапах, де швидкий результат пріоритетніше. Але, при появі більшої кількості залежностей, приховані прогалини починають вилазити назовні, як гриби після дощу.
Друга типова ситуація - коли BA-процеси існують, але вони неефективні. На папері вони можуть виглядати структуровано, але насправді команди їх обходять, бо вони занадто складні, повільні або просто непристосовані до реальних умов.
Процес, якого люди уникають, говорить сам за себе.
Третій тригер - збільшення складності. Більше систем, більше команд, більше вендорів, більше залежностей, більше стейкхолдерів - усе це підвищує ціну невизначеності.
Я дуже чітко бачила це у великому мультивендорному середовищі на проєкті в сфері подорожей. Кілька виділених команд працювали над взаємопов’язаними частинами платформи; було задіяно кілька BA, проте не було чітко виділеної лідерської ролі або принаймні чіткого розділення обов’язків. Однією з ключових проблем було те, що навіть єдиного розуміння поточного стану між командами не було. Дуже важко покращити процес чи визначити майбутні зміни, коли різні люди мають різне бачення того, як усе працює сьогодні. У тій ситуації побудова BA-процесу означала спершу відновити видимість: розподілити відповідальність BA-ків за підсистеми, налагодити регулярний обмін знаннями між аналітиками й попрацювати з бізнес-стейкхолдерами над роз’ясненням, а в подальшому - документуванням поточних процесів. Лише після цього, коли пазл склався, обговорення майбутнього стану стали продуктивними.
Саме тому BA-процеси часто доводиться перебудовувати, а не просто будувати. Проєкти еволюціонують, і початковий спосіб роботи може перестати відповідати поточній реальності.
Базові патерни BA-процесів
Єдиного універсального BA-процесу не існує, але більшість проєктів іде за одним із трьох патернів: лінійним, ітеративним або гібридним:
Лінійний патерн рухається від запиту до аналізу, документації, валідації й доставки послідовно. Він корисний там, де важливі контроль, узгодження чи координація з фіксованим скоупом.
Ітеративний патерн більш типовий для agile команд, де вимоги поступово деталізуються й уточнюються через повторювані цикли обговорень, опрацювання, валідації й делівері.
Гібридний патерн поєднує обидва. З мого досвіду, це найреалістичніший підхід для багатьох команд, особливо коли задіяні кілька сторін. Тут зазвичай потрібне чітке попереднє узгодження скоупу, залежностей, розподілу обов’язків, але при цьому є простір для змін деталізованих вимог і гнучкість процесів.
Згаданий вище проєкт у сфері utilities - гарний приклад. Команда не могла покладатися тільки на agile-флоу в чистому вигляді, бо було занадто багато кросстрімових залежностей: мобільний, веб, бекенд, API-інтеграції та зовнішня дизайн-команда. Водночас складна модель документування сповільнила б команду ще більше. Що там спрацювало, так це гібридний сетап: структуровані вимоги в Confluence, лаконічні задачі в Jira, з посиланням на детальні вимоги, і кілька типів рефайнмент-сесій, залежно від мети. Внутрішні рефайнменти використовувалися для раннього виявлення залежностей і технічних блокерів. Ко-рефайнменти допомагали узгодити інтеграційні питання. Сесії з дизайн-командою допомагали пересвідчитись, що є технічна можливість реалізувати запропоновані дизайни і внести потрібні правки до початку розробки.
Урок простий:
Структура процесу має відображати реальні ризики проєкту. Там, де залежності складні, комунікаційні точки дотику важливіші за ідеальні шаблони.
Що має включати BA-процес
Якщо ви будуєте BA-процес, корисно думати не в категоріях "які документи створити", а в категоріях "які проблеми розв'язати". У більшості випадків робочий BA-процес має охоплювати щонайменше такі сфери.
1. Запит (intake)
Команді потрібно розуміти, як з'являються нові запити на зміни та яка мінімальна інформація потрібна перед початком аналізу. Якщо запити з’являються хаотично, то решта процесу теж буде хаотичною.
У деяких командах навіть простий шаблон запиту може значно поліпшити якість. Наприклад:
● що потрібно;
● навіщо це потрібно;
● від кого запит;
● яку проблему це розв'язує;
● на які системи чи команди це впливає.
Ця інформація не має бути просто частиною формального процесу, вона потрібна для осмисленого аналізу.
2. Ідентифікація стейкхолдерів
Один із найшвидших способів отримати зайву роботу для всієї команди - це валідувати вимоги з неправильними людьми або лише з одним типом стейкхолдерів.
Це особливо важливо в мультикомандних чи мультивендорних середовищах. У згаданому проєкті в сфері подорожей розподіл відповідальностей за підсистемами був не просто організаційним рішенням. Він був необхідним, щоб залучення стейкхолдерів стало керованим. Без чіткого розподілу обов’язків аналітики легко дублюють роботу, пропускають залежності або роблять припущення через брак інформації.
3. Виявлення та уточнення вимог (elicitation)
Конкретні методи виявлення залежать від контексту: інтерв'ю, воркшопи, спостереження, аналіз документів, перегляд тікетів, аналіз даних або проходження процесів. Але мета завжди одна - зібрати достатньо інформації, щоб зменшити невизначеність до моменту, коли команда почне втілювати в життя свої припущення.
На проєкті, пов’язаному зі спортивним рітейлом, до якого я долучилася на пізній стадії, однією з найбільших проблем було те, що BA-активність фактично припинилася після discovery. PM намагався самотужки керувати скоупом і запитами, але був перевантажений, і частина запитів просто не перетворювалася на задачі. Навіть коли тікети вже існували, їм бракувало достатньої деталізації, тож команда витрачала забагато часу на постійні уточнення. На момент мого долучення до проєкту, клієнт уже був незадоволений співпрацею, а реліз-таймлайн був далеко від попередніх очікувань.
У цій ситуації перебудова BA-процесу не вимагала нічого інноваційного. Навпаки - потрібно було відновити базові, але необхідні практики, які пропустили: повноцінні refinement-сесії, пріоритизація вимог, оцінка трудомісткості задач і чітка пріоритизація дефектів.
Іноді покращення процесів - це не про винайдення нового. Це про повернення практик, які мали бути там від самого початку.
4. Аналіз і структурування
Необроблені вхідні дані від стейкхолдерів рідко бувають повними і несуперечливим. Гарний BA-процес має визначати, як інформація структурується, ставиться під сумнів, декомпозується й валідується.
Це може включати:
● уточнення бізнес-правил;
● виявлення відсутньої інформації;
● виявлення суперечностей;
● співставлення залежностей;
● моделювання поточних і майбутніх процесів;
● декомпозицію скоупу на керовані частини.
На проєкті у сфері подорожей відтворення поточних бізнес-процесів разом із бізнес-стейкхолдерами стало одним із найцінніших кроків. Воно дало команді спільне розуміння того, як усе працює зараз, які проблеми існують і що саме потребує покращення. Без цього розуміння поточного стану обговорення покращень залишилося б абстрактним.
5. Документація
Документація повинна бути достатньою, корисною і адаптованою до моделі роботи команди.
Проєкт у сфері utilities навчив мене, що проблема часто не в тому, що документації немає, а в тому, що вона фрагментована або відірвана від реальності. Як виявилось, там спрацював простий, але дисциплінуючий підхід:
● детальні вимоги в Confluence;
● стислі описи задач у Jira;
● чіткі посилання між тікетами Jira та відповідними сторінками вимог.
Це дозволило мати прості описи задач (Jira) зі збереженням контексту в централізованому місці (Confluence) . Також, зрозумілий мапінг прибрав необхідність дублювання інформації в тікетах.
Точний набір артефактів може варіюватися, але типові елементи включають:
● короткий опис бізнес-потреби;
● сторінки з вимогами;
● user stories;
● критерії приймання (acceptance criteria);
● діаграми процесів;
● логи рішень;
● залежності.
6. Валідація та пріоритизація
BA-процес має визначати, як підтверджується розуміння і як узгоджуються пріоритети. Інакше скоуп перетворюється на суміш припущень, заяв про "це терміново" та неофіційних обіцянок.
На рітейл-проєкті з відкладеним релізом пріоритизація скоупу стала одним із інструментів, що допоміг покращити ситуацію. Коли все потрібно “на вчора”, то стає очевидним, що не кожен запит вже однаково важливий. Адекватна пріоритизація допомогла команді зосередитися на тому, що справді мало значення для релізу.
7. Делівері та обробка змін
Аналіз не повинен зникати, щойно починається імплементація. Команді все одно потрібні постійні уточнення, підтримка під час refinement-сесій та структурована обробка змін у скоупі.
Це особливо важливо там, де між стрімами є залежності. На проєкті utilities внутрішні refinement сесії були корисні не лише для уточнення вимог, а й для виявлення того, де фронтенд можна розблокувати через моки бекенд-ендпоінтів, поки бекенд ще в розробці. І це гарне нагадування: BA-процес - це не лише про документування очікуваної функціональності. Це також про налагодження комунікації, яка дозволяє команді продовжувати рух до мети.
🔗 Продовження у Частині 2
Тепер ви розумієте, що таке BA-процеси, чому їх часто потрібно перебудовувати, які патерни варто розглянути та які елементи мають бути туди включені.
У Частині 2 ми переходимо від теорії до практики:
● Як насправді побудувати BA-процес з нуля
● Як оновити або адаптувати наявний BA-процес
● Практичні поради, що роблять процес робочим
● Типові помилки, яких варто уникати
● Фінальні висновки та порівняння слабкого та гарного BA-процесів
👉 Продовжуйте читати: "Як побудувати BA-процеси з нуля - Частина 2: Побудова, адаптація та підтримка процесу"
Новини та статті з бізнес-аналізу:
