Det enkleste i verden er å komme på løsninger. Det vanskelige er å vite om vi løser riktig problem.
Det er mandag morgen for noen år siden hos en stor, statlig etat med ansvar for et samfunnskritisk område. Jeg sitter i et møterom med flere av de som kjenner domenet best. Oppdraget mitt er å forstå hvorfor utrulling og kvalitetssikring av leveranser i virksomheten ofte tar måneder lenger enn planlagt.
Det jeg så for meg som en ryddig prosess av dokumentasjon, testing og kvalitetssikring, viser seg raskt å være et komplekst økosystem av avhengigheter, uklare ansvarslinjer og overlappende krav.
«Problemet er ikke at vi ikke vet hva vi skal gjøre», sier en av dem.
«Problemet er at vi ikke vet når vi skal gjøre det, hvem som faktisk har ansvaret, eller hva som egentlig er godt nok.»
Det kunne vært sitert fra et hvilket som helst utviklingsprosjekt. Forskjellen er at her handler det om samfunnskritisk funksjonalitet, sikkerhet og menneskeliv.
Dette er heller ikke så veldig uvanlig. Etter mange år i store, gjennomregulerte virksomheter i både offentlig og privat sektor har jeg observert et paradoks: ekstremt lav risikotoleranse rundt løsninger – kombinert med overraskende lav bevissthet om å avdekke rotårsaker før man setter i gang.
Instinktet sier: finn flaskehalsene og fiks dem
I «Transformed» skriver Marty Cagan at de beste produktteamene bruker minst like mye tid på produktutforsking (discovery) som på å produsere (delivery). Det høres åpenbart ut, men i praksis hopper de fleste organisasjoner raskt til løsninger, særlig i komplekse, regulerte domener, som offentlig sektor er, men også finans og telecom, for den del.
Teresa Torres beskriver i «Continuous Discovery Habits» product discovery som et kontinuerlig arbeid for å ta gode produktbeslutninger, ikke som en fase i starten av et prosjekt. I stedet for å bruke innsikt til å validere en løsning vi allerede har bestemt oss for, argumenterer hun for at vi må bruke discovery til å forstå problemet og utforske flere mulige konsepter før vi låser oss til løsning.
Da jeg startet arbeidet med å kartlegge hvordan denne typen leveranser rulles ut, var oppdraget mitt tydelig: identifiser barrierer og foreslå tiltak. Instinktet mitt var også ganske klassisk: snakk med folk, tegn opp flyten, finn flaskehalsene og foreslå forbedringer.
I det første intervjuet kom det likevel et utsagn som fikk meg til å stoppe opp: «Problemet er ikke at prosessen tar lang tid. Problemet er at vi starter for sent med riktig dokumentasjon.»
Jeg hadde forventet å høre om lange løp, tunge runder og trege beslutningslinjer. I stedet ble det tydelig at mye av rotårsaken lå tidligere, i planleggingen, og i hva som må produseres før noe sendes videre i systemet.
Fem ganger «hvorfor»
God discovery handler nettopp om dette: å forstå hvilket problem du egentlig skal løse, ikke å få bekreftet løsningen du allerede har bestemt deg for. Det er nært beslektet med det Teresa Torres kaller et «discovery mindset»; Du er mer nysgjerrig på problemet og konteksten enn på å få rett i din egen idé. Da vi begynte å spørre «hvorfor?» flere ganger, endret problembeskrivelsen seg.
- «Hvorfor tar det lang tid?»
- Fordi dokumentasjon og avklaringer må gjentas.
- «Hvorfor må de gjentas?»
- Fordi krav og forventninger ikke er tydelige når arbeidet starter.
- «Hvorfor er de ikke tydelige?»
- Fordi ulike aktører tolker regelverk, ansvar og kvalitet på forskjellige måter.
Plutselig handlet det ikke lenger bare om en «treg prosess», men om manglende felles forståelse, uklare ansvarslinjer og sviktende koordinering på tvers.
«Discovery handler ikke om å validere løsningen din. Det handler om å oppdage hvilket problem du faktisk skal løse.»
Verdistrømkartlegging: når én boks skjuler flere ukers arbeid
Verdistrømkartlegging er et klassisk Lean-verktøy for å forstå hvordan verdi faktisk flyter gjennom en prosess, fra oppstart til leveranse. Enkelt sagt: du tegner opp alle stegene som må til for å levere noe, og ser hvor ting går bra, og hvor tiden forsvinner i venting, omarbeid og misforståelser.
I dette arbeidet brukte vi verdistrømkartlegging som et discovery-verktøy, ikke som et rent effektiviseringsverktøy. Målet var ikke først og fremst å «trimme prosessen», men å forstå hvor problemer oppsto, hvilke fagmiljøer som faktisk var involvert, og hvor ansvar og informasjon falt mellom stolene.
Da vi tegnet opp hele løpet, fra de første planene og dokumentene ble laget, via testing og avklaringer, til leveransen kunne tas i bruk, dukket det ikke opp én tydelig flaskehals, men et nettverk av små og store utfordringer:
- Krav til dokumentasjon som ikke var godt nok koblet til konkret regelverk
- Fagmiljøer som ble involvert sent eller alt for uforutsigbart
- Testing som skjedde mens løsningene fortsatt ble endret
- Manglende regelverks- og domenekompetanse hos dem som utformet løsninger
- Uklarhet om hvem som faktisk hadde myndighet til å si ja eller nei i ulike faser
Et konkret eksempel var et steg der en fagavklaring formelt lå inne som «en kort kvalitetssjekk», men som i praksis innebar at en nøkkelperson måtte sette seg inn i store mengder dokumentasjon på kort tid, ofte samtidig som vedkommende hadde andre driftskritiske oppgaver. På verdistrømkartet så dette ut som én boks; i virkeligheten var det her flere uker forsvant, fordi forespørsler kom sent, ustrukturert og uten tydelig forventningsavklaring.
Verdistrømkartlegging gjør nettopp slike ting synlige på én flate: hvem gjør hva, når, med hvilken informasjon, og hva som skjer hvis det ikke blir gjort. Det gir et felles bilde for alle involverte, og er derfor et kraftfullt verktøy i produktutforsking, særlig når prosessen går på tvers av enheter, fag og systemer.
Invester i discovery før du investerer i løsninger
De dyreste feilene gjøres ikke når du bygger feil, men når du bygger det rette svaret på feil spørsmål.
Både Marty Cagan og Teresa Torres peker på det samme: discovery handler om å redusere risikoen for å satse stort på feil problem, ved å utforske problemet og mulige løsninger tidlig og kontinuerlig før vi binder opp store ressurser i levering.
I regulerte domener med høye sikkerhetskrav er dette ekstra kritisk fordi du ikke har råd til å lære av feil i produksjon.
Discovery i offentlig sektor handler ikke om å kopiere metodikk fra teknologiselskaper. Det handler om å anvende de grunnleggende prinsippene: kartlegg hele verdikjeden, finn barrierene, still «hvorfor?» flere ganger og finn rotårsaken før du bestemmer deg for løsningen.
For den som vil lese mer om discovery i produktutvikling, anbefaler jeg særlig Marty Cagan: «Inspired» og «Transformed» og Teresa Torres: «Continuous Discovery Habits».
