[Inhaltsverzeichnis]Inhaltsverzeichnis anzeigen
Technische Schulden sind wie eine Hypothek: in kleinen Dosen tragbar, tödlich, wenn man die Zinsen ignoriert. Die meisten Unternehmen kennen nicht einmal ihre Monatsrate. Sie haben keine technische Bilanz, rechnen keine Zinsen, planen keine Tilgung. Vom Ausmaß erfahren sie Freitag um 17:00 Uhr, wenn das System fällt und niemand es hochbringt.
Bei Do More Soft führen wir Rescue Missions seit fünf Jahren durch — wir retten Projekte, die andere aufgegeben haben. Wir haben jedes Level an Schulden gesehen, von kosmetisch bis terminal. Unten ein Framework, das klar sagt: retten oder in 8 Wochen von null neu schreiben.
5 Level technischer Schulden
Jedes Level hat eine operative Konsequenz — keine theoretische, sondern in Sprints messbar.
- Kosmetisch — inkonsistente Benennung, fehlende Kommentare. 10-20% langsamer, aber keine Prod Fires.
- Strukturell — keine Schichtentrennung, keine Tests. Ein Feature dauert 3× länger, Regression in jedem Sprint.
- Architektonisch — Monolith ohne API, Datenbank als Integration Point. Jede Integration ist ein Quartalsprojekt.
- Infrastrukturell — null CI/CD, Deploy manuell per FTP. Freitagsdeploy = Russisches Roulette.
- Terminal — tote Technologie, null Tests, Originalteam ist weg. 80% des IT-Budgets in der Wartung, Entwicklung praktisch eingefroren.
Level 1: Kosmetisch
Suboptimale SQL-Abfragen, Duplikation, fehlende Kommentare. Das System funktioniert korrekt, ist aber unangenehm zu warten. Reparatur: Refactoring im Rahmen normaler Sprints, ohne dediziertes Budget. Jedes Projekt hat dieses Level und das ist OK.
Level 2: Strukturell
UI mit Geschäftslogik vermischt, keine Tests, hardcodierte Konfiguration. Das System läuft, aber jede Änderung erfordert Modifikationen an 5 Stellen und erzeugt Regression. Reparatur: dedizierter Refactoring-Sprint alle 4-6 Wochen.
Level 3: Architektonisch
Ein Monolith, der nicht skaliert. Datenbank als Integration Point — Systeme kommunizieren über Shared Database. Null API, null Integrationen. Neue Funktionalitäten dauern 3-5× länger. Reparatur: kritische Module in separate Services auslagern, API-Schicht. 2-4 Monate Arbeit.
Level 4: Infrastrukturell
Kein CI/CD, Deploy per FTP, Produktion auf einem Server ohne Backup, null Monitoring. Das System läuft nach dem Prinzip „bloß nicht anfassen”. Risiko eines katastrophalen Ausfalls plus totale Abhängigkeit von einer Person, die „weiß, wie es funktioniert”. Reparatur: Infrastruktur von null aufbauen bei laufendem System — Motorwechsel bei fahrendem Auto. 1-3 Monate.
Level 5: Terminal
Classic ASP, AngularJS, PHP 5. Null Tests, null Dokumentation, Originalteam ist weg. Jede Änderung erzeugt unvorhersehbare Nebeneffekte. Niemand versteht das System als Ganzes. Die Wartung verschlingt 80%+ des IT-Budgets. Binäre Entscheidung: retten oder neu schreiben.
Rescue Assessment Matrix — retten vs. neu schreiben
30+ Mal durchgegangen. Drei von fünf Dimensionen bei 3+? Rettbar. Drei bei 1-2? Neuentwicklung gewinnt. Wenn ein Kunde mit einem „zu rettenden” Projekt zu uns kommt, machen wir ein 3-5-tägiges Technologieaudit und bewerten 5 Dimensionen auf einer Skala von 1-5 (1 = wegwerfen, 5 = solide): Datenbankqualität, Testabdeckung, API-Design, Infrastruktur, Dokumentation.
Entscheidungsregel
Drei von fünf Dimensionen bei 3+ — Rescue Mission. Wir retten, was gut ist, und schreiben neu, was schlecht ist. Typische Kosten: 40-60% des Budgets einer kompletten Neuentwicklung, Dauer: 2-4 Monate. Drei Dimensionen bei 1-2 — Neuentwicklung von null. Die Rettung würde mehr kosten als ein neues System und ein schlechteres Ergebnis liefern. Die Datenbank ist der Hebelpunkt: sind die Daten gut modelliert, ist der Rest reproduzierbar.
In einem Automotive-Projekt: Datenbank solide (5/5), API legacy (1/5), Tests null (1/5). Gerettet, weil 2 von 5 zum Retten — Datenbank und Frontend. API und Tests haben wir in 14 Wochen von null geschrieben, der Kunde behielt Daten und Prozesse.
Realer TCO des Ignorierens
Unternehmen, die Schulden ignorieren, zahlen Zinsen in jeder TCO-Dimension: langsamere Time-to-Market (die Konkurrenz zieht vorbei), 90% des IT-Budgets in der Wartung statt in der Entwicklung, Abhängigkeit von Schlüsselpersonen (der Weggang eines Entwicklers lähmt das Projekt), Risiko eines katastrophalen Ausfalls.
Die teuerste Position im TCO der Schulden sind die Kosten verpasster Chancen. Ein Unternehmen, das ein Produkt in 3 Monaten launchen könnte, launcht es in 12 — weil 75% der Team-Kapazität gegen die Schulden kämpfen. In dieser Zeit besetzt die Konkurrenz den Markt. Diese Kosten sind in der Bilanz unsichtbar und in den Quartalszahlen schmerzhaft.
Rettungs-Playbook: Rescue Mission Schritt für Schritt
Woche 1: Audit und Stabilisierung. Kritische Sicherheitslücken, Monitoring, Backup, As-Is-Architektur-Dokumentation.
Woche 2-4: Prioritäts-Refactoring. Wir trennen Core Logic von UI, Tests für kritische Pfade, CI/CD-Pipeline.
Monat 2-3: Modernisierung. Neues API, Infrastruktur-Migration, toten Code eliminieren.
Monat 4+: Weiterentwicklung. Neue Funktionalitäten auf solidem Fundament.
Die 20%-Regel
Freitagssprint bei DailyHair: 2h Refactor, 1h Docs, 30 min Test Coverage. Nicht optional. Das ist das Muster, das wir bei jedem Kunden mit Engineering-Kultur durchsetzen.
Warum es funktioniert — kumulativer Effekt
20% Kapazität jedes Sprints in die Tilgung. 20% heute sparen 200% in einem Jahr, weil jede nicht beseitigte Abkürzung die nächsten architektonischen Entscheidungen blockiert. Ein Team, das regelmäßig tilgt, ist schneller und schreibt besseren Code. Der Kunde zahlt dafür zweimal: einmal in niedrigeren Wartungskosten, ein zweites Mal in höherem Feature-Tempo.
Wie durchsetzen — Spike Card, non-negotiable Backlog
Spike Card „Tech Debt 20%” im Backlog jedes Sprints, priorisiert zusammen mit Features, nicht danach. Definition of Done identisch wie für eine Business-Story. Keine Spike → der Sprint startet nicht. Für Unternehmen ohne technische Kultur: ein Freitag pro Monat ausschließlich für Cleanup („Tech Debt Fridays”). Das ist Investition in zukünftige Produktivität, kein Verlust.
Wir machen das selbst
Q2 2026, Velocity 45 SP. 9 Punkte auf den Freitag-Tech-Debt, 36 auf Features. Bei jedem neuen Projekt zeigen wir dem Kunden den Schuldenzähler des vorherigen Systems — damit endet meistens die Diskussion, ob 20% „wirklich nötig” sind.
FAQ
Was sind technische Schulden und wie misst man sie? Prozent des IT-Budgets in Wartung statt Entwicklung. Über 70% → rote Flagge.
Wann refaktorisieren, wann neu schreiben? Rescue Matrix, 5 Dimensionen × Skala 1-5. Drei bei 3+ → Rescue (40-60% der Kosten einer Neuentwicklung). Drei bei 1-2 → Neuentwicklung.
Was ist die 20%-Regel? 20% Sprint-Kapazität in die Tilgung, Spike Card im Backlog, nicht „falls Zeit übrig bleibt”.
Wie viel kosten technische Schulden ein Unternehmen? 60-90% des IT-Budgets in der Wartung. Die teuerste Position sind die Kosten verpasster Chancen.