Доброго дня, Марино.

Дякую за увагу до моєї статті.

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

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

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

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

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

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

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

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

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

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