V članku bom opisal nekaj dilem Product Owner (PO) vloge, izzivov povezanih z njo in anti-vzorcev, ki se lahko pojavijo v procesu.
Zaradi svoje obsežnosti, je Product Owner vloga običajno slabo razumljena. Razteza se namreč daleč izven okvira razvojnega teama katerega član je PO. Klub temu pa delegiranje teama ni njegova/njena naloga.
Mantro glede PO vloge, bi lahko povzeli na naslednji način:
“V Agilnem ekosistemu je Product Owner zadolžen za maksimiranje poslovne vrednosti iniciative.”
Različice PO vloge so prisotne tudi v ostalih Agilnih frameworkih (Product Manager, Solution Manager, Customer rep., Executive Sponsor, Project Manager). Napisano velja tudi zanje.
POGOJI ZA USPEH
Da Product Owner lahko uspešno opravlja svoje naloge, mora biti izpolnjenih nekaj pogojev:
- PO mora imeti pravico odločati o funkcionalnostih produkta, ki je subjekt iniciative.
- PO mora imeti pravico odobravanja sredstev za razvoj produkta.
- PO mora imeti dostop do ne-razvojnih resursov organizacije, kot na primer marketinga, poslovnih analitikov, strank, managementa.
- PO potrebuje podporo višjega managementa.
Izpolnjeni pogoji seveda niso garancija uspeha, so pa njegova osnova.
PRODUCT OWNER SPEKTER
Obstaja cel spekter na katerem se lahko v organizaciji nahaja PO.
Leva stran spektra je rezervirana za “ogrožene” PO, ki na iniciativo nimajo dovolj vpliva, da bi lahko uspešno usmerjali razvoj. Kljub temu pogosto nosijo krivdo za neuspeh produkta.
Product Owner, ki si želi maksimirati rezultat projekta, se mora potruditi, da se v tem spektru pomakne čim bolj v desno.
Ne bo sicer prevzel vloge podjetnika, (razen, če je lastnik) idealno bi pa bilo, če bi imel vlogo projektnega sponzorja. S tem efektivno prevzame tudi vlogo Produktnega Managerja z vsemi nalogami povezanimi s to funkcijo. V tem primeru so izpolnjeni zgoraj našteti pogoji, ki PO omogočajo učinkovito usmerjanje razvoja produkta.
Ne bom se spuščal v konkretne naloge in tehnike, ki jih uporablja PO oz. Produktni Manager. To je dobro dokumentirano v drugih virih, detajlno pa to temo obdelam tudi na Product Owner tečaju.
Poglejmo si kje se lahko zalomi.
ANTI-VZOREC 1
Pred časom sem se na svetovanju srečal z izredno strokovnim in proaktivnim PO, ki pa nikakor ni uspel najti skupnega jezika z razvojniki (dva teama na istem produktu). Po krajšem razgovoru z razvojniki je postalo jasno, da se čutijo preveč delegirane. Namesto, da bi PO na Backlog Refinement ali Sprint Planning predstavil poslovni problem, razložil zakaj smatra, da ima visoko poslovno vrednost in nato z razvojniki predebatiral možne rešitve, je PO razvojnikom posredoval kar lastno zamišljeno rešitev. Pogosto celo v obliki GUI wireframe ali arhitekturnega okvirja.
Razvojniki se niso čutili slišane. Zdelo se jim je, da so na avtopilotu in njihov potencial ni izkoriščen. Posledično je bila motivacija razvojnikov nizka. Po mojem mnenju še ni prišlo do globljih zamer, so pa verjetno bili na tej poti.
Delegiranje razvojnega teama ni v skladu z idejo in ne izkorišča potencialov samo usmerjajočega (self-managed) teama.
Žal zaradi določenih organizacijskih “odstopanj”, podjetje izraženih ugovorov razvojnikov do tedaj ni upoštevalo. PO je bil v prejšnji vlogi namreč razvojnik in ga je vodstvo smatralo za kompetentnega, da razvojnike tudi naprej usmerja na tehničnem področju.
PO bi se moral zavedati, da so sedaj njegove naloge drugačne in poznati faktorje, ki vplivajo na motivacijo razvojnikov. Poleg tega se polno zaposleni PO nima časa ukvarjati s tehničnimi detajli ampak se posveča produktnemu managementu.
Odnos PO in razvojnikov bi lahko strnili na naslednji način:
- PO določi ZAKAJ ima določen problem poslovno vrednost (tržne raziskave, razgovori z uporabniki, analiza).
- PO in razvojniki se skupaj dogovorijo KAJ je potrebno narediti, da se problem reši. To so funkcionalnosti rešitve (scope).
- Razvojniki se odločijo KAKO in KDO bo scope realiziral.
Ne samo v razvojnih teamih, ampak v celotnem Agilu velja, da naj problem rešujejo tisti, ki so mu najbližje. Mogoče bi bila delegirana rešitev lahko celo boljša, ampak če je razvojniki ne sprejmejo kot svojo, bojo trpeli motivacija, kvaliteta in feedback za prihodnje nadgradnje. Delegiranje teama ni naloga PO. Agilni teami so samo organizirajoči in samo usmerjajoči (v okviru produktne in organizacijske vizije).
“Manj optimalna rešitev, ki jo izberejo razvojniki sami, v izvedbi praviloma prekaša bolj optimalno delegirano rešitev.”
ANTI-VZOREC 2 (COPY-PASTE PO, TICKET MONKEY)
PO tretira Product Backlog kot preprosto skladišče zahtev po funkcionalnostih, ki so jih posredovali naročniki/deležniki. Zahteve razbije na pod-funkcionalnosti, epike ali celo uporabniške zgodbe in jih kot blok umesti v backlog. Pogosto je to FI-FO backlog, kjer PO ni preveril poslovnih vrednosti posredovanih zahtev. Glede na to, da je zadolžen za uspeh celotne iniciative, bi moralo to biti samo po sebi umevno. Žal ni.
Ta anti-vzorec je posledica nerazumevanja lastne PO vloge v Agilnem okolju. Takšni teami pogosto ne izvajajo Backlog Refinement srečanj. Ta so (poleg ostalega) namenjena izogibanju pastem, ki jih kreira takšen anti-vzorec:
- Identifikacija odvisnosti med Product Backlog Items (PBIs), ki lahko vpliva na poslovno vrednost posamezne zahteve.
- Združevanje PBIjev v skupno arhitekturo omogoča sinergično izvedbo in s tem nižanje stroškov razvoja in višanje poslovne vrednosti posameznega PBIja.
- Kritična presoja PBIjev s strani razvojnikov glede zahtevnosti ali celo poslovne vrednosti. Razvojniki so pogosto tudi sami v neposrednem stiku z naročnikom in imajo vpoglede, ki jih PO mogoče nima.
- Optimizacija rešitev. Naročnik mogoče zahteva celoten nov programski modul, pa je njegov cilj v resnici mogoče doseči s spremembo par vrstic programske kode.
- Tudi naročnik se v svojih zahtevah lahko moti. Mogoče funkcionalnost, ki jo želi, že obstaja?
Backlog Refinement nudi tudi druge koristi, ki niso neposredno povezane s tem anti-vzorcem. V zrelih razvojnih okoljih, teami porabijo okoli 10% časa za Backlog Refinement.
ANTI-VZOREC 3 (ZAKRINKANI PROJEKTNI MANAGER)
PO se obnaša kot tradicionalni projektni vodja. Spremlja dokončanje nalog, roke in individualno uspešnost razvojnikov, namesto da bi se osredotočil na maksimiranje vrednosti produkta.
Ta anti-vzorec je posledica zastarelega načina razmišljanja. Takšen PO je verjetno ocenjevan (in nagrajevan) glede na količino opravljenega dela, ne glede na ustvarjeno poslovno vrednost.
V podobnem primeru je potrebno:
- Preveriti ali je podjetje v resnici pripravljeno izvesti organizacijske spremembe, ki jih zahteva Agilni pristop. Mnoga podjetja tega niso pripravljena, ovijajo pa se v zastavo Agilnosti, delujejo pa v tradicionalnem hierarhičnem okviru. Seveda so rezultati v takšnem primeru daleč pod potencialom. Žal tega, dokler je podjetje profitabilno, ne bo nihče opazil. Ko pa tržni pritiski postanejo preveliki (tehnološki zaostanek), je pogosto prepozno.
- PO je potrebno izobraziti o prednostih Agilnega načina dela in mu/ji odvzeti možnost ocenjevanja individualne uspešnosti razvojnikov (ter s tem njihovega nagrajevanja). V Agilu se ocenjuje le teamsko uspešnost in to z merilom ustvarjene poslovne vrednosti.
- Vpeljati OKR za uskladitev poslovnih zahtev in razvojnega dela. To v našem primeru pomaga predvsem “navzgor”, ker management prisili v definiranje profitabilnih poslovnih objektiv, kar do sedaj verjetno ni bila praksa. Pravtako OKRji omogočajo merjenje uspešnosti iniciativ in s tem določajo odgovornost glede njihove uspešnosti. Seveda si marsikdo tega ne želi.
