Як я побудувала кар’єру Product Owner: особистий досвід та поради для початківців

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

Привіт! Мене звати Анна і сьогодні я спробую допомогти вам розібратися з професією Product Owner (РО) на прикладі того, як робота Продакт Оунера реалізується в нашій компанії.

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

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

Мій професійний шлях до позиції Product owner

Мій шлях почався у 2008 році, коли на останніх курсах університету я працювала HTML/CSS-кодером у вебстудії. Пізніше я два роки вчилася в магістратурі за кордоном. Повернулася в Україну в момент, коли IT вже нісся на шаленій швидкості. У командах розробки диференціювалося багато нових ролей і мене зацікавила роль Бізнес Аналітика. Я знайшла курси в одній із харківських компаній, в якій з часом отримала офер. Тож можу сказати, що мій шлях до Product Owner почався саме з бізнес-аналітики.

Потім кар’єра розвивалась стрімголов: я попрацювала як Business Analyst->Project Manager->Scrum Master->System Analyst->Product Owner -> Functional Manager — Functional Manager Lead. З кожної ролі я брала щось нове і зараз успішно інтегрую ці напрацювання при підготовці нових Product Owners та Product Owner Associates.

Наразі в мої основні обов’язки входить індивідуальна допомога PO у професійному розвитку через Professional Development Plan та командне навчання (внутрішня ініціатива в нашій компанії, яка називається Community of Practice).

Хто такий Product Owner

Отже, почнемо з початку й спробуємо визначити, ким є Product Owner. Product Owner — це роль у Scrum-команді, яка зазвичай складається зі Scrum Master, Product Owner та Development team. Як визначають SAFe та SCRUM-першоджерела, PO відповідає за підвищення бізнес-цінності того, що робить команда розробки. Своєю чергою, це досягається через відповідність списку задач команди до потреб клієнтів.

Нижче на ілюстрації зображена основна суть такої дефініції:

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

Серед типових функцій Product Owner можемо виділити такі:

1. Комунікація зі стейкхолдерами. Саме РО відповідальний за своєчасну і конструктивну комунікацію з усіма сторонами процесу розробки (стейкхолдерами). Його задача — зрозуміти вимоги й очікування стейкхолдерів та переконатися, що продукт їм відповідає. В даному процесі цей фахівець є центральним вузлом, від роботи якого залежить досягнення цілей всіма залученими сторонами.
2. Керування беклогом. Регулярний рефаймент беклогу, актуальна пріорітезація верхньої частини беклогу та підтримка адекватної ієрархічної структури: Feature->Epic->Story/Task->Sub-task.
3. Робота з вимогами. Бізнес-вимоги зазвичай готує Product Manager (але теж бувають виключення). Проте підготовка юзер-вимог у вигляді User Stories або Use Cases буде вже роботою РО. Робота з функціональними й нефункціональними вимогами на рівні опису рішення теж входить до функцій Product Owner.
4. Опис складної бізнес-логіки та пояснення вимог розробникам. Тут РО може користуватись арсеналом Business Analytics і, наприклад, використати нотації моделювання — UML (Unified Modeling Language) або BPMN (Business Process Modeling). Також фахівець може зробити декомпозицію вимог за допомогою WBS (Work Breakdown Structure) або User Story Map.

Щодо особливостей РО в нашій компанії можу виділити те, що у нас не заведено сприймати Product Owner як «людину-оркестр», тобто вимагати від цього фахівця одночасно закривати функції Business Analytics, Scrum Master, тестувальника або бути відповідальним за декілька проєктів одразу. За потреби наш РО може запросити допомогу — в цьому випадку допомагати йому буде Product Owner Associate. Тобто, РО отримує помічника, якому можна делегувати частину роботи, і водночас Product Owner Associate отримує можливість розвиватися і рости до ролі Product Owner.

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

Або, якщо хтось із колег потрапив у проблемну ситуацію (наприклад, є складнощі у комунікації зі стейкхолдером або із розв’язанням певної проблеми), він попереджає про це інших, щоб всі були в єдиному інформаційному полі. Також у нас вже давно існують спеціальні мітинги для того, щоб ділитися актуальними професіональними кейсами — ми називаємо їх Community of Practice.

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

