Hvordan Discovery og de 5 hvorfor'ene sikrer at du bygger det kundene virkelig trenger - ikke bare det de ber om.

Programvareingeniører vet at datamaskiner gjør akkurat det de blir bedt om – ikke nødvendigvis det vi har tenkt. Dette gapet blir større når kravene kommer fra ikke-tekniske interessenter eller når en forespørsel tar for seg symptomer i stedet for underliggende problemer.

Så hvordan kan du redusere risikoen for å implementere feil ting? To enkle fremgangsmåter er til stor hjelp:

• Oppdagelse å forstå konteksten og det ønskede resultatet
• De 5 grunnene å avdekke årsaken til problemet (slik at det ikke kommer tilbake i en annen form)

I Notas IT bruker vi begge deler tidlig i prosessen, vanligvis i det aller første møtet etter at vi har mottatt et krav.

Oppdagelse: Start med kontekst, ikke kode

Når en kunde sender en forespørsel som "bygg X" eller "legg til Y", behandler vi den som et utgangspunkt - ikke som det endelige kravet:

• Hvem opplever problemet (roller, team, kunder)?
• Når skjer det (hyppighet, topptider, spesifikke scenarier)?
• Hva er konsekvensene (penger, tid, feil, churn, compliance-risiko)?
• Hvor dukker det opp (systemgrenser, integrasjoner, prosesstrinn)?
• Hvordan vil suksess se ut (målbare resultater, ikke leverte funksjoner)?

Først når vi har forstått disse, kan vi bruke de 5 hvorfor-ene til å trykkteste om vi løser det reelle problemet.

De 5 hvorfor-ene: Gjør "en forespørsel" til "en årsak".

5. Hvorfor er enkelt: Ta utgangspunkt i problemstillingen og spør "hvorfor?" til du kommer frem til en årsak du kan handle ut fra. Det handler ikke om å avhøre kunden – det handler om å skape en felles forståelse. Ofte trenger du ikke nøyaktig fem. Noen ganger trenger du tre. Noen ganger trenger du syv. Og i programvareprosjekter er det en ekstra detalj: Selv om symptomet er synlig på ett sted, kan årsaken ligge i et helt annet lag.

De "fem lagene" der problemene skjuler seg (og hvorfor dette passer til Discovery + 5 Whys)

I de fleste tilfeller legger brukeren merke til feilen eller den inkonsekvente oppførselen i brukergrensesnittet. Men systemer er mer komplekse enn så. Et typisk forretningssystem har flere lag, og hvert lag kan skape symptomer som dukker opp andre steder. Når vi undersøker et problem og jobber med å finne en løsning, graver vi oss derfor vanligvis gjennom fem lag:

1. Kode for brukergrensesnitt
2. Backend-logikk og rammeverk
3. Databasestruktur og datasett
4. Brukergrensesnitt, backend og databaseservere
5. Operativsystem (og kjøretid for miljøet)

Disse lagene tvinger deg naturligvis til å spørre "hvorfor?" flere ganger. En klage på brukergrensesnittet kan faktisk skyldes backend-validering, en databaseindeks, begrensede serverressurser eller et problem på operativsystemnivå. De fem "hvorfor"-spørsmålene gir deg en struktur som gjør at du unngår å stoppe opp for tidlig – og Discovery hjelper deg med å velge riktig vei gjennom disse lagene basert på konsekvenser for virksomheten, reelle arbeidsflyter og begrensninger. I praksis gir Discovery deg retning, og 5 Whys gir deg dybde.

Eksempel 1: "Vi trenger en knapp for eksport til Excel."

Kundeforespørsel: "Legg til en Eksporter til Excel-knapp på bestillingssiden."

Oppdagelsesspørsmål:

• Hvem trenger eksportvirksomheten, finans og salg?
• Hva gjør de med Excel-filen etterpå?
• Hvor ofte eksporterer de, og hvor stort er datasettet?
• Hva går galt i dag hvis de ikke eksporterer?

5 hvorfor: kartlegging av rotårsaker og lag

1. Hvorfor trenger du en eksport?
2. "Vi trenger ukentlige ordrenumre til ledelsen." (UI-symptom / rapporteringsbehov)
3. Hvorfor må du sende dem manuelt?
4. "Det finnes ikke noe pålitelig dashbord." (brukergrensesnitt/produktkapasitet)
5. Hvorfor finnes det ikke noe pålitelig dashbord?
6. "Ordrestatusene er inkonsekvente, og rapporteringen brytes." (backend + database)
7. Hvorfor er statusene inkonsekvente?
8. "Ulike team bruker ulike statuser og hopper noen ganger over trinn." (UI + backend)
9. Hvorfor hopper de over trinn?
10. "Arbeidsflyten er ikke håndhevet, og brukergrensesnittet veileder dem ikke." (UI + backend)

Hva vi implementerer i stedet

