Som hovedregel bør et produkt med betalende kunder forbedres gradvist, og en samlet omskrivning er undtagelsen, der skal begrundes. En omskrivning lover en ren start, men I skal bygge alt det, der allerede virker, en gang til, mens det gamle produkt fortsat skal rettes, drives og sælges. Valget er en forretningsbeslutning med store konsekvenser, og det bør træffes af ledelsen på et skriftligt grundlag. Udviklernes frustration er et vigtigt signal, og den kan ikke stå alene som begrundelse.
Hvorfor omskrivninger trækker ud
Det gamle produkt rummer mere viden, end nogen kan se. Hver mærkelig betingelse i koden kan være en kundesag fra for ti år siden, en særregel fra en skattelov eller en rettelse efter et nedbrud. Den viden er sjældent skrevet ned, så det nye produkt møder de samme fejl en efter en.
Hertil kommer det løbende mål. Mens I bygger, får det gamle produkt nye funktioner, ellers mister I salget. Hver af dem skal også ind i det nye, så slutpunktet flytter sig. Og i den lange periode leverer de stærkeste udviklere intet, kunderne kan se, mens andre passer det gamle produkt. Det slider på begge hold.
Til sidst venter flytningen. Kunder og data skal over, og produktet er først færdigt, når den sidste kunde har forladt det gamle, som kunderne, der ikke vil over på den nye version, viser. Indtil da har I to produkter.
Tre veje at vælge imellem
Diskussionen bliver ofte til ja eller nej til en omskrivning. Reelt er der tre veje:
- Vedligehold og lad være. Produktet kører, kunderne er tilfredse, og forretningen vokser andre steder. Det kan være det rigtige, og det kræver et ærligt blik på, hvor længe det holder.
- Gradvis forbedring. I retter de dele, der ændres oftest, og flytter stykke for stykke over på ny teknologi, mens produktet er i drift. Udførelsen står i gradvis udskiftning i praksis.
- Samlet omskrivning. I bygger et nyt produkt ved siden af og flytter kunderne, når det er klar.
Fem spørgsmål, der afgør det
- Hvad er det konkrete problem? “Koden er grim” er en beskrivelse. “Det tager flere uger at ændre prisberegningen” eller “ingen kan hyres til denne teknologi” er problemer, der kan vurderes.
- Sidder problemet i hele produktet eller i bestemte dele? Sidder det i nogle få moduler, er en samlet omskrivning for stort et værktøj.
- Kan de to udgaver leve side om side? Kan nye dele kobles på det gamle, er den gradvise vej åben.
- Kan vi leve uden nye funktioner i lang tid? Hvad sker der med salget og med konkurrenterne imens?
- Er produktet egentlig det rigtige? En omskrivning er kun værd at tage, hvis I ved, hvad det nye skal kunne. Er forretningen ved at skifte retning, er det dét, der skal afklares først.
Hvornår en omskrivning alligevel er rigtig
Der er rimelige grunde. Produktet er lille, kunderne er få, og det kan bygges igen på overskuelig tid. Teknologien kan ikke længere drives forsvarligt, og den kan ikke opdateres eller skilles ad, se produkt i gammel teknologi. Grundantagelserne i data er så forkerte, at al ny udvikling kæmper imod dem. Eller det gamle produkt er en installeret løsning, der skal blive til en tjeneste, hvor overgangen til SaaS kræver en ny kerne.
Også i de tilfælde kan omskrivningen skæres til. Sæt den første version så snævert som muligt, vælg en kundegruppe, den kan betjene fuldt ud, og flyt dem først.
Stil krav til beslutningsgrundlaget
Bed om et kort, skriftligt oplæg på få sider. Det skal beskrive problemet i forretningens sprog, de tre veje med fordele og risici, hvad I ikke får lavet imens, og hvordan I kan stoppe undervejs uden at have tabt det hele.
Det sidste er det vigtigste. Aftal på forhånd, hvad der skal være leveret og i brug hos rigtige kunder efter første etape, og hvad I gør, hvis det ikke er nået. En plan, der først giver værdi, når alt er færdigt, er den farligste version.
Vær opmærksom på, hvem der taler. Nye udviklere og nye leverandører ser ofte det gamle som dårligt, for de har ikke været med til at bygge det, og en leverandør tjener på det nye projekt. Vurderingen kan sagtens være rigtig, og den skal efterprøves, se artiklen om påstanden, at alt skal laves om.
Har ingen i ledelsen de tekniske forudsætninger for at veje argumenterne, giver det mening at hente en, der ikke selv skal bygge det nye. Et forløb hos Nielco IT begynder med en gennemgang, der ser på teknologivalg, team, ledelse og leverandører. Den kan købes for sig, og kodearbejdet forbliver hos jeres egne udviklere. Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud.
Det skal I lade være med
- At lade et enkelt argument om teknologi afgøre sagen · uden konsekvenser for kunder og salg er det halvdelen af billedet.
- At stoppe al udvikling på det gamle uden en dato · kunderne mærker det længe før det nye er klar.
- At love en slutdato, før første del er leveret · datoen bliver et løfte, ingen kan holde.
Det skal I kræve af den eksterne
- ☐ Et skriftligt oplæg med alle tre veje, også den, hvor I lader være.
- ☐ En klar beskrivelse af, hvad I ikke får lavet i perioden.
- ☐ Første etape med værdi for rigtige kunder og et aftalt stoppunkt.
- ☐ Uafhængighed af den, der skal bygge det nye.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Teknisk gæld forklaret for ledelsen · Et produkt, der er vokset fra sin teknologi
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
