Hvorfor du må dokumentere
Det er ved å dokumentere at du beviser din verdi som en dyktig IKT-servicemedarbeider.
Å 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.
Dokumentere løsninger på problemer
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.
Helpdesken kan ha god nytte av grundig dokumentasjon.
Ta notater fortløpende mens du løser brukerproblemer, så går det raskt å gjøre dem tilgjengelig for deg selv og andre etterpå.
Venn deg til å ta notater med en gang slik at du ikke glemmer viktige detaljer.
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:
- De er strukturerte og løsningsorienterte.
- De blir ajourført fortløpende.
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:
- beskrivelse av problemet
- årsaken til problemet
- løsningen på problemet
Beskrivelsen av problemet forklarer kort hvordan problemet arter seg. For eksempel hva som skjer eller ikke skjer, hva som vises på skjermen, eller andre konsekvenser av problemet.
Årsaken er hva som forårsaker eller utløser problemet. Det kan være brukerfeil, en programfeil, defekt maskinvare og så videre.
Løsningen er beskrivelsen av hva som må gjøres for å ordne feilen.
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.
Dokumentere rutiner
I tillegg til å dokumentere løsninger på problemer er det viktig å dokumentere rutiner.
Husk gode rutiner for sikkerhetskopiering!
Lenke
Guide til god driftsdokumentasjon
(Fra Auduns IT-weblogg)
Her finner du et eksempel på en rutine for sikkerhetskopiering av server.
Den beste måten å dokumentere en rutine på er skrive ned hva du gjør, mens du utfører oppgaven.
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:
- for at oppgaven skal bli gjort
- for at oppgaven skal bli gjort riktig
Å 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
- hva rutinen gjelder
- når den skal utføres
- hvem som skal utføre rutinen
- hvem som er ansvarlig for at rutinen utføres (og hvem man skal rapportere til)
- hva som kreves for å utføre rutinen (for eksempel utstyr, programvare, tilganger og så videre)
- hvem som har skrevet rutinen
- når rutinen er skrevet eller sist oppdatert
- om rutinen er en delrutine som inngår i en større rutine
- steg-for-steg-beskrivelser av hva som skal gjøres
Steg-for-steg-beskrivelser kalles også for prosedyrer. Du lærer mer om hvordan du skal skrive prosedyrer litt senere.
Rutinebeskrivelse
Du må tenke gjennom hvilke personer som må involveres, hvilke standarder som skal følges, hvilken informasjon som må samles inn, hvilken informasjon som må gis ut, hvordan informasjonen skal gis, og så videre.
Her er noen forslag til hva du kan vurdere:
- Hvem er ansvarlig for å gi beskjed om når en ny bruker skal opprettes?
- Hvem bestemmer hvilke tilganger brukeren skal ha?
- Hva skal standarden for brukernavn og passord være?
- Hva skal standarden for e-postadresse være?
- Skal brukeren ha et eget dataområde på serveren?
- Hvem er ansvarlig for å informere brukeren om hvordan han logger seg på?
- Hvem er ansvarlig for at en brukerkonto blir slettet eller deaktivert når en person slutter?
- Hva skal skje med data som ligger på personlig dataområde eller e-post som ligger igjen etter en bruker som slutter?
Listen er ikke komplett, men er ment å gi en idé om hva slags informasjon du kan ta med i rutinen.
Merk at det ikke er meningen at du skal skrive noen steg-for-steg-beskrivelser som viser hvordan man oppretter brukere, e-postkontoer eller lignende i denne oppgaven.
Skrive brukerdokumentasjon
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:
- Hvem skriver jeg for?
- Hvilket kunnskapsnivå har brukeren?
- Hvorfor leser brukeren dokumentasjonen?
- Når og hvor leser brukeren dokumentasjonen?
- Hva vil jeg oppnå med dokumentasjonen?
- Hvilket detaljnivå er nødvendig?
- Kan illustrasjoner eller video være til noen hjelp?
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. (Se eksempel i figuren under.)
Eksempel på innledning til brukerdokumentasjon.
Opphavsmann: Arne Jansen
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.
Skrivetips
Ikke alle er forfattere – og det er heller ikke nødvendig for å skrive brukerdokumentasjon. Det vesentlige er at informasjonen er lettlest, og at den blir forstått.
Skrivefeil kan være morsomme og sjarmerende i visse sammenhenger, men i brukerdokumentasjon bør du passe på å unngå stavefeil.
Det vesentlige er at informasjonen er lettlest, og at den blir forstått.
Her ser du et eksempel på hvordan skjermdumper og tekst kan spille sammen og forenkle forståelsen for leseren.
Her kan du finne et eksempel på en enkel brukerveiledning i videoformat: Skifte blekk i printeren
Bruk enkelt språk og korte setninger
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.
Det som er opplagt for deg, er ikke alltid like opplagt for andre
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.
Vær konsekvent
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.
Bruk stavekontrollen
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.
Hvis det er vanskelig å forklare, vis det i stedet
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.
Skrive brukerinformasjon
Hensikten med denne oppgaven er at du skal få øve deg på å skrive informasjon for brukere. Oppgaven bør gjøres individuelt.
Tenk deg at du er IKT-servicemedarbeider i en bedrift som har hatt mye problemer med datavirus de siste månedene. En stor del av grunnen til virusproblemene er at brukerne har for liten kunnskap om hva et datavirus er, og hvordan det fungerer. Du skal derfor skrive en enkel informasjon som forklarer
- hva et datavirus er
- hvordan brukeren skal unngå at maskinen får virus
- hvordan brukeren kan oppdage at maskinen har fått et datavirus
- hva brukeren skal gjøre når han har mistanke om at maskinen har fått et datavirus
Du må ta hensyn til at mange av brukerne har liten kunnskap om IKT generelt, og at brukerne stort sett ikke vet mer om datavirus enn det de har lest i aviser eller hørt på radio eller sett på TV.
Skrive for skjerm
En godt utformet tekst gjør det enkelt for brukeren å lese.
Husk
- Start med konklusjonen.
- Uthev nøkkelord.
- Lag gode overskrifter.
- Bruk punktlister.
- Ha ett poeng per avsnitt.
- Bruk få ord.
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:
Uthev nøkkelord
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.
Bruk meningsfulle avsnittsoverskrifter
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.
Bruk punktlister
Punktlister er raske å skumlese, så de blir derfor nesten alltid lest.
Ha kun ett poeng per avsnitt
Når du har flere poenger du vil formidle, bør du skille dem godt slik at hvert poeng får sitt eget avsnitt.
Start med konklusjonen
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.
Bruk færre ord
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.
- Vi forstår innholdet i en tekst selv om den ikke har så mange ord.
- Vi forstår innholdet i en tekst som har få ord.
- Vi forstår innholdet i en kort tekst.
- Vi forstår kort tekst.
Oppgave – Informasjon for skjerm
Hensikten med denne oppgaven er at du skal få øvelse i å skrive informasjon for skjerm. Du kan gjøre oppgaven individuelt eller sammen med en annen.
Under ser du en tekst som er dårlig formatert og ikke spesielt godt skrevet. Skriv om teksten slik at den blir lettere å forstå – uten at det vesentlige i innholdet forsvinner. Formater den på en slik måte at den er bedre egnet for å lese på skjerm.
Et eksempel på en tekst som er dårlig formatert og ikke spesielt godt skrevet.
Opphavsmann: Arne Jansen
Skrive prosedyrer
Brukerinformasjon skal ofte inneholde prosedyrer som brukeren kan følge steg for steg for å få utført en bestemt oppgave.
Det er ikke vesentlig hvilken løsning du velger – så lenge du bruker den konsekvent.
Når du er på arbeid som IKT-servicemedarbeider, kan det være til stor hjelp å ha gode prosedyrer du kan følge.
Som bruker kan du også ha stor glede av gode prosedyrebeskrivelser. Kanskje du har erfaring med å bruke prosedyrer når du har løst problemer på skolen eller hjemme?
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.
Under ser du et eksempel på en prosedyre for hvordan man slår på visningen av skjulte filer og mapper i Windows utforsker.
- Åpne Windows Utforsker (Startknappen – Datamaskin).
- Velg menyen Organiser og Mappe og søkealternativer.
Dialogboksen Mappealternativer vises. - Velg fanen Vis.
- Velg rullefeltet Avanserte innstillinger, rull ned til Skjulte filer og mapper.
- Klikk på radioknappen Vis skjulte filer, mapper og stasjoner.
- Klikk OK.
Eksempelet viser de viktigste prinsippene for å skrive prosedyrer.
De valgene brukeren skal gjøre, er tydelig markert (uthevet)
Når man uthever de valgene som skal utføres i hvert steg, kan hele prosedyren sammenfattes ved å bare bruke de uthevede ordene:
- Windows Utforsker
- Organiser – Mappe og søkealternativer
- Vis
- Avanserte innstillinger – Skjulte filer og mapper
- Vis skjulte filer, mapper og stasjoner
- OK
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.
Tilleggsinformasjon og kommentarer er satt i kursiv
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.
Alle stegene i prosedyren er nummerert
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.
Alle stegene står i den rekkefølgen de skal utføres
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.
- Velg Mappe og søkealternativer fra menyen Organiser.
- Velg menyen Organiser og Mappe og søkealternativer.
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.
Prosedyren beskriver resultatet av en handling og det man skal se på skjermen
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.
Distribuere informasjon
Når man har skrevet brukerinformasjon, må man velge hvordan man skal distribuere den. Det er flere mulige måter å distribuere på, og alle har sine fordeler og ulemper.
Det er fremdeles mulig å sende ut informasjon til kollegaene dine på papir, men vurder når denne løsningen er mest hensiktsmessig.
E-post er en effektiv måte å distribuere informasjon på, men innholdet kan lett forsvinne blant mange andre e-poster.
Informasjon som legges på nettsider, bør alltid være i et format som kan skrives ut.
De tre mest aktuelle måtene å distribuere informasjon på er papir, e-post eller publisering på nett, for eksempel virksomhetens intranett.
Papir
Å 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
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
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 informasjonstjenete. 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.
Ikt-ressurser 
0 Comments