Hvis én udvikler kender hele produktet, har I en risiko, der ikke står i nogen rapport, før den dag personen ikke er der. Det skyldes sjældent, at nogen holder på viden med vilje. Det er sket, fordi det var den hurtigste måde at arbejde på. Afhængigheden kan kortlægges på en eftermiddag og spredes over nogle måneder med dokumentation, parprogrammering og fælles adgange. Begynd, mens personen er her og gerne vil hjælpe.
Hvad det koster jer
I faget taler man om en bus factor: hvor mange personer skal forsvinde, før projektet går i stå? Er svaret ét, har I et problem, også selv om alle har det godt.
Personen behøver ikke at sige op. Sygdom, barsel eller lang ferie giver samme problem, og det sker oftere. I hverdagen koster det også. Fejl venter, til personen er tilbage. Nye medarbejdere kommer langsomt i gang, og teamet tør ikke ændre det, de ikke forstår. Samtidig kan personen selv have svært ved at holde fri, og mange bliver trætte af at være den eneste, der kan.
Kunder med krav til jeres leverandørrisiko begynder i øvrigt også at spørge, se kundens spørgeskema om produktet. Den samme risiko i en virksomhed, der bruger IT frem for at lave software, er beskrevet på ekstern-it-chef.dk under afhængig af en person.
Kortlæg afhængigheden
Sæt teamet sammen en eftermiddag. Tag en liste over produktets dele: fx betaling, login, integrationer, database, byggesystem, drift og de vigtigste kunders særlige løsninger. Spørg for hver del:
- Hvem kan ændre det her i dag med sikkerhed?
- Hvem kan rette en fejl her, hvis det sker en lørdag?
- Hvor står det skrevet, hvordan det virker?
Skriv navne på. Giv hver del en farve: rød for én person, gul for to, grøn for flere. Det færdige kort viser, hvor risikoen ligger, og det er tit overraskende.
Se også på det, der ikke er kode: adgange, konti, certifikater, aftaler med leverandører og viden om, hvorfor ting er, som de er. Tjek, hvem der står som ejer af domænet og app-butikken, se tjeklisten om ejerskab.
Læg vægten på de røde områder, der betyder mest for forretningen. Et rødt område, som ingen har rørt i to år, kan vente. Et rødt område, der ændres hver uge og bærer betalingen, kan ikke.
Fordel viden
Parprogrammering. To udviklere arbejder sammen på samme opgave ved samme skærm. Det er den hurtigste vej til at flytte viden, som ingen tænker på at skrive ned. Lad den, der ikke kender området, styre tastaturet, mens den erfarne forklarer.
Rotation af opgaver. Giv bevidst den næste opgave i det røde område til en anden, og lad nøglepersonen være den, der hjælper og gennemgår. Det går langsommere til at begynde med. Det er prisen, og den er værd at betale.
Kodegennemgang. Når andre skal godkende ændringer i området, lærer de det at kende, se en udviklingsproces, der passer til fem udviklere.
Fælles vagt. Lad flere tage vagten og rette fejl i området, med nøglepersonen som backup. Intet lærer folk et system så hurtigt.
Skriv det rigtige ned
Dokumentation af alt er spild. Skriv det, der er svært at se i koden:
- Et overblik over, hvordan delene hænger sammen.
- Hvordan man sætter produktet op, frigiver det og ruller en ændring tilbage.
- Hvad man gør ved de almindeligste fejl, som en kort driftsvejledning.
- Hvorfor de vigtigste valg blev truffet, se skriv de tekniske beslutninger ned.
Lad en anden end nøglepersonen skrive. Den, der skal lære det, stiller de rigtige spørgsmål, og resultatet bliver forståeligt for andre. Test det ved at lade en, der ikke kender området, følge vejledningen.
Korte optagelser kan også hjælpe, hvis en erfaren person forklarer en del af systemet, mens de viser det på skærmen. Det er hurtigt, og det kan bruges ved oplæring.
Adgange
Adgange skal ikke hænge på en enkelt person. Læg dem i en fælles adgangskodeboks, og giv mindst to personer administratorret. Tjek, at ingen automatik kører i en privat konto, og at nøgler til produktion kendes af flere. Afprøv det: kan en anden lave en release og gendanne fra backup uden at spørge nøglepersonen?
Sådan tager I samtalen
Det er vigtigt, hvordan I siger det. For nøglepersonen kan det lyde som et tegn på, at vedkommende skal skiftes ud, eller at viden er det, der gør personen værdifuld. Sig det åbent: vi vil gerne have, at du kan holde ferie, og at du får tid til andet end at rette fejl. Giv opgaven et formål, som personen får noget ud af, fx mere interessante opgaver eller en rolle som den, der lærer andre op. Giv personen tid. Viden spredes ikke oven i et fuldt skema.
Sæt det ind i køreplanen, så det ikke altid taber til nye funktioner. Tjek kortet igen hvert kvartal.
Skulle personen allerede være på vej ud, så brug opsigelsesperioden, se opsigelsesperioden for en CTO. Er nøglepersonen stifteren, tager det længere tid, se softwarehusets stifter stopper.
Det skal I lade være med
- At skrive alt ned på én gang · det forældes, og ingen læser det.
- At lade nøglepersonen stå alene med opgaven · vedkommende er i forvejen den travleste.
- At vente til en opsigelse · viden flyttes bedst, mens der er tid og god vilje.
Det skal I kræve af den eksterne
- ☐ Et kort over produktets dele og hvem der kender hvad.
- ☐ En prioriteret plan efter betydning for forretningen.
- ☐ En kontrol af adgange, konti og automatik i personers navn.
- ☐ Opfølgning hvert kvartal, så kortet bliver grønnere.
Senest gennemgået: november 2026.
Næste skridt
Læs også: CTO’en har sagt op: de første 30 dage · Lead developeren er blevet flaskehalsen
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
