Бізнес-аналітик як Proxy Product Owner в українському аутсорсі

💡 Усі статті, обговорення, новини для аналітиків — в одному місці. Приєднуйтесь до Analysts спільноти!

Я працюю бізнес-аналітикинею вже понад 9 років. Я працювала в аутсорсі, аутстафі та продуктових компаніях. У кожної з них був свій спосіб організації роботи над проєктами. Деякі використовували більш Waterfall-підхід у поєднанні з Agile-принципами, деякі просто застосовували Kanban без складних конфігурацій, інші — різні Agile-фреймворки, такі як SAFe, Scrum, Scrum of Scrums тощо. Цікаво, що як бізнес-аналітикиня я працювала в усіх цих різних налаштуваннях. Як так? Адже, як ми знаємо, в Agile немає ролі Business Analyst. Є лише Product Owner, Developers і Scrum Master. Тоді хто я?

Хто такий Proxy Product Owner в українському аутсорсі

Після певного дослідження та аналізу я можу впевнено сказати: я, як і багато інших бізнес-аналітиків в українському аутсорсі, часто виконую функцію Proxy Product Owner.

Proxy Product Owner знаходиться десь між Product Owner і командою розробки.

Для мене така модель досить проста, адже вона використовується в більшості аутсорс/аутстаф-проєктів в Україні.

Згідно з теорією Scrum, Product Owner відповідає за:

Максимізацію цінності продукту, що створюється в результаті роботи Scrum-команди.

Ефективне управління Product Backlog, що включає:

• Розробку та чітку комунікацію Product Goal;
• Створення та чітке формулювання елементів Product Backlog;
• Впорядкування елементів Product Backlog;
• Забезпечення прозорості, видимості та зрозумілості Product Backlog.

(Scrum Guide 2020)

Чому з’являється роль Proxy Product Owner

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

Через це багато компаній використовують бізнес-аналітиків як Proxy Product Owner і делегують їм частину обов’язків Product Owner.

Обмеження ролі Proxy Product Owner

Проте роль Proxy Product Owner має свої обмеження:

Повноваження щодо прийняття рішень: Навіть якщо Proxy Product Owner бере на себе значну частину обов’язків Product Owner, він не може приймати фінальні рішення. Це може спричиняти затримки, якщо Product Owner зайнятий.

Відповідальність за успіх продукту: Незважаючи на делегування багатьох обов’язків Proxy Product Owner, відповідальність за успіх продукту залишається за Product Owner. Саме він визначає продуктову стратегію та ухвалює ключові рішення, що впливають на напрям розвитку продукту. У такому випадку Proxy Product Owner більше виступає як фасилітатор або консультант.

Недостатнє знання домену: Proxy Product Owner (часто бізнес-аналітик) може не мати достатнього доменного досвіду, особливо в умовах аутсорсу або аутстафу. В аутсорсі люди часто переходять на новий проєкт після завершення попереднього, і новий проєкт може бути в зовсім іншій доменній області. Тому бізнес-аналітик у ролі Proxy Product Owner стикається з викликом швидкого вивчення домену, щоб ефективно виконувати свою роботу.

Чому така конфігурація існує, попри всі мінуси

Незважаючи на ці обмеження, така конфігурація команди є найпоширенішою в українському ІТ, і як компанії-підрядники, так і клієнтські компанії, здається, задоволені нею. Я була здивована дізнатися, що згідно з best practices Agile/Scrum це не вважається ідеальною моделлю, і компаніям рекомендується уникати ролі Proxy Product Owner або розглядати її як тимчасове рішення, поки фактичний Product Owner зайнятий. По суті, Proxy Product Owner не має повноважень приймати рішення, не несе повної відповідальності, не формує бачення продукту та не має доступу до бюджету. Вважається, що наявність Proxy Product Owner призводить до непорозумінь, довших процесів ухвалення рішень та зайвих взаємодій між командою розробки та реальним decision-maker’ом.

І все ж ця модель існує вже давно, і здається, ніхто не намагається її усунути або змінити.