I stedet for bare å legge til en eksportknapp, kan vi implementere:

• En enkel ukentlig KPI-visning (bestillinger, kanselleringer, forsinkelser)
• En statusmodellopprydding + validering (redusere "garbage in")
• En veiledet arbeidsflyt i brukergrensesnittet for å sikre at statusene er konsistente.
• Og hvis det fortsatt er behov for eksport: planlagt rapportering i stedet for manuell eksport

Resultat: mindre manuelt arbeid, mer pålitelige tall, færre "Excel-sannheter".

Eksempel 2: "Systemet er tregt - vi trenger en raskere server."

Kundeforespørsel: "Systemet er tregt. Kan vi oppgradere serveren?"

Oppdagelsesspørsmål:

• Når er det tregt (hele dagen eller bare i rushtiden)?
• For hvilke handlinger (søk, lagre, innlogging, rapporter)?
• Hvor mange brukere er aktive når det skjer?
• Hva er "treg" i tall (2s vs 20s)?

5 hvorfor: kartlegging av rotårsaker og lag

1. Hvorfor er den treg?
2. "Det tar 10-15 sekunder å søke etter kunder." (symptom på brukergrensesnitt)
3. Hvorfor tar det så lang tid å søke?
4. "Backend vent på databaseforespørselen." (backend)
5. Hvorfor er spørringen treg?
6. "Den skanner en enorm tabell." (database)
7. Hvorfor skanner den hele tabellen?
8. "Det finnes ingen indeks som samsvarer med filtrene." (databasedesign)
9. Hvorfor ble ikke dette oppdaget tidligere?
10. "Ingen ytelsesbaseline + datatilvekst var ikke en del av gjennomgangen." (prosess - og ofte servermålinger)

Hva vi implementerer i stedet

I stedet for å oppgradere serverne (en midlertidig løsning), er det bedre å velge en annen løsning:

• Riktige indekser og optimalisering av spørringer (database)
• Paginering/begrensninger som samsvarer med reell bruk (UI + backend)
• En ytelsesbaseline og varsling (overvåking av servere/OS)

Resultat: raskere UX og vanligvis lavere infrastrukturkostnader.

Eksempel 3: "Vi trenger et godkjenningstrinn før fakturaene sendes ut."

Kundeforespørsel: "Legg til et godkjenningstrinn før fakturaer sendes."Oppdagelsesspørsmål (kontekst)

• Hvilken risiko prøver du å redusere?
• Er det feil faktura, feil mottaker, feil beløp eller feil tidspunkt?
• Hvor ofte skjer det, og hva koster det?

5 hvorfor (rotårsak) + lagkartlegging

1. Hvorfor trenger du godkjenning?
2. "Noen ganger sendes fakturaer ut med feil priser." (symptom på brukergrensesnitt)
3. Hvorfor er prisingen feil?
4. "Rabattregler brukes ikke konsekvent." (backend-logikk)
5. Hvorfor brukes ikke reglene konsekvent?
6. "Salgsavdelingen legger inn rabatter manuelt i fritekstfelt." (UI-design)
7. Hvorfor er det manuell/fritekst?
8. "Systemet støtter ikke rabattyper på riktig måte." (datamodell + backend)
9. Hvorfor støtter den dem ikke?
10. "Det vokste organisk uten en prismodell." (database + produktdesign)

Hva vi implementerer i stedetI stedet for å legge til et godkjenningstrinn for hver faktura (friksjon), kan vi

• Innføre en strukturert pris-/rabattmodell (database)
• Legge til valideringsregler og fjerne UI-kontroller (UI + backend)
• Legg til en arbeidsflyt for unntak kun for risikable tilfeller (UI + backend)

Resultat: færre feil og lavere driftskostnader.

En praktisk sjekkliste du kan bruke i ditt neste kundemøte

Når en kunde kommer med en løsning, kan du prøve denne sekvensen:

1. Omformuler forespørselen i én setning.
2. Spør: "Hva skjer hvis vi ikke gjør noe? "Hva skjer hvis vi ikke gjør noe?" (innvirkning)
3. Spør: "Hvordan løser du det i dag? "Hvordan løser du det i dag?" (løsninger avslører det reelle behovet)
4. Still spørsmålet "Hvordan ser suksess ut?" (målbart resultat)
5. Kjør de 5 hvorfor'ene, og test bevisst hvilket lag du befinner deg i:
   • UI
   • backend
   • database
   • servere
   • OS/miljø

Oppdagelse gir deg retning. De fem grunnene gir deg dybde. Den mentale modellen med fem lag hjelper deg med å unngå å bli sittende fast i feil lag.

Avsluttende tanke

Discovery og 5 Whys bremser ikke leveransen – de reduserer omarbeiding. Du leverer fortsatt løsninger, men du leverer de løsningene som faktisk flytter nålen for kunden.