Att argumentera för att åtgärda teknisk skuld utan siffror förlorar alltid mot nästa feature. Här är ett ramverk för att kvantifiera teknisk skuld i kronor och tid - så att beslutet blir affärsmässigt, inte ideologiskt.
"Vi måste ta tag i den tekniska skulden" är en av de svagaste meningarna en utvecklare kan säga till en VD. Inte för att den är fel, utan för att den saknar siffror. Här är ett ramverk som översätter teknisk skuld till språket ledningen fattar beslut på: tid och pengar.
Vad teknisk skuld faktiskt är
Teknisk skuld är inte ful kod. Det är skillnaden mellan hur snabbt ni kan förändra systemet idag och hur snabbt ni borde kunna. Precis som finansiell skuld har den en ränta: varje ny feature i ett skuldtyngt område tar längre tid, har högre risk och kräver mer testning.
Det viktiga: lite skuld är ofta rationellt. Att ta en genväg för att hinna med en lansering kan vara helt rätt - om ni betalar tillbaka medvetet. Problemet är omedveten, ackumulerande skuld som ingen mäter.
Steg 1: Hitta räntan
Börja med att mäta var förändringar går långsamt. Tre signaler:
- Lead time per område: hur lång tid från idé till produktion i olika delar av kodbasen? Vissa moduler tar 3x längre - där sitter skulden.
- Change failure rate: hur ofta går en ändring i ett område sönder? Hög felfrekvens = hög skuld.
- Bus factor: hur många kan röra ett område utan att be om hjälp? Om svaret är "en person" är det en skuld.
Steg 2: Räkna räntan i kronor
Ta ett skuldtyngt område. Uppskatta hur mycket längre varje ändring tar jämfört med ett rent område - säg 40 % längre. Multiplicera med antalet ändringar per kvartal och utvecklarkostnaden. Plötsligt har "den där modulen är jobbig" blivit "den här modulen kostar oss X kr per kvartal i förlorad utvecklingstid".
Lägg till risk-kostnaden: incidenter orsakade av området × genomsnittlig incidentkostnad. Nu har ni ett tal som en CFO kan väga mot kostnaden att åtgärda.
Steg 3: Prioritera med ROI, inte med smärta
Inte all skuld är värd att betala. Ett område med hög ränta men få framtida ändringar kan lämnas. Ett område med medelränta men där ni ska bygga mycket framöver bör prioriteras. Matrisen är enkel: ränta × förväntad förändringsfrekvens = prioritet.
Steg 4: Betala kontinuerligt, inte i ett "städsprint"
Stora omskrivningsprojekt misslyckas oftast. Bättre att avsätta en fast andel av varje sprint (säg 15-20 %) till skuldåterbetalning i de prioriterade områdena. Det håller skulden i schack utan att stoppa feature-leveransen - och det är lättare att försvara budgetmässigt.
Poängen
När teknisk skuld uttrycks i kronor och kopplas till framtida leveranstakt blir beslutet inte längre en kamp mellan "utvecklare som vill städa" och "affär som vill leverera". Det blir en investeringskalkyl - och då vinner de rätta åtgärderna på egna meriter.
“Teknisk skuld är skillnaden mellan hur snabbt ni kan förändra systemet idag och hur snabbt ni borde kunna. Precis som finansiell skuld har den en ränta.”
- Simon Axelsson
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.
Fler artiklar
