Чим займається та для чого потрібен Technical Product Owner в Agile-команді

Привіт. Я Настя, Technical Product Owner і тімлід у Forte Group. В цій статті ми спробуємо розібратися з тим, які задачі на проєкті у Product Owner, а які в Technical Product Owner, кому з них потрібен вагомий технічний досвід, та з якими ще ролями в Agile-команді перетинається TPO.

Для початку, визначимося з головними термінами.

Product Owner (PO) — це ключова людина в Agile-команді. Product Owner відповідає за те, щоб цінність продукту, над яким працює команда інженерів, була максимальною. PO визначає, пріоритезує та пояснює цілі продукту і план виконання проєкту. Проте, є такі питання, які виходять за межі території, де PO почувається, як риба у воді. Якщо потрібно зануритися в технічні вимоги продукту, PO звертається за допомогою до технічних спеціалістів. Загалом, техліди підтримують PO у таких випадках.

Але це добре працює у невеликих розробницьких командах. Стає складніше, коли продукт швидко масштабується і кількість Agile-команд зростає. Команди стикаються з кейсами, які необхідно вирішувати: більше нових і складних функцій, залежностей, технічний борг, який зростає, відчутні архітектурні зміни, збільшення термінів виходу на ринок. Хтось повинен взяти відповідальність за технічну сторону розробки продукту. Саме тому з’являється ще одна важлива роль у команді — Technical Product Owner.

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

Хто такий Technical Product Owner

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

Обов’язки TPO

Ви навряд чи знайдете деталізований опис обов’язків TPO в Scrum чи SAFe інструкціях. Ця роль виникає в процесі, і тому важко попередньо визначити опис її функцій. Зазвичай, зона відповідальності TPO коригується, коли представляється на конкретному проєкті, і залежить від потреб проєкту. Та все ж, спробуймо розібратись у ключових обов’язках TPО.

Технічний асистент і радник

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

Ключові завдання TPO як технічного асистента такі:

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

Також TPO виступає у ролі технічного радника для стейкхолдерів, як-от business owners, product managers, scrum masters та членів інших команд. Його обов’язками є:

  • підтримувати команди щодо важливих технічних рішень;
  • показувати та допомагати налагоджувати міжкомандні взаємодії;
  • допомагати розгрібати беклог, пріоритезувати його та планувати спрінти.

Консультант для клієнтів

Більшість клієнтів не дуже в темі технічних питань, вони просто хочуть, щоб була зроблена робота. TPO доносять до клієнтів інформацію про те, що продукт може робити, а що не може з технічної перспективи, розказують про технічні рішення та залежності в зрозумілій формі. Якщо коротко підсумувати, то робота TPO допомагає прокласти своєрідний міст між клієнтами та Agile-командою у співпраці з PO. Аби цей міст існував, вони:

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

General (Advanced) Technical Ownership

Комплексні технічні продукти (великомасштабні технічні продукти чи продукти зі значною кількістю очікуваних архітектурних змін) вимагають більшої залученості від TPO, наприклад:

  • взаємодіяти із Solution Architect;
  • розробляти єдиний технічний беклог для всіх команд;
  • створювати та управляти архітектурною картою;
  • направляти архітектурні зміни через декілька команд послідовно;
  • складати графік технічних типів історій користувачів для пошуку рішення і зменшення ризиків чи архітектурних змін, залежно від функціональних зобов’язань заздалегідь в продуктовій карті.

❗️Зверніть увагу: усі функції TPO, описані вище, можуть або не можуть бути. Ви самі вирішуєте, що робить TPO, залежно від особливостей проєкту. В цій статті я хочу розкрити максимальну кількість можливих функцій.

Різниця між TPO та іншими ролями в команді

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

1. Technical Product Owner vs. Product Owner

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

2. Technical Product Owner vs. Solution Architect (SA)

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

3. Technical Product Owner vs. Delivery Manager (DM)

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

Коли роль TPO вже представлена, я рекомендую визначити зони відповідальності між ролями в команді, про які згадала вище, щоб уникнути накладок і перевантаження ресурсів.

Як виглядає робочий день TPO

