Talangprogrammet: Att vara produktägare

Tack vare att vi lär oss att agera på våra insikter så kan vi utföra en massa saker utan att detaljplanera innan. Och det är inte ovanligt att saker som vi har detaljplanerat i slutändan inte alls blir som vi tänkt oss.

Att vara produktägare

Med produktägare menar vi den person från verksamheten som kan ansvara för att produkten når uppsatta mål samt den som under utvecklingsprojektet har mandat att prioritera och fatta beslut. Man behöver ha kunskap om vad produkten skall leverera för värde och nytta och till vilken målgrupp. Det kräver även att man förstår att den största nyttan uppstår först när man börjar att använda produkten, därav att man försöker korta ned tiden mellan idé och när funktionen finns i produktion. Under arbetets gång så måste man hela tiden prioritera och förstå konsekvenserna av detta. Att vara produktägare innebär att du måste vara engagerad och tillgänglig under hela utvecklingen.

Att kravställa

Kan vi inte bara specificera alla krav och önskemål och beställa arbetet? Vi vet ju vad vi vill… Hur var det nu?

Vi lär oss hela tiden, och kunskapen ger oss nya insikter vilka skapar nya förutsättningar.

Detaljspecifikationen blir snabbt inaktuell, och hur vi än gör kommer våra krav att vara föremål för löpande förändring, samtidigt som vi hela tiden kommer ställas inför situationer där vi måste fatta beslut om förändringar. Alltså är arbetet att sätta ihop detaljspecifikationen i ett tidigt skede inte så viktigt som man instinktivt kan tro.

Talangprogrammet är ett utbildningsprogram på Valtech som riktar sig till juniora ingenjörer och studenter i slutskedet av utbildningen. I programmet ingår en blandning av utbildningar, certifieringar och projekt.

Projektet den här omgången är att utveckla en webbapplikation för att presentera konsult-CV:n och projektteam till kunder i samband med offerter.

En inte helt ovanlig uppfattning är att, om du inte kan detaljspecificera alla krav och önskemål, så har du inte tillräcklig beställar-kompetens. Troligtvis är det så att det är just dessa personer av denna uppfattning som inte skall beställa något annat än färdiga produkter.

Produktägare

Jag har under ett antal veckor haft förmånen att vara produktägare i vårt (Valtechs) talangprogram. Talangprogrammet är ett utbildningsprogram på Valtech som riktar sig till juniora ingenjörer och studenter i slutskedet av utbildningen. I programmet ingår en blandning av utbildningar, certifieringar och projekt. Projektet i den här omgången är att utveckla en webbapplikation för att presentera konsult-CV:n och projektteam till kunder i samband med offerter.

Vi är ett konsultbolag och lever på att sälja vår kunskap, så man kan säga att kunskap är vår kärnverksamhet. För att säkerställa och dokumentera vår kunskap och erfarenheter samt för att kunna kommunicera detta till våra kunder behöver vi ett verktyg för att hantera konsultprofiler.

Målsättning

Målsättningen med webbapplikationen är att skapa ett verktyg som ersätter dagens hantering av konsultprofiler, vilket består av wordfiler på vårt intranät.

Samtidigt vill vi lyfta upplevelsen för våra kunder dels den grafiska designen men också användbarheten. Andra viktiga målsättningar i projektet har varit att tidigt kunna releasa en beta. Detta är en viktig framgångsfaktor för att så tidigt som möjligt få in synpunkter och önskemål för att ha möjligheten att ta hänsyn till dessa i den första leveransen.

Projektupplägg

Projektet har drivits med tvåveckors-sprintar som avslutats med öppna demos (inbjudan på intranätet). Sprintarna börjar med en sprintplanering bestående av genomgång av backloggen, den lista med krav och önskemål som kommer från produktägare och stakeholders (användare och andra intressenter). I backloggen är varje önskemål och krav på funktioner formaliserade som userstorys enligt följande struktur:

”Som en… Vill jag… För att… ”

Detta gör vi för att få en bra överblick över de krav vi har. Meningen är att det ska vara kortfattat och ungefär lika mycket text i varje krav, detta gör att det är lätt att få en överblick och prioritera. Att ha en färdig struktur hjälper till att få ner sina userstories på ett överskådligt sätt. När teamet sedan jobbar med varje userstory kommer de att bryta ned dessa i mindre beståndsdelar, men det är oftast inte nödvändigt att veta om alla detaljer när man i rollen som produktägare ska prioritera userstorys.

I och med att backloggen förändras (userstorys tillkommer, förändras eller tas bort löpande, en naturlig del i lärandeprocessen) så börjas arbetet alltid med att prioritera aktuella userstorys. Prioritering sker utifrån vilket värde funktionen ger i förhållande till omfattningen att utveckla funktionen. Teamet får också vikta omfattningen av varje enskild userstory enligt ett poängsystem. I början är det svårt att uppskatta hur många poäng som teamet kan leverera under en sprint men för varje sprint så blir teamet bättre och bättre på att uppskatta. Som produktägare är det viktigt i början att vara medveten om detta och att vara beredd att prioritera om (ta bort, lägga till storys).

Erfarenheter från projektet

Att vara produktägare är inte en helt enkel uppgift och jag har försökt sammanfatta det jag ser som de tre viktigaste framgångsfaktorerna:

• Tillgänglighet: som produktägare måste man vara tillgänglig under hela projektet för att kunna diskutera och bolla ideer. Det betyder inte att produktägare är ett heltidsarbete, lika lite som det betyder att det är ett arbete man kan schemalägga ex. måndagar och tisdagar.

• Mandat: som produktägare ställs du inför situationer där du måste fatta beslut om prioriteringar. Beslut som kräver att du förstår konsekvenserna ur ett kostnads-, tids- och användarperspektiv. Om produktägaren inte har mandat innebär det stora risker att det påverkar tidsplanen och därmed kostnaderna i projektet.

• Engagemang: självklarhet för de flesta på pappret men inte alltid självklart i verkligheten. Som produktägare måste man vara engagerad i arbetet, bolla ideer, göra prioriteringar etc. Det är också produktägaren som skall se till alla stakeholders intressen och formalisera dessa till userstorys.

Hur gick det?

Då återstår frågan, hur gick det? Vi har lanserat en webbapplikation för att hantera konsultprofiler och vi har uppfyllt följande mål:

• Ersätta befintlig lösning (wordfiler på intranätet). Check

• Ett system där alla profiler finns tillgängliga. Check

• Förbättra upplevelsen och användbarhet, kund får länk till profilen som är responsive (anpassar sig till aktuell enhet), och det går att exportera profilen till PDF för utskrift.Check

• Det går att sätta ihop förslag på projektteam där det går att lägga till en inledande text och där de olika profilerna visualiseras i en vy. Check

Resultatet blev bättre än förväntat då budget = tiden varit begränsad och inte funnits möjlighet att utöka. Men sättet att arbeta har medfört att vi tillsammans löpande kunnat göra prioriteringar för att säkerställa att vi fokuserar på att leverera värde utifrån målbilden. Med oss har vi dessutom en backlogg med massor av värdefulla userstorys att ta till nästa version. User storys som tillkommit tack vare den lärande process som ett utvecklingsprojekt innebär.

Det är skillnad i synsätt på ovan eller att tolka det som att vi inte levererat hela lösningen. Vi har uppnått våra mål och lite därtill även om vi fortfarande har massor med userstorys kvar.

Den version som är byggd hittills är dessutom en fullt fungerande lösning med den funktionalitet som ger oss mest affärsvärde.

Så vad är slutsatsen? Traditionella projektmodeller där vi försöker detaljspecifisera alla krav i förväg innebär att vi kommer missa en hel del värdefulla funktioner, och vi kommer samtidigt bygga funktioner som inte levererar värde.