Усі ці практики були сформовані нами емпіричним шляхом протягом кількох років, і наразі вони забезпечують команді стабільні та позитивні показники.

Шлях до професії Product Owner

Якщо ж проаналізувати мій професійний шлях та приклади моїх колег з команди, я точно не знайду жодної однакової історії. Наприклад, до ролі Product Owner переходять із ролі Business Analytics, коли окрім створення вимог спеціаліст хоче більшої залученості у прийнятті рішень по продукту. Або приходять Project Managers, які хочуть вийти за межі «клієнт — аутсорс провайдер», хочуть синхронно рухатися з бізнесом до його цілей і бути частиною загального успіху.

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

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

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

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

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

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

З чого почати. Базові hard skills

У нашій команді ми провели співбесіди з більш ніж сотнею кандидатів на роль РО. З цього досвіду можу відмітити: багато хто вважає, що наявного досвіду вже достатньо і не обов’язково систематично здобувати теоретичні й практичні знання у сфері Product Ownership.

На мій погляд, це припущення вкрай помилкове. Я рекомендую обов’язково працювати зі знаннями на фундаментальному рівні — розуміти теоретичний концепт техніки або підходу та вміти реалізувати його на практиці.

Отже, з чого рекомендую починати.

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

Визначення цілей. Перед стартом навчання на РО важливо мати чітку мету та підійти до цього, як до повноцінного проєкту: розбити на етапи, кожен зі своєю ціллю та термінами. Це значно прискорить опанування ролі Product Owner, а також збільшить шанси на успішне проходження співбесіди.

Освіта. Курси з бізнес-аналізу будуть гарним початком для отримання базової інформації. Навчальні програми з проджект-менеджменту допоможуть отримати структуровані знання в управлінні проєктами. Курси з розробки (web і mobile) допоможуть у вивченні основ програмування та тестування продуктів. Отримавши цю базу, ви вже зможете починати в ролі Product Owner або Product Owner Associate. Знайти такі курси можна як на українських, так і на міжнародних освітніх платформах.

Варто також звернути увагу на сертифікаційні програми, наприклад, Professional Scrum Product Owner™ (PSPO) або Certified Scrum Product Owner™, які дають розуміння про роль РО у всесвіті SCRUM. Такі програми не тільки надають ґрунтовні знання й практичні рекомендації, а й можуть бути вагомим плюсом при пошуках роботи.

Книги. Скажу відверто: в нашій тімі новачки переважно вчаться на матеріалах, які створила наша команда. За 9 років командного досвіду нам вдалося зібрати як теоретичну, так і практичну базу з нашими власними кейсами. Сюди ж додається досвід саме нашої компанії, аби людина одразу вчилася працювати з тим, з чим працює команда.

Проте ми, звісно, спираємося також на класичні авторитетні джерела, з яких можу порадити наступні матеріали:

• BABoK (A Guide to the Business Analysis Body of Knowledge). Всесвітньо визнаний стандарт практики бізнес-аналізу, який вчить працювати з організаційними змінами та створювати бізнес-цінність на стратегічному, тактичному та операційному рівнях.
• PMBoK (A Guide to the Project Management Body of Knowledge). Це видання називають настільною книгою менеджерів проєктів і використовують при розробці міжнародних стандартів. Найбільш розповсюджене зібрання знань з управління проєктами, що використовується у понад 200 країнах.
• Software Requirements. Книга вважається класичним посібником із розробки вимог до програмного забезпечення. Це сучасний набір практик, що охоплює повний спектр розробки вимог і діяльності з управління проєктами програмного забезпечення.
• Моделювання бізнес-процесів. BPMN 2.0 — Business Process Model and Notation. Структурована та скомпонована інформація про основні елементи діаграми та їх призначення.
• User Stories Applied. Ця книга описує процес створення вимог, який побудовано на історіях користувачів — простих, зрозумілих, коротких описах функцій. Цей підхід економить час та допомагає створювати краще програмне забезпечення.
• Quick Ideas To Improve Your User Stories. У випадку, якщо ви вже пишете вимоги у вигляді історій, книга дає ідеї, як їх можна покращувати.
• Kanban and Scrum — making the most of both. Рекомендую пошукати й почитати книги Хенріка — він надихає.

