Product Owner survival handbook

Jak nevytvářet backlog nesplněných slibů

Každý, kdo slyšel o agilním vývoji, asi ví, kdo je scrum master a co je jeho úkolem. Ne všichni ale vědí, kdo přesně je product owner. Z důvěryhodného zdroje vím, že zatímco školení na scrum mastera jsou poměrně dobrým obchodním artiklem, naplnit pár míst na školení product ownera je problém. Přitom si upřímně myslím, že dobrý product owner je pro jakoukouliv agilní software firmu důležitější než scrum master…

PO.png

Ještě před tím, než se pustím do samotného psaní o product ownerovi, musím zmínit svůj důležitý poznatek o software společnostech: lidé se v nich dělí na dva druhy a to na business people a software people. Business people jsou manažeři, obchodníci, finančníci, accounťáci, supporťáci  a tak dále. Software people pak jsou vývojáři, scrummasteři, admini, testeři, architekti, designeři, UXáxi, DBAčka a tak.

Product owner je zcela zvláštní typ a má moc tyhle dva, docela často rivalizující, tábory spojovat. Hodně ale záleží na tom, jak je role product ownera ve firmě ukotvená. Může to být buď plnohodnotný product owner nebo proxy product owner.

il-PO

Pošťák alias proxy product owner

Pošťak je velmi běžným typem product ownera. Hlavním důvodem je fakt, že lidé, kteří skutečně definují produkt, nemají disciplínu a čas se tomu skutečně věnovat. Dost často ani něchtějí být ve styku se software lidmi, protože nepatří do jejich světa. V ten okamžik je na snadě vytvořit product ownera, který dostává přesné informace, co se má dělat a ten je pak jen tlumočí software lidem.

Slovo tlumočit je zavádějící a notně zjednodušené. Tlumočení většinou reálně znamená přepisování „projektů“ na user stories, starání se o backlog, poskytování informací vývojářům. Na takového product ownera je často nahlíženo jako na ryze software člověka a jeho možnosti ve sbližování business a software lidí jsou proto limitované.

Product Owner mission

Když se zeptáte, co je hlavním úkolem product ownera, asi nejčastější odpověď bude, že se stará o backlog. To je určitě pravda, ale pojdmě to pojmout trochu jinak, užitečněji…

Hlavním úkolem product ownera je maximalizovat ROI (return on investment). Produkt owner společně s business lidmi definuje vizi produktu, rozkládá jí na proveditelné projekty a ty poté doručuje v menších celcích zvaných user stories. Nástroji, které k tomu využívá je soubor lean a agilních technik, zprostředkování komunikace a zdravý racionální úsudek. V ideálním případě je product owner v kontaktu i se zákazníky.

Product Owner musí být dobrý posluchač, který je schopen pochopit očekávání uživatelů a transformovat je v doručitelné projekty. Měl by mít kuráž odmítnout nesmyslné plány, ale měl by to být schopen provést diplomaticky, vědom si toho, že vše, co se zdá být nesmyslné v sobě může nést i užitečné nápady.

Product owner by se měl vyhnout slovům ne a nikdy. Slovník založený na ne teď hned a později je v komunikaci mnohem praktičtější.

Product owner by měl určitě rozumět projektům i po technické stránce. Musí být schopen v diskuzích se scrum masterem a  vývojáři chápat technické apekty práce a je tlumočit business lidem, a to jazykem, kterému business lidé rozumí. V backlogu se vždy budou kromě front-endově orientovaných features objevovat i čistě technické nebo back-endové user stories. Product owner jim musí rozumět a musí být schopen vyhodnocovat jejich důležitost.

V neposlední řadě je product owner vlastníkem backlogu a je zodpovědný za projekty, které v něm jsou a jak reflektují to, co firma nejvíce potřebuje. O tom si ale řekneme více za chvilu.

Nevděčná role?

Z výše uvedeného je jasné, že role product ownera je důležitá. Je zde ale jeden zádrhel. Product owner je v pozici někoho, kdo byl měl doručovat výsledky skrze práci jiných lidí, nemá ale všechny nástroje, pomocí kterých to může realizovat. Pokud se věci nedaří, tak jak mají, může spoléhat na své charisma, může si stěžovat managementu, může se snažit motivovat lidi pomocí výsledků jejich předchozí společné práce, může dělat bububu. A tím to asi končí. Tohle je z mého pohledu velký rozdíl například oproti scrum masterovi, který je vybyven poměrně slušným řídícím arzenálem.