Тепер спробуймо поринути в реальне робоче життя. Які типи задач щодня виконує TPO? Ми можемо виділити такі ключові напрями роботи:

  • брати участь у зустрічах і спільно працювати з бізнес-стейкхолдерами і PO. TPO необхідно бути на всіх цих зустрічах, адже завдяки цьому можна досягти виконання таких завдань:
    • давати всім стейкхолдерам зрозуміти, що реально виконати, а що ні;
    • продумувати всі можливі залежності і технічні інструменти, щоб втілити в життя те, що хоче бачити бізнес.
  • Управління беклогом. TPO розробляє і пріоритезує технічний беклог для усіх команд, зручно розділяє беклог на декілька категорій:
    • нефункціональний (технічний) беклог складається з технічних інструментів для розробки бізнес-елементів продукту;
    • архітектурний беклог наповнений комплексними, довготривалими технічними історіями досвіду користувачів і різними дослідженнями та аналізом;
    • беклог рефакторингу (реорганізації) використовується для роботи з технічним боргом;
    • беклог DevOps (інфраструктурний) містить елементи, які ведуть до продуктової чи командної інфраструктури (нової або зміненої інфраструктури, визначення або покращення процесу установки, представлення нових інструментів, всього, що може допомогти команді зробити програмний продукт).
  • Управління дорожньою картою проєкту. TPO і PO працюють разом як партнери, щоб об’єднати функціональний беклог продукту з технічним беклогом. Вони це роблять на рівні підготовки роадмапу проєкту та індивідуально на рівні беклогу команд.
  • Взаємодія з командами і усіма зацікавленими сторонами. TPO — це своєрідний міст, посередник між значною кількістю членів команди: PO, техліди, архітектори, DevOps, і DM. TPO — це людина, яка інформує про стратегію технічного бачення усіх колег і партнерів і тих, чиїм рекомендаціям можуть довіряти всі сторони.
  • Підтримка у плануванні релізу та управління ним. Як людина, що займається повним технічним баченням проєкту, TPO бере участь у зустрічах з планування релізів для визначення потенційних залежностей і допомагає з їхньою пріоритезацією.

Висновки

Як бачимо, роль TPO не має чіткого опису зобов’язань. Все залежить від потреб проєкту, масштабу, комплексності й етапу продуктової розробки. Це дозволяє команді маневрувати з обов’язками від проєкту до проєкту і змінювати їх з часом. Зазвичай є сенс робити TPO з техлідів, архітекторів чи delivery менеджерів, коли така потреба є.

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

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

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

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

Частина команди Forte з найдобрішим вайбом IT-спільноті

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Вітаю, Анастасіє.

Прочитав, прослухав, але картинка в мене так і не склалася.

TPO і PO працюють разом як партнери, щоб об’єднати функціональний беклог продукту з технічним беклогом

Яким чином TPO і PO володіють беклогом продукту? Однією з причин введення ролі PO було саме те, що він повноцінно володіє продуктом, і має повну владу приймати рішення щодо пріоритетів та порядку роботи. І це не має бути комітет, це роль однієї людини.
Складається враження, що TPO володіє однією частиною продуктового беклогу, PO — іншою частиною, в результаті повноцінно не володіє ніхто.
Чи я в чомусь помиляюся?

І цікаво почути нетиповий досвід інших, дякую!

Доброго дня, Максиме!

Суть у тому, що TPO та PO повинні працювати спільно. Беклог загальний і формальним власником бэклога продукту виступає все-таки PO.
На практиці, для зручності роботи з беклогом, його все одно ділять на будь-які логічні частини — функціональний/бізнесовий (фічі та імпрувменти), технічний обов’язок, баги, архітектурні/технічні завдання. TPO допомагає PO керувати технічною частиною беклогу.

Пару прикладів (взагалі, стикалася з великою кількістю кейсів — але типові і прості)
— клієнт хоче додати нову бізнес-фічу, але це тягне за собою обов’язкове додавання кількох винятково технічних завдань (technical enablers for business features).
— або TPO попереджає PO, що якщо не закрити кілька завдань з технічного боргу, можна зіткнутися з проблемами через місяць-два.
Саме з наповненням таких завдань (деталі, критерії приймання у jira-тикетах) та їх пріоритезацією допомагає TPO.

У нас була домовленість — 80% завдань у спринт — це нові фічі, 20% — техборг або баги.
Ну і як правило, останнє слово має бути за PO, оскільки він є довіреною особою клієнта та відповідає за пріоритезацію бізнесового/функціонального беклогу та розвиток продукту. У разі перетину інтересів — ми знаходили компроміси — тому що працювали спільно і ми мали спільне розуміння чого хоче бізнес.

Якщо є необхідність глобальних архітектурних змін, то TPO володіє частиною беклогу повністю і приймає самостійно рішення про пріоритезу задач. Більш складні випадки описані у статті в частині — General (Advanced) Technical Ownership.

Зрозуміло, Анастасіє. З теоретичної точки зору я б посперечався, але в цьому немає сенсу.
Радий, що на практиці даний підхід працює для вас, і приносить свої результати.
Успішних вам релізів!

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

