Prosess og rådgivning / 5 minutter /
Skal Product Owner være en allviter?
På JavaZone snakket Tim Berglund fra Github om hvordan Product Owners ved å være eiere av domenekunnskap tok fra utvikleren muligheten til å ha forståelse for det som skulle lages.
Kvitte oss med Product Owners (PO)
Her er lenke til foredraget Tim holdt: First, Kill Alle the Product Owners. Sitatet er fra Shakespeare, og er ikke så brutalt ment som sagt. I foredraget fortalte Tim hvor inspirert Github er av en bok av Daniel H. Pink: Drive The Surprising Truth About What Motivates Us. Og den var tilfeldigvis lesestoffet mitt på vei til og fra JavaZone.
Grunnen til at jeg har lyst til å skrive om temaet er at etter å ha hørt på foredraget kom to av mine kloke kolleger - uavhengig av hverandre - bort til meg og sa: "men det går jo ikke hos oss".
Daniel H. Pink sier at autonomi (selvbestemmelse), mestring og formål er de tre sentrale punktene enhver arbeidstaker må ha.
Så hva var det Tim sa, og hvorfor tror de det ikke går hos oss? Og hva er det de tror ikke går? Daniel H. Pink sier at autonomi (selvbestemmelse), mestring og formål er de tre sentrale punktene enhver arbeidstaker må ha. Hvorfor? Fordi en medarbeider som ikke har autonomi ikke har engasjement for jobben. Og uten engasjement får man lett mennesker som gjør det de får fortalt, men ikke noe mer. Det mine kolleger tror ikke går - hvis jeg forstår dem riktig - er at vi som en skreddersømsbedrift må gjøre som kunden sier - ikke det vi vil selv. Vi har altså ikke selvbestemmelse. Men hva har det med Product Owner å gjøre?
Tim sin påstand er at hvis en utvikler/konsulent skal ha selvbestemmelse må han/hun forstå hva det er som skal lages. Derfor må konsulenter ha forretningsforståelse og sette seg godt inn i det domenet de skal lage noe for.
Normalt er Product Owners definert som den som har domenekunnskap, mens konsulenten er utøvende. Det som blir igjen til systemutvikleren er "lag det som er beskrevet her"-rollen.
Har du prøvd å løse en oppgave der du får en oppskrift og ikke forstår hvorfor du skal gjøre det og hva det skal brukes til? Hvor god kvalitet ga det? Nemlig! Derfor er jeg helt enig med Tim i at hver konsulent må forstå. Det er sløsing hvis du ikke bruker hodene til de som lager løsningen. De må tenke ut hva som er best for kunden - og for kundens kunde. Og da må de forstå. Hver konsulent må være nær kunden, og forstå så mye som mulig av kundens forretning. På den måten kan de bidra ordentlig til hva som skal lages.
Vi ønsker at hver konsulent skal være nær kunden, og forstå så mye som mulig av kundens forretning
Men betyr det at vi skal kvitte oss med Product Owners? La oss se på hva mer Tim sa først.
Ikke bare forstå, men også bestemme
Tim sa at en konsulent må få bestemme selv hva som skal lages. Altså ikke bare forstå, men også bestemme. Og det er her mismotet til kantegerne kommer inn; "det går jo ikke - vi må lage det kunden vil". Ja, hvis vi lager noe kunden ikke vil ha så kan det være vanskelig å få betalt. Men jeg kjente en rådgiver en gang som sa at når kunden kommer til deg og sier hvor han skal, så tar du han i hånden og leder ham dit han trenger å være.
Når kunden kommer til deg og sier hvor han skal, så tar du han i hånden og leder ham dit han trenger å være
Når en kunde kommer til oss for at vi skal lage noe, så kan oppdraget ha forskjellig kompleksitet og detaljeringsnivå. Uansett skal vi alltid stille oss spørsmålet "er det virkelig det du trenger?" Når vi forstår kundens behov kan vi si "du burde be meg om å lage dette isteden, for det vil gi en bedre oppfyllelse av dine behov."
I Github lager de verktøy som andre utviklere trenger, og siden de selv er utviklere betyr det at de lager verktøy som de trenger selv. I Kantega lager vi systemer som forskjellige kunder trenger. Forskjellen mellom oss og Github er altså hvor forskjellig kunden er fra oss selv og våre egne behov. Hva slags betydning har det for skaperlysten til hver enkelt konsulent? Forutsatt at det utvikler seg et tillitsfullt forhold mellom kunde og konsulentene vil de ha stor frihet til å foreslå løsninger. Og forutsetningen for et tillitsfullt forhold er bl.a. engasjement hos konsulenten.
Hittil har jeg skrevet som om det er én konsulent som jobber med en kunde. Men ofte er det flere. Forskjellige konsulenter har forskjellige talenter, og bidrar inn på forskjellige nivå i løsningen. Utfordringen blir da å ta vare på medkonsulentenes autonomi innenfor det området de kan best, og samtidig viderebringe og forbedre den forståelsen som man oppnår. Forståelsen må deles på en måte som åpner, ikke stenger. Flere hos oss har benyttet Effect Maps for å få til en slik deling, og jeg har inntrykk av at det fungerer bra.
Forståelsen må deles på en måte som åpner, ikke stenger.
Så igjen tilbake til Product Owner - er jeg enig i at de skal vekk? Nei, men de skal være seg bevisst det ekstra ansvaret de har for å legge til rette for at alle i teamet utvikler forståelse for kunden og kundens behov. De skal ikke være en allviter, men en tilrettelegger. Product Owners representerer ofte mange interessenter, og må også passe på å bringe interessentenes forståelse inn i arbeidet direkte, ikke bare som en videreformidler.
Svaret til mine kolleger ang. selvbestemmelse? Hvis du vil ha fullstendig frihet til å gjøre akkurat hva du vil, så bør du kanskje finne deg et annet sted å jobbe. Hvis du synes det er meningsfylt å lage nyttige og gode løsninger for mennesker du blir godt kjent med, så skal du fortsette å være her.