Я почала замислюватися, чому? Хіба компанії не повинні максимально дотримуватися best practices?

Я поставила це питання Agile Coach. Якщо я працюю бізнес-аналітикинею в ролі Proxy Product Owner, і це не вважається правильним з точки зору best practices, то що мені робити?

Згідно з best practices, у Scrum-команді мають бути лише Product Owner, Developers і Scrum Master. Отже, бізнес-аналітики можуть або комунікувати з менеджментом і клієнтською компанією, щоб повністю взяти на себе роль Product Owner з усією відповідальністю та підзвітністю, або стати частиною команди розробки. Проте в такому випадку вони матимуть менший вплив на беклог, пріоритети та комунікацію зі стейкхолдерами.

Які є варіанти

Якщо ми говоримо про класичну західну ентерпрайз-організацію або продуктову компанію, я повністю погоджуюся з best practices. Але в ІТ-індустрії Східної Європи, де існує велика кількість аутсорсингових і аутстафінгових компаній, цей підхід може потребувати адаптації.

Disclaimer: Наступна частина — це лише моя особиста думка.

Сценарій 1

Наприклад, розглянемо перший підхід. Бізнес-аналітик у ролі Proxy Product Owner намагається перейти до повноцінної ролі Product Owner із повною відповідальністю та підзвітністю. Це може бути великим викликом для бізнес-аналітика. У більшості випадків клієнтська компанія не погодиться на це, і на це є причина.

Роль Product Owner є стратегічною та має значний вплив на дохід компанії, її зростання та успіх. Передача цієї ролі на аутсорс створює високі ризики для компанії. Клієнтська компанія може змінити підрядника або співробітник компанії-підрядника може звільнитися, залишивши клієнта без контролю над прийнятими рішеннями. Відсутність Product Owner і пошук нового може бути дорогим процесом. З точки зору клієнтської компанії безпечніше мати людину, яка виконує частину завдань Product Ownership на стороні підрядника, але при цьому залишати decision-maker’а у себе, щоб за потреби він міг втрутитися.

Іншою причиною можуть бути обмеження NDA (Non-Disclosure Agreement). Деяким компаніям не дозволено ділитися певною інформацією з третіми сторонами (наприклад, із підрядниками). У такому випадку Product Owner буде складно виконувати свою роботу без доступу до необхідної інформації.

Сценарій 2

Другий сценарій, у якому бізнес-аналітик є частиною команди розробки, відрізняється. У такій моделі бізнес-аналітики тісно працюють із командою та глибоко розуміють процес розробки й технології. Але й тут є обмеження. Може виникати брак розуміння бізнесу та стратегічного бачення. Доступ до стейкхолдерів може бути обмеженим, і якщо Product Owner зайнятий, бізнес-аналітик може залишатися в очікуванні відповідей. У такій ситуації бізнес-аналітику складно напряму працювати зі стейкхолдерами через брак повноважень та авторитету. Повне право приймати рішення та встановлювати пріоритети зазвичай залишається за Product Owner. Іноді в такій конфігурації бізнес-аналітик може опинитися в ролі секретаря або протоколіста Product Owner.

Тому моя особиста думка полягає в тому, що модель із Proxy Product Owner є «золотою серединою» для бізнес-аналітиків і компаній. Вона забезпечує взаємодію з бізнесом, стейкхолдерами та розробниками. Крім того, Product Owner може наділити Proxy Product Owner повноваженнями приймати рішення в окремих сферах, що дозволяє працювати більш автономно та зменшує залежність від Product Owner у процесі ухвалення рішень. Бізнес-аналітики мають сильні навички роботи з вимогами, змінами та різними системами. Вони можуть помітити проблеми, які були пропущені, або виявити залежності з іншими командами. Або використати BA-техніки для вирішення різних проблем і створення рішень. Водночас комунікація з клієнтом, стратегічне планування та фінальні рішення залишаються за Product Owner, що допомагає клієнтській компанії керувати ризиками та залишатися в безпечній зоні.

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

А як ви думаєте? Чи має це сенс у вашому випадку? Поділіться своїм досвідом!