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

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

Привіт. Я Настя, 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-спільноті