Je dobré si tohoto být vědom a mít pozici product ownera ve společnosti dobře ukotenou a respektovanou. Zajistit takové chápání product ownerovi role je úkolem managementu a product ownera samotného. Neúspěšnými projekty si moc respektu nevybuduje…

Zacíleno na úspěch

Tohle je opravdu důležité a možná je to klíčová věc proto, aby firma přijala agilní metodologii. Většina projektů a nápadů, které vznikají v hlavách obchodníků, produkťáků a zákazníků, je často tak nějak featurově přestřelená. Asi mají pocit, že honosnější a komplexnější featura udělá zákazníkům větší radost a bude z toho více peněz. Může to být motivováno i  pocitem, že když už se jim projekt podaří protlačit do vývoje, tak tím z toho takhle vymáčknou maximum. Samozřejmě také chtějí, aby to bylo v produkci co nejdřív. Bohužel, tenhle přístup je víceméně agilně leanový antipattern. Pojdmě si to ukázat na příkladu:

Naši zákazníci musí při každé platbě znovu a znovu vyplňovat údaje o kreditní kartě. To vede k nižším konverzím, protože čast z nich si platbu jednoduše rozmyslí.

Pojdmě jim umožnit, aby si své karty mohli uložit v našem systému. Při placení by si pak pouze vybrali kartu se seznamu uložených a zaplatili víceméně na jeden click.

Skvělé, to dává smysl. Při dalším přemýšlení o featuře a o tom, jak by to mělo fungovat, nám začnou vyskakovat další věci, které je potřeba doplnit.

Protože zákaznící mohou mít v sytému uloženo více karet, měli by mít možnost své karty upravovat, přidávat a mazat. Proto nechť existuje malá webová aplikace, kam se přihlásí svým emailem a heslem a tam si budou své karty spravovat.

Když už máme tohle, tak je celkem logické, aby zákazník přihlášený do této webové aplikace viděl svoje předešlé transakce a měl možnost nahlásit support ticket ohledně problémů s placením.

Zakazníci by měli mít možnost prohlížet si v bezpečném webovém rozhraní transakce udělané jednotlivými uloženými kartami a měli by být schopni platby reklamovat.

Už víte, kam tím mířím? Je to záměrně nadsazené, ale ne že bych podobné kreativní brainstormmingy nezažil na vlastní kůži… Takže tady máme projekt na vytvoření webové služby na správu uložených karet, s přehledem historie plateb, reklamací. Všechno je propojené s vlastním platebním formulářem, tak že zákazník může uložené karty použít místo zadávání čísel manuálně. Budeme muset řešit přihlašování do aplikace, registrace, lost password emaily a bezpečnost nové aplikace.

Odhadem třeba 2 – 6 mešíce práce pro jeden tým a rovnou můžeme jít napsat několik user stories. Těžko říct, kdy se to dokončí a jestli tak velký projekt kdy dostane zelenou.

Dobrý product owner bude schopný z výše uvedeného vydestilovat základní esenci toho, co je chtěno a toho, co přinese zásadní část business hodnoty.

Jeho redukovaný návrh může znít:

Zákazník si muže jednoduchou akcí (zaškrtnutí checkboxu) uložit právě použitou platební kartu pro použití při následných platbách. Při další návštěvě bude karta již předvyplněna a zákazník se bude moci rozhodnout, zda-li ji použije nebo zadá jinou. V případě uložení karty zákazník dostane email s linkem na odstranění karty ze systému.

Dovolil bych si tvrdit, že rozdíl v náročnosti implementace původního projektu a redukované varianty je zásadní. Business value doručená oběma projekty však bude srovnatelná.

Projekt bude doručen. Idea bude validována reálnými zákazníky. A protože to nebyl nijak velký projekt, nic nebrání tomu, aby se v blízké době přidalo něco dalšího z původního velkého plánu. Možná ale bude rozumnější investovat čas do jiné části systému a adresovat tam jinou důležitější oblast, která přinese větší business value.

Toto je jeden z lean přístupů a toto je práce product ownera.

Backlog slibů

Chápů, že následující řádky nemohou být přímo aplikovatelné u všech typů projektů. Nejlépe to funguje v continuous delivery prostředí. Důležitá je ale základní myšlenka toho, co se vám pokusím sdělit…

Slovo backlog pro mě osobně v sobě nese jakousi negativní konotaci. Je to seznam neudělané a nedokončené práce. To nezní moc pozitivně. Když se snažím zmapovat stav věcí v nějaké firmě, ptám se kolik věcí mají v backlogu. Obvyklá odpověď je 100 a víc.  To je moc a dá se na to nahlížet jako na klasický leanový waste.

