Softwareingeniører ved, at computere gør præcis, som de får besked om – ikke nødvendigvis det, vi har tænkt os. Denne kløft vokser, når kravene kommer fra ikke-tekniske interessenter eller når en anmodning adresserer symptomer snarere end underliggende problemer.

Så hvordan reducerer man risikoen for at implementere det forkerte? To enkle fremgangsmåder hjælper meget:

• Opdagelse at forstå konteksten og det ønskede resultat
• De 5 hvorfor'er at afdække den grundlæggende årsag (så problemet ikke kommer tilbage i en anden form)

Hos Notas IT bruger vi begge dele tidligt i processen, typisk på det allerførste møde, efter at vi har modtaget et krav.

Opdagelse: start med kontekst, ikke kode

Når en kunde sender en anmodning som "byg X" eller "tilføj Y", behandler vi den som et udgangspunkt – ikke som det endelige krav. I Discovery-samtalen sigter vi mod at svare:

• Hvem oplever problemet (roller, teams, kunder)?
• Hvornår sker det (hyppighed, spidsbelastninger, specifikke scenarier)?
• Hvad er konsekvenserne (penge, tid, fejl, churn, compliance-risiko)?
• Hvor dukker det op (systemgrænser, integrationer, procestrin)?
• Hvordan ville en succes se ud (målbart resultat, ikke leveret funktion)?

Først når vi har forstået dem, bruger vi de 5 hvorfor'er til at trykprøve, om vi løser det reelle problem.

De 5 hvorfor'er: Gør "en anmodning" til "en årsag".

De 5 hvorfor'er er enkle: Tag problemformuleringen og spørg "hvorfor?", indtil du når frem til en årsag, du kan handle ud fra. Det handler ikke om at udspørge kunden - det handler om at skabe fælles klarhed. Ofte har man ikke brug for præcis fem. Nogle gange har man brug for tre. Nogle gange har du brug for syv. Og i softwareprojekter er der en ekstra detalje: Selv når symptomet er synligt ét sted, kan årsagen befinde sig i et helt andet lag.

De "fem lag", hvor problemerne gemmer sig (og hvorfor det passer til Discovery + 5 Whys)

I de fleste tilfælde opdager brugeren fejlen eller den inkonsekvente adfærd i brugergrænsefladen. Men systemer er mere komplekse, end man skulle tro. Et typisk forretningssystem har flere lag, og hvert lag kan skabe symptomer, der dukker op andre steder. Når vi undersøger et problem og arbejder på at finde en løsning, graver vi os derfor normalt gennem fem lag:

1. Kode til brugergrænseflade
2. Backend-logik og frameworks
3. Databasestruktur og datasæt
4. Brugergrænseflade, backend og databaseservere
5. Operativsystem (og miljøets runtime)

Disse lag tvinger dig naturligvis til at spørge "hvorfor?" flere gange. En klage over brugergrænsefladen kan faktisk skyldes backend-validering, et databaseindeks, begrænsninger i serverressourcer eller et problem på OS-niveau. De 5 hvorfor'er giver en struktur til at undgå at stoppe for tidligt - og Discovery hjælper dig med at vælge den rigtige vej gennem disse lag baseret på forretningsmæssige konsekvenser, reelle arbejdsgange og begrænsninger. Så i praksis giver Discovery dig retning, og de 5 Whys giver dig dybde.

Eksempel 1: "Vi har brug for en eksportknap i Excel."

Kundeønske: "Tilføj en Eksporter til Excel-knap på ordresiden."

Spørgsmål om opdagelse:

• Hvem har brug for eksportaktiviteter, økonomi og salg?
• Hvad gør de med Excel-filen bagefter?
• Hvor ofte eksporterer de, og hvor stort er datasættet?
• Hvad går der galt i dag, hvis de ikke eksporterer?

5 Whys: grundårsag og kortlægning af lag

1. Hvorfor har du brug for en eksport?
2. "Vi har brug for ugentlige ordrenumre til ledelsen." (UI-symptom/rapporteringsbehov)
3. Hvorfor skal du sende dem manuelt?
4. "Der er ikke noget pålideligt dashboard." (Brugergrænseflade/produktkapacitet)
5. Hvorfor er der ikke et pålideligt dashboard?
6. "Ordrestatusser er inkonsekvente, og rapporteringen går i stykker." (backend + database)
7. Hvorfor er statusser inkonsekvente?
8. "Forskellige teams bruger forskellige statusser og springer nogle gange trin over." (UI + backend)
9. Hvorfor springer de trin over?
10. "Arbejdsgangen håndhæves ikke, og brugergrænsefladen vejleder dem ikke." (Brugergrænseflade + backend)

Hvad vi implementerer i stedet

