Proxy Product Owner – je na škodu?

V mnoha firmách se lze setkávat se situací, kdy product owner má sice svěřenou některou ze služeb, ale vedle něj méně či více dalších requestorů, kteří přichází se svými požadavky do backlogu dané služby. Je to dobře nebo špatně? Kdo by měl být Product Ownerem takové služby? Mohl by to být například správce budgetu, ze kterého je rozvoj dané služby financován. Nebo by to mohl být requestor s největším počtem požadavků. Nebo requestor s požadavky, které mají na službu největší dopad. Nebo někdo úplně jiný. Jak se vypořádat se situací, kdy Product Owner vlastně není až tak úplně Product Ownerem. Můžeme se setkat s označením Proxy Product Owner pro takovou roli.

V první řadě vás musím uklidnit. S výjimkou malých start-upů je taková situace více než běžná. V málokteré firmě vystupuje product owner jako ultimátní vlastník svěřené služby, který má nad všemi věcmi 100% kontrolu. Taková představa se sice objevovala v ranných definicích role Product Ownera, ale přiznejme si, že v prostředí jakékoliv větší firmy se jedná o představu značně utopistickou. Reálně do sféry vaší papírové kompetence product ownershipu zasahuje méně či více intenzivně množství vašich kolegů. Product Owner se tak brzy může cítit relativně prázdný. Může se stát, že je jen vykonavatelem přání a myšlenek jiných a to člověku, podle nastavení jeho mysli, na spokojenosti zpravidla příliš nepřidává. Jak se s tím vyrovnat?

V první řadě je potřeba akceptovat, že daný stav není špatně. Je to situace, která plyne z organizačních struktur větších firem a lze ji přirovnat k situaci, kdy se občas cítíte trochu v opozici vůči svému šéfovi. Nezapomínejte, že i on má svého šéfa a dost často se může cítit podobně jako vy, i když to na sobě nedá znát. Stejně tak v produktovém vlastnictví se můžete občas cítit trochu v opozici kvůli požadavkům, se kterými za vámi přicházejí vaši kolegové – ať už z důvodu, že s nimi ne úplně souhlasíte nebo čistě z důvodu, že jich je prostě moc a vy tak nemáte kapacitu na realizaci vlastních myšlenek a nápadů.

Druhým krokem je zpřehlednění procesu, kterým jsou požadavky od všech requestorů (i od vás) realizovány. To zahrnuje zavedení přehledné evidence všech požadavků – může jít o fyzickou tabuli, kam budou všichni lepit lístečky se svými požadavky nebo zavedení elektronické varianty pomocí některé z dostupných aplikací. Viditelnost všech požadavků je základním stavebním kamenem, který obrušuje hrany špatných pocitů vlastníků ve chvíli, kdy jejich požadavek nemá prioritu.

Dalším krokem je zavedení objektivní prioritizace. Způsobům prioritizace se budeme věnovat v samostatném článku. Doba, kdy prioritizace byla obdobou naslinění prstu a jeho vztyčení do poryvu větru je už naštěstí pryč. Prakticky každý požadavek, který se objeví lze objektivně prioritizovat – určit jeho hodnotu. Ta nemusí spočívat jen ve finančním vyjádření (o kolik díky tomu vyděláme více), ale i v úsporách. Objektivně lze hodnotit i přínos například technologických úprav, které na byznys a jeho výsledky nemají žádný dopad.

Posledním krokem k dobrému fungování je kvalitní komunikace. Ta musí být pravidelná a na všechny zúčastněné, resp. všichni zúčastnění musí mít k dispozici stejné informace, přičemž cesta, jak se k těmto informacím dostanou, může být různá. S některými kolegy je lépe si sednout a vše probrat osobně, jiným stačí hromadný status rozesílaný emailem.

Shrnutí výše popsaných základů efektivního fungování Product Ownera ve větším týmu:

• akceptace daného stavu, mentální přizpůsobení se dané situaci,
• zpřehlednění procesu řízení požadavků,
• zavedení objektivní prioritizace,
• kvalitní komunikace.

V dalším článku si povíme jak řešit mimořádné situace, které z pohledu Product Ownera, který obhospodařuje stádečko svých requestorů, mohou nastat.