Boost og Nick Butler: https://www.boost.co.nz/blog/2018/05/stakeholders-in-scrum-product-owner
Produkteierskapet for smidige tverrfaglige team er noe som engasjerer og diskuteres, uten at noe tydelig svar utkrystalliseres. Min holdning er at produkteierskapet er det smidige akilleshæl, og at dette er et område som bør videreutvikles hos alle virksomheter med tverrfaglige team. Det er mange som har innført produkteiere gjennom kun å endre stillingstitler fra produktsjefer eller prosjektleder, noe som er for lettvint da produkteierskap er en dramatisk endring fra historisk lignende roller.
Jeg tror det er vanskelig å løse produkteierskapet på eget kontor, og de fleste trenger å samarbeide tett med teamet. Et godt produkteierskap er kritisk for suksess, faktisk så viktig at hos FINN.no så vi en dobling i effektiviteten hos team som hadde en langsiktig produkteier som klarte å engasjere og involvere.
Produkteierskap for tverrfaglige team handler om å forstå brukeren bedre enn brukeren selv, forstå teknologien som man bruker og som man kan ta i bruk, være i tett dialog med organisasjonen og ledere, og legge en inspirerende visjon: Tenk stort, start smått. Dette er meget vanskelig. Under oppdrag som produkteier så trenger jeg å samarbeide tett med tech lead og interaksjonsdesigner, hvor vi i samarbeid lager en god backlog. Denne backlogen forankres mot ledere og viktige interessenter. I tillegg så var teknologene med på brukerintervjuene, og interaksjonsdesigneren med på teknologimøtene. Vi var ett team. Den ekstra tiden vi bruker på tverrfaglige møter får vi igjen i god kommunikasjon, engasjement og kreativitet.
Det undrer meg at man fortsatt skiller mellom funksjonelt og teknisk ansvar innen programvareutvikling. De fleste andre som skal utvikle produkter, enten det er sjokolade, bil eller et hus, er dette skillet mellom funksjonelt og teknisk ansvar absurd.
«Bilen skal ha behagelige seter, komme i 4 ulike farger, være stilig, og ha et behagelig ratt. Den tekniske kvaliteten og kjørekomforten får de i fabrikken selv håndtere, da jeg ikke kan noe om teknologi»
Det enkleste på en løsning, er å få laget funksjonaliteten. En av Silicon Valleys mest legendariske nordmenn, Chris Halvorsen, sa til meg en gang: «Utvikling er enkelt. Google setter sammen et team, og vips så lager de funksjonalitet. Det vanskelige er drift og å få denne løsningen til å fungere dag og natt.» Det ingeniørene strever med er å lage en løsning som kan skaleres, kommunisere med andre løsninger og ha høy driftskvalitet. Dermed trenger alle tverrfaglige team en produkteier som også har kompetanse på disse kostbare og kritiske elementene.
Spør du brukerne (noe jeg har gjort i flere omganger gjennom spørreundersøkelser), så er brukerne opptatt av at basisfunksjonaliteten virkelig fungerer. Dermed blir datakvalitet og tilgjengelighet mye viktigere enn ekstra funksjonalitet og brukervennlighet. Dette er egenskaper med din løsning som må beskrives, diskuteres, utvikles og overvåkes sammen med teamet.
Dersom datakvaliteten er dårlig, så kan «dritten» med fordel være nede spør du brukeren. Dersom du for femte gang forsøker å kjøpe en bil via FINN.no, og den ikke er til salgs, så gir du opp hele markedsplassen uansett hvor høy tilgjengelighet den har og vakre websidene er.
Med kvaliteten og tilgjengeligheten på stell, så blir det viktig at løsningen er intuitiv og lett å bruke. Til slutt så håper du at løsningen kan gi deg ny innsikt, slik som at den bilen du tenkte å kjøpe har hatt mange feil, eller er dårlig likt av andre eiere.
For å lykkes med dette blir det dermed kritisk at produkteier ser på seg selv som en del av teamet, og at alle er involvert i å lage brukerhistorier. En produkteier er gjerne en del av en produkteiergruppe, og må ofte forholde seg til en ledende produkteier (CPO — Chief product Owner). Det er derfor fornuftig at produkteieren har ansvar for prioriteringen av backlogen, men da må han også ta ansvar for teknologien når løsningen ikke fungerer. Hadde du vært produkteier hos en bilprodusent, så ville produkteieren måtte forsvare hvorfor bilen har kvalitetsproblemer. En produkteier bør aldri peke på teamet når løsningen har feil, men alltid peke på seg selv.
Originally published at Linkedin on September 12, 2018.
------------------------------
Produkteier er det smidiges akilleshæl, del 1 was originally published in
Coworkforce on Medium, where people are continuing the conversation by
highlighting and responding to this story.