Pokud máte takhle velký backlog, tak jeho obhospodařování někomu konzumuje více času, než je zdrávo. Určitě existují i lidé, kteří trpělivě sledují nějakou položku na seznamu a ona jim pořád zůstává někde hluboko dole, daleko od možnosti být realizována. Dlouhý backlog je seznamem slibů, z nichž mnoho se nikdy neodehraje. U takového backlogu se reálně mění často horních deset položek, přicházejí tam nové a ty ostatní tam tak nějak zůstávají a čekají. Takový seznam je zdrojem frustrace a dokumentuje fakt, že s vývojem software není něco v pořádku.

Co se mi osvědčilo, je nahrazení dlouhého seznamu user stories v backlogu  dokumentem, který definuje vizi, kam by se produkt měl v horizontu, dejme tomu, nasledujících 6 měsíců ubírat a jaký přínos by takový posun měl mít. Tato vize může mít formu dokumentu o několika málo stránkách a je to určitý deal mezi business lidmi a product ownerem. Product owner pak může v rámci této vize vytvářet user stories tak, aby v každý daný okamžik, kdy se píše nová user story, udělal ten nejužitečnější krok k naplnění vize. V backlogu pak bude mít cca. 4 – 8 user stories. Kdykoliv, kdy je nejvýše položená story dokončena a z backlogu odstraněna, může přidat novou a to na základě toho, co bylo doposud uděláno a toho jakou business value to přinese. Toto chápu jako skutečně iterativní project development, dlouhé seznamy předpřipravených stories postrádají flexibilitu.

Ze zkušenosti mohu říct, že software lidé jsou rádi, když vizi znají. Jinými slovy, vědí na čem budou v následujících měsících zhruba pracovat. A skrze backlog několika málo user stories mají detailnější a detailní informace o tom, co konkrétně budou dělat nejbližších dnech a týdnech.

Pokud ve vás vře pocit, že tohle není způsob, jak pracovat, protože nejsou jasné deadlines a datumy doručení featur, zkuste se na chvilku zamyslet nad tím, jestli je lepší featury skutečně doručovat a zároveň při tom stíhat fixovat bugy a drobné requesty nebo jestli vám vyhovuje dlouhý backlog a deadlines, které se stejně pořád jen oddalují.

Vize, je současně kontraktem mezi business a software lidmi na čem se primárně bude pracovat v určitém období. Pokud se dohodnete, že cílem následujících šesti měsíců je radikálně vylepšit konverze vašich platebních stránek a pak vám neustále chodí požadavky na vylepšovaní interních reportovacích nástrojů – máte nad čím přemýšlet.

Zákazník, který průběžně dostává dobré featury a jeho požadavky jsou reflektovány, bude spokojený a nepotřebuje nerealistické sliby, které ho mají u vás udržet.

 

Variety Reducer a Flow Maker

Ač to může znít ošklivě, na tým vývojářů se můžeme dívat jako na stroj, který zpracovává materiál jedoucí na přepravním pásu. Pokud se jednotlivé balíčky (materiál) jedoucí na pásu bodou zásadně lišit ve své velikosti a složitosti, bude muset i stroj, který je zpracovává být složitější a bude obtížnější předpovědět, jak dlouho zpracování  balíčků bude trvat. Variety se samozřejmě týká i frekvence přísunu balíčků. Pokud se frekvence mění, stroj bude někdy přetížen a nebude stíhat balíčky odbavovat, v jiných okamžicích bude stát a nebude mít, co zpracovávat.

il-belt-1

versus

il-belt-ok

Doufám, že ilustrativní příklad pomohl. Pojďme se podívat, co to reálně znamená pro product ownera.

Product owner by se měl snažit udržovat stálé a předvídatelné flow práce. Čím méně neočekávaných situací bude nastávat, tím předvídatelnější bude doručování user stories. Neočekávanými situacemi rozumíme hlavně:

  • příliš mnoho práce s těsnými deadlines v jeden okamžik (zahlcení prací)
  • střídání velkých a miniaturních user stories
  • prostoje, kdy není co dělat (nedostatek práce nebo špatná příprava user stories)

Dosažení flow obvykle vyžaduje dvě akce ze strany product ownera. První je jasná, musí se snažit spolu s týmy vytvářet user stories, které jsou podobně veliké. Já mám dobrou zkušenost s user stories, které zaberou jednomu týmu jeden až dva týdny. Druhá akce je zakomponování asynchroních událostí jako je řešení software defektů (bugs), různých malých požadavků (requests) a řešení technického dluhu (td) do flow práce na user stories.

