Har hver stor kunde sin egen udgave af koden, betaler softwarehuset for hver rettelse flere gange, og udviklingen bliver langsommere for hver aftale, salget lukker. Vejen tilbage går gennem tre skridt: et overblik over alle afvigelser, en sortering af dem, og en fast flytning af kunderne over på én fælles kode, hvor forskellene styres med konfiguration. Samtidig skal salget have en grænse, ellers vokser problemet hurtigere, end teamet kan afvikle det. Det er et ledelsesspørgsmål, fordi årsagen ligger i de aftaler, virksomheden har indgået.
Sådan opstår det
Det begynder med en god grund. En vigtig kunde vil have en særlig beregning, en anden rapport eller en anden arbejdsgang. Udvikleren laver en kopi af koden, en såkaldt forgrening eller fork, og retter den til. Det går hurtigt, kunden er glad, og der er en faktura at sende.
Så kommer næste kunde. Efter nogle år er der flere udgaver, der ligner hinanden og ikke helt er ens. En sikkerhedsrettelse skal laves mange steder, nye funktioner skal tilpasses hver udgave, og kun enkelte kender forskellene. I et installeret produkt kan det gemme sig i årevis, for hver kunde har sin egen installation. Det bliver først rigtig synligt, når I vil flytte til SaaS eller opdatere til en ny platform.
Tegn på, at I er der
- En fejl, der er rettet hos én kunde, dukker op hos en anden.
- Nye funktioner rulles ud kunde for kunde, med særskilt test.
- Teamet svarer “det afhænger af kunden” på, om noget virker.
- Nogle kunder står på gamle versioner, fordi deres tilpasninger ikke kan flyttes.
- Support skal slå op, hvilken udgave kunden har, før de kan svare.
Det er også et tegn, hvis ingen kan sige præcist, hvad I har lovet hvem.
Fælles kode med forskelle, der er styret
Målet er ét produkt, hvor forskellene mellem kunder ligger uden for koden eller på bestemte, kontrollerede steder. Der er tre redskaber.
Konfiguration. Kundens forskelle står som indstillinger: regler, felter, skabeloner, godkendelsesflow. Samme kode håndterer alle, og indstillingerne kan testes.
Funktionsflag. Et flag, på engelsk feature flag, er en kontakt, der tænder eller slukker en funktion for bestemte kunder. Det er godt til gradvis udrulning og valgfrie moduler. Hold flagene få, ellers bliver de selv en kilde til rod.
Udvidelsespunkter. Produktet har faste steder, hvor kundespecifik logik kan kobles på, for eksempel via API’et, altså produktets grænseflade til andre systemer. Så lever særlige behov uden for kernen og kan opdateres for sig.
Det, kunderne har fået, skal altså over i disse former. Kan et ønske ikke presses ned i én af dem, er det et tegn på, at det ikke bør ind i produktet.
Vejen tilbage til ét produkt
- Kortlæg. Lav en liste over alle tilpasninger: hvem har dem, hvad gør de, bruges de stadig, og er de nævnt i kundens aftale? Det er en opgave for teamet og support sammen, og resultatet overrasker ofte.
- Sortér. Hver tilpasning får én af fire skæbner. Den bliver standard for alle, fordi flere har brug for den. Den bliver konfiguration. Den bortfalder, fordi ingen bruger den. Eller den forbliver en særaftale med en navngiven ejer.
- Vælg en basis. Find den udgave, der ligger tættest på det, I vil have, og gør den til hovedsporet.
- Flyt kunderne en ad gangen. Begynd med dem, der afviger mindst. Hver flytning lærer jer noget og gør listen kortere.
- Luk døren bag jer. Når en udgave er tom, slettes den. Tilbage ligger fælles kode.
Planen hører hjemme på den tekniske køreplan, for den kører i årevis ved siden af det øvrige arbejde. Kundernes aftaler kan binde jer til funktioner, så tjek dem tidligt, og tag spørgsmål om ændring af aftaler med en advokat.
En grænse, salget kan arbejde med
Ét produkt holder kun, hvis der kommer færre nye særaftaler. Salget skal derfor have en grænse, som de kan sælge ud fra.
Et godt regelsæt svarer på tre spørgsmål. Hvad kan vi altid? Det står på en kort liste over, hvad konfiguration dækker. Hvad kan vi gøre som produktudvikling? Det, der har værdi for flere kunder, og som kommer på køreplanen. Hvad gør vi ikke? Det kan være kode til én kunde, uanset kundens størrelse. Beslutningen om undtagelser skal ligge ét sted, hos den, der ejer produktet, og den skal skrives ned.
Når én kunde presser på, er spørgsmålet ofte større end en enkelt funktion. Det er beskrevet i én stor kunde vil bestemme køreplanen. Sælger I til virksomheder, der selv vurderer, om de bør tilpasse eller holde sig til standarden, kender mange af dem afvejningen mellem tilpasning eller standard fra køberens side, og det kan bruges i samtalen.
Det skal I lade være med
- At fjerne tilpasninger uden at tale med kunden · nogle af dem bærer en vigtig arbejdsgang.
- At erstatte kopier af koden med hundredvis af flag · så har I flyttet problemet.
- At lade salget aftale kode til én kunde, før produktansvarlig har set det · det er sådan, det hele begyndte.
Det skal I kræve af den eksterne
- ☐ Et samlet overblik over tilpasninger, koblet til kunder og aftaler.
- ☐ En plan for flytning af kunderne i en rækkefølge, teamet kan bære.
- ☐ Et regelsæt for salget, skrevet sammen med dem, der skal bruge det.
- ☐ Klare krav til, hvordan nye forskelle må håndteres i produktet.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Når salg lover det, udviklingen ikke kan holde · Teknisk gæld forklaret for ledelsen
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
