Å dokumentere de feilene og problemene som oppstår, og hvordan de ble løst, er en svært viktig del av IKT-support og drift. Når du dokumenterer systematisk, bygger du opp kunnskap og verdifull informasjon om de systemkombinasjonene virksomheten har, og de spesielle feilene og problemene som kan oppstå.
Du tenker kanskje at du vil huske hvordan et bestemt problem ble løst, men når et tidligere problem dukker opp igjen senere, har man som regel glemt detaljene. Du kommer sikkert ikke til å være i samme jobb for all fremtid heller, og den erfaringen du bygger opp og dokumenterer, er derfor uvurderlig for den som skal overta jobben din. Når du dokumenterer, gjør du det altså både for din egen skyld og for andres.
Tenk også på at når du dokumenterer løsninger på problemer, bygger du opp kunnskap som du senere kan dele med andre i et kunnskapsnettverk.
Noen unngår til og med bevisst å dokumentere løsninger på problemer fordi de gjerne vil gjøre seg uunnværlige. Tanken er at kunnskap er makt, og så lenge man er den eneste som er i stand til å løse problemene, er jobben trygg. Det burde være opplagt at dette ikke er en strategi du bør satse på. Det er ved å dokumentere at du beviser din verdi som en dyktig IKT-servicemedarbeider.
I forbindelse med helpdesk lærte du at det er viktig å registrere alle henvendelser og løsninger i en supportdatabase slik at de som betjener helpdesken, raskt kan finne løsningen på kjente problemer. I kompetansemålet om bruk av hjelpfunksjoner og kunnskapsdatabaser var erfaringsdatabaser (egne og andres erfaringer) en viktig kilde til informasjon.
Slike informasjonsdatabaser har to kjennetegn:Med «strukturert og løsningsorientert» mener vi at dokumentasjonen følger en fastsatt mal og hvert problem har sin egen oppføring som bare inneholder informasjon om hvordan det bestemte problemet kan løses.
Det finnes ikke noen fasit for hvordan en slik mal bør se ut, men det er hensiktsmessig å dele informasjonen inn i tre deler:Med «ajourføres fortløpende» mener vi at informasjon om problemet legges inn så snart som mulig. I forbindelse med helpdesker som har telefonsupport eller fjernsupport, er det ikke uvanlig at supportmedarbeideren dokumenterer mens han snakker med brukeren.
Det er selvsagt ikke alltid mulig å skrive ned alt mens du jobber med å løse feilen, men du bør venne deg til å ta notater så snart som mulig slik at du ikke glemmer viktige detaljer. Du kan for eksempel bruke en mobiltelefon eller et nettbrett til å notere på når du er hos brukere, slik at du kan overføre informasjonen direkte til en database senere.
Det viktigste er ikke hvordan du dokumenterer løsninger på problemer, men at du forstår nødvendigheten av å gjøre det og faktisk gjør det.
En rutine kan defineres som et sett med oppgaver som skal gjøres på samme måte og i samme rekkefølge hver gang de utføres.
I motsetning til løsninger på problemer, som kanskje bare dukker opp én gang, er rutiner oppgaver som skal utføres regelmessig (for eksempel sikkerhetskopiering), eller oppgaver som skal utføres på en bestemt måte når de må gjøres (for eksempel tilbakekopiering av en sikkerhetskopi).
Man må dokumentere rutiner av to grunner:Å lage rutiner er en måte å sikre at oppgaver blir gjort på, og alle rutinebeskrivelser skal si noe om hvem som er ansvarlig, og når eller i hvilken sammenheng rutinen skal utføres. Det må ikke nødvendigvis være en bestemt dato eller et bestemt tidsintervall – rutiner kan også knyttes opp til andre oppgaver eller bestemte hendelser. For eksempel vil en rutine for tilbakekopiering av en sikkerhetskopi bare være aktuell når data har gått tapt.
Å dokumentere rutiner på en god måte kan være omstendelig, men samtidig tvinges du til å gjennomgå alle de arbeidsoppgavene rutinen innebærer, på en systematisk måte. Den beste måten å dokumentere en rutine på, er å skrive ned hva du gjør, mens du utfører oppgaven.
Når du dokumenterer en rutine, må du passe på at informasjonen er så komplett at andre kan følge den steg for steg senere og oppnå riktig resultat. Rutinebeskrivelser kan derfor bli svært detaljerte, og noen ganger er det nødvendig å dele opp en større rutine i flere delrutiner.
Rutinebeskrivelsen må også inneholde informasjon om hva som eventuelt må gjøres før eller etter selve oppgaven, og annet som er nødvendig for å få gjort den. For eksempel må en rutine for tilbakekopiering av sikkerhetskopi inneholde informasjon om hvor sikkerhetskopiene oppbevares.
Alle rutiner bør inneholde informasjon om:Det kan være en utfordring – det er ofte vanskeligere enn man tror – å skrive god brukerdokumentasjon. Sjansen for et godt resultat øker imidlertid betraktelig hvis du stiller deg selv noen enkle spørsmål før du begynner å skrive:
Ved å besvare disse spørsmålene blir du bevisst på hvem du skriver for, og hva dokumentasjonen må inneholde for at den skal bli forståelig og nyttig for den som skal lese. I tillegg unngår du å ta med informasjon som er unødvendig, eller som kanskje ikke blir forstått eller lest i det hele tatt.
I noen tilfeller vil brukeren også være usikker på om den informasjonen han har funnet frem til, er den riktige, om den er ment for ham, og om han behøver og lese den. God brukerdokumentasjon tar hensyn til dette og opplyser med en gang leseren hvem den er beregnet for, og hva han kan forvente å finne informasjon om.
Ved å spesifisere hvem dokumentet er beregnet for, noen stikkord om hva det inneholder, og hvorfor du har skrevet det, får brukeren med en gang mulighet til å avgjøre om dette er noe han bør lese. Videre bør dokumentet ha en innholdsfortegnelse som gjør at det er enkelt å finne frem.
Legg merke til at det å kunne besvare de spørsmålene vi listet opp innledningsvis, er utgangspunktet både for innledningen til dokumentasjonen og hvilket innhold som skal være med.
God brukerdokumentasjon opplyser med en gang leseren hvem den er beregnet for, og hva han kan forvente å finne informasjon om.
Korte setninger er lettere å lese og lettere å forstå. Unngå også å bruke mange lange og vanskelige ord. Det er ikke alle som leser like godt.
Faguttrykk kan by på spesielle problemer fordi du ikke kan være sikker på at brukeren forstår dem. Generelt bør du forsøke å unngå faguttrykk, men i noen tilfeller er det uunngåelig. Er du usikker på om brukeren kommer til å forstå et uttrykk, bør du forklare det den første gangen du bruker det.
Vær bevisst på hvem du skriver for, og hvilket kunnskapsnivå brukeren har. Du kjenner ditt eget fagfelt godt, og det er derfor fort gjort å forenkle stoffet slik at det blir uforståelig for brukeren. Samtidig må du selvsagt ikke undervurdere brukerens kunnskapsnivå og plage ham med for mange unødvendige detaljer heller.
Ofte finnes det flere uttrykk og skrivemåter som i praksis betyr det samme, men dette kan virke forvirrende på brukeren. Hvis du har begynt å skrive for eksempel skriver, bør du være konsekvent og ikke skrive printer senere.
Det burde være unødvendig å si det, men stavefeil er unødvendig og får dokumentasjonen til å virke uprofesjonell. Hvis du ikke stoler på stavekontrollen, kan du la noen andre lese gjennom og rette eventuelle skrivefeil for deg.
Bilder av programvinduer sammen med tekst gjør det enklere for brukeren å se hvor han skal klikke, og hvordan skjermen hans skal se ut underveis. En annen mulighet er å bruke et verktøy for å spille inn det som skjer på skjermen mens du utfører en oppgave, og deretter lagre det som en video.
Bruk av bilder og video gjør at du kan skrive mindre, og du kan bruke bilder til annen dokumentasjon også. Det er for eksempel enklere å ta noen bilder eller lage en video av hvordan man skal skifte blekkpatron i en skriver, enn å forklare hele prosessen med ord. Dette kan du se mange eksempler av på YouTube, der både produsenter og brukere har lagt ut videoer med brukerveiledninger, tips og demonstrasjoner.
De fleste har en tendens til å «skumme» en tekst på skjerm og plukke ut det som ser interessant ut, i stedet for å lese teksten sammenhengene slik vi vanligvis gjør på papir. Vi leser i større grad bruddstykker av teksten og hopper mer frem og tilbake.
En tekst som skal leses på skjerm, bør derfor være skrevet slik at den egner seg for slik «skumming». Det oppnår du ved å huske på følgende:
Vi stopper opp ved det som skiller seg ut, som for eksempel de tre ordene du nettopp leste. Ved å markere ord og begreper som er særlig viktige i teksten, kan du lede brukerens oppmerksomhet dit. Man kan utheve på vanlig måte, for eksempel ved å streke under eller bruke farger.
Vi leser nesten alltid avsnittsoverskriftene, så det er viktig at de er så meningsfulle som mulig. Det vil si, de bør beskrive innholdet i det avsnittet som følger. Unngå morsomme eller «smarte» overskrifter i brukerdokumentasjonen.
Punktlister er raske å skumlese, så de blir derfor nesten alltid lest.
Når du har flere poenger du vil formidle, bør du skille dem godt slik at hvert poeng får sitt eget avsnitt.
Innledningen eller det første avsnittet blir nesten alltid lest, og det vesentlige bør derfor stå der, slik at det er større sjanse for at brukeren får det med seg. Tenk på hvordan avisartikler er bygget opp. Hovedpoenget kommer i overskriften og ingressen, deretter følger detaljene i selve teksten.
Som hovedregel bør du forsøke å bruke færre ord når du skriver for skjerm enn for papir. De fleste setningene kan gjøres kortere uten at meningen forsvinner. Se på eksempelet under.
Alle de fire setningene sier egentlig det samme, men den første har nesten fire ganger så mange ord som den siste:Prosedyrer er ofte en viktig del av rutiner eller brukerdokumentasjon. Det finnes ikke noen standard for hvordan man skal skrive prosedyrer, men det er noen prinsipper du bør følge.
Det gjør at erfarne brukere kan jobbe seg gjennom en prosedyre uten å måtte lese all teksten. Det er også tidsbesparende hvis man må utføre en prosedyre flere ganger.
Vi antar at de fleste vet hvordan de skal åpne Windows Utforsker i linje 1, men for de som eventuelt er usikre, er veien vist i kursiv parentesen (Startknappen – Datamaskin). I prosedyrer kan vi bruke kursiv tekst til tilleggsinformasjon og kommentarer.
Nummerering gir bedre oversikt og gjør det enklere å følge en prosedyre. Det er også lettere å referere til et nummer i en prosedyre ved for eksempel telefonsupport.
Det er viktig at alle steg står i den rekkefølgen de skal utføres, både linje for linje og innbyrdes på hver linje.
De to setningene under beskriver det samme steget, men bare den siste er riktig når du skal skrive en prosedyre:Den første setningen beskriver ikke valgene i den riktige rekkefølgen, og da blir det vanskeligere å følge prosedyren. Hvis vi forsøker å sammenfatte ved bare å lese de uthevede ordene, blir prosedyren feil.
Når en handling skal medføre at noe skjer, bør resultatet alltid beskrives. I linje 2 får brukeren vite at det skal komme opp en dialogboks med tittelen Mappealternativer når han har valgt Mappe og søkealternativer. Hvis boksen vises, vet han at han kan gå videre til neste punkt. Hvis den ikke vises, vet han at noe er galt, og at han må gå tilbake til forrige punkt i prosedyren.
Vi kunne også ha erstattet beskrivelsen med en illustrasjon som viste dialogboksen. Bruk av illustrasjoner er en effektiv måte å vise brukeren hva han skal se på skjermen sin. Men pass på å ikke overdrive bruken av illustrasjoner og skjermbilder, for det kan gjøre prosedyren uoversiktlig.
Tenk også på at skjermbildene du ser på din maskin, ikke alltid er helt identiske med det brukeren ser på sin maskin. Forskjeller i skjermoppløsning, fargevalg, temaer, programversjoner og så videre kan medføre at det er forskjell på illustrasjonen og det brukeren ser på sin skjerm, og da kan brukeren bli usikker.
Det finnes som sagt ikke noen standard for hvordan man skal skrive en prosedyre. Du vil derfor kunne se mange andre løsninger hvor man bruker utheving, kursiv, understreking eller varierer med skrifttyper. Det er heller ikke så viktig hvilken løsning du velger – så lenge du bruker den konsekvent. Det blir fort forvirrende hvis for eksempel noen menyvalg er uthevet og andre er understreket.
Det er også lurt å unngå å bruke farger for å skille de ulike delene av en prosedyre. Det er nyttig for brukeren å kunne forstå informasjonen også på en sort-hvitt-utskrift.
De tre mest aktuelle måtene å distribuere informasjon på er papir, e-post eller publisering på nett, for eksempel virksomhetens intranett.
Å distribuere informasjon på papir er arbeidskrevende og kostbart sammenlignet med alternativene, men vi skal ikke avskrive papir helt likevel. Informasjon som mottas på papir, blir ofte oppfattet som viktigere enn noe som kommer som e-post, og det er derfor større sjanse for at informasjonen blir lest og tatt vare på.
E-post er en effektiv måte å distribuere informasjon på, men den er ikke alltid like hensiktsmessig. De fleste som arbeider i en virksomhet, mottar et stort antall e-postmeldinger hver dag. Hvis informasjonen ikke er aktuell akkurat når e-postmeldingen leses, er det store muligheter for at den blir arkivert, glemt eller slettet. Det gjør det vanskelig for brukeren å finne informasjonen senere, når han har behov for den.
En mulighet er å sende informasjonen som vedlegg i en e-post. Det øker mulighetene for at den blir tatt vare på, men samtidig krever det en del ekstra arbeid fra brukerens side; vedlegget må lastes ned, åpnes eller eventuelt skrives ut før informasjonen kan leses. E-post bør derfor helst bare benyttes til å distribuere informasjon som skal brukes med en gang.
Publisering på nett er ofte den mest effektive måten å distribuere informasjon på. Metoden er kostnadseffektiv og krever som regel lite arbeid hvis virksomheten har en intranettløsning eller tilsvarende informasjonstjeneste. Ulempen er at brukerne selv må oppsøke informasjonen når de trenger den. Hvis de ikke er aktive brukere av informasjonstjenesten, når informasjonen sent eller aldri fram.
Informasjon som legges ut på nettsider, bør alltid være i et format som kan skrives ut. Dette er spesielt viktig for prosedyrer der brukeren vil ønske å kunne lese instruksjonene samtidig som han utfører dem på maskinen.
I praksis viser det seg at det er langt vanskeligere å holde informasjon oppdatert enn det man i utgangspunktet skulle tro. I de fleste virksomheter trenger man ikke å lete lenge for å finne utdatert informasjon. Bruk av Internett/intranett har heller ikke gjort situasjonen bedre.
Problemet med utdatert informasjon oppstår fordi det ofte finnes en rutine for å dokumentere, men ingen rutine for å oppdatere eller fjerne gammel dokumentasjon. En annen årsak er at ansatte slutter, og at den som overtar, er usikker på om gammel dokumentasjon er utdatert eller ikke. Da føles det ofte tryggere å ikke gjøre noe enn å risikere å fjerne noe som kanskje fortsatt er aktuelt.
Du vil aldri kunne eliminere problemet med utdatert informasjon helt, men her er noen enkle grep som kan hjelpe langt på vei: