Knappen

Frode Fagperson kikket opp fra skjermen sin og så over på Une Utvikler. “Jeg trenger en knapp for å vise kundenes siste innbetalinger,” sa han.

Une så nysgjerrig opp fra tastaturet sitt. “Hvorfor trenger du det?” spurte hun.

“Det har seg nemlig sånn,” sa Frode, “at jeg trenger å følge med på når fakturaene blir betalt.”

“Hvorfor det?” undret Une og lente seg frem.

“Fordi jeg er nødt til å sjekke om de betales innen forfall. Og det er jo ikke alltid det skjer, for å si det sånn,” humret Frode. Han likte godt å fortelle om faget sitt.

Une smilte og fortsatte å spørre: “Hvorfor er det viktig at du sjekker det, egentlig?”

“Vi er nødt til å ha oversikt over hvilke kunder som er pålitelige,” forklarte Frode. “Hele forretningsmodellen vår er jo bygd opp rundt at vi får pengene i tide.”

Une nikket mens hun tenkte seg om. “Jeg tror faktisk vi har dataene vi trenger for å finne de pålitelige kundene automatisk.”

Frode lyste opp i ansiktet. “Det hadde vært supert!” utbrøt han. “Kanskje vi kunne vist frem et ikon ved siden av dem?”

“Absolutt,” sa hun, “det får vi til!”

En annen på teamet som hadde overhørt samtalen, skjøt inn: “Hva om vi snur på det og heller identifiserer kundene som ikke gjør opp for seg innen forfall? Kunne vi vist et varselikon ved siden av dem i stedet?”

En liten stund senere hadde de laget en løsning. Kunder som gjentatte ganger betalte etter forfall, ville automatisk få tilsendt en advarsel på e-post. Ingen nye skjermbilder, ingen ikoner.

Ingen knapp.

For mye fokus på løsninger

Jeg har blitt bedt om å legge til en knapp i alle prosjekter jeg har jobbet i, og det kan vel hende at du har opplevd det samme. I min erfaring er det fort gjort å bare implementere knappen uten videre seremoni. Vi har jo fått en konkret forespørsel fra en fagperson som skal bruke verktøyet vi lager. Hva kan vel være bedre enn det?

Forbedringspotensialet ligger i å bedre utnytte kompetansen og erfaringen utviklingsteamet sitter på. Vi er tross alt kreative problemløsere, med inngående kunnskap om både tekniske muligheter og begrensninger.

Men okei, hvordan gjør vi det da?

Vi må starte med behovene

Sakichi Toyoda, mannen bak Toyota, utviklet teknikken “5 Whys” for å utbedre problemer som oppstod på fabrikkene. Den går rett og slett ut på å stille spørsmålet “hvorfor?” fem ganger, og på den måten avdekke rotårsaken til at et problem oppstod. Deretter kunne man finne og iverksette mottiltak for å forhindre at det skjedde igjen.

Såre enkelt, og utrolig effektivt.

Heldigvis fungerer den i min erfaring like godt til å identifisere behovene som ligger bak en foreslått løsning. Det er imidlertid en fordel å unngå å følge opp hvert eneste utsagn med et smått irriterende “hvorfor?”, og det er på ingen måte nødvendig å stille spørsmål i nøyaktig fem omganger. Vær nysgjerrig, og grav deg bakover til de underliggende behovene gjennom naturlige samtaler.

Når vi har forstått hva fagpersonene har behov for, kan vi samarbeide om å finne frem til de aller beste løsningene. Det er mer givende enn å bare legge til knappen – og brukerne av systemene våre får en bedre hverdag.