Einführung
„Wir müssen technische Schulden abbauen” ist eines der am wenigsten überzeugenden Argumente, das man einem Product Manager oder einer Führungskraft gegenüber vorbringen kann. Es ist vage, klingt nach Beschweren und stellt keine Verbindung zu Geschäftsergebnissen her.
Nach Jahren, in denen ich mich schwertat, Zustimmung für technische Verbesserungen zu bekommen, habe ich ein Rahmenwerk entwickelt, das technische Schulden als Investitionsentscheidungen mit messbarem Ertrag neu formuliert.
Das Problem mit „technischen Schulden”
Der Begriff selbst ist problematisch. Er impliziert:
- Etwas Schlechtes, das nicht existieren sollte
- Eine Last, die beseitigt werden muss
- Vergangene Fehler, die behoben werden müssen
Diese Rahmung bringt Entwickler:innen in eine Verteidigungshaltung und macht Stakeholder skeptisch.
Neu formuliert: Technische Investition
Statt „Schulden abzubauen”, denken Sie in „Investitionen tätigen”. Jede technische Verbesserung sollte haben:
- Klare Kosten (Entwicklungszeit)
- Erwarteten Ertrag (schnellere Entwicklung, weniger Fehler, weniger Vorfälle)
- Eine Amortisationszeit
Technische Schulden quantifizieren
Auswirkung auf die Entwicklungsgeschwindigkeit
Verfolgen Sie, wie viel Zeit Entwickler:innen verbringen mit:
- Umgehungslösungen für Legacy-Code
- Debugging von Problemen, die durch technische Schulden verursacht werden
- Einarbeitungsreibung durch Komplexität
Wöchentliche Schuldensteuer = (Stunden für Workarounds) × (durchschnittliche Stundenkosten)Zusammenhang mit Vorfällen
Ordnen Sie Produktionsvorfälle den entsprechenden technischen Schulden-Posten zu:
- Welche Systeme verursachen die meisten Vorfälle?
- Wie hoch sind die Kosten pro Vorfall (Entwicklungszeit + geschäftliche Auswirkung)?
- Wie würde der Abbau der Schulden die Vorfälle reduzieren?
Auswirkung auf die Feature-Auslieferung
Messen Sie, wie sich technische Schulden auf die Auslieferung von Features auswirken:
- Umsetzungszeit für Features in schuldenbelasteten Bereichen im Vergleich zu sauberen Bereichen
- Anzahl der eingeführten Fehler in verschiedenen Teilen der Codebasis
- Zufriedenheitswerte der Entwickler:innen nach Bereich
Das Rahmenwerk für Investitionsvorschläge
Wenn Sie technische Verbesserungen vorschlagen, strukturieren Sie es wie einen Business Case:
1. Kosten des aktuellen Zustands
„Unser Authentifizierungssystem verursacht 3 Vorfälle pro Monat, jeder benötigt 4 Stunden zur Behebung. Das sind 12 Entwicklungsstunden monatlich, zuzüglich Auswirkungen auf Kund:innen.”
2. Vorgeschlagene Investition
„Das Refactoring des Auth-Systems wird 2 Sprints (80 Stunden) dauern.”
3. Erwarteter Ertrag
„Basierend auf ähnlichen Refactorings erwarten wir eine Reduzierung der Vorfälle um 70 %, was mehr als 8 Stunden monatlich spart und die Kundenerfahrung verbessert.”
4. Amortisationszeit
„Die Investition amortisiert sich innerhalb von 10 Monaten und erwirtschaftet danach weiterhin Erträge.”
Priorisierungsmatrix
Nicht alle technischen Schulden sind gleich. Priorisieren Sie basierend auf:
| Faktor | Gewichtung |
|---|---|
| Häufigkeit von Vorfällen | Hoch |
| Auswirkung auf Entwicklungszeit | Hoch |
| Auswirkung auf Feature-Geschwindigkeit | Mittel |
| Sicherheitsrisiko | Kritisch |
| Skalierbarkeitsrisiko | Mittel |
Kommunikationsstrategien
Mit Product Managern
Fokus auf Geschwindigkeit und Planbarkeit:
- „Dieses Refactoring wird es uns ermöglichen, Features in diesem Bereich 30 % schneller auszuliefern”
- „Wir werden unsere Fehlerquote senken, was zu weniger Unterbrechungen der geplanten Arbeit führt”
Mit Führungskräften
Fokus auf Geschäftsergebnisse:
- „Dies senkt unsere Vorfallsrate und verbessert die Kundenzufriedenheit”
- „Wir werden schneller auf Marktveränderungen reagieren können”
- „Dies adressiert ein Sicherheitsrisiko, das zu [konkrete Konsequenz] führen könnte”
Mit anderen Entwickler:innen
Seien Sie direkt bezüglich der technischen Vorteile:
- „Das macht die Codebasis leichter verständlich und veränderbar”
- „Wir werden eine bessere Testabdeckung und mehr Vertrauen bei Änderungen haben”
Ein Budget für technische Schulden aufbauen
Setzen Sie sich für eine feste Zuweisung ein:
- 20-%-Regel: 20 % der Entwicklungskapazität für technische Verbesserungen reservieren
- Schulden-Sprints: Einen Sprint pro Quartal gezieltem Schuldenabbau widmen
- Pfadfinder-Regel: Code besser hinterlassen, als man ihn vorgefunden hat (kleine, kontinuierliche Verbesserungen)
Fortschritt verfolgen
Machen Sie technische Schulden sichtbar:
- Ein Schulden-Backlog mit geschätzten Kosten und Erträgen pflegen
- Schulden-Metriken über die Zeit verfolgen
- Erfolge feiern, wenn Verbesserungen messbare Ergebnisse zeigen
Ein reales Beispiel
Wir hatten ein Legacy-Benachrichtigungssystem, das:
- 5 Vorfälle pro Monat verursachte
- 2 Stunden Workarounds pro Feature erforderte
- Keine Testabdeckung hatte
Investition: 3 Wochen Refactoring Ergebnis:
- Vorfälle sanken auf 1 pro Monat
- Die Entwicklungszeit für Features reduzierte sich um 40 %
- Amortisationszeit: 4 Monate
Fazit
Technische Schulden sind nicht grundsätzlich schlecht – oft sind sie ein vernünftiger Kompromiss. Entscheidend ist, informierte Entscheidungen darüber zu treffen, wann man Schulden eingeht und wann man sie abbaut.
Indem Sie technische Verbesserungen als Investitionen mit messbarem Ertrag darstellen, können Sie produktive Gespräche mit Stakeholdern führen und Zustimmung für die wichtige Arbeit gewinnen.
Hören Sie auf, um Erlaubnis zu bitten, „Schulden abzubauen”. Fangen Sie an, Investitionen mit klarem Ertrag vorzuschlagen.