Чи знайома вам ситуація, коли довгоочікуваний продукт не виправдовує сподівань клієнтів? Або коли команда розробників витрачає занадто багато часу на уточнення вимог? Ці проблеми часто кореняться в недостатній чи неефективній взаємодії між бізнес-аналітиком (BA) та продакт-овнером (PO). Звісно, в теорії ролі BA та PO належать до різних методологій (Waterfall та Agile відповідно) й їх не має бути на одному проєкті за замовчуванням. Проте на практиці ми часто бачимо присутність і ВА і РО в одному проєкті. Або ж бачимо аналогічні обов’язки в інших ролях. Наприклад в SAFe (Scaled Agile Framework) замість пари РО та ВА ви знайдете пару РМ (Product Manager) та PO (Product Owner) з аналогічним розподілом ролей.
Ця стаття допоможе вам розібратися:
- Хто такий BA та PO?
- Які ключові відмінності та спільні риси притаманні ролям BA та PO?
А почнемо ми з основ, розглянувши детальніше кожну з цих ролей та їхнє місце в процесі розробки продукту.
Чому з ролями BA та PO не все так однозначно?
Ролі BA та PO часто сприймаються як взаємозамінні або тісно пов’язані. Дійсно, їхні обов’язки значною мірою перетинаються, і на практиці межі між ними можуть бути зовсім стертими. Однак кожна з цих ролей має свої унікальні фокуси та відповідальність.
Чому виникає плутанина? Виокремимо три причини:
- Перетинання завдань. Обидва фахівці займаються збором та аналізом вимог, взаємодією зі стейкхолдерами, створенням документації тощо.
- Різниця у підходах з розподілу обов’язків. У деяких організаціях PO виконує більшу частину роботи BA, а в інших – навпаки.
- Залежність від масштабу розробки. У невеликих командах одна людина може поєднувати обидві ролі, тоді як у масштабних проєктах ви можете зустріти обох спеціалістів.
Зазвичай PO фокусується на стратегічному баченні продукту, пріоритезації функціоналу, взаємодії з клієнтами та командою розробки, а BA заглиблюється в деталі, аналізує бізнес-процеси, збирає вимоги.
Кого шукають за кордоном?
Якщо ми порівняємо описи вакансій у рекрутингових агенціях 1 2 ролей PO та BA, то побачимо багато перетину в обов’язках цих двох позицій.
PO | BA |
---|---|
Співпрацювати з потенційними користувачами та клієнтами для розуміння й передбачення їхніх потреб та перекладу їх у вимоги до продукту. Визначати бачення продукту для команди та підтримувати його протягом усього процесу. Створювати дорожню карту відповідно до бачення. Управляти беклогом та пріоритезувати завдання на основі змінних вимог. Наглядати за усіма етапами створення продукту: від дизайну до розробки. Моніторити та давати оцінку прогресу на кожному етапі процесу. Співпрацювати з командою продукту та кінцевими користувачами для надання оновлень та звітів про стан. Брати участь у скрам нарадах. |
Збирати та аналізувати дані для розширення бізнесу. Визначати бізнес-можливості. Впливати на зацікавлені сторони для підтримки проєктів. Допомагати в управлінні проєктами. Координувати роботу команд. Тестувати бізнес-процеси та рекомендувати покращення. Перетворювати функції дорожньої карти на менші юзер-сторі. Писати чіткі бізнес-вимоги та документацію. Створювати звіти й візуалізації. Аналізувати проблеми та вузькі місця процесів для покращення. Комунікувати та валідувати вимоги з зацікавленими сторонами. Розробляти та підтримувати інструменти звітності. Співпрацювати з менеджерами продукту щодо планування дорожньої карти та оптимізації робочої сили. |
Отже, обидва фахівці визначають вимоги, аналізують ринок, виявляють проблеми та можливості, працюють з даними та впливають на розвиток продукту.
Однак у функціях PO частіше використовується термінологія, пов’язана з управлінням продуктом: беклог, спринти, дорожня карта; у BA – з бізнес-аналізом: вимоги, процеси, моделювання.
Чому виникають такі відмінності? Це пов’язано передусім з тим, що ці 2 ролі взяті з різних методологій. Роль бізнес аналітика описана у передбачуваних (Waterfall) методологіях, тоді коли роль Product Owner описана в Scrum. Тому при описі тієї чи іншої ролі й додаються терміни з відповідної методології. Тобто логічно, що РО буде відвідувати планування спрінта, daily stand-ups й інші скрам наради.
Хто що робить?
Зупинимось на ключових відповідальностях BA.
1. Формулювання вимог
Саме BA гарантує, що всі вимоги до проєкту чітко сформульовані, узгоджені та пріоритезовані. Саме він займається:
- Створенням чітких, повних і вичерпних вимог до системи. Вони охоплюють не лише основні функціональні вимоги, а й граничні умови, сценарії використання та інші важливі деталі.
- Організацією процесу узгодження вимог, що забезпечує, аби всі зацікавлені сторони підписали документи, що підтверджують їхню згоду з вимогами.
2. Управління змінами об’єму робіт
BA не просто фіксує зміни в об’ємі робіт, а й активно керує процесом адаптації команди до них. Спеціаліст проводить детальний аналіз кожної зміни, оцінюючи її вплив на інші аспекти проєкту (бюджет, терміни та якість).
Важливою частиною роботи BA в цьому контексті є комунікація. Він інформує всіх зацікавлених сторін про причини змін, їхній потенційний вплив та необхідні дії. Такий проактивний підхід допомагає управляти очікуваннями всіх зацікавлених сторін.
3. Пріоритезація вимог
Задача ВА впевнитись, що пріоритети до вимог проставлені, та затвердити їх з ключовими зацікавленими особами.
Чимало аналітиків використовують стандарт BABOK (Business Analysis Body of Knowledge). Він надає детальний опис знань і навичок, необхідних для успішної роботи BA. Однак BABOK не наділяє когось відповідальністю за прийняття рішень щодо ранжування вимог за значенням. Це зазвичай визначається конкретними процесами та політиками організації.
Обов’язки РО
PO відрізняється від BA кількома характеристиками.
Зміщення фокуса
На відміну від BA, який традиційно фокусується на зборі та детальному документуванні вимог користувачів, PO дивиться на продукт ширше. Він не просто фіксує, що необхідно зробити, а й глибоко розуміє бізнес цінність, які принесе виконання тієї чи іншої вимоги.
Постійна активна участь у процесі
PO не обмежується передачею вимог розробникам та відповідями на питання. Він є постійним учасником усього процесу розробки та тісно співпрацює з командою, допомагаючи:
- приймати обґрунтовані рішення;
- оцінювати результати роботи та оперативно приймати або не приймати зроблену роботу команди;
- вносити необхідні корективи в дорожню карту продукту.
Такий тісний контакт дозволяє PO забезпечити відповідність продукту потребам бізнесу та користувачів.
Тісний зв’язок з кінцевими користувачами
PO розуміє, як продукт буде розвиватися в майбутньому та як він вписується в загальну стратегію компанії. А також постійно перевіряє як ринок та кінцеві користувачі реагують на той чи інший функціонал й на основі такого зворотнього зв’язку оновлює беклог продукту.
Що у підсумку?
Докладно розглянувши ролі BA та PO, їхні взаємозв’язки та відмінності, ми з’ясували, що:
- Залежно від проєкту та компанії, обов’язки обох фахівців частково збігаються або доповнюють один одного.
- Через різне розуміння ролей та пріоритетів можуть виникати складності у комунікації між спеціалістами.
- Ефективна робота команди залежить від чіткого розуміння кожним членом своїх обов’язків та очікувань від інших.
Щоб глибше зануритися в тему бізнес-аналізу та управління продуктом, рекомендуємо пройти курс «Business Analysis Intensive Online» від спеціалістів E5. Ви отримаєте детальну інформацію про різні аспекти цих професій та навчитеся ефективно працювати в команді.