Професійні івенти, спільноти та платформи

Сучасний професійний розвиток важко уявити без обміну знаннями з досвідченими колегами. Тож рекомендую обов’язково відвідувати фахові події та приєднуватися до професійних ком’юніті.

• Міжнародні події: ProductCamp, Agile Alliance, Mind the Product, що збирають експертів із різних країн для обміну ідеями та практиками.
• Українські події, спільноти та курси: Lviv IT Arena та заходи в UNIT.City, платформи Art of Business Analysis, IAMPM та IIBA Ukraine. Ці майданчики пропонують спеціалізовані курси та воркшопи, щоб Product Owners могли поглиблювати знання й удосконалювати навички. Онлайн-спільноти: активні групи на Facebook і Telegram, наприклад, Product Management Ukraine та Agile Ukraine. Такі майданчики надають постійний доступ до обміну досвідом, актуальних дискусій і важливих інсайтів.

Внутрішні програми в компаніях

У нашій команді, наприклад, ми створили Community of Practice — простір для регулярного обміну досвідом між Product Owners. Тут PO можуть обговорювати актуальні виклики, разом шукати рішення, синхронізувати підходи, а також ділитися як успішними кейсами, так і невдачами, з яких можна винести важливі уроки. Такий підхід стимулює колективний розвиток, постійне вдосконалення процесів і впровадження перевірених практик, що допомагає підтримувати якість наших підходів на висоті.

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

Як стати класним професіоналом. Важливі soft skills

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

Комунікація. Щоб реалізувати весь функціонал ролі, про який ми говорили на самому початку, потрібно буде багато спілкуватися: з командою, зі стейкхолдерами, з end-users, з C-level компанії. Це спілкування є постійним, і Product Owner відіграє в ньому роль центрального вузла. Саме тому швидкість, точність та ефективність передачі інформації — ті вміння, якими має володіти РО.

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

Відповідальність. Від Product Owner залежать важливі процеси — аналіз минулих помилок і перетворення їх у вивчені уроки, своєчасне делівері фіч в поточному моменті та правильне бачення майбутнього обсягу. Тому відповідальність — одна з базових характеристик успішного РО.

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

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

Не бійтеся відкрито запитувати, експериментувати та вчитися на помилках. Ваш шлях до ролі Product Owner може бути нелегким, але з наполегливістю ви зможете досягти успіху.

Self-care або як не дати PO вигоріти

Варто проговорити, що може статися так, що романтичний період в новій ролі РО закінчиться. На зміну приходить рутина та високий рівень відповідальності, росте кількість задач, і все може почати рухатися в сторону стану вигорання.

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

Ми це вирішуємо за допомогою вже згаданої вище ролі помічника, бо майже кожен Product Owner має Product Owner Associate, якому вже після процесу онбордингу можна буде делегувати деякі задачі й таким чином вивільняти час РО на залучення в нові ініціативи та професійний розвиток.

Таке рішення є win-win для всіх учасників процесу. Для Product Owner Associate ця стратегія дозволяє в безпечній атмосфері почати свій шлях в Product Ownership під дбайливим наглядом ментора. Тобто працювати в діючій команді, набуваючи необхідні знання та навички.

Для Product Owner це можливість спробувати нові челенджі для себе, або й, може, спробувати реалізувати деякі нестандартні проєкти. Наприклад, у нас РО може перейти до команди архітекторів, яка закладає базис для побудови системи, й рухатися в напрямку Technical PO. Або ж почати допомагати з delivery, і не в одній команді, а одразу в декількох, на кшталт Delivery Manager.

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

Я дуже вам дякую за увагу до цього тексту. Сподіваюсь, він був вам корисний.

Буду рада дізнатися про ваш досвід роботи в ролі PO або про ваше бажання перейти на дану позицію. Також готова відповісти на питання на тему статті, тож прошу залишати їх в коментарях.