Teknisk køreplan og teknisk gæld

Alle softwareprodukter opbygger teknisk gæld: de genveje og forældede løsninger, der gjorde det muligt at levere i går, og som gør det langsommere at levere i morgen. Gælden er sjældent en fejl, og den kan være et fornuftigt valg, så længe nogen ved, at den er der. Det bliver et ledelsesproblem, når den ikke kan ses i planen. Så oplever direktøren, at alting tager længere tid, mens udviklerne oplever, at de aldrig får lov at rydde op. Siden her samler artiklerne om, hvordan de to verdener kommer til at bruge samme plan.

Det, der går igen

De fleste uenigheder mellem ledelse og udviklere kan føres tilbage til tre spørgsmål. Hvad koster det os i tid og risiko at lade det ligge? Hvor stor en del af kapaciteten går til platformen, og hvem har besluttet det? Og hvem kan sige nej til et nyt løfte? Svarene skal stå ét sted, som både ledelse og udviklere kan læse. Det sted er køreplanen, altså den plan for det kommende arbejde, som produktet følger. Er det en stor beslutning om produktets fremtid, I står med, fortsætter emnet under gammelt produkt.

Gælden gjort forståelig

• Teknisk gæld forklaret for ledelsen Hvad gælden koster i tid og risiko, og hvorfor den ikke forsvinder af sig selv.
• Sådan gør I teknisk gæld synlig og prioriterbar Et gældsregister, en fast del af kapaciteten, og hvem der beslutter.
• Skal produktet skrives om? Hvorfor store omskrivninger ofte trækker ud, og hvordan valget træffes.

Plan og prioritering

• Teknisk køreplan ved siden af produktkøreplanen Hvordan platformsarbejde får plads, og hvornår et stop for nye funktioner er rimeligt.
• Når salg lover det, udviklingen ikke kan holde Et bestemt møde, hvor salgets løfter vurderes, og en aftale om, hvem der kan afvise dem.
• Hvorfor holder estimaterne aldrig? Intervaller, små leverancer og tidlige varsler, og hvorfor tavse forsinkelser er det egentlige faresignal.

Når tempoet falder

• Hvorfor går udviklingen langsommere end før? Årsagerne i kode, proces og organisering, og hvordan flowet måles frem for den enkelte udvikler.
• Når én udvikler kender hele koden Afhængigheden kortlagt og spredt gennem dokumentation, parprogrammering og adgange.

Teknologien på ledelsesmødet

• Teknologien på ledelsesmødet: hvad direktion og bestyrelse skal se Hvad ledelsen har brug for at se om produktet hver måned, skrevet, så alle kan læse det.

Fra uenighed til fælles plan

Ledelsen behøver ikke forstå koden for at tage stilling til gælden. Den skal have valget stillet op, så det ligner andre forretningsvalg: det her kan vente, det her gør de næste leverancer langsommere, og det her kan vælte en kundeaftale. Det kræver, at nogen kan oversætte begge veje, og i mange virksomheder er det den rolle, der mangler. Rapporterer I også til bestyrelsen om sikkerhed, er det et emne for sig, som er beskrevet under bestyrelsen og sikkerheden. Hænger uenigheden om tempo sammen med, at alt går gennem én person, så læs Når jeres tekniske leder ikke kan nå det hele.

Det er også værd at se på, hvor gælden opstår. Nogle gange ligger årsagen i aftaler med kunder, og så er særlige versioner af produktet det sted, der skal ændres.

Det skal I lade være med

• At behandle oprydning som noget, udviklerne laver i overskudstiden · den tid kommer ikke af sig selv.
• At bruge estimater som løfter · bed om intervaller, og følg op tidligt.
• At måle den enkelte udvikler på antal leverancer · det flytter arbejdet derhen, hvor målingen peger.
• At starte en omskrivning for at slippe for samtalen · valget skal træffes med åbne øjne.

Det skal I kræve af den eksterne

• ☐ Et gældsregister, som ledelsen kan læse uden oversættelse.
• ☐ En køreplan, hvor platformsarbejde står ved siden af nye funktioner.
• ☐ Faste punkter til ledelsesmødet i et sprog uden fagord.
• ☐ Tidlige varsler, når en dato ikke længere kan holdes.

Senest gennemgået: november 2026.

Næste skridt

• Teknisk gæld forklaret for ledelsen
• Sådan foregår et forløb

Læs også: Artikler om CTO as a Service · Det får I af en fractional CTO

→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT