Handover af en specialbygget løsning: det skal I kunne overtage

En specialbygget løsning er klar til overdragelse, når de ansvarlige kan bruge den, finde de nødvendige adgange og håndtere den aftalte drift. En mappe med kode kan være en del af leverancen, men den fortæller ikke nødvendigvis, hvem der betaler for hosting, hvor en fejl bliver meldt, eller hvordan en ny kollega får adgang.

Brug gennemgangen til jeres egen handover. Ejerskab, ansvar og fortsat servicearbejde skal fremgå af jeres aftale.

Lav en oversigt over det, løsningen afhænger af

Begynd med en liste over de konti og tjenester, der holder løsningen i gang. Det kan være domæne, hosting, database, mailtjeneste, kodearkiv og forbindelser til andre systemer. For hver del skriver I, hvem der ejer kontoen, hvem der administrerer den, og hvem der modtager driftsbeskeder og regninger.

Sæt et navn på ansvaret frem for blot at skrive kunden eller leverandøren. Hvis den daglige kontaktperson skifter job, skal oversigten stadig pege på en funktion, som virksomheden kan overtage. Notér også, hvor adgangen administreres. Selve adgangskoder og hemmelige nøgler skal ikke kopieres ind i den almindelige projektbeskrivelse.

Kontroller adgangen med den, der skal bruge den

En sendt invitation er ikke det samme som en gennemført overdragelse. Lad den nye ansvarlige logge ind med sin egen konto og afprøve den relevante handling. Det kan være at invitere en kollega, finde et projekt eller se driftsstatus. Tildel rettigheder efter personens opgave, og aftal hvem der fortsat har brug for adgang efter projektet.

GitHub illustrerer forskellen mellem adgang og ejerskab: tjenesten har flere roller til kodearkiver, og en overførsel af et arkiv flytter ikke automatisk alle forhold omkring den samlede løsning. GitHubs dokumentation beskriver også, at blandt andet webhooks og deploy keys kan følge med et overført arkiv. En overførsel bør derfor ledsages af en gennemgang af forbindelser og rettigheder.

Skriv dokumentationen til de daglige opgaver

Start med de handlinger, som brugeren skal kunne udføre uden hjælp. En kort vejledning til at oprette en sag, finde en kunde og rette en oplysning kan være mere anvendelig end en lang gennemgang af systemets opbygning. Vis, hvad man skal se efter, og hvordan man ved, at ændringen er gemt.

• Hvor starter en ny bruger, og hvordan får personen adgang?
• Hvilke oplysninger skal være klar, før en opgave kan gennemføres?
• Hvordan genfindes en opgave, der blev afbrudt undervejs?
• Hvem kontaktes ved en fejl, og hvilke oplysninger skal følge med?

Gem den tekniske dokumentation ved siden af, med en tydelig målgruppe. Den skal hjælpe den, der vedligeholder løsningen, med at finde kode, opsætning og afhængigheder. Hvis en bestemt version eller en manuel handling er nødvendig for at starte løsningen, skal det være beskrevet. Hold vejledningen fri for nøgler, som giver direkte adgang til driftssystemerne.

Aftal hvad der sker, når noget stopper

Gennemgå, hvem der opdager fejl, og hvem der tager imod dem. Beskriv en reserveprocedure for den vigtigste arbejdsgang, hvis løsningen er utilgængelig. Det kan være at registrere opgaven et aftalt sted og lægge den ind senere. Aftal, hvordan I undgår at registrere den to gange, når systemet er tilbage.

Backup og gendannelse skal også have en ansvarlig. Bed om at få forklaret, hvad der er dækket, hvor det dokumenteres, og hvordan en gendannelse afprøves uden at påvirke det daglige arbejde. En grøn besked om, at en backup er taget, viser ikke i sig selv, at hele forløbet er afprøvet.

Afslut med en prøve fra kundens side

Lad en kommende bruger gennemføre en typisk opgave med sin egen adgang og den dokumentation, der afleveres. Personen skal kunne starte, gennemføre opgaven og finde resultatet igen. Notér de steder, hvor en mundtlig forklaring stadig er nødvendig. De peger ofte på noget, som bør forbedres i vejledningen eller i produktet.

Prøv også en relevant fejl og vejen tilbage. Hvis en invitation udløber, et felt mangler, eller en ekstern forbindelse er utilgængelig, skal det være tydeligt, hvad brugeren kan gøre. Afslut ikke blot prøven ved den første grønne skærm; kontroller at resultatet findes det sted, hvor næste person skal arbejde videre.

Gem restlisten sammen med den aftalte aflevering

Et åbent punkt skal have en beskrivelse, en ansvarlig og et aftalt næste skridt. Skeln mellem fejl i det aftalte og ønsker til en senere udgave. Det hjælper begge parter med at forstå, hvad der er afleveret, og hvilket arbejde der stadig ligger foran dem.

Hvis I endnu er ved at vælge samarbejdspartner, kan I tage spørgsmålene med fra begyndelsen. Læs guiden til valg af udviklingspartner, eller beskriv den løsning, I gerne vil have bygget. Handover bliver lettere at planlægge, når den kommende brug og drift er en del af briefet.

Kilder

GitHub: Transferring a repository og GitHub: Repository roles for an organization, læst 8. september 2026. Bruges til eksemplet om kodearkiv, adgang og overførsel. Den øvrige gennemgang er redaktionens forslag til en praktisk aflevering.