Конфлікти в ролях BA та PO, або антипатерни поведінки та їх вирішення
Не дивлячись на те, що в літературі ролі ВА та РО належить до різних світів, а точніше підходів до управління розробкою (Waterfall та Scrum відповідно), на практиці ви часто можете побачити на одному проєкті ці 2 ролі.
Чому важливо розрізняти ролі BA та PO? Чому деякі ситуації призводять до суперечок між цими ролями? Причина криється в наявності деструктивних шаблонів поведінки, так званих антипатернів, що виникають в процесі їх взаємодії. Їхнє розуміння слугуватиме кращому управлінню очікуваннями та ефективнішій координації зусиль в рамках проєкту.
Антипатерн 1. Недостатня комунікація
Один з найпоширеніших антипатернів, який виникає не лише у взаємодії між BA та PO, а в взаємодіях будь-яких інших ролей, – це недостатня або прихована комунікація, що проявляється як приховування (або просто неоприлюднення) інформації.
Як це виглядає на практиці? Наприклад, PO передає вимоги, але команда та бізнес-аналітик не до кінця розуміє, навіщо ці фічі потрібні і як вони вписуються в загальне бачення продукту чи реліз-план. Не надаються бізнес та фінансові цілі, заради яких передається в розробку та чи інша вимога. Просто зробіть й все.
Існує й інший варіант: члени команди спілкуються між собою, але не діляться інформацією, що веде до ситуації, коли кожен чує лише частину історії або трактує її по-своєму. В результаті відсутність єдиного джерела правди призводить до непорозумінь, які можуть бути помітними лише на етапі тестування або деплою на продакш. Тобто тоді, коли з’ясування розбіжностей стає критичним на шляху успіху продукту.
Антипатерн 2. Король гори
Виникає, коли в команді кожен намагається продемонструвати свою перевагу, що призводить до невиправданої конкуренції. Спеціалісти починають критикувати результати роботи один одного, часто без конструктивного підходу, що створює атмосферу недовіри.
До прикладу, BA представляє рішення, але PO його критикує не щоб зробити кращим, а щоб довести ВА, що він не правий, звертається до команди за додатковими підтвердженнями й залучає їх на свою сторону. Або навпаки – BA знецінює роль РО, постійно говорить фрази, що нема ніякого сенсу в роботі РО, оскільки її робить за нього ВА.
У такому випадку індивідуальні інтереси перемагають над потребами команди, що призводить до ігнорування важливих завдань. Основні зусилля та час людей йдуть на доведення неправоти протилежної сторони, а не на створення гарного продукту.
Антипатерн 3. Перетягування ковдри
Попередні антепатерни розглядали ситуації, де існують конфлікти або недостатня комунікація між двома сторонами. Третій шаблон зображує іншу крайність – коли в рамках великого продукту чи команди відповідальність зосереджена на одній особі. Ця людина намагається взяти на себе всі ролі та завдання – від аналізу ринку до технічних вимог, прицьому ігноруючи той факт, що її робочого часу не вистачить, щоб зробити все це якісно. В результаті якість роботи відчутно просідає, команда отримує “сирі” вимоги постійно.
Подібний підхід може бути виправданий в молодих командах з обмеженим бюджетом, в інших кейсах таке «супергеройство» призведе до вигорання і деградації якості роботи. Найкраще рішення – проаналізувати, в яких областях існують проблеми, і делегувати обов’язки або ж залучити додаткових фахівців для ефективнішого управління проєктом.
Як зазвичай взаємодіють BA та PO?
Роль BA та PO в сучасній розробці програмного забезпечення постійно еволюціонує. Існує кілька моделей їхньої взаємодії на практиці. Тоді ж як в теорії – ці ролі з різних метологій й не мають пеертинатись. У вас є або ВА або РО. Розгляньмо типові варіанти взаємодії ВА та РО.
| Варіант | Характеристика |
|---|---|
| Аутсорсинг | Передбачає чіткий розподіл обов’язків. BA відповідає за формулювання детальних вимог до продукту, збираючи інформацію у РО та інших представників замовника. PO, зі свого боку, представляє інтереси замовника, визначає пріоритети та приймає рішення щодо розвитку продукту. Використовується в аутсорсингових проєктах, де важливо забезпечити чітку структуру та формалізацію процесів. |
| Розподіл обов’язків | PO зосереджується на стратегічному баченні продукту, визначаючи його довгострокову мету та цільову аудиторію. BA, своєю чергою, деталізує вимоги, описує user stories та забезпечує ефективну комунікацію між командою розробки та PO. Ця модель дозволяє досягти глибшого пропрацювання вимог та гарантує плідну співпрацю з командою розробки. Однак існує ризик надмірної деталізації на ранніх етапах проєкту, що уповільнить процес. |
| Одна людина | У невеликих компаніях або на ранніх етапах розробки продукту часто використовується сценарій, в якій одна людина виконує функції як BA, так і PO. Це дозволяє швидко приймати рішення, адаптуватися до змін і знизити витрати на штат. Однак у процесі зростання проєкту одна людина може не впоратися з усіма завданнями, що призведе до перевантаження і зниження якості роботи. |
Як тоді спрацюватись?
Створення ефективної команди – це тривалий процес, який вимагає постійної уваги та зусиль. Завдяки дотриманню певних принципів можна значно прискорити цей процес.
Спільний вектор розвитку
Щоб люди працювали якісно, їм необхідне чітке розуміння спільної мети та бачення. Це не просто слова, а життєво важливий компас, який орієнтує кожного в загальному напрямку. Без цього розуміння виникають проблеми: від зниження мотивації до конфліктів та неефективного використання ресурсів. Критично для ВА та РО визначити спільні цілі (побудова успішного на ринку продукту) та зафіксувати їх.
Чіткі межі та очікування
Щоб уникнути непорозумінь та підвищити ефективність роботи, необхідно чітко визначити зони відповідальності ВА та РО.Як це зробити? Перший варіант – формальні або неформальні домовленості, які описують очікування від ролі BA чи PO. Другий – використання таких інструментів, як Definitions of Ready/Done, що допомагають встановити критерії готовності вимог та завдань та чітке розуміння хто буде відповідати за яку частину.
Дозвіл на екстра крок
Щоб підтримувати високий рівень мотивації та заохочувати ініціативність, варто дозволяти членам команди виходити за межі своїх прямих обов’язків. Наприклад, BA може проаналізувати користувацькі метрики, а PO взяти участь у технічних обговореннях.
Обговорення ідей, а не особистостей
Конструктивна критика та обговорення є невіднятною частиною будь-якого проєкту. Важливо пам’ятати, що ми розглядаємо ідеї, а не особисті якості колег. Висловлюючи свою думку, слід зосередитись на тому, як покращити проєкт, а не на тому, щоб образити чи принизити когось.
Зворотний зв’язок
Зворотний зв’язок – інструмент, який допомагає розвиватися усій команді. Якщо вас щось турбує у взаємодії з колегою, не варто накопичувати негатив. Відкрите і вчасне обговорення дозволяє розв’язати проблему на ранній стадії та запобігти подальшим непорозумінням. Однак пам’ятайте, що ми маємо донести конструктивний зворотній зв’язок, а не довести, що колега не правий. Інакше всі розмова перетвориться на сперечання заради сперечання й лише погіршить вашу взаємодію.
Що у підсумку?
Докладно розглянувши ролі BA та PO, їхні взаємозв’язки та відмінності, ми з’ясували, що:
- Залежно від проєкту та компанії, обов’язки обох фахівців частково збігаються або доповнюють один одного.
- Через різне розуміння ролей та пріоритетів можуть виникати складності у комунікації між спеціалістами.
- Ефективна робота команди залежить від чіткого розуміння кожним членом своїх обов’язків та очікувань від інших.
Щоб глибше зануритися в тему бізнес-аналізу та управління продуктом, рекомендуємо пройти курс «Business Analysis Intensive Online» від спеціалістів E5. Ви отримаєте детальну інформацію про різні аспекти цих професій та навчитеся ефективно працювати в команді.
Зростайте професійно з Е5!
