Ja! Det forekommer! Og selvom teknisk gæld er uønsket, så kan det være et nødvendigt kompromis for at nå i mål med et komplekst it-system. Så hvordan håndterer du teknisk gæld?
Teknisk gæld er i praksis mere reglen end undtagelsen. Især med store, komplekse, specialudviklede it-systemer.
Som topleder tænker du måske som følger:
”Men hvordan skete det lige? Jeg mener … Vi har lige anskaffet et nyudviklet it-system til et større millionbeløb til erstatning for det gamle bras. Og vi måtte endda tage af reservebudgettet for at komme helt i mål. Så forventer vi da også, at systemet er spitzenklasse!”
En stor del af den tekniske gæld blev formentlig stiftet kort tid efter, at it-leverandøren rapporterede risiko for forsinkelse af leverancerne og behov for benhård prioritering.
Måske foreslog it-leverandøren at udskyde dele af leverancerne?
Men det ville betyde, at forretningen skulle leve med uhensigtsmæssige arbejdsgange på tværs af det nye system og det gamle system i en længere periode. Og konsekvensen ville måske være lavere produktivitet eller dårligere kundeservice?
I blev derfor enige om at udskyde leveringstidspunktet lige til smertegrænsen. Og måske accepterede I også øgede udviklingsomkostninger for, at leverandøren kunne øge bemandingen.
Måske sagde forretningens ledelsesrepræsentant på styregruppemødet noget i stil med følgende:
”Vi har i forretningen ikke ekstra kapacitet til at kompensere for uhensigtsmæssige overgangsløsninger. Afdelingen kører på forhånd på pumperne – ikke mindst pga. at vi skulle deltage i flere langstrakte afklaringsforløb i projektet end oprindeligt planlagt.
Vi accepterer den nye deadline og de øgede udviklingsomkostninger.
Men it-systemet skal leveres i sin helhed … no matter what! Vi kan ikke tåle flere forsinkelser!”
Og her opstår misforståelsen.
It-leverandøren opfatter formentlig meldingen som en carte blanche til at indgå alle nødvendige kompromiser. Og måske indbefatter dette mere end forretningens ledelsesrepræsentant lige havde fantasi til at forestille sig?
Måske har it-leverandøren allerede udskudt at udarbejde de mere tekniske dele af dokumentationen. Det kan være et acceptabelt kompromis – men så kun på den korte bane.
Næste kompromis er måske at droppe den del af udviklingsarbejdet, der skal gøre løsningen lettere at driftsovervåge. Konsekvensen kan i praksis være lavere oppetid.
Måske er det også hurtigere for programmørerne at kopiere og tilpasse eksisterende kode – end at genbruge og videreudvikle eksisterende komponenter og overholde arkitekturen? Konsekvensen er øget kompleksitet i koden og dermed øgede omkostninger og leveringstid til efterfølgende vedligeholdelse og videreudvikling.
Måske bliver nogle af programmørerne på projektet hasteomdirigeret til nye opgaver, men uden at få mulighed for at teste den netop udviklede systemintegration til bunds. Programmørerne tænker måske, at kompromiset er acceptabelt. Det meste af koden er jo alligevel kopieret fra et tidligere udviklingsprojekt, hvor der blev gjort meget ud af at sikkerhedsteste.
Men den it-mæssige kontekst for systemintegrationen er nu en anden. Og evt. sikkerhedsmæssige konsekvenser bliver ikke gennemtænkt og i værste fald heller ikke testet til bunds. Konsekvensen kan være øget sikkerhedsrisiko. Fx med risiko for tab af fortrolighed og integritet af data ved integrationen.
Typisk lider testforløbet stort under det opskruede projekttempo.
Dækningsgraden for testen bliver utilstrækkelig og fokus er især på den primære funktionalitet. Og samtidig begynder testteamet at overse nye fejl, når udviklingsteamet leverer fejlrettelser.
Måske udskyder projektet også penetrationstesten og andre sikkerhedstest på ubestemt tid?
I takt med at deadline nærmer sig, står det også mere og mere klart, at ikke alle fejl kan nå at blive rettet inden idriftsættelsen. De kritiske fejl bliver rettet, men forretningen må acceptere flere alvorlige og måske endda en hel del mindre-alvorlige fejl.
Hvis ikke belastningstesten er nedprioriteret, så viser den måske næsten ubrugelige svartider i spidsbelastningsperioder. Problemet er en konsekvens af udviklingsmæssige kompromiser, der tilsidesætter effektiv serverudnyttelse til fordel for hurtigere fremdrift. Og måske kan problemet afhjælpes ved at skrue op for driftsmiljøet, selvom det introducerer nye omkostninger?
Skruer jeg tykt på?
Niks!
Eksemplerne er mere reglen end undtagelsen.
Når projektet skruer op for tempoet og arbejdsindsatsen – især på opløbsstrækningen – så lider kvaliteten.
Også kvaliteten af den tekniske løsning. Og dét er teknisk gæld!
En vis grad af teknisk gæld kan være acceptabelt af hensyn til at styre et komplekst og udfordrende it-projekt i mål til tiden.
Men det er vigtigt, at du som kunde kender kompromiserne og omfanget af teknisk gæld, så det ikke kommer bag på dig. Du bør formentlig ikke acceptere teknisk gæld, der medfører øget risiko for it-sikkerhed. Især ikke hvis du arbejder med fortrolige data eller persondata omfattet af GDPR.
Men måske kan du godt acceptere øget kompleksitet i koden og lavere dokumentationsgrad på den kortere bane, hvis der samtidig er en klar plan for, hvordan den tekniske gæld igen kan afvikles?
For gælden skal betales tilbage. Og tiderne med hårde kompromiser er ikke overstået blot fordi, at it-systemet er i drift.
Så hvad kan du gøre?
Som kunde kan du med fordel have fokus på følgende:
- Stil krav om tidlig forebyggelse, fx med guidelines til udviklingen.
- Vær eksplicit omkring hvilke typer kompromiser og grad af teknisk gæld, du vil acceptere.
- Stil krav om løbende at have indsigt i omfanget af teknisk gæld. Især når det går stærkt.
- Hav en plan for hvordan teknisk gæld afvikles.
- Vær parat til at prioritere afviklingen af teknisk gæld højere end funktionalitetsønsker i den efterfølgende periode med vedligeholdelse og videreudvikling af systemet.
Teknisk gæld kan og skal ikke undgås.
Men hvis du har kendskab til den tekniske gæld, kan du kontrollere den. Så kan du prioritere og afvikle den tekniske gæld på den mest hensigtsmæssige måde. Og du undgår, at den tekniske gæld bliver en permanent byrde for it-systemet.