Tato ad hoc práce by měla být rozumným způsobem prioritizována a důležité problémy a menší požadavky by měl tým být schopen řešit za chodu. Jinými slovy tým by si měl najít rozumné rozdělení času tak, aby předvídatelným způsobem doručoval user stories a zároveň průběžně řešil duležité bugy a triviální a malé změny.

il-board

ukázka vytvoření wip limitů na různé typy práce. User stories vs bugs & requests

 

Některé firmy používající scrum se tomuto vyhýbají. Řešení bugů a requestů vždy odkládají na další sprint nebo tuto práci dělá někdo jiný. To je sice možné, ale má to několik zásadních úskalí:

Jednak, business lidé přestanou mít agilní přístup rádi. Nechápou, proč některé triviální nebo důležité věci musí zbytečně čekat. Výsledkem je to, že agilní přístup začnou chápat jako velice neflexibilní a výhodný pouze pro software lidi. Pokud budete odmítat vyřešení urgentnějších problémů nebo triviálních změn s tím, že pracujete na sprintu, vystavujete se také velkému riziku, že  se vám to vrátí jako bumerang až některý ze sprintů nestihne doručit přesně to, co měl a co bylo naplánováno.

V setupu, kdy někdo píše „nový“ software a někdo jiný primárně fixuje jeho defekty, se poruší zdravý code ownership. Ti, co píší nový software, přijdou o důležitou zpětnou vazbu a jejich motivace řešit kvalitu aplikace může být potlačena. V neposlední řadě v takovém setupu může vzniknout řevnivost mezi těmi, co bugy produkují a těmi, co je musí opravovat.

Nájít způsob, kterým se flow práce naladí pro potřebu konkrétní firmu, je opět důležitým úkolem product ownera.

Závěr

Mohl bych pokračovat v psaní dál a dál. K product owneru se toho dá napsat opravdu hodně. V tomto článku jsem se záměrně vůbec něvěnoval těm základní aktivitám jako je práce s backlogem, splitovaní user stories, odhadovaní velikosti, atd. Myslím, ale že o tom je informací na internetu docela dost. Šlo mi spíš o to, vypíchnout několik témat, které odlišují obyčejného product ownera od opravdu dobrého…

 

 

 

 

 

Reklamy

3 thoughts on “Product Owner survival handbook

  1. martinpavlas napsal:

    Anglicismy použité v tomto článku vzbuzují docela dost emocí. Chápu to a nejsem z toho nijak šťastný. Je mi to líto, ale je téměř nemožné se jim vyhnout. Agilní vývoj i jeho terminologie byla vytvořena v anglicky mluvících zemích a překládání termínů by bylo kontra-produktivní a poměrně směšné. Kolem roku 1997 se mi dostala do rukou jedna z prvních českých knih o javě – „appletům“ se tam říkalo „jablíčka“. Nechtěl bych se dostat do podobné situace 🙂

  2. Marek Cais napsal:

    V našem týmu pro AdHoc issues máme rotující pozici — tzv. Rychlou Rotu (známé také pod termínem Kadibudky). Jeden člověk z týmu vždy řeší bugy, supportní issue a obecně maintenance záležitosti. Cca po týdnu (vždy až po dokončení aktuálního issue) se pozice posune dál. Tímhle způsobem aspoň není daný člověk téhle méně populární práci vystavená dlouho.

    • martinpavlas napsal:

      Ano, to taky funguje. Je to jen další způsob, jak alokovat část zdrojů na fixovaní bugů/maintenance, tzn. máte na to systém a průběžně se tomu věnujete. Je dobré, že lidi rotojute – takovou práci dlouhodobě nedělá nikdo rád. Mám jedinou poznámku k zamyšlení. Pokud děláte scrum nebo cokoliv, kde se dělají daily-standups, je dost pravděpodobné, že ten člověk, co fixuje bugy, stojí trochu mimo hru. Představuje to nějaký problém nebo je to v pohodě?

Zanechat Odpověď

Vyplňte detaily níže nebo klikněte na ikonu pro přihlášení:

WordPress.com Logo

Komentujete pomocí vašeho WordPress.com účtu. Odhlásit / Změnit )

Twitter picture

Komentujete pomocí vašeho Twitter účtu. Odhlásit / Změnit )

Facebook photo

Komentujete pomocí vašeho Facebook účtu. Odhlásit / Změnit )

Google+ photo

Komentujete pomocí vašeho Google+ účtu. Odhlásit / Změnit )

Připojování k %s

%d bloggers like this: