En feil har oppstått …

Gode feilmeldinger kan spare bedriften for mye frustrasjon.

Tenk deg følgende: Du jobber som økonomiansvarlig for en bedrift som selger byggutstyr. En bedriftskunde har gått konkurs, og du ønsker derfor å deaktivere denne kunden i økonomisystemet. Når du forsøker å gjøre dette, kommer følgende feilmelding opp: «En feil har oppstått». Hva gjør du da? Du går til «guruen» i bedriften din. Der får du en smørbrødliste over ting som «pleier å hjelpe», og når ingen av disse tingene hjelper, er det en uendelig lang vei om support, hvor saken til slutt ender hos utviklerne til firmaet som har laget økonomisystemet. Etter masse frem og tilbake med utviklerne får du omsider beskjeden: «Jammen, du kan jo ikke deaktivere en kunde som har utestående fordringer …» Hvorfor kunne ikke økonomisystemet ha gitt den tilbakemeldingen med én gang? Da hadde det tatt to minutter å fjerne fordringene, slik at kunden kunne vært deaktivert.

Hvorfor gir så mange systemer uforklarlige – og i mange tilfeller kryptiske feilmeldinger? Hvem har vel ikke sett en feilmelding som dette?

feil 1 En feil har oppstått ...

Eller dette:

feil 2 En feil har oppstått ...

Jeg hører av og til kommentarer som «skjønner ikke utviklerne at dette er en håpløs feilmelding», eller «Utviklere er håpløse på brukerinteraksjon. Se bare på disse feilmeldingene her». Det paradoksale er at hvis du presenterer en slik melding for en utvikler, så vil vedkommende være helt enig i at dette er en dårlig tilbakemelding for brukerne av systemet. Men hvorfor presenterer de da en så dårlig feilmeldingen?

Svaret ligger i et arkitekturvalg, eller snarere mangelen på et. Når ikke annet er spesifisert, har arkitekter og utviklere en tendens til å falle tilbake på en teknologi som benytter såkalte exceptions. Dette er en veldig kodeeffektiv måte å håndtere feil på, og den er allerede bygget inn i de aller fleste teknologier vi kommer borti, fra database-servere til Internet Explorer. Det er derfor veldig tiltalende å benytte denne videre i implementasjonen av forretningslogikken.

Utfordringen med exceptions er at feilmeldingene som genereres av databasemotorer og andre rammekomponenter først og fremst er laget for å hjelpe utviklere under utviklingen av et system. Disse feilmeldingene er derfor ikke spesielt egnet for sluttbrukere. I tillegg gjør strukturen til exceptions det svært vanskelig å oversette en feilmelding til noe som en bruker kan forstå. Resultatet blir altså ubrukelige – og ofte kryptiske feilmeldinger.

For å kunne lage fornuftige feilmeldinger i et system, må man ikke løpe etter feilene, men komme dem i forkjøpet. Feilmeldingene må også komme på et fornuftig format slik at de både gir brukeren, en eventuell driftsansvarlig og en utvikler så my informasjon som behøves for å skjønne hvordan en situasjon kan løses. Feilmeldinger bør altså komme i flere versjoner, hver til sin målgruppe.

Men når vi nå har påpekt at det er et arkitekturvalg som ofte gir dårlige feilmeldinger, skal det også sies at feilmeldinger til brukerne egentlig burde adresseres i den funksjonelle spesifikasjonen. Hvis de blir det, har ikke arkitekten noe annet valg enn å lage en strategi for utformingen av dem. Dessuten, hvem er vel bedre egnet til å lage gode feilmeldinger enn de fremtidige brukerne? De har domenekunnskapen, og er jo tross alt de som til syvende og sist skal skjønne disse feilmeldingene.

Nå er det ikke bare snakk om punkter i spesifikasjonen som «feilmeldinger skal være forståelige», eller «Feilmeldinger skal vises i en dialogboks med ok-knapp». Nei, det er snakk om detaljerte beskrivelser av spesifikke feilmeldinger. For eksempel hva meldingen til bruker skal være dersom man prøver å deaktivere en kunde med utestående fordringer. For å vite hva slags informasjon som er nyttig i en slik feilmelding må man ha domenekunnskap. Det er opplagt at dette krever detaljerte funksjonelle spesifikasjoner, og at det tar tid å identifisere alle mulige feil som kan oppstå, men tenk hva det koster i tapt arbeid og support med de meldingene systemet ellers vil gi! Dessuten er de fleste feilsituasjoner allerede definert i forretningslogikken. Fra eksempelet over vil det overraske meg mye hvis ikke følgende punkt allerede finnes i den funksjonelle spesifikasjonen: «Kunder med utestående fordringer skal ikke kunne deaktiveres».

Det bør også påpekes at en slik tilnærming ikke kommer helt gratis. Det er en «up front»-kostnad å implementere god validering. Det er også en ekstra utfordring for utviklerteamet. Man vil som utvikler kunne føle at man skriver noe unødvendig kode for feil som neppe kommer til å inntreffe. Progresjonen på utviklingen av det funksjonelle vil derfor også føles noe lavere. Man må altså ha en prosjektgruppe som ser verdien i å gjøre en slik tilnærming, og som disiplinert fokuserer på sluttproduktet. Man kan med fordel kombinere gode feilmeldinger med et brukergrensesnitt som «hindrer» brukeren i å gjøre feil for å begrense omfanget av nødvendige valideringen.

Men summa summarum er mitt inntrykk at feilmeldinger/tilbakemeldinger er noe man i altfor liten grad ser på, både under funksjonell utforming og under implementering. Kostnader og frustrasjon rundt bruk av it-systemer kan reduseres betraktelig ved å ta med seg dette aspektet i utviklingen av systemet.

Publisert