Före agila metoders intåg gjorde många alldeles för mycket analys, för länge, av det system, produkt eller tjänst som skulle utvecklas. Nu gör vi alldeles för lite, under för kort tid, under stress, press och leveranshets.
Det finns en bra mellanväg i processen där vi kan tänka utan att fastna, där vi kan ta reda på fakta först utan att gräva för djupt, där vi kan undersöka, rita, diskutera och testa utan att för den skull vänta med att börja.
Att få tid
Det finns stunder i mitt yrkesliv då jag har fått eller tagit tiden som behövs för att förstå ett problem. På riktigt.
Ibland har jag fått den tiden från en chef eller kund. Vid ett tillfälle var uppgiften: “Du får tre veckor på dig att ta fram en rapport om Feature Area X. Genomför på vilket sätt du vill. Om tre veckor ska vi upp i Tech Buzz Market Reports och ge vår bild av läget.
Tre veckor! Jag som brukar få tre dagar, eller tre timmar på sin höjd att sätta mig in i och förstå ett nytt område. Att ta fram en lösningsidé, value proposition, usp (unique selling point), testbara hypoteser och kundinsikter. För en hel produkt eller tekniskt område. Den här gången fick jag tre veckor. Wow!
På tre veckor hinner en produktledare ganska mycket har jag upptäckt. Och ibland behövs mer tid, ibland mindre. Oavsett om det är tre veckor eller tre månader som avsätts, så uppstår skillnaden när fokus tillåts vara på ETT område, i stället för hundra under en period.
För att förstå ett problem. När det finns tillräckligt fria händer att ta in den hjälp och kompetens som behövs, av kollegor eller utomstående.
På tre veckors fokuserad arbetstid går det att utforska omvärlden, intervjua, testa, prototypa, göra affärsanalys, följa användbara modeller (vilka oftast tar mer än tre timmar), samtala och testa med kunder, och konkurrensjämföra produkter. Det finns även lite tid att bevaka forum, läsa (många) rapporter, sätta sig in i statistik och nyheter.
På tre veckor kan det finnas tid, i mitt fall med lite hjälp av en designer, att sammanställa och beskriva insikter på ett pedagogiskt, visuellt och tydligt sätt. Något som spar mycket tid när det finns fler än ett par involverade parter.
På tre veckor finns det tid att rita, bolla idéer med olika personer, rita om.
På tre veckor finns det tid att gräva fram de siffror som behövs, för att få en uppfattning om kostnader, istället för att bara gissa.
Vid det här tillfället fick de som behövde ett bra och gediget underlag som de kunde använda för att fatta sina beslut. Tillsammans med andra underlag och egen research.
Jag blev fascinerad av hur mycket jag och andra hinner med på tre veckor, när förstoringsglaset hålls riktat mot ett område. Vilka insikter som kan bubbla upp till ytan
Förstår vi problemet?
Det här exemplet är ovanligt, därför är det värt att nämna.
Ofta är det istället så att en produktägare, en ux-designer, affärschef eller systemutvecklare, inom loppet av timmar eller minuter förväntas ha svar på komplexa frågor om affärsmöjligheter, kundbehov och tekniska strategier.
Vi förväntas att kill- och tjejgissa oss fram till lösningar på problem som knappt är formulerade. Vi förväntas att med blixtens hastighet leverera en roadmap och så snabbt som möjligt börja bygga, utveckla appar och andra tjänster i full fart. Så länge det syns action är vi både agila och effektiva.. eller?
Jag slås av hur bra det blir, när jag eller någon annan, sätter stopp för leveranshetsen och inte ger ett svar direkt. När vi bestämmer oss för att undersöka och förstå problemet vi just ställts inför.
“Vad är frågan egentligen?”
“Vet vi ens vad kundens eller vårt eget problem är?”
“Är det här något vår organisation borde lösa?”
“Om det är det, har vi rätt förutsättningar för det?”
“Och vad är vår strategi, egentligen? Någon som vet?”
Vi behöver gräva under ytan.
Självförtroende
Genom att ägna lite mer tid, åt ett problem, och ta reda på det som krävs för att förstå bättre, så får vi också självförtroende i de lösningar, hypoteser och experiment vi föreslår.
Åtminstone upplever jag det så. Jag har upplevt ett lugn de gånger jag med hjälp av t.ex intensiv “prao” hos de användare som ska köra min produkt, har förstått på riktigt vad som kan hjälpa dem och inte,
Eller de gånger när jag tagit tid att rita upp och visa de observationer jag gjort, flöden av information, användare och data.
Ibland har det varit en workshop i begrepp eller domänmodell som har gett en stor grupp många insikter om vad “vi egentligen håller på med”. Även om workshopen tog flera halvdagar.
“Har vi verkligen tid med det här?” Ja!
När jag under många dagar tog med mig team-medlemmar och besökte, praoade, hos en inköpsavdelning som vi skulle leverera ett nytt systemstöd till, fick jag just frågan av uppdragsgivaren. “Har ni verkligen tid med det där?”. Mitt svar var: “Har vi tid att inte göra det?”
Som Rich Hickey säger i sitt tal på samma tema “Step away from the computer”: “De flesta av de största problemen i mjukvaror är problem som beror på missförstånd.”
Rekommenderas varmt: Hammock Driven Development - Rich Hickey
Skjuta från höften
Att hetsa fram roadmaps och lösningar, att skjuta från höften, kan ibland fungera. Det har jag sett i organisationer som är riggade för att snabbt kunna ta bort det som var dåligt, och göra om, prova något nytt.
Det är inte många organisationer som är rustade för det. Som är rustade för snabba svängningar i investeringar, uppstarter och nedstängningar. Jag har varit på en, resten har behövt betydligt längre cykler både för att starta upp och lägga ner ett initiativ.
Vi kan spara månader och års utveckling på att ge problemformulering och lösningsidéer aningens lite mer tid och fokus.
Att ha alla svar i huvudet direkt, kan fungera för vissa frågor. Med erfarenhet kommer en viss magkänsla som kan vara rätt, och ibland väldigt fel. När är det okej att gå på magkänsla? När är det inte det? Det viktiga är vi ställer den frågan, i stället för att bara rusa fram i magkänslan varje gång vi får ett nytt kundbehov, produktidé eller affärsproblem i knät.
Agila metoder och problemförståelse
Vart tog tiden för problemförståelse och research vägen?
I takt med agila metoders spridning så verkar det som att en del viktiga aktiviteter kastades ut. Det är inte konstigt: många inom IT-utveckling kom från organisationer som tidigare led av analys-förlamning, där ingenting någonsin kom ut i kod och allt skulle analyseras och specas i minsta detalj. Kanske skrämde det oss så mycket att hela analysen åkte ut i det agila stålbadet som många utvecklingsorganisationer gått igenom senaste 20 åren.
Att gå från att tänka för mycket, till att inte tänka alls, verkar vara där vi hamnat nu.
Det finns en bra plats däremellan. Och kanske är vi mogna nu att ta oss an det.
Det behövs utrymme där vi får tänka och bena ut frågor lagom mycket. Det behövs tid att prototypa lagom mycket innan vi kastar oss över implementation av komplicerade lösningar som snabbt kan bli onödiga, instabila eller obegripliga tjänster – eller som bara har onödigt höga kostnader, för att lösa ett kanske enkelt problem.
“Vi borde lösa problem, inte lägga till features!” säger Rich Hickey.
Einstein tyckte också problemanalys var viktigt. Han lär ha sagt “Om jag har en timme att lösa ett problem, så spenderar jag 55 minuter på att fundera på problemet och 5 minuter för att tänka på lösningen.”
Var sak inom digital utveckling förtjänar sin tid. Det går inte snabbare om vi hoppar över analysen - tvärtom.
Ulrika Vincent 
Ulrika has a background as a software developer, product leader & analyst, manager, change leader and other roles in digital development. Currently growing skills in data analytics,statistics & Python. She has been working with several popular mobile apps, web services & other platforms in Sweden such as Res I Sthlm, Travis, SL, Expressen, KTH, Fritidsresor (TUI), Coop, Lantmännen and SoapUI.
Ulrika has a passion for problem solving, data driven work and understanding the users real needs. To build high quality products. She encourages self directing and cross functional work, testing, open data and learning.
You can contact her for open questions or support within digital product development
- E-post: ulrika@agical.se
- LinkedIn: Ulrika Vincent