En teknisk køreplan er ét overblik over det arbejde, produktet skal have, for at det kan blive ved med at virke og udvikle sig: opgraderinger, afvikling af gæld, skalering, sikkerhed og krav fra kunder og regler. Den står ved siden af produktkøreplanen, som viser de funktioner, kunderne får, og de to skal deles om den samme kapacitet. Uden den taber platformsarbejdet hver prioritering, indtil noget går galt. Med den kan ledelsen se, hvad der er planlagt, hvad det koster af nye funktioner, og hvornår en risiko er accepteret med åbne øjne.
Hvorfor to spor, der skal mødes
Produktkøreplanen er let at forsvare. Hver linje har en kunde, en sælger eller en konkurrent bag sig. Platformsarbejde har en udvikler bag sig, som taler om versionsnumre. Står det på hver sin liste, vinder funktionerne, og når I først opdager prisen, er den høj.
Formålet er derfor at samle tingene ét sted, så ledelsen træffer valget. Den tekniske køreplan skal ind i den samme prioritering som funktionerne, med de samme mennesker til stede. Lever den et liv for sig hos udviklerne, får den ingen virkning.
Hvad der hører med
Fire slags arbejde dækker det meste:
- Vedligehold, der har en dato. Sprog, platforme og komponenter, der mister support, certifikater og aftaler, der udløber. Datoen kommer, uanset om I vil det eller ej.
- Afvikling af gæld. De poster fra overblikket over teknisk gæld, der koster mest i tid og risiko.
- Evne og kapacitet. Det, der skal til for at nå næste trin: flere kunder, større kunder, hurtigere udgivelser, bedre overvågning.
- Krav udefra. Det, store kunder forventer, og det, reglerne for softwarevirksomheder kræver på bestemte datoer. Krav med en lovfastsat dato skal planlægges bagfra.
Skriv hvert punkt, så det kan forstås
En teknisk post får plads, når dens konsekvens er tydelig. Brug denne form: Hvad er det, hvad sker der, hvis vi lader være, hvad bliver bedre, hvor stor er opgaven, og hvem ejer den?
Et tænkt eksempel: “Skift af den databaseversion, leverandøren holder op med at opdatere. Lader vi være, kører vi fra næste efterår på en version uden sikkerhedsrettelser, hvilket flere kunder har skrevet ind i deres aftaler. Opgaven er stor og tager det meste af en udviklers tid i to måneder. Ejer: lead developer.” Den tekst kan en direktør tage stilling til. “Opgradér databasen” er sværere at veje mod en kundefunktion.
Sådan får platformsarbejdet plads
Tre modeller er almindelige, og mange teams blander dem.
En fast del af kapaciteten. Teamet har altid en aftalt del af tiden til platformsarbejde. Det er den mest robuste model, fordi arbejdet ikke skal forhandles hver gang. Hvor stor delen skal være, afhænger af produktets tilstand og skal besluttes af ledelsen.
Følgeskab med funktioner. Når en ny funktion alligevel rører et gammelt område, rydder teamet op dér som en del af opgaven. Det kræver, at estimater regner tiden med, ellers sker det ikke.
Afgrænsede projekter. Større opgaver får egen plads på køreplanen med en start og en slutning, for eksempel skift af hosting.
Den, der skal sige ja til fordelingen, er ledelsen. Bliver platformsarbejde fjernet, så snart salget presser på, har I ingen plan. Aftal derfor, at en sådan ændring skal besluttes udtrykkeligt og noteres, så I kan se, hvad I har valgt fra. Pres fra salget har sin egen artikel om løfter, som udviklingen ikke kan indfri.
Hvornår er et funktionsstop rimeligt?
Et funktionsstop, på engelsk feature freeze, betyder, at nye funktioner sættes i bero i en periode, mens teamet samler sig om fundamentet. Det er en tung beslutning, og den virker kun i særlige situationer. Rimelige grunde er gentagne nedbrud, sikkerhedsproblemer, der ikke kan vente, en fast dato for en lukket teknologi eller en flytning, der ikke kan gennemføres med ændringer undervejs.
Stil fire krav. Stoppet har et klart mål, der kan efterprøves. Det har en slutdato. Salg og kunder ved, hvad der sker, og hvad der ikke sker, i perioden. Og der er en undtagelsesregel for akutte kundesager. Mangler et af de fire, ender stoppet som en lang periode, hvor alle er utilfredse.
Form og rytme
Hold planen enkel. Tre kolonner rækker: nu, næste og senere. Datoer er kun nødvendige, hvor de er reelle. Punkterne i “nu” er aftalte, punkterne i “senere” er retning.
Gennemgå den sammen med produktkøreplanen hvert kvartal, og lad den stå som fast punkt i ledelsesrapporteringen. Den CTO eller lead developer, der ejer planen, skal også kunne forklare, hvad der blev rykket, og hvorfor.
Det skal I lade være med
- At have to adskilte møder om funktioner og platform · så ser ingen afvejningen.
- At lave planen så detaljeret, at den er forældet efter en måned · retning og rækkefølge er det, der skal holde.
- At lade funktionsstop stå åbent · uden slutdato bliver det en vane, salget ikke kan leve med.
Det skal I kræve af den eksterne
- ☐ Én samlet plan med alle fire slags arbejde, skrevet, så ledelsen kan følge den.
- ☐ Konsekvensen af at lade være for hvert større punkt.
- ☐ Et forslag til fordeling af kapaciteten, som ledelsen kan beslutte.
- ☐ En fast gennemgang med produktansvarlig og salg, så køreplanerne hænger sammen.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Teknologien på ledelsesmødet · Hvorfor holder estimaterne aldrig?
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
