I föregående artikel gav jag en kort introduktion till PO-rollen och beskrev vad som normalt ingår i arbetsuppgifterna och inom vilka ansvarsområden. Ett av de mer centrala områdena handlar om användarbehov och krav. Det är också det området jag tänkte fördjupa mig i den här gången.
Beprövade metoder för att samla in behov/krav
Som jag tidigare skrivit om finns det många olika metoder för att effektivt samla in verksamhetens behov, krav och önskemål. Tyvärr finns det inga hundraprocentiga topplistor som visar vilka metoder som ger mest utan det enda jag kan rekommendera dig att göra är att testa lite olika varianter för att se vad som fungerar bäst i ditt team och i din organisation.
Jag har under mitt arbete i många olika typer av organisationer, stora som små, offentliga och privata kommit fram till att det inte finns något facit. Olika metoder fungerar olika bra beroende på en mängd olika faktorer och därför är det svårt att peka på ett visst tillvägagångssätt och en specifik metod.
En vanlig metod, som ofta används av frontendutvecklare och UX-are är så kallade personas som är ett slags fiktiva användarprofiler med namn, egenskaper och mål. Dessa bör grundas på riktiga användarintervjuer, men du kan med fördel även hitta på några så att du får ihop ett tillräckligt stort antal.
Om du aldrig har jobbat med personas kanske du tycker att det verkar lite suspekt, men sanningen är att det kan ge ganska mycket och framför allt visualisera dina användares behov på ett helt annat sätt än om du bara ser texter i ett dokument.
Användarundersökningar och intervjuer är ett annat sätt som kan vara effektivt för att samla in behov. Kan vara svårt inledningsvis och om det inte finns någon produkt att utgå ifrån, men om det redan finns en produkt/tjänst som används av flera användare är detta ett mycket bra sätt att få en djupare förståelse för användarnas behov och vad de skulle vilja ändra på.
Användardialoger, feedback och användarresor är andra sätt att skapa mer strukturerade processer för att samla in behoven löpande. Med resor menar jag att du följer användaren genom systemet/tjänsten/produkten och observerar hur de beter sig och vad som kan förbättras. Det finns ju en del tekniska verktyg för att hjälpa till med detta som t.e.x Matomo, AWStats, OW Analytics, Octopussy med flera men gemensamt för de allihop är att de endast ger den tekniska bilden av ett flöde.
För att få till en mer fulländad upplevelse krävs att du kanske filmar användaren, följer ögon- och musrörelser och samtidigt ber användaren ”tänka högt” så att du får så mycket input som möjligt.
Till allt detta som jag beskrivit finns ju ständigt det här med iterativ utveckling med små, små steg och med ständig feedback. Prototyping har funnits sedan 80-talet så det är inget nytt, men med dagens moderna verktyg är det väldigt enkelt att ta fram skisser, wireframes, prototyper och mockups. Jag tänker på verktyg som t.ex. Figma.
Lyssna aktivt och med empati
Det här är också en kär repris. En av de mest grundläggande byggblocken är det här med att lyssna aktivt och med empati. Det här är en svår konst att bemästra och en av de absolut viktigaste sakerna. Det är därför jag tjatar så mycket om den här konsten.
Se till exempel min artikel i serien om att skapa det optimala utvecklingsteamet som handlar om att hantera stress, konflikter och utmaningar eller i min bloggserie om att utvecklas till en Super Scrum Master i inlägget som handlade om att utvecklas som ledare.
Med det sagt tänker jag inte orda så mycket mer om det här utan jag råder dig till att läsa dessa artiklar där du kan få mer tips om detta.
Samarbete och kommunikation med intressenter
En annan viktig aspekt i din roll som PO är konsten att samarbeta och kommunicera med andra intressenter. För att lyckas med detta krävs att du både kan intressera och engagera intressenter. Det kan du göra genom att engagera dem tidigt i processen så att de kan vara med och bestämma och påverka från början.
På det sättet får du också deras feedback och kommentarer i ett tidigt skede och kan enkelt anpassa produkten efter önskemål som uppkommer.
Ju mer tid du ägnar åt att verkligen förstå dina intressenters behov och mål desto mer effektiv blir också din kommunikation och ditt samarbete med dem. En annan poäng med det här är att du indirekt skapar ett förtroende bland intressenterna. Om de ser att de kan lita på det du som PO åtar dig och utlovar å teamets vägnar bidrar det automatiskt till att du stärker tilliten mellan er.
Det är också viktigt att du bygger långsiktiga relationer med intressenterna. Om du är lyhörd, ödmjuk och nyfiken kommer du väldigt långt om du också kombinerar detta med ett aktivt och empatiskt lyssnande.
Hantera konflikter
Även om du har en bra dialog med era intressenter med öppna, ärliga kommunikationskanaler kan det hända att det uppstår konflikter eller meningsskiljaktigheter som behöver lösas. Anledningarna till detta är flera, men av de vanligare är att det plötsligt uppstår delade meningar om hur något ska lösas eller prioriteras.
När det händer, för det kommer att hända, är det viktigt att du som PO är väl förberedd och försöker sätta dig in i deras situation och förstå deras perspektiv. Här är det extra viktigt att du verkligen lyssnar aktivt och empatiskt eftersom detta påverkar hela teamets framtid. Om du inte kommer överens med intressenterna kan det att få stora negativa konsekvenser för hela teamet och dess framtida leveranser.
Det bästa tipset jag kan ge är att du lägger manken till och verkligen försöker hitta en kompromiss med intressenterna så att ni kanske kan hitta en lösning som tillfredsställer deras önskemål och samtidigt inte äventyrar målet med produkten. Nu är det kanske utopiskt att tänka sig att alla går superlyckliga ur den här konflikten/överenskommelsen, men ni kanske kan nå en lösning som gör ”minst ont”.
Dokumentera och ta lärdom av gamla misstag
Jag har tidigare pratat lite om vikten av att dokumentera och dra lärdom av sina misstag. Speciellt viktigt blir det i samband med att du ska kommunicera olika beslut till teamet. Detta hjälper till att skapa transparens och undviker missförstånd och tvetydighet. Samtidigt kan det ju vara svårt att veta hur du ska dokumentera och framför allt hur du ska strukturera upp allting.
Mitt råd till dig är att inte tänka så mycket på det utan att bara göra det! Det är ungefär som det här med träning. Om du sitter hemma och funderar på att börja träna och tänker att du ska gå dit och köra ett pass när du känner dig redo så kommer du troligtvis aldrig att göra det.
Lite på samma sätt är det med dokumentation. Om du ägnar alltför mycket tid på att fundera på hur du ska strukturera upp allting och vilka metoder du ska använda, ja då kommer du troligtvis aldrig att få igång arbetet med dokumentationen.
Fokusera istället på att komma igång med att dokumentera på något sätt så kan du parallellt fundera på hur du ska strukturera upp allting. Jag har full förståelse för att det kan bli jobbigt att skyffla runt och märka upp data i efterhand, men jag har flera gånger sett detta fallera på grund av att personen i fråga har snöat in på hur man ska göra istället för att bara göra det.
I nästa avsnitt tänkte jag komma in på hur du som PO kan hantera backloggen med några enkla metoder och hur du tillsammans med din Scrum Master ständigt kan hålla den aktuell.
