Hur Discovery och 5 Whys säkerställer att du bygger det som kunderna verkligen behöver - inte bara det som de frågar efter.

Mantas Damijonaitis • 2026-04-14

Mjukvaruingenjörer vet att datorer gör precis som de blir tillsagda – inte nödvändigtvis som vi tänkt oss. Detta gap växer när kraven kommer från icke-tekniska intressenter eller när en förfrågan behandlar symptom snarare än underliggande problem.

Så hur minskar du risken för att implementera fel saker? Två enkla metoder är till stor hjälp:

Upptäckt att förstå sammanhanget och det önskade resultatet
De 5 orsakerna för att hitta grundorsaken (så att problemet inte återkommer i en annan form)

På Notas IT använder vi båda tidigt i processen, vanligtvis i det allra första mötet efter att vi har fått ett krav.

Upptäckt: börja med sammanhanget, inte koden

När en kund skickar en begäran som "bygg X" eller "lägg till Y" behandlar vi den som en utgångspunkt – inte som det slutliga kravet. I Discovery-samtalet strävar vi efter att svara:

Vem upplever problemet (roller, team, kunder)?
När händer det (frekvens, topptider, specifika scenarier)?
Vilka konsekvenser får det (pengar, tid, fel, kundbortfall, compliance-risk)?
Var dyker den upp (systemgränser, integrationer, processteg)?
Hur skulle framgång se ut (mätbart resultat, inte en funktion som levereras)?

Först när vi har förstått dem kan vi använda 5 Whys för att testa om vi löser det verkliga problemet.

De 5 varför: gör "en förfrågan" till "en orsak".

5 Whys är enkelt: ta problemformuleringen och fråga "varför?" tills du kommer fram till en orsak som du kan agera på. Det handlar inte om att förhöra kunden – det handlar om att skapa gemensam tydlighet. Ofta behöver du inte exakt fem. Ibland behöver du tre. Ibland behöver du sju. Och i mjukvaruprojekt finns det en extra detalj: även om symptomet är synligt på ett ställe kan orsaken finnas i ett helt annat lager.

De "fem lagren" där problemen gömmer sig (och varför detta passar in på Discovery + 5 Whys)

I de flesta fall märker användaren felet eller det inkonsekventa beteendet i användargränssnittet. Men system är mer komplexa än så. Ett typiskt affärssystem har flera lager, och varje lager kan skapa symptom som syns på andra ställen. När vi undersöker ett problem och arbetar för att hitta en lösning gräver vi oss därför vanligtvis genom fem lager:

Kod för användargränssnitt
Backend-logik och ramverk
Databasstruktur och dataset
Användargränssnitt, backend och databasservrar
Operativsystem (och körtid för miljö)

Dessa lager tvingar dig naturligtvis att fråga "varför?" flera gånger. Ett klagomål på användargränssnittet kan faktiskt orsakas av backend-validering, ett databasindex, begränsningar av serverresurser eller ett problem på OS-nivå. 5 Whys ger en struktur för att undvika att stanna upp för tidigt – och Discovery hjälper dig att välja rätt väg genom dessa lager baserat på affärspåverkan, verkliga arbetsflöden och begränsningar. Så i praktiken ger Discovery dig riktning och de 5 Whys ger dig djup.

Exempel 1: "Vi behöver en knapp för export till Excel."

Kundförfrågan: "Lägg till en knapp för export till Excel på ordersidan."

Frågor om upptäckt:

Vem behöver exportverksamheten, finans och försäljning?
Vad gör de med Excel-filen efteråt?
Hur ofta exporterar de och hur stort är datasetet?
Vad kan gå fel idag om de inte exporterar?

5 Whys: kartläggning av grundorsaker och lager

Varför behöver du en export?
"Vi behöver veckovisa ordernummer till ledningen." (UI symptom / rapporteringsbehov)
Varför måste du skicka dem manuellt?
"Det finns ingen tillförlitlig instrumentpanel." (användargränssnitt/produktkapacitet)
Varför finns det ingen tillförlitlig instrumentpanel?
"Orderstatusar är inkonsekventa och rapporteringen bryts." (backend + databas)
Varför är statusarna inkonsekventa?
"Olika team använder olika statusar och hoppar ibland över steg." (UI + backend)
Varför hoppar de över steg?
"Arbetsflödet upprätthålls inte och användargränssnittet vägleder dem inte." (användargränssnitt + backend)