Дякуємо Вам за увагу до статті та гарного Вам дня!

дякую всім за коментарі!
Постараюся відповісти на основну критику в одному повідомленні:
1. згодна, що обов’язки частково перетинаються з ролями типу архітектора та техліда. Можливо, варто було розкрити розбіжності — моя помилка, але знову ж таки — все залежить від потреб конкретного проекту і його масштабу.
2. згодна, що TPO роль — це екзотика, але у статті зазначено, що це варіант роботи у великих, технічно складних і швидкозростаючих проектах, де є кілька команд розробки (3+ agile-команди), які мають свої Ліди. TPO якраз потрібен для того, щоб РАЗОМ з лідами та архітектором управляти загальним технічним баченням всього продукту, що розробляється.

це варіант роботи у великих, технічно складних і швидкозростаючих проектах, де є кілька команд розробки (3+ agile-команди),

Я працював на проектах з 200+ людей але TPO ніколи не чув.

TPO якраз потрібен для того, щоб РАЗОМ з лідами та архітектором

Архітекторів теж може бути кілька.
І з різними відповідальностями.
ІМХО, замість того щоб придумувати колесо могли б заюзати термінологію з SAFe.

SAFe defines three architect roles: Enterprise, Solution, and System architect, that address architectural concerns at their respective levels (portfolio, program, and solution).

З опису TPO десь між солюшн і систем архітектором.

Хіба що у вас TPO це фасілітатор/подавач маркерів, тоді могли б його назвати скрам мастером архітект команди:)

Добавляя любую дополнительную роль, вы отнимаете часть ответственности у команды. Есть проблемы с качеством? А давайте введем роль ответственную за качество! Есть проблемы с релизами? — вставляем ответственного за релизы... Agile — это об уменьшении кол-ва ролей, артефактов и упрощении процессов. Настоящая agile команда самостоятельно координируется, овнит продукт, взращивает архитектуру и умеет говорить на языке бизнеса

Мені одному здається що описана роль — це по суті tech lead?

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

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

Scrum каже про три ролі SM + PO + Developers у кожної ролі свої обов’язки і насправді більше нікого не потрібно якщо кожна з ролей має достатньої кваліфікації та бажання щоб виконувати свої обов’язки. Якщо ж кваліфікації та бажання немає то з’являються PM, PMO, TPO, BA, TW, і т.д. але то вже не scrum і використовувати найменування ролей та принципи з цієї методології вже немає ніякого сенсу бо то вже якийсь Ваший специфічний підхід який можливо норм для вашої команди, але на 99% не підійде для інших. До того ж Ви розказали тільки про роль ТРО в процесі який створили, але змовчали що ви там ще наміняли в стандартному scrum або nexus процесі щоб воно запрацювало, а також не надали жодних порівнянь в фінансовій, якісній та часовій складовій проекту щоб сказати що мати додаткового ТРО це якійсь профіт для проекту, а не тільки для Вас як людини що обіймає цю посаду та РО і Tech Lead Developers які скинули з себе частину роботи за яку отримують гроші.

This. Фактично це не нова роль, а просто частину ролі PO та розробників віддали окремій людині. Може бути працездатним рішенням для конкретного кейсу, але, по аналогії з програмуванням — це антипатерн та створення технічного боргу, тільки не в коді, а в управлінській структурі. Якщо ми добре розуміє, що ми цим виграємо та скільки нам буде коштувати «зробити нормально» в майбутньому — чому б і ні.

На мою думку Product owner має бути технічним у будь-якому випадку. Це велика втрата для команди якщо PO найняли тільки через підвішений язик. На жаль, більшість PO що я бачив — не технічні люди зі слабким розумінням розробки (але хорошим контактом з кастомерами і топ-менеджментом), а окрема позиція Technical PO — екзотика. Тож команда залишається ще й винною в тому що їй не надали достатніх вимог.

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

Щось виглядає як: PO нічого не розуміє, SA не має часу — най буде ще одна позиція, TPO — який по факту невідомо за що, й яким чином, відповідає. але з «листуванням у чаті, презентаціями та пошуком креативу»? Найс.

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

Так це ж обов’язки техліда.
Досить популярна структура РО + скрам мастер + тех лід + кілька інженерів.

Як на мене, то не вистачає ще одного порівняння: TPO vs Tech Lead. ІМХО це приблизно одна й та сама роль

По сути, описали рутину архитектора, как оно в жизни бывает.
Только не такого Ivory Tower half-time Architect

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

 а обычного живого полезного ithare.com/...​ive-to-coding-architects

Підписатись на коментарі