Чому Product Owner — це більше ніж роль? Шлях до змін в IT-компанії

Мене звати Єжі Рудь, я Senior Manager, Product Ownership у SPD Technology. І вже близько 20 років я працюю з продуктами як на стороні клієнта, так і в умовах інтегрованого аутсорсингу/аутстафінгу.

У роботі я завжди люблю виклики та прозорі процесі і завжди йду туди, де важко і незрозуміло. У 2023 році, коли я приєднався до SPD Technology, переді мною постало амбітне завдання: створити нову функцію «Product Owner», яка б стала наступним етапом еволюції поточного відділу бізнес-аналітики. Така трансформація в результаті мала підвищити відповідальність та вплив на процеси реалізації продуктів. 

Це завдання вимагало не лише чіткої візії ролі Product Owner і визначення її обов’язків, щоб окреслити зони відповідальності та позбутися «історичного контексту», але й уміння об’єднати людей, які починали з різних напрямів.

Яких результатів ми досягли, з якими проблемами зіштовхнулися та наскільки цей кейс може бути релевантним для вас — цим я і поділюся. Маю надію, що цей досвід допоможе й вам у ваших проєктах (хоча б з огляду на саморефлексію та можливість навчитися на наших помилках).

Від ідеї до дії: як ми впроваджували професію Product Owner?

Ми почали з команди та визначення її культурного коду: Courage, Honesty, Family. Це про сміливість у діях, чесність у комунікації та підтримку без маніпуляцій. Важливо було не лише впровадити зміни, а й завоювати довіру команди. Дехто сприйняв цей виклик із ентузіазмом, дехто — зі скепсисом, але зрештою всі включилися в роботу.

Далі ми чітко окреслили роль Product Owner (PO) у процесі Delivery. Це ключова позиція, що не лише передає вимоги стейкхолдерів, а й формує їхні очікування, покращує процеси та деталізацію завдань. І головне завдання PO — пріоритизувати беклог за цінністю для користувачів, підтримувати комунікацію між бізнесом та інженерією й разом із техлідом та менеджером бути лідером команди. 

Щоб зробити PO «єдиним джерелом істини» у тактичних вимогах, ми поступово розширили їхню відповідальність. Сьогодні 26 із 29 команд вже працюють із Product Owners, що вимагає від них глибокого розуміння бізнес-домену та тісної співпраці зі стейкхолдерами. 

Раніше Product Managers виступали посередниками між бізнесом і технічними командами, що не завжди було ефективним, адже їхня зона відповідальності — стратегія та прибутковість, а не технічні нюанси. І це спричиняло перевантаження команд і затримки. Тож ми розділили ці дві функції: Product Managers зосередилися на аналітиці, роадмапах і формуванні Product Requirements Documents (PRD), а Product Owners — на деталізації вимог, рефайнменті та управлінні беклогом. Вони також оцінювали ресурси, контролювали прогрес і гарантували, що кожен спринт приносить конкретний результат.

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

Чіткість і ясність: як ми формувалися і еволюціонували? 

Перший крок: чітка кар’єрна траєкторія

Ми створили чітку «кар’єрну траєкторію» для Product Owners, використовуючи Radford-модель, що дало змогу окреслити два основні напрями розвитку:

Підписуйтеся на наші соцмережі

Також ми забезпечили, щоб професія Product Owner відповідала стандартам сучасного ринку. І це допомогло:

Другий крок: реформа підпорядкованості

Ми переглянули структуру підпорядкування, формуючи команди за доменними зонами. Раніше менеджери часто працювали з командами, які не були безпосередньо пов’язані з їхньою зоною експертизи. Це створювало труднощі у вирішенні ескалацій і затримувало процеси. Тож нова система дозволила:

Третій крок: сертифікація PSPO

Ми ввели сертифікацію Professional Scrum Product Owner (PSPO) як стандарт для залучення нових Product Owners. Спочатку сертифікація була опційною для поточних співробітників, але згодом стала однією з умов закріплення певного рівня посади у річних OKRs. Такий підхід допоміг кожному Product Owner:

Четвертий крок: формалізація зон відповідальності

Ми чітко визначили зони відповідальності Product Owners та узгодили їх із функціональними групами (Product Designers, Product Managers, Technical Program Managers), і це надало нам можливість:

Тепер кожна роль виконує свої завдання відповідно до чітко визначених зон відповідальності.

П’ятий крок: професійний план розвитку (PDP)

Ми впровадили професійний план розвитку (PDP) для кожного Product Owner. Це річний план, який допомагає або закріпити рівень кваліфікації, або перейти на новий. План включає чотири основні категорії:

Кожен план розробляється індивідуально, але має загальні курси, що можуть покривати потреби кількох спеціалістів та допомогає:

Завдяки впровадженню цих змін ми забезпечили послідовність, чіткість та якість у роботі Product Owners. Це надало змогу створити сильну базу для їхньої професійної еволюції, а також підвищити ефективність та узгодженість команд у масштабах організації.

Результати та реальність: що це все нам дало та на якому етапі ми зараз?

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

Помилка 1: KPI для Product Owners

Однією з помилок стало впровадження KPIs для Product Owners. Попри простоти розрахунку, незалежність у підрахунках і можливість швидкого впливу, ми зіштовхнулися із факторами, які ускладнили процес, перетворюючи прості формули на складний аналіз.

І хоча KPIs не можна назвати повним провалом, адже вони допомогли виявити проблеми в командах, після воркшопу стало зрозуміло, що багато девіацій знаходяться поза зоною нашого впливу. Тому ми тимчасово поставили їх на hold.

Натомість ми перейшли до наступного етапу — «сигналів», що вимірюють цикл розробки фічі від ідеї до першого конвертованого замовника. Це також дозволяє орієнтуватися на Backlog Health та встановити єдиний baseline для ключових метрик.

Помилка 2: Зони відповідальності в Agile

При введенні Agile важливо завжди пам’ятати, що це двосторонній процес, і без чітких методів та стандартів він є мертвим. І хоч я не фанат процесів, яким треба сліпо слідувати, а більше просуваю стандарти – чітко описані ситуації та дії, на які можна «спертися» при вирішенні конфліктних ситуацій, без високого рівня відповідальності з усіх сторін будуть постійно створюватися «сірі зони», які постійно треба буде закривати. І у нашому випадку це була «прозорість» у побудові роадмапів та звітності.

Помилка 3: Децентралізація

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

Тепер кожен процес проходить ітеративне обговорення та затвердження всією командою PO. Кожен, незалежно від рівня — Associate чи Team Lead, може впливати на глобальні стандарти, не лише підіймаючи проблеми, а й пропонуючи конкретні рішення для покращення продукту та робочих процесів.

Наостанок подякую всім, хто дочитав до кінця, і скажу, що ця модель підходить лише тим, хто готовий будувати команди з людьми та для людей. Тим, хто вирішить спробувати це у своїй організації, побажаю: не бійтеся вносити зміни, вчитися на чужих помилках і робити свої. Адже кожна помилка, яку добре пропрацьовано і з якої зроблено висновки, — це просто ще один крок у вашому невпинному русі вперед.