Proč máme Product Ownera

O roli Product Ownera toho bylo napsáno hodně. Přesto však některé firmy nepochopily jeho význam a berou takového člověka jako administrativní sílu. Ostatně, kdo jiný by měl mít čas být týmu k dispozici a psát jasné a konkrétní User Story. Product Manager na to nemá čas, v lepším případě je furt u zákazníka, v horším řeší takových produktů několik nebo jen tráví většinu času na obecných firemních mítincích a stihnout to ani při nejlepší vůli nemůže. V obou případech se pak velmi často setkáváme s modelem, kdy o všem rozhoduje Product Manager, který ale nemá čas, a takzvaný Product Owner se na všechno chodí ptát, protože o čemkoli rozhodne, stejně Product Manager shodí při customer demu ze stolu. Vychází to z neochoty a často i neschopnosti delegovat, nesmyslné organizaci, a také toho, že takový Product Owner není nositelem vize a sám jí často nerozumí. Jak se to pozná? Zeptejte se ho, proč by tým měl na produktu pracovat. Většina takových Product Ownerů odpoví něco ve smyslu, že to asi firma potřebuje… že… Když tím testem přeci jen projde, obvykle se zasekneme hned na další otázce, proč děláme tuhle User Story. A kde je její business value. Co přinese zákazníkovi? A obvyklá odpověď je ‘no Product Manager nebo zákazník to tak chce‘. Kde se pak má brát motivace a zapojení týmu a proč by zrovna na tomhle produktu měli pracovat?

Samozřejmě i takové rozdělení role Product Ownera mezi více osob může fungovat. Jeden příklad z nedávné praxe. Máme Product Managera co nemá moc čas. Je to vizionář, většinu času cestuje po světě a je v letadle. Oblítává zákazníky z různých koutů světa, vymýšlí inovace, dívá se, co má konkurence. Aby tým nebyl od produktu odtržený, není tento člověk vnímán v roli plného Product Ownera, ale spíše interního zákazníka, co chodí s high-level nápady. Product Owner je s ním v častém kontaktu, sdílí spolu nápady a vize, přemýšlí, co by se mělo jak udělat, co změnit. Product Manager je zodpovědný za budget a celkový úspěch produktu na trhu. V podstatě by šlo i říct, že definuje Backlog na úrovni Epiců maximálně velkých Super User Stories, zatímco reálný Product Owner se za pomoci týmu stará o to, aby vznikla správná granularita User Stories a tým byl na produkt, vizi a business value napojený. Je součástí Backlog Groomingů, je zodpovědným za Product Backlog, jeho hodnotu a porozumění týmu. Výhodou je, že takový Product Owner má v roli Product Managera zástupce, a když se stane, že z nějakého důvodu není k dispozici, tak Product Manager převezme jeho roli a tvoří s týmem User Stories. Je to tedy jen o lidech. Tihle to zvládli rychle a nejsou zdaleka jediní. Ale není to bohužel zdaleka tak obvyklé, jak by bylo potřeba.

Další obvyklý problém v této oblasti je neschopnost firem se nad portfoliem produktů zamyslet a nějak je omezit nebo prioritizovat a serializovat. Takové firmy si myslí, že tím, že se na produktu už pracuje, je zajištěna jejich úspěšnost. Musíme dělat všechno najednou. A tak se některé firmy podobají střelcům s automatickými zbraněmi, co sice mají zavázané oči, ale o to více střílejí kolem sebe. Čím více výstřelů, tím větší pravděpodobnost že se do něčeho nakonec trefíte… S takovou strategií vám v efektivitě a úspěšnosti nepomůže nic. Ani Agile, ani krásný formát User Stories. Role Product Ownera je tu proto, aby se někdo staral o to, co nám to přinese a s pomocí agilních metod dostal na business nápady rychlou zpětnou vazbu. Když se to neosvědčilo, zahoďte to a zkuste něco jiného. Ale na to musíte mít již v začátku jasnou představu, co chcete dosáhnout a jak poznáte, že se to povedlo. Jinak střílíte kolem a doufáte, že se to tentokrát povede. Agile a Scrum není jen o týmu a spolupráci, ale je o napojení na business a zpětné vazbě. Je o schopnosti prioritizovat. A to nejen na úrovni User Stories a každého produktu, ale i produktů v rámci firmy. A to se bohužel ve spoustě firem neděje.

Super User Story, User Story a Epics

Jak už jsem psala v minulém příspěvku, User Story musí vytvářet obrázek, být nezávislá, popsatelná, přinášet hodnotu, ohodnotitelná, malá a testovatelná – tedy v originále: Independent, Negotiable, Valuable, Estimatable, Small, Testable requirement (zkráceně “INVEST”). Tedy něco, do čeho chcete investovat úsilí a potažmo peníze. Po té co se pokusíte User Story takto definovat, často zjistíte, že potřebujete ještě něco co je širší, co vám drží globální kontext a jednotlivé User Story pohromadě.

K dispozici jsou dva koncepty. První se na User Story dívá jako na entitu, která jde v podstatě donekonečna škálovat a zavádí tak pojem Super User Story – např. Jedu na výlet do Evropy – nebo jen do Německa – nebo jen do Berlína – nebo chci navštívit Berlínské Egyptské museum. Je to takový strom vnořených User Story. Samozřejmě že když to takto rozdrobíme, budou se nám jednotlivé User Story (listy toho stromu) samostatně jen velice špatně prodávat jako super zájezd. Ale na druhou stranu, asi si umíte představit zájezd jen s památkami bez jídla a zájezd all inclusive. A s vaším produktem je to podobné. Také obvykle existuje funkcionalita, kterou můžete oželet a která vlastně není tak prioritní.

Druhý koncept zavádí pojem Epics, kde Epics je něco co jednotlivé User Story zastřešuje – tedy taková souhrnná Super User Story. Epics se ovšem již nepíše ve formátu ‘jako uživatel, chci funkcionalitu, abych dostal business value‘, ale zároveň se jako takový nedá naplánovat do sprintu a ani nechat reálně týmem ohodnotit. Na to je v něm skrytá moc velká dávka nejistoty.

Obě varianty jsou v podstatě podobné, a pomáhají vám udělat si představu o backlogu, ujasnit si co má jakou prioritu a kde je jaká přidaná hodnota.