Ролі у SCRUM: Епізод І. Схождення Product Owner’а

URL copied!

Categories: DevelopmentAutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

Автор: Олександра Скібіна, Project Manager, Kharkiv Agile Practice Head, Consultant, GlobalLogic Ukraine

Автор: Андрій Кульшан, Business Analyst, Product Owner, Consultant, GlobalLogic Ukraine

У цій колонці ми розглянемо в цілому структуру команди в Agile, ролі Product Owner (далі – PO) і Business Analyst (далі – бізнес-аналітик). Ми – це Олександра Скібіна – менеджер, лідер Agile-практик та Андрій Кульшан, бізнес-аналітик і Product Owner.

Наша історія побудови Agile почалася ще з 2012 року. За цей час ми пройшли довгий шлях по Далекій-Далекій Галактиці. Матеріал об’ємний, розповісти хочеться багато про що, тож ми прийняли рішення розбити публікацію на два епізоди. Зараз перед вами Епізод І.

Огляд Agile команди

Empire

Всім відома сага “Зоряні Війни”. Для зразка пропоную взяти команду імперських інженерів, штурмовиків і офіцерів, які є на малюнку вище. Чому? На наш погляд, саме ці хлопці проактивно діють згідно з принципами Agile: інженери ітеративно будують “Зірку Смерті”, штурмовики борються з повстанцями, а офіцери швидко реагують на зміни вимог від Імператора (він же стейкхолдер), які до них доносить Дарт Вейдер (він же Product Owner). А хто такий Вейдер поменше? Це – Business Analyst! Розглянемо, хто вони такі.

Головна відмінність: Business Analyst – це професія, а Product Owner – роль у Scrum. PO може бути хто завгодно: власники бізнесу, тестувальники та бізнес-аналітики. Product Owner відповідає за стратегічний напрямок продукту, бізнес-аналітик – за тактичне. На стику цих областей вони перетинаються. Не завжди зрозуміло, хто повинен розписувати бізнес-кейси, збирати первинні вимоги, комунікувати їх в команді. Особливо в умовах аутсорс-продуктів, коли ролі “не те, чим здаються”.
Розберемо докладніше кожну роль.

Product Owner

Product Owner – це людина, яка виступає представником клієнта. Він же представляє результати роботи команди. Як видно з назви, зона відповідальності цього фахівця – кінцевий продукт, це містить:

Управління backlog – списком завдань з різним пріоритетом. Product Owner вирішує, що піде в беклог, а що – ні, пріоритети завдань, і цінність, яку їх рішення принесе бізнесу.
Визначення MVP, тобто minimum viable product. Частина продукту, яка з мінімальним набором функцій може бути надана клієнтам і кінцевим користувачам в найкоротший термін.
Участь в розробці. Відповідає на питання команди та бере участь у всіх Scrum Events. Це як щоденні мітинги, так і так званий “backlog refinement”, коли PO описує команді завдання і бізнес-кейси, надає інформацію для якісної оцінки й збирає фідбек про обмеження системи.
Демо для стейкхолдерів в кінці спринту, де в деталях описує функціональність і відповідність бізнес-вимогам.
Навчання кінцевих користувачів.
Написання документації.
Каже “Ні”. Це найголовніше. Product owner збирає вимоги зі стейкхолдерів, всередині команди. Найчастіше, завдань і ідей більше, ніж команда може виконати в реалістичні терміни. Важливо не просто відкладати, але і повністю відкидати деякі ідеї. PO повинен враховувати потреби бізнесу, бажання користувачів, метрики, пріоритети різних груп, завантаженість і спеціалізації команд, ринок, тренди і багато всього іншого. Можна сказати, що це мало не центральне завдання Product Owner – ґрунтуючись на досвіді та знаннях відбирати ті ідеї, що приведуть проєкт до успіху. Деякі приймають рішення інтуїтивно, але навіть в цьому випадку потрібно вміти пояснити своє “ні” всім зацікавленим сторонам.

Business Analyst

