Har du varit med om att en funktion inte riktigt blev som ni hade tänkt er? Att nya krav dök upp gång på gång under utvecklingen och kanske även efter det att funktionen blev klar? Fick ni slita era hår för att ni missat basala krav som påverkade hela domänen? Kan det ha varit så att ni sköt mot ett väldigt oklart mål utan att ha insett det i tid?
När vi skriver stories eller diskuterar funktioner så är det väldigt lätt att fastna på små detaljer, och samtidigt helt missa att diskutera de viktigaste frågorna: Varför gör vi just det här? Vad är målet? Teamet tänker gärna ur slutanvändarens perspektiv och det är inte alltid det överensstämmer med de affärsmässiga målen. Låt oss ta ett exempel på en funktion som för de flesta känns självklar. Tänk dig en sajt med artiklar som behöver en ny kommentarsfunktion. Vi har väl alla läst kommentarer på en sajt och vi får väl alla en tydlig bild i huvudet av hur en sådan funktion ser ut. Tänk lite på vilka krav du kan tänka dig på en sådan funktion. Har du en klar bild i huvudet? Bra.
Låt oss titta närmare på funktionen…
Ur användarperspektiv kan kraven vara: snabbladdad, lätt att använda och komma igång med, inga besvärliga registreringar, möjlighet att kommentera anonymt, samt så få klick som möjligt för att läsa många kommentarer.
Affärsmässigt kan målen vara: så många sidvisningar som möjligt pga bannerannonseringen som drar in pengar, samt så bra sökmotorindexering som möjligt för att dra trafik. Ur andra delar av organisationen kan kravet vara att inloggningen ska ske via tex Facebook för att minska skräpkommentarer, eller olika funktioner såsom filter för att stoppa spam, hot eller olämpliga länkar.
Från marknadssidan är förmodligen registrering innan kommentarer eller en Facebook-koppling högaktuell, med förhoppningen att samla in mer användaruppgifter som sedan kan användas både för annonsering och kampanjer. Där kanske kraven blir direkt motsatta till användarperspektivet, det mest värdefulla är en omfattande registrering där användaren måste uppge mycket information om sig själv.
Bland utvecklarna i teamet kan dessutom andra mål dyka upp, några av utvecklarna kanske tycker att det här är ett gyllene tillfälle att passa på att refaktorera en del gammal skräpkod som är kopplad till kommenarsfunktionen. Några andra i teamet kanske ser chansen att få prova ett nytt ramverk eller en ny teknik som inte använts förut och äntligen få möjligheten att lägga lite tid på det.
Driftavdelningen kanske allra helst vill att hela kommentarsfunktionen ska läggas ut på en extern tjänst då databaserna redan går på knäna, eller att en viss teknik ska användas för att underlätta lagringen.
Den ansvariga utgivaren för sajten behöver följa lagen och vill definitivt ha bra system för moderering av kommentarer, att IP-adresser och kommentarer ska sparas på ett bra sätt, att vissa IP-adresser ska kunna blockeras, och möjligheten att kunna stänga av kommentarsfunktionen snabbt i en krissituation. Frågan är även om kommentarerna ska förhandsmodereras och godkännas eller efterhandsmodereras.
Slutligen kanske sajten använder ett externt företag för granskning och godkännande av kommentarer. Det företaget behöver komma åt kommentarerna med allt vad det innebär, inklusive inloggning och åtkomst utanför brandväggen, samt deras egna krav på användbarhet för sina moderatorer, som smarta listningar efter tidpunkt och IP-nummer, och enkel radering av kommentarer.
Hur många av de här målen missade du när du snabbt tänkte dig funktionen? Hur ofta diskuterar vi en så enkel funktion ur alla aspekterna? Även den bäste produktägaren kan missa någon av alla vinklingar av en funktion.
Ändå har jag alltför ofta sett hur man överhuvudtaget inte diskuterar mål med nya stories eller funktioner, varken mindre eller större. Saker ska göras utan att man tar en vidare diskussion på varför man gör det och vad målet är.
Direkta och indirekta mål
Vad är det egentliga direkta eller indirekta målet med just den funktionen? Underlätta för användaren eller underlätta för en administratör någonstans? Ge en slutanvändare mervärde eller få intäkter till företaget? Vara före konkurrenter eller förbereda inför en annan funktion som kommer senare? Är det på grund av lagkrav eller för att få testa en ny teknik? Ta inte för givet att någon inblandad vare sig vet, eller helt har tänkt igenom det, oavsett om du är produktägare eller utvecklare – ifrågasätt!
I min erfarenhet händer det väldigt ofta att man skjuter snett för att man inte har hela bilden klar för sig och inte ställer rätt frågor tillräckligt tidigt och inte blandar in rätt folk. Dessutom är det mycket mer givande att arbeta med en funktion när man vet varför och vilka effekter man hoppas uppnå i slutändan, både som produktägare och utvecklare. Viktigt att poängtera är dock att jag inte här rekommenderar förstudier eller utredningar, utan smarta frågor inför sprintplaneringar och i diskussioner mellan produktägare, kravspecialister och team.
Hur kan man göra istället?
I flera team jag varit inblandad i har vi lagt till “Varför” och “Mål” i våra stories med stränga krav på tydliga mål av produktägaren. Vi har uppmuntrat varandra att verkligen fråga varför och vem i flera sammanhang. I de verktyg eller mallar för stories vi använt har vi lagt till fält för “Varför” och “Mål” för att ytterligare tvinga fram dem, vare sig de funnits på papper, ett kalkylark eller i ett verktyg som tex Jira.
Jag kan varmt rekommendera att lägga till sådana fält. Det kan till och med vara smart att ha tydlig plats för flera mål, teamets, produktägarens/företagets, slutanvändarens, etc.
En populär metod i agila kretsar är “5 whys” för att komma till roten till problem. Metoden går ut på att man fortsätter att fråga “Varför?” tills man når grundproblemet. Det kan man gott prova även i det här fallet men med annat fokus: “Vi behöver en ny kommentarsfunktion” – “Varför?” “För att den gamla är usel” “Varför är den det?” “Det går inte att göra X och Y?” “Varför vill man kunna göra det?/Vem vill att det ska gå att göra?”. Släng gärna in lite “vem” och “vad” också för att hitta krav från andra avdelningar.
En annan bra idé är att gemensamt skissa upp vilka intressenter som egentligen finns runt funktionen. Uppmuntra till att tänka ett steg längre, såsom drift och externa partners som inte omedelbart dyker upp, men kan vara nog så viktiga. Kanske ni kan rita upp en mindmap över alla som faktiskt har intresse av det ni utvecklar på ett stort papper? Sätt upp på väggen och titta på det varje gång ni funderar på en ny funktion!
Hur mycket vi än pratar om kortare feedback-loopar i agila kretsar så är vi usla på det. Gör en pappersprototyp direkt på mötet när ni pratar om funktionen och kontrollera att ni förstått varandra! Visa upp funktionen under utvecklingens gång – och för fler än de självklara intressenterna. Vad skulle någon på kundservice säga om den där nya funktionen för kunden tex? Vänta inte på slutdemon, eller ännu värre till efter release när resten av företagets avdelningar får en chans att se vad som hänt och kan reagera.
Det bästa exemplet jag har sett är ett team där flera olika intressenter faktiskt var med på standup varje dag och sedan fanns tillgängliga direkt efteråt för teamet att visa upp vad de gjort. Direkt efter standup ryckte utvecklarna dem och visade vad de gjort sedan sist, frågade om oklarheter i kraven, ifrågasatte användbarheten i funktionen eller föreslog en helt annan lösning de själva kommit på. En kvart om dagen vigde de – hur många timmar, misstag och veckor av svordomar vi vann på det går knappt att tänka sig.
En stor fara är de små funktionerna som “bara är att göra” eller “bara erbjuder en liten extra funktion”. Där är det i min erfarenhet rätt vanligt att man glömmer att tänka till. Tyvärr är det rätt ofta just där man skjuter helt snett och det upptäcks alldeles för sent. Det är också där små till synes banala saker kan råka strida mot lagar, viktiga policys på företaget, eller ställa till med säkerhetsaspekter man inte tänkt på. Våga vägra ta in små funktioner som “bara är att göra” utan att tänka igenom den. Kanske kan en mindmap över intressenter hjälpa er där?
Om du känner igen problemet med krav som upptäcks för sent, intressenter som inte är självklara och snabbfixar som ställer till med problem långt efteråt, prova någon av de här teknikerna! Nästa gång ni diskuterar ny funktionalitet, en snabbfix eller skriver en story, tänk till lite extra om målet, skissa upp intressenterna och prata med någon på en annan avdelning. Med lite eftertanke och övning kan ni slippa rätta till fel som aldrig borde ha uppstått och göra grymt mycket bättre funktioner redan från början.
Lycka till!