Verdiepende handleiding
Simulator voor snelheidsverlies door technische schuld: wat herwerk uw engineeringteam kost
Brancheanalyse voor het management
Technische schuld is de opgebouwde prijs van sluiproutes: code die werkt maar moeilijk te wijzigen is, ontbrekende tests, verstrengelde afhankelijkheden en oude systemen die niemand meer begrijpt. Ze verschijnt zelden in een begroting. In plaats daarvan verschijnt ze als het gevoel dat alles langer duurt dan vroeger. Schattingen lopen uit, kleine wijzigingen breken niet-gerelateerde onderdelen en het team besteedt sprints aan werk dat niets nieuws oplevert. De rekening hiervoor komt niet als een kostenpost maar als een kleiner aantal opgeleverde functies per maand voor dezelfde loonkosten.
De structuur van het probleem is een belasting op capaciteit. Als een vijfde van elke sprint opgaat aan noodoplossingen en herwerk, gedraagt het team zich alsof het een vijfde kleiner is, terwijl de salarissen gelijk blijven. Schuld stapelt zich ook op. Elke nieuwe functie op een wankele basis voegt complexiteit toe, dus het verloren aandeel groeit tenzij er moeite in aflossing wordt gestoken. Schuld aflossen kost nu output, en daarom is het altijd verleidelijk om uit te stellen, en daarom verdient de beslissing cijfers.
Het dominomodel volgt het verlies. Het aandeel van de sprint dat aan schuld verloren gaat, verlaagt de capaciteit voor nieuw werk, wat het aantal opgeleverde functies verlaagt. Minder functies verlagen de opgeleverde waarde per dollar loonkosten, en de last van herwerk, brandjes blussen en verloop groeit met de schuld. Het laatste vak vergelijkt de opgeleverde waarde met de werkelijke kosten van het team. Een bescheiden stijging van de schuld kan een gezond rendement in een verlies veranderen, omdat de loonkosten vast zijn terwijl de waarde dat niet is.
De ijsberg laat zien wat de regel met loonkosten verbergt. Zichtbaar zijn de loonkosten zelf. Onder de waterlijn zitten het deel van de loonkosten dat aan herwerk wordt besteed, het brandjes blussen dat schuld in productie veroorzaakt, het verloop van engineers die vermoeide codebases verlaten en de waarde van functies die nooit zijn gebouwd. Het laatste is een alternatieve kost die nooit in de boekhouding verschijnt, maar meestal de grootste is. Gebruik de simulator om het schuldniveau te vinden waarop het team zichzelf niet meer terugbetaalt, en om te testen of een aflosplan de moeite waard is.
Blauwdruk van formules en methodiek
Het model is een maandelijks beeld van een productteam. De loonkosten zijn engineers maal volledige kosten. Een deel van de sprint gaat naar schuld en een deel naar bewuste aflossing, en de rest bouwt nieuwe functies. Opgeleverde functies zijn engineers maal functies per engineer maal dat resterende deel, gewaardeerd tegen de waarde per functie. Schuld veroorzaakt ook incidenten, als aandeel van de herwerkkosten, en verhoogt het verloop, geprijsd op vier maanden volledig salaris per vervanging. In de projectie loopt de schuld elke maand op tenzij aflossing wordt gefinancierd.
- Bouwaandeel
- b = 1 − schuld − aflossing
- Het deel van de sprint dat in nieuwe functies gaat.
- Opgeleverde functies
- F = engineers × functies per engineer × b
- Nieuwe functies die in een maand worden opgeleverd.
- Herwerkkosten
- H = loonkosten × schuld
- De loonkosten die geen nieuwe waarde kochten.
- Verloopkosten
- V = engineers × (1% + 0,06% × schuldpunten) × 4 maanden × kosten
- Verwachte maandelijkse kosten van het vervangen van engineers, stijgend met de schuld.
- Nettoresultaat
- Netto = F × waarde − loonkosten − 0,15 × H − V
- Geleverde waarde min de werkelijke kosten van het team. Het breekpunt ligt waar dit nul bereikt.
Doorwerkende elasticiteit
Het schuldaandeel is de meest elastische invoer, omdat het de output verlaagt en tegelijk de incident- en verloopkosten verhoogt. Waarde per functie en functies per engineer schalen het hele rendement. De loonkosten tellen mee omdat ze de vaste basis vormen die de waarde moet overstijgen.
Drie praktijkvoorbeelden
Starter op eigen kracht
Een klein team met een schone codebase
Een team van drie houdt de schuld laag, levert snel op en waardeert elke functie hoog ten opzichte van de loonkosten. Herwerk is klein. Laad dit scenario om het vroege voordeel van een schone basis te zien en hoe weinig schuld nodig is om dat te beginnen uit te hollen.
Opschalend middensegment
Een groot team dat in aflossing investeert
Een team van vijfenveertig mensen heeft een gematigde schuld maar reserveert een tiende van elke sprint voor opruimwerk. Functies worden in een goed tempo opgeleverd en incidenten blijven laag. Laad dit scenario om te zien waarom gedisciplineerde aflossing schaalt.
Crisis door zwarte zwaan
Een snelgroeiende codebase die niemand kan wijzigen
Een team van vijfentwintig mensen heeft jarenlange sluiproutes geërfd. Meer dan de helft van elke sprint gaat naar herwerk en incidenten, het verloop is hoog en de aflostijd is nul. Laad dit scenario om te zien hoe hoge loonkosten weinig opleveren en welke hefboom de maand herstelt.
Matrix met branchebenchmarks
| Maatstaf | Gevarenzone | Branchegemiddelde | Elite (top 10%) |
|---|---|---|---|
| Aandeel van de sprint dat aan herwerk verloren gaat | Boven 40% | 15–25% | Onder 10% |
| Tijd gereserveerd voor het aflossen van schuld | Nul | 5–10% | 15–20% waar nodig |
| Opgeleverde waarde per dollar loonkosten | Onder 1,0 | 1,2–1,6 | Boven 2,0 |
| Maandelijks verloop van engineers | Boven 2,5% | 1–1,5% | Onder 1% |
| Incidentwerk als aandeel van de herwerkkosten | Boven 25% | 10–15% | Onder 8% |
Variabelen en hefbomen
Engineers in het team
Ontwikkelaars die aan het product werken, geteld als voltijdsequivalenten.
Hefboom: Voeg geen engineers toe aan een team met veel schuld, want elke nieuwe medewerker erft dezelfde rem en vertraagt de onboarding.
Volledige kosten per engineer per maand
Salaris plus belastingen, secundaire voorwaarden, apparatuur en overhead voor één engineer in een maand.
Hefboom: Houd salarissen op marktniveau maar snijd in verborgen overhead, want elk uur dat aan schuld verloren gaat, wordt tegen het volledige tarief betaald.
Sprint verloren aan schuld en herwerk
Het aandeel engineeringtijd dat opgaat aan noodoplossingen, bugfixes, trage builds en worstelen met oude code in plaats van nieuwe functies.
Hefboom: Maak schuld zichtbaar: som de slechtste modules op, schat de herwerkuren en los eerst de onderdelen op die de meeste functies raken.
Functies per engineer per maand (zonder schuld)
Hoeveel zinvolle functies één engineer in een maand zou opleveren als er geen tijd aan schuld verloren ging.
Hefboom: Verwijder frictie bij builds, tests en reviews, want de ontwikkelaarservaring bepaalt hoeveel functies iemand kan opleveren.
Maandelijkse waarde van een opgeleverde functie
Omzet, besparingen of retentie die een gemiddelde functie per maand toevoegt zodra ze is opgeleverd, volgens uw eigen schatting.
Hefboom: Lever functies op die omzet of retentie bewegen. Als de opgeleverde waarde laag is, maakt geen enkele snelheid het team winstgevend.
Sprint geïnvesteerd in het aflossen van schuld
Het aandeel van de sprint dat bewust wordt besteed aan het verminderen van schuld. Het kost nu output en vermindert later de schuld.
Hefboom: Reserveer een vast deel van elke sprint, vaak tien tot twintig procent, voor schuld die aankomend werk blokkeert.
Zo gebruikt u deze simulator
- 1Begin met de realistische voorinstelling of voer uw teamgrootte, volledige kosten en geschatte aandeel herwerk in.
- 2Lees de vijf dominovakken om te zien of de snelheid of de schuldenlast als eerste rood kleurt.
- 3Druk op Vind mijn breekpunt om te zien welk schuldaandeel het team verliesgevend maakt.
- 4Vergelijk het huidige plan met het aflosplan op de grafiek van 24 maanden.
- 5Meet het herwerk gedurende een paar sprints en neem het model elk kwartaal opnieuw door.
Fouten die u moet vermijden
- De tijd die aan schuld verloren gaat als gratis beschouwen omdat salarissen vast zijn, terwijl elk uur de volledige kosten draagt.
- Engineers toevoegen aan een trage codebase en verwachten dat de snelheid evenredig stijgt.
- Een grote herschrijving plannen in plaats van schuld gestaag af te lossen waar die aankomend werk blokkeert.
- Verloop negeren, een echte en terugkerende kostenpost van onaangename code.
Veelgestelde vragen
Hoe schat ik het aandeel van de sprint dat aan schuld verloren gaat?
Label gedurende een paar sprints tickets en pull requests die herwerk, bugfixes of noodoplossingen zijn, en deel die tijd door de totale engineeringtijd. Vraag het team ter controle om een ruw getal.
Is alle technische schuld slecht?
Nee. Een sluiproute nemen om sneller te leren of een deadline te halen kan een goede ruil zijn, als u de schuld bijhoudt en aflost. Schuld wordt een probleem wanneer ze onbeheerd blijft en zich opstapelt.
Hoeveel tijd moeten we aan aflossing besteden?
Dat hangt af van het schuldniveau en het aankomende werk. Een vaste tien tot twintig procent is gebruikelijk, maar besteed die aan schuld die geplande functies blokkeert en niet aan opruimen om het opruimen.
Hoe waardeer ik een functie?
Schat de maandelijkse omzet, retentie of kostenbesparing die ze toevoegt, desnoods ruw. Als dat niet lukt, gebruik dan de gemiddelde omzetgroei gedeeld door de opgeleverde functies als uitgangspunt.
Hoe vind ik het schuldniveau waarop het team geld verliest?
Druk op Vind mijn breekpunt. De tool verschuift elke invoer richting het ongunstige uiteinde en meldt de waarde waarbij de maandwinst nul bereikt.
Hoe nauwkeurig is dit?
Het is een educatief model met vermelde aannames en geen managementadvies. Echte engineeringresultaten hangen van veel factoren af. Vervang de invoer door uw eigen gegevens.
Dit is een educatief planningsmodel met vermelde aannames. Het is geen financieel, fiscaal of juridisch advies. Vervang de invoer door uw eigen cijfers en laat belangrijke beslissingen controleren door een gekwalificeerde professional.