Product Owner — це роль чи позиція? В аутсорсингових чи в продуктових ІТ-компаніях? Він підпорядковується продакт-менеджеру чи керує ним? Насправді компетенції, обовʼязки та ступінь впливу цього фахівця залежать від компанії, її розмірів, структури бізнесу, продукту та ще багатьох факторів. Артем Садурський, Chief Product Owner в Solidgate, партнерській компанії Genesis, розповів про дві популярні моделі взаємодії Product Owner з командою, про обовʼязки, ключові навички та виклики, а також пояснив, чим відрізняється ця позиція від продакт-менеджера.
> Виклики
Product Owner — роль у Scrum чи позиція
Поняття Product Owner вперше зʼявилося в методології управління проєктами Scrum у 90-х. Суть цього підходу — у гнучкості та пріоритезації завдань, які треба виконати протягом спринту (проміжок часу від одного до чотирьох тижнів). Власне, за це і відповідає Product Owner. А ще — за цінність продукту, комунікацію зі стейкхолдерами та всередині команди, щоби всі однаково розуміли цілі й завдання. Головна ідея цієї ролі — збирати вимоги стейкхолдерів, клієнтів, користувачів, обирати з них ключові та доносити команді разом зі своїм баченням кінцевого продукту. Цю роль можуть виконувати люди різних позицій — наприклад, бізнес-аналітик або навіть власник бізнесу.
Крім Product Owner до традиційної Scrum-команди також входять розробники та Scrum-майстер, який відповідає за ведення беклогу і регулярні зустрічі.
Але залежно від розмірів команд, специфіки компанії, ніші та багатьох інших факторів, цей фреймворк зазнає змін. Кожна команда адаптує його під себе. Так, у маленьких командах зазвичай немає Scrum-майстра, а всі його обовʼязки переходять Product Owner. А якщо в компанії є декілька команд, вимальовується зовсім інша схема взаємодії та зʼявляються нові ролі. Згодом ці трансформації фреймворку зайшли так далеко, що роль Product Owner стала окремою позицією.
Чим відрізняється Product Owner від Product Manager
Описи вакансій на ці дві позиції часто ідентичні — для однакового переліку обовʼязків компанії просто використовують різні назви посад. Але як взаємодіють ці спеціалісти в одній команді? Розділення обовʼязків та відповідальності продакт-менеджерів та Product Owner — дуже субʼєктивне. «Залежно від геометрії команди цей спеціаліст може стояти на різних сходинках ієрархії — бути керівником продакт-менеджера або навпаки підпорядковуватися йому» — говорить Артем Садурський, CPO в Solidgate.
Розберемо дві найпоширеніші моделі команд та роль Product Owner в них.
Модель № 1
Ця схема близька до класичної Scrum-команди. Product Owner комунікує зі стейкхолдерами, Scrum-майстром, а ще — продакт-менеджером (наявність цієї ролі не передбачена в базовій Scrum-команді).
Продакт-менеджер взаємодіє з користувачами або клієнтами, бере на себе дослідження їхніх потреб та поведінки, проводить кастдеви (спосіб тестування ідей та прототипів майбутніх проєктів). Його завдання — працювати з аналітикою, знаходити інсайти, формувати гіпотези та презентувати все це Product Owner. Разом вони формують завдання команді, пріоритезують та віддають Scrum-майстру, який з командою втілює ці ідеї. Таких команд у Product Owner може бути декілька. Загалом він відповідає за місію й цінність продукту, те, яким він буде в результаті, та комунікацію між усіма учасниками процесу.
Модель № 2
В цій моделі Product Owner підпорядковується продакт-менеджеру й певною мірою «розвантажує» його. Ідея полягає в тому, щоби розділити продукт компанії на частини — компоненти, і створити для них окремі команди, кожну з яких має очолити Product Owner. Вони відповідають за тактику та середньостроковий розвиток своїх частин продукту. А продакт-менеджер — за стратегічний розвиток продукту та взаємодію зі стейкхолдерами, у яких також є певні вимоги та очікування.
Залежно від компонента, поруч із продакт-менеджером можуть додавати спеціалістів — технічних райтерів, продуктових дизайнерів тощо.
Чим займається Product Owner в межах свого компонента:
розуміє потреби бізнесу та збирає вимоги до продукту;
забезпечує роботу команди розробки;
контролює виконання та оцінює прогрес;
працює з цілепокладанням (KPI або OKR);
керує Scrum-процесами (планування, пріоритезація завдань, наповнення і грумінг беклогу, церемонії тощо);
складає епіки та юзер-сторі;
організовує кастдеви, фічер-квести;
вивчає аналітику та розуміє, що в продукті працює, а що ні;
складає специфікацію;
шукає інсайти, формує гіпотези та перевіряє їх;
відповідає за технічний і продуктовий дизайн;
обирає якісні методи вирішення тієї чи іншої проблеми.
За моделлю № 2 працює команда Solidgate, партнерської компанії Genesis, яка створює фінтех продукт — платіжний провайдер, що надає онлайн-підприємцям можливість приймати всі види популярних у світі платежів.
«Цей рік ми починали в складі трьох команд, зараз їх шість, а на початку наступного року — буде сім. Тому останнім часом ми будували окремі продуктово-технічні команди на рівні компонентів. Така структура дає сформувати чіткий фокус у командах та ефективніше керувати ними», — Артем Садурський, CPO в Solidgate.
Коли команд було декілька, функції продакт-менеджера в команді виконував СРО. Саме він синхронізував роботу всіх команд. Але кількість команд зростала, і зʼявилася потреба вводити в ієрархію продакт-менеджерів. Вони відповідатимуть за роботу зі стейкхолдерами, довгострокову стратегію й побудову дорожньої карти розвитку компонентів.
Але може бути й третя модель — коли в компанії немає Product Owner, а всі його функції виконує продакт-менеджер.
Ключові навички Product Owner
Комунікація
Аналітичні здібності
Системне мислення
Знання методології розробки Scrum та таск-трекерів
Відповідальність та вміння приймати рішення
Управління проєктами, планування, контроль
Лідерство та менеджмент
Гнучкість та адаптивність
Емоційний інтелект
Вміння досліджувати та аналізувати потреби користувачів
Product Owner — позиція, яка вимагає великого діапазону особистих якостей. Ця людина вміє домовлятися, аргументувати та доносити свою позицію. Знаходити спільну мову не тільки зі стейкхолдерами, але й із технічною командою — розуміти суть процесів їхньої роботи, скільки часу потрібно для того чи іншого завдання.
Залежно від продукту чи його компоненту, можуть бути затребуваними специфічні бекграунди:
технічний;
маркетинговий;
операційний;
аналітичний;
стратегічний;
Growth.
«Комусь потрібен спеціаліст, який вийшов із дизайну та може відповідати за UI/UX частину. Комусь — технічний фахівець, який може спілкуватись однією мовою з розробниками, писати API-специфікації, створювати Activity та Sequence діаграми, взаємодії між різними сервісами та системами. А комусь потрібен фахівець із бізнес-бекграундом, який буде доносити команді, скільки грошей вони сьогодні зароблять, і чому це важливо для компанії — каже Артем Садурський.
Тому, відгукуючись на вакансії, або наймаючи на цю позицію, важливо чітко формулювати, що входить у перелік обовʼязків саме для цієї компанії.
Виклики для Product Owner
Головний виклик Product Owner — розвиток продукту або його компоненту, за який він відповідає та досягнення цілей, які стоять перед компанією загалом. На думку Артема, це є найскладнішим і одночасно найцікавішим на цій позиції. Окрім цього є багато інших викликів, які залежать від специфіки продукту.
Наприклад, в одному продукті викликом буде робота з аналітикою, зокрема сегментами користувачів, щоби знайти якісь інсайти та розв’язати проблеми у воронці. А в іншому — побудова складних логік системи на бекенді. У такому випадку Product Owner має придумати нову фічу та реалізувати її в системі з великою кількістю розгалужень так, щоби не зламати все інше. Solidgate — саме такий продукт, де цьому фахівцю необхідне системне мислення.
«Є технічна архітектура — як виглядає продукт з точки зору коду, інфраструктури. А є продуктова архітектура — коли тобі потрібно думати, як правильно побудувати послідовність функціональностей. Тому що ти не завжди можеш просто придумати та реалізувати якусь фічу: можуть виникнути проблеми, доведеться вигадувати «костилі». І врешті твій продукт схожий на Франкенштейна. А якщо ти не продумав їхню послідовність або пропустив важливий етап, ти вже не матимеш змоги змінити свою систему, щоби не зламати все», — Артем Садурський, CPO в Solidgate.
Як стати Product Owner
Рішення світчнутися на цю позицію приймають спеціалісти з різних сфер. Зазвичай вони хочуть більше впливати на продукт та бачать на цій позиції потенціал свого розвитку. Ними керує бажання створювати сам продукт та кінцеву цінність для користувачів.
Сфери, з яких приходять на позицію Product Owner:
продуктовий дизайн;
маркетинг;
бізнес-аналітика;
системна аналітика;
дата-аналітика;
розробка.
Спеціалісти кожної з цих сфер мають свою унікальну комбінацію знань із різних сфер, ніш та аудиторій і мають попит на ринку. Якщо людина хоче світчнутися із суміжної сфери, їй варто розібратися і специфіці створення ІТ-продуктів, а також вивчити методики управління проєктами на спеціальних курсах або самостійно.