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

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

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

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

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

Всім відома сага “Зоряні Війни”. Для зразка пропоную взяти команду імперських інженерів, штурмовиків і офіцерів, які є на малюнку вище. Чому? На наш погляд, саме ці хлопці проактивно діють згідно з принципами 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 і поділах їх обов’язків.

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

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

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

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