“Det virker ikke.” Det er den hyppigste fejlbeskrivelse, vi får, og den er næsten altid sand. Den er bare ikke til at arbejde ud fra.
Det her er ikke et krav til jer. En sag bliver oprettet, fordi nogen har travlt og noget er gået i stå, og så skriver man kort. Men der er fire oplysninger, som næsten altid mangler, og som hver gang flytter en sag fra gætteri til diagnose. De gælder, uanset om I ringer til os eller til jeres egen IT-ansvarlige.
“Det virker ikke” er et symptom, ikke en fejl
Når en sag kommer ind sådan, går det første stykke arbejde med at finde ud af, hvad “det” er. Er det programmet? Printeren? Adgangen til den mappe, programmet skriver til? Tre forskellige fejl ser ens ud fra skrivebordet.
Det koster sjældent mere end et par spørgsmål frem og tilbage. Problemet er, at hvert spørgsmål er en rundtur: vi skriver, I ser det først efter frokost, I svarer, vi er optaget af noget andet. En sag, der kunne have taget tyve minutter, bliver til to dage — ikke på grund af teknikken, men på grund af ventetiden mellem svarene.
De fire oplysninger, vi altid spørger om
- Hvad prøvede du at gøre, da det gik galt? Ikke hvad der ikke virkede, men hvad du var i gang med. “Jeg skulle gemme en faktura i sagsmappen” fortæller mere end “Word driller”.
- Hvornår skete det første gang? Dato og cirka klokkeslæt.
- Sker det for andre end dig? Kan kollegaen ved siden af gøre det samme?
- Hvad står der ordret i fejlmeddelelsen? Gerne som skærmbillede.
De to første siger noget om, hvor fejlen er. De to sidste siger noget om, hvor stor den er.
Tidspunktet er den vigtigste af dem
Den bliver oftest sprunget over, og den hjælper mest.
Alt, hvad en server, en firewall og en pc laver, bliver skrevet i logfiler, og de er sorteret efter tid. Har vi et klokkeslæt, kan vi slå ned på et par minutter og se, hvad der ellers skete netop der: en opdatering, en genstart, en netværksforbindelse der faldt ud, en licens der udløb ved midnat.
“I går ved frokosttid” er nok. “På et tidspunkt for nylig” er det ikke — så er der tusindvis af linjer at læse, og som regel ender vi med at spørge igen.
Er fejlen sket flere gange, så skriv gerne to af gangene. To tidspunkter afslører nogle gange mønsteret med det samme: hver mandag morgen, eller altid lige efter klokken 17.
Et skærmbillede slår ti linjers beskrivelse
En fejlmeddelelse indeholder ofte en kode. Den kode er ikke pynt. Den peger direkte på årsagen, og den er svær at gengive rigtigt fra hukommelsen.
På Windows tager Windows + Shift + S et udsnit, der kan sættes direkte ind i en mail. På Mac er det Cmd + Shift + 4. Tag gerne mere med end selve boksen — det, der står bagved, viser hvilket program og hvilken fil det handler om.
Ét forbehold: er der personoplysninger eller kundedata på skærmen, så beskær billedet først. Det er fejlmeddelelsen, vi skal bruge.
Når fejlen ikke kan genskabes
Nogle fejl optræder én gang og er væk, når man kigger efter. De er ikke mindre virkelige, og de skal meldes ind alligevel.
Skriv i de tilfælde, hvad I lavede, hvornår det skete, og om noget var anderledes den dag: en ny kollega, en flytning, et strømsvigt om natten, en opdatering. Den slags fejl bliver sjældent løst i første sag. De bliver løst, fordi der ligger tre beskrivelser, og den tredje afslører mønsteret.
Derfor er det værd at melde en fejl ind, også når den gik over af sig selv.
Skabelonen
Fire linjer. Sæt dem i jeres eget intranet, eller som fast tekst i den postkasse, der opretter sager:
Det er ikke en formular, der skal udfyldes korrekt. Står en af linjerne tom, er det også en oplysning.