I stedet for kun at tilføje en eksportknap kan vi implementere:

• En simpel ugentlig KPI-visning (ordrer, aflysninger, forsinkelser)
• En statusmodeloprydning + validering (reducer "garbage in")
• En guidet arbejdsgang i brugergrænsefladen for at sikre ensartede statusser.
• Og hvis der stadig er brug for eksport: planlagt rapportering i stedet for manuel eksport

Resultat: mindre manuelt arbejde, mere pålidelige tal og færre "Excel-sandheder".

Eksempel 2: "Systemet er langsomt - vi har brug for en hurtigere server."

Kundeønske: "Systemet er langsomt. Kan vi opgradere serveren?"

Spørgsmål om opdagelse:

• Hvornår er det langsomt (hele dagen eller kun i myldretiden)?
• Til hvilke handlinger (søgning, lagring, login, rapporter)?
• Hvor mange brugere er aktive, når det sker?
• Hvad er "langsomt" i tal (2s vs 20s)?

5 Whys: grundårsag og kortlægning af lag

1. Hvorfor er den langsom?
2. "Det tager 10-15 sekunder at søge efter kunder." (UI-symptom)
3. Hvorfor tager det så lang tid at søge?
4. "Backend venter på databaseforespørgslen." (backend)
5. Hvorfor er forespørgslen langsom?
6. "Den scanner en kæmpe tabel." (database)
7. Hvorfor scanner den hele tabellen?
8. "Der er ikke noget indeks, der matcher filtrene." (databasedesign)
9. Hvorfor blev det ikke opdaget tidligere?
10. "Ingen performance-baseline + datavækst var ikke en del af gennemgangen." (proces - og ofte servermålinger)

Hvad vi implementerer i stedet

I stedet for at opgradere servere (en midlertidig løsning) er der bedre løsninger:

• Korrekte indekser og optimering af forespørgsler (database)
• Paginering/begrænsninger, der matcher reel brug (UI + backend)
• En baseline for ydeevne og alarmering (overvågning af servere/OS)

Resultat: hurtigere UX og normalt lavere infrastrukturomkostninger.

Eksempel 3: "Vi har brug for et godkendelsestrin, før fakturaerne sendes."

Kundeønske: "Tilføj et godkendelsestrin, før fakturaer sendes."Opdagelsesspørgsmål (kontekst)

• Hvilken risiko forsøger du at reducere?
• Er der tale om forkerte fakturaer, forkerte modtagere, forkerte beløb eller forkerte timing?
• Hvor ofte sker det, og hvad koster det?

5 Whys (grundårsager) + kortlægning af lag

1. Hvorfor har du brug for godkendelse?
2. "Nogle gange sendes der fakturaer ud med forkerte priser." (UI-symptom)
3. Hvorfor er prissætningen forkert?
4. "Rabatregler anvendes ikke konsekvent." (backend-logik)
5. Hvorfor anvendes reglerne ikke konsekvent?
6. "Salgsafdelingen indtaster rabatter manuelt i fritekstfelter." (Design af brugergrænseflade)
7. Hvorfor er det manuel/fritekst?
8. "Systemet understøtter ikke rabattyper ordentligt." (datamodel + backend)
9. Hvorfor støtter den dem ikke?
10. "Det voksede organisk uden en prismodel." (database + produktdesign)

Hvad vi implementerer i stedetI stedet for at tilføje et godkendelsestrin for hver faktura (friktion), kan vi gøre det:

• Indfør en struktureret pris-/rabatmodel (database)
• Tilføj valideringsregler og ryd UI-kontroller (UI + backend)
• Tilføj et workflow med undtagelser kun for risikable tilfælde (UI + backend)

Resultat: færre fejl og lavere driftsomkostninger.

En praktisk tjekliste, du kan bruge til dit næste kundemøde

Når en kunde kommer med en løsning, så prøv denne sekvens:

1. Omformuler anmodningen i én sætning.
2. Spørg: "Hvad sker der, hvis vi ikke gør noget?" (påvirkning)
3. Spørg ind til det: "Hvordan løser du det i dag?" (løsningerne afslører det reelle behov)
4. Spørg om det: "Hvordan ser succes ud?" (målbart resultat)
5. Kør de 5 hvorfor'er, og test bevidst, hvilket lag du befinder dig i:
   • UI
   • backend
   • database
   • servere
   • OS/miljø

Discovery giver dig retning. De 5 hvorfor'er giver dig dybde. Den mentale model med fem lag hjælper dig med ikke at sidde fast i det forkerte lag.

Afsluttende tanke

Discovery og de 5 Whys bremser ikke leveringen – de reducerer omarbejdet. Du leverer stadig løsninger, men du leverer dem, der rent faktisk flytter nålen for kunden.