Vad vi implementerar istället

Istället för att bara lägga till en exportknapp kan vi implementera:

En enkel veckovis KPI-översikt (order, avbokningar, förseningar)
En statusmodell för upprensning och validering (minska "garbage in")
Ett guidat arbetsflöde i användargränssnittet för att säkerställa att statusarna är konsekventa.
Och om export fortfarande behövs: schemalagd rapportering i stället för manuell export

Resultat: mindre manuellt arbete, mer tillförlitliga siffror och färre "Excel-sanningar".

Exempel 2: "Systemet är långsamt – vi behöver en snabbare server."

Kundförfrågan: "Systemet är långsamt. Kan vi uppgradera servern?"

Frågor om upptäckt:

När är det långsamt (hela dagen eller under rusningstid)?
För vilka åtgärder (sökning, spara, inloggning, rapporter)?
Hur många användare är aktiva när det händer?
Vad är "långsamt" i siffror (2 s vs 20 s)?

5 Whys: kartläggning av grundorsaker och lager

Varför är det långsamt?
"Att söka efter kunder tar 10-15 sekunder." (UI symptom)
Varför tar det så lång tid att söka?
"Backend väntar på databasförfrågan." (backend)
Varför är sökningen långsam?
"Den skannar en enorm tabell." (databas)
Varför skannar den hela bordet?
"Det finns inget index som matchar filtren." (databasdesign)
Varför upptäcktes inte detta tidigare?
"Ingen baslinje för prestanda + datatillväxt var inte en del av granskningen." (process - och ofta servermätvärden)

Vad vi implementerar istället

I stället för att uppgradera servrar (en tillfällig lösning) finns det bättre lösningar:

Korrekta index och optimering av sökfrågor (databas)
Paginering/begränsningar som matchar verklig användning (UI + backend)
En baslinje för prestanda och varningar (övervakning av servrar/OS)

Resultat: snabbare UX och vanligtvis lägre infrastrukturkostnader.

Exempel 3: "Vi behöver ett godkännandesteg innan fakturorna skickas."

Kundförfrågan: "Lägg till ett godkännandesteg innan fakturorna skickas."Frågor om upptäckt (sammanhang)

Vilken risk försöker du minska?
Handlar det om felaktiga fakturor, fel mottagare, fel belopp eller fel tidpunkt?
Hur ofta händer det och vad kostar det?

5 Whys (grundorsak) + kartläggning av lager

Varför behöver du ett godkännande?
"Ibland går fakturor ut med felaktig prissättning." (UI symptom)
Varför är prissättningen felaktig?
"Rabattregler tillämpas inte konsekvent." (backend-logik)
Varför tillämpas inte reglerna på ett konsekvent sätt?
"Säljarna anger rabatterna manuellt i fritextfält." (design av användargränssnitt)
Varför är det manuellt/fritext?
"Systemet stöder inte rabattyper på rätt sätt." (datamodell + backend)
Varför stödjer den inte dem?
"Det växte organiskt utan en prismodell." (databas + produktdesign)

Vad vi implementerar iställetIstället för att lägga till ett godkännandesteg för varje faktura (friktion) kan vi göra det:

Införa en strukturerad prissättnings-/rabattmodell (databas)
Lägga till valideringsregler och rensa UI-kontroller (UI + backend)
Lägg till ett arbetsflöde för undantag endast för riskfyllda fall (UI + backend)

Resultat: färre fel med mindre driftskostnader.

En praktisk checklista som du kan använda i ditt nästa kundmöte

När en kund kommer med en lösning kan du prova den här sekvensen:

Omformulera begäran i en mening.
Fråga: "Vad händer om vi inte gör någonting?" (påverkan)
Fråga: "Hur löser du det idag?" (lösningar avslöjar det verkliga behovet)
Fråga: "Hur ser framgång ut?" (mätbart resultat)
Kör 5 Whys, och testa medvetet vilket lager du befinner dig i:
- UI
- backend
- databas
- servrar
- OS/miljö

Discovery ger dig riktning. De 5 varför-frågorna ger dig djup. Den mentala modellen med fem lager hjälper dig att undvika att fastna i fel lager.

Avslutande tanke

Discovery och 5 Whys saktar inte ner leveransen – de minskar omarbetningen. Du levererar fortfarande lösningar, men du levererar de som faktiskt gör skillnad för kunden.