Як уже писалося вище, BA на Scrum проєктах допомагають Product owner деталізувати вимоги. На Scrum-проектах бізнес-аналітик може бути як частиною команди, так і самостійною одиницею, працюючи відразу з декількома командами, описуючи вимоги для різних модулів або підпроєктів.

Зрозуміло, одним менеджментом вимог роль Business Analyst не обмежується, він може точно так само спілкуватися як зі стейкхолдерами, так і з користувачами, проводити аналіз ринку, складати гіпотези, але, в умовах аутсорс, це не завжди можливо. А як можливо? З досвіду, я можу виділити кілька конфігурацій взаємодії бізнес-аналітика і PO і поділах їх обов’язків.

Завдяки цим конфігураціям можна зрозуміти – де ми знаходимося, куди нам далі рухатися і як ефективніше побудувати взаємодію з клієнтом. Розгляньмо кожну:

BA-PO- Client (Product Group)	Перша конфігурація ідеальна. У нас є Business analyst і Product owner, і у нас є клієнт (Product Group). Якщо PO ще і є частиною цієї Product групи, тобто може приймати рішення, впливати на обсяг завдань, то тут все прекрасно. Business analyst – деталізує вимоги, Product owner – займається стратегічним плануванням, говорить всім “ні”. Клієнт щасливий і задоволений, що у нас така система, що самоорганізується команда. При цьому ми вже не просто аутсорс компанія, але й виконуємо послуги консалтингу. При такій конфігурації можна в майбутньому пропонувати клієнтові повний, автономний цикл розробки – від ідеї до реалізації.
BA/PPO-Client	Це добре для початку проєкту, коли у нас ще немає довіри з боку замовника. Тут клієнт спускає зверху “епіки” – чітко прописані бізнес-вимоги, у нього вже є бачення всіх етапів проєкту (roadmap) і список вимог (backlog) для кожної команди. Бізнес-аналітик, який виступає ще і як Proxy Product owner, просто розподіляє ці вимоги та стежить за їх оцінкою й виконанням командою. Така модель роботи, через час і при добрих відносинах може перерости в перший варіант, з більшою свободою прийняття рішень.
BA-PPO-Client	Мабуть, найменш ефективна конфігурація. Розтягується ланцюжок і прийняття рішень й перевірки вимог. Грубо кажучи, РРО майже ні за що не відповідає, а бізнес-аналітик не знає, що конкретно робити, чи можна звертатися безпосередньо до клієнта, або навіщо йому потрібен РРО. Тому – намагайтеся уникати цього.
BA-Client	У такій схемі взаємодії готові вимоги приходять від Product групи клієнта, а з нашого боку бізнес-аналітик тільки допомагає опрацьовувати локальні функціонал, постійно стверджуючи кожну зміну. Така модель зустрічається, коли майже немає довіри команді з боку замовника.
PO-Client	Є клієнт, є Product група, є scrum команди й у кожної команди Product Owner. PO отримує від Product group ініціативу, опрацьовує бізнес-кейси, вимоги, і доносить їх до команди. При великій свободі прийняття рішень як PO, так і командою, в цій схемі немає аналітика, тому PO та команда повинні працювати спільно над завданнями, які зазвичай виконує аналітик. Не всі команд раді перспективам писати описувати user story і use cases, тому впровадження подібної схеми зустрічає певний опір. Часто потрібно перехідний період від BA – PO – Client, але при успішній трансформації підвищується ефективність всієї команди, якість розробки і зменшується час реагування на будь-які зміни бізнес-завдань.

Якщо підсумувати, хоча PO і бізнес-аналітик концептуально різні, але в багатьох задачах перетинаються. Щоб зрозуміти, хто потрібен вам на проєкті, необхідно з’ясувати очікування замовника, його рівень довіри до вас, а так же потреби й ступінь автономності команди.

У наступному епізоді ми обговоримо ролі стейкхолдерів, розберемося, хто такий scrum-майстер і чим же повинен займатися менеджер команди.

Залишайтеся на зв’язку!

Top Insights