Technische Schulden im Griff: ein praxisnaher Leitfaden

Um technische Schulden in den Griff zu bekommen, machen Sie sie sichtbar, ordnen Sie sie nach geschäftlicher Wirkung, reservieren Sie in jedem Sprint oder Budget einen festen Anteil für den Abbau und messen Sie, ob sich die Arbeit auszahlt. Sie brauchen weder eine Neuentwicklung noch einen Stopp neuer Funktionen. Sie brauchen eine kurze schriftliche Liste der Schulden, die am meisten weh tun, und die Gewohnheit, sie stetig abzubauen.

Dieser Leitfaden geht den Weg der Reihe nach durch: Was technische Schulden sind, wie Sie sie erheben, wie Sie priorisieren, wie viel Kapazität Sie reservieren und woran Sie erkennen, dass es wirkt.

Kurz zusammengefasst

• Technische Schulden sind die künftigen Kosten heutiger Abkürzungen. Sie wachsen mit Zinseszins: Je länger sie liegen bleiben, desto teurer werden sie.
• Beginnen Sie mit einem Audit: Ausgangswerte zu Ihren Lieferkennzahlen, ein Blick auf Architektur, Code und Infrastruktur, Gespräche mit Ihren Entwickler:innen und ein gemeinsames Verzeichnis.
• Bewerten Sie jeden Posten nach geschäftlicher Wirkung und nach den Kosten des Aufschiebens, nicht danach, wie hässlich der Code aussieht.
• Reservieren Sie dauerhaft einen Teil Ihrer Kapazität. Veröffentlichte Zahlen reichen von rund 15 % bis 30 % der IT-Budgets. Wählen Sie also einen Wert, den Sie halten können, und bleiben Sie dabei.
• Verfolgen Sie wenige Kennzahlen, etwa Lieferfrequenz, Wiederherstellungszeit und die Quote technischer Schulden, und schauen Sie jedes Quartal darauf.

Was technische Schulden sind und warum sie echtes Geld kosten

Gartner definiert technische Schulden als the deviation of a system from its nonfunctional requirements. Teams erzeugen sie durch kurzfristige Kompromisse, Abkürzungen und Behelfslösungen, um einen Termin zu halten. Die wissenschaftliche Arbeitsdefinition aus einem Dagstuhl seminar sagt dasselbe formeller: Entwurfs- oder Umsetzungsentscheide, die heute bequem sind, künftige Änderungen aber teurer oder unmöglich machen.

Der Vergleich mit Finanzschulden trägt. IBM describes technische Schulden so, dass sie über die Zeit Zinsen ansammeln: Je länger sie unbearbeitet bleiben, desto teurer wird ihre Beseitigung. In der Praxis zeigen sich diese Zinsen als langsamere Releases, wiederkehrende Fehler und Entwickler:innen, die ihre Woche damit verbringen, das System zu umgehen, statt es zu verbessern.

Verbreitet ist das Problem ebenfalls. Eine Gartner-Umfrage von Dezember 2022 bis März 2023 ergab, dass 93% of respondents currently experienced technical debt, am häufigsten in der Architektur (67 %), in der Infrastruktur (58 %) und im Code (53 %). Gartner erwartet zudem, dass bis 2027 80% of technical debt will be architectural sein werden, gegenüber 30 % im Jahr 2024. Das ist für das Vorgehen wichtig: Die teuren Schulden stecken immer öfter darin, wie Systeme zusammenspielen, und nicht in einzelnen Codezeilen.

Die geschäftlichen Folgen sind messbar. Eine Morning-Consult-Umfrage von 2024 unter 500 US-amerikanischen Führungskräften aus Wirtschaft und Technologie ergab, dass 80% had delayed or canceled business-critical projects in den vorangegangenen zwölf Monaten wegen technischer Schulden; 79 % meldeten höhere Softwarekosten. Auftraggeber der Umfrage ist ein Softwareanbieter, und die Stichprobe ist amerikanisch. Lesen Sie die Zahlen deshalb als Hinweis, nicht als Schweizer Referenzwert.

Nicht jede Schuld ist ein Fehler

Bevor Sie Schulden abbauen, trennen Sie die bewusst eingegangenen von jenen, in die Sie hineingerutscht sind. Martin Fowlers Quadranten, summarized by Asana, sortieren sie entlang zweier Achsen: absichtlich oder unabsichtlich, umsichtig oder leichtsinnig.

Quadrant	Wie es aussieht	Was zu tun ist
Umsichtig und absichtlich	Sie liefern schnell und planen, die Folgen später anzugehen	Eintragen, mit einem Auslöser für die Rückzahlung
Leichtsinnig und absichtlich	Sie kennen den besseren Weg, lassen ihn aus Tempogründen aus	Muster stoppen, die riskantesten Punkte zuerst beheben
Umsichtig und unabsichtlich	Sie finden nach dem Bauen einen besseren Entwurf	Refactoring einplanen, wenn Sie den Bereich das nächste Mal anfassen
Leichtsinnig und unabsichtlich	Dem Team fehlte das Wissen, es gut zu machen	Reviews, Pairing oder erfahrene Begleitung ergänzen, dann beheben

Schulden bewusst einzugehen, kann richtig sein. Der Dagstuhl-Bericht hält fest, dass dies Dagstuhl seminar sein kann, in dem die Zeit bis zum Markteintritt entscheidend ist. Ein Start-up, das in acht Wochen ein MVP lanciert, trifft einen Handel, keinen Fehler. Der Fehler besteht darin, diesen Handel einzugehen und ihn nie festzuhalten.

Die Autoren von InfoQ ergänzen einen nützlichen Punkt: Fast jeder Architekturentscheid trades one quality against another, etwa Sicherheit gegen Bedienbarkeit oder Skalierbarkeit gegen Zeit bis zum Markteintritt. Ein Teil der Schulden ist also schlicht der Preis jeder Entscheidung, und das Ziel ist zu wissen, wo sie liegen.

Schritt 1: Technische Schulden erheben

Eine Erhebung, oder ein Audit der technischen Schulden, verschafft Ihnen ein gemeinsames Bild davon, was Sie schulden. Ein praxistaugliches Vorgehen, angelehnt an GainHQ’s audit guide, sieht so aus.

Ausgangswerte zu den Lieferkennzahlen sammeln

Ziehen Sie Daten aus den Werkzeugen, die Sie ohnehin nutzen, etwa GitHub, GitLab, Azure DevOps oder Jira. Schauen Sie sich die Deployment-Frequenz der letzten 6 bis 12 Monate an, die mittlere Wiederherstellungszeit nach Störungen und die Fehlerquote bei Änderungen. Diese Zahlen zeigen, ob Schulden Sie bremsen, und sie werden zu Ihrem Bild der Ausgangslage.

Architektur, Code und Infrastruktur prüfen

Gehen Sie die aktuellen Architekturdiagramme durch und vergleichen Sie sie mit dem, was tatsächlich läuft. Nutzen Sie statische Analyse, um Brennpunkte zu finden: Dateien mit hoher Komplexität oder geringer Testabdeckung. GainHQ schlägt vor, Werte der zyklomatischen Komplexität über 10 als Zeichen für ein hohes Wartungsrisiko zu werten. Nehmen Sie das als Faustregel, nicht als Urteil, und achten Sie auf Brennpunkte, die zudem häufig geändert werden.

Gehört eine öffentliche Website zu Ihren Schulden, kann ein automated technical website audit Probleme auf Seitenebene neben dem Code-Review aufdecken, damit alle Befunde in einer Liste landen.

Mit den Menschen sprechen, die damit leben

Daten übersehen vieles. Fragen Sie Entwickler:innen und Beteiligte, welche Teile des Systems sie ungern anfassen, welche Releases weh tun und welche Behelfslösungen alle kennen. Eine Supportleitung nennt oft eine fragile Schnittstelle, die kein Dashboard zeigt.

Ein einziges Verzeichnis aufbauen

Halten Sie jeden Befund in einem einzigen Verzeichnis der technischen Schulden fest, mit einheitlichen Feldern: Kategorie, Ort im Code, Symptome, geschätzter Aufwand und geschäftliche Wirkung. Für ein kleines Team genügt eine Tabelle. Grössere Organisationen verfolgen teils Status über den gesamten Lebenszyklus; das IF4IT inventory model listet Zustände von Suspected und Validated über Deferred und Approved for Remediation bis Closed. Für ein kleines Team reichen vier: vermutet, bestätigt, geplant, erledigt.

Schritt 2: Priorisieren, was zuerst behoben wird

Die Forschung zur Priorisierung beginnt mit einer einfachen Frage. Eine systematic literature review hält fest, dass Praktiker:innen zuerst entscheiden sollten, ob sie Refactoring-Aufgaben untereinander vergleichen oder ein Refactoring gegen neue Funktionen und Fehlerbehebungen abwägen, denn beides verlangt eine andere Art, die Wirkung zu beurteilen.

Für die meisten Teams ist die zweite Frage die entscheidende: diese Schuld gegen jene Funktion. Ein brauchbares Bewertungsschema nutzt vier Fragen pro Posten:

1. Geschäftliche Wirkung. Blockiert der Posten Umsatz, verzögert er ein Vorhaben auf der Roadmap oder erhöht er das Risiko eines Ausfalls oder eines Datenproblems?
2. Berührungshäufigkeit. Wie oft fassen Entwickler:innen diesen Bereich an? Schulden in Code, den niemand ändert, kosten wenig.
3. Kosten des Aufschiebens. Wird es schlimmer, je mehr Sie darauf aufbauen? Bei Architekturschulden ist das meist so.
4. Aufwand. Lässt sich das in Tagen beheben, oder braucht es ein Projekt über mehrere Monate?

Bewerten Sie jede Frage von 1 bis 3, multiplizieren Sie Wirkung, Berührungshäufigkeit und Aufschubkosten und teilen Sie durch den Aufwand. Es geht nicht um mathematische Genauigkeit. Es geht darum, ein Gespräch zu erzwingen, in dem Technik und Geschäft dieselbe Sprache sprechen.

Gartner warnt, dass der Abbau von Schulden voraussetzt, dass die Beteiligten the deviation of a system from its nonfunctional requirements. Genannt werden drei Hindernisse: kurzfristiges Sparen, das Jagen nach dem Neuesten und Blockaden zwischen den Beteiligten. Ohne Fokus auf die Hauptprobleme, so Gartner, fällt das Unternehmen in seinen Ausgangszustand zurück. Wählen Sie also wenige wirkungsvolle Punkte und bringen Sie sie zu Ende, statt den Aufwand dünn zu verteilen.

Ein durchgerechnetes Beispiel

Stellen Sie sich ein Zürcher E-Commerce-Team mit vier Posten im Verzeichnis vor:

Posten	Wirkung	Berührung	Aufschub	Aufwand	Priorität
Selbstgebauter Bestellexport ins ERP fällt monatlich aus	3	2	3	2	9
Veraltetes Checkout-Framework	3	3	3	3	9
Uneinheitliche Benennungen in den Admin-Masken	1	3	1	1	3
Ungenutztes Alt-Modul für Reports	1	1	1	1	1

Export und Checkout-Framework liegen gleichauf, deshalb nimmt sich das Team zuerst den Export vor: Er ist der kleinere Brocken und lässt sich in einem Sprint erledigen. Das Benennungschaos wartet, bis jemand diese Masken das nächste Mal anfasst. Das ungenutzte Modul wird bei Gelegenheit gelöscht. Niemand streitet über Geschmack, weil die Reihenfolge auf Wirkung und Aufwand beruht.

Schritt 3: Kapazität reservieren und fest einplanen

Arbeit an Schulden, die in jeder Planungssitzung gegen Funktionen antreten muss, verliert. Die Lösung ist ein fester Anteil.

Die veröffentlichten Zahlen gehen weit auseinander, was zeigt: Die eine richtige Zahl gibt es nicht.

• Accenture schreibt, Unternehmen müssten rund allocate about 15% of IT budgets für den Abbau technischer Schulden vorsehen, und Unternehmen mit unterdurchschnittlichen Schulden erwarteten stärkeres Wachstum (5,3 % gegenüber 4,4 % für 2024 bis 2026).
• Protiviti berichtet, dass Organisationen im Schnitt spend on average 30% of IT budgets und 20 % ihrer Ressourcen für das Management technischer Schulden aufwenden.
• Eine vFunction-Studie von 2024 unter mehr als 1'000 US-Führungskräften ergab, dass 51% of companies dedicate more than a quarter ihres jährlichen IT- und Engineering-Budgets für die Behebung einsetzen.

Für ein kleines Team ist ein Tag von fünf ein praktischer Startwert; das entspricht der verbreiteten Faustregel von etwa 15 bis 20 %. Planen Sie ihn als benannte Arbeit mit einer verantwortlichen Person in den Sprint ein, genau wie eine Funktion. Steht ein Release auf der Kippe, kürzen Sie lieber den Umfang der Funktion, statt den Anteil für Schulden anzuzapfen. Sonst verschwindet er still und leise.

Zwei Gewohnheiten verhindern, dass Schulden nachwachsen:

• Besser hinterlassen. Wenn jemand für eine Funktion einen riskanten Bereich anfasst, ergänzt er im selben Zug Tests oder vereinfacht ihn.
• Definition von «fertig». Eine Funktion ist erst fertig, wenn ihre Abkürzungen im Verzeichnis stehen, inklusive Auslöser für die Rückzahlung, zum Beispiel «erneut anschauen, sobald wir 1'000 Bestellungen pro Tag überschreiten».

Schritt 4: In kleinen Schritten abbauen

Komplette Neuentwicklungen auf einen Schlag sind der teuerste Weg, technische Schulden zu senken, weil Sie altes und neues System gleichzeitig bezahlen und das Geschäft wartet. Schrittweiser Abbau funktioniert besser:

• Refactoring hinter Tests. Zuerst Tests um ein fragiles Modul legen, dann sein Innenleben ändern.
• Das Altsystem umschliessen. Eine Funktion nach der anderen auf eine neue Komponente umleiten und den alten Code stilllegen, sobald ihn nichts mehr aufruft.
• Erst kapseln, dann ersetzen. Eine saubere API vor ein unübersichtliches System stellen, damit neue Arbeit nicht mehr von dessen Innerem abhängt, und das Innere später ersetzen.
• Löschen. Ungenutzte Funktionen, toter Code und verwaiste Abhängigkeiten sind die günstigsten Schulden überhaupt.
• KI-generierten Code prüfen. Code aus Assistenzsystemen braucht dieselben Reviews und Tests wie alles andere, sonst entstehen neue Schulden schneller, als Sie die alten abtragen.

Steckt die Schuld in der Plattform selbst, ist eine schrittweise Migration oder ein Replatforming manchmal die ehrliche Antwort. Planen Sie das als Reihe von Releases mit einem funktionierenden System nach jedem Schritt, nicht als einmalige Umstellung.

Schritt 5: Messen, ob es wirkt

Wählen Sie wenige Kennzahlen und schauen Sie jedes Quartal darauf.

• Lieferkennzahlen. Deployment-Frequenz, Wiederherstellungszeit und Fehlerquote bei Änderungen, die Sie im Audit erhoben haben. Verbessern sich die Trends, ist das das klarste Zeichen, dass sich die Arbeit lohnt.
• Quote technischer Schulden. SonarSource describes sie als geschätzte Kosten zur Behebung bestehender Probleme im Verhältnis zu den Kosten, den Code ursprünglich zu bauen. Eine steigende Quote zeigt, dass Schulden schneller wachsen, als Sie sie abbauen.
• Zustand des Verzeichnisses. Erledigte gegenüber neu erfassten Posten pro Quartal. Wächst das Verzeichnis nur, ist Ihr Anteil zu klein oder Ihre Gewohnheiten ändern sich nicht.
• Stimmung im Team. Eine kurze Quartalsfrage an die Entwickler:innen: Wie schwierig ist es, eine Änderung sicher auszuliefern? Sie bewegt sich oft früher als die Zahlen.

Berichten Sie darüber in geschäftlichen Begriffen, etwa «wir liefern jetzt wöchentlich statt monatlich», denn das sichert die Finanzierung des reservierten Anteils.

Wann externe Hilfe sinnvoll ist

Ein Blick von aussen lohnt sich, wenn Ihr Team zu nah am System ist, um dessen Probleme zu ordnen, wenn eine Schlüsselperson aus dem Engineering gegangen ist oder vor einer Investition, einer Übernahme oder einem grossen Replatforming, wenn Sie ein unabhängiges Bild brauchen.

Bei Ampersand führen erfahrene Engineers jedes Mandat von der ersten Besprechung bis zur Übergabe. Wer Ihr System prüft, erklärt Ihnen also auch die Ergebnisse. Unser Angebot umfasst Audits, technische Due Diligence, Replatforming und Migration von Altsystemen sowie CTO-Mandate auf Teilzeitbasis. Wenn Sie laufende Begleitung wünschen: Unser Guidance-Paket kostet 799 CHF pro Monat, unser Paket «Run & monitor» für fortlaufenden Support 750 CHF pro Monat. Projekte und weitere Pakete finden Sie in der vollständigen Übersicht unserer Leistungen und Pakete, oder starten Sie auf unserer Startseite.

Häufige Fragen

Wie viel Zeit sollten wir für technische Schulden aufwenden?

Eine allgemeingültige Zahl gibt es nicht. Veröffentlichte Werte reichen von rund 15 % der IT-Budgets bei Accenture bis zu durchschnittlich 30 % bei Protiviti. Ein kleines Team kann mit einem Tag von fünf starten und nach einem Quartal nachjustieren, je nachdem, wie sich Ihre Lieferkennzahlen entwickeln.

Sollen wir die Arbeit an Funktionen stoppen, um technische Schulden zu beheben?

Meistens nicht. Ein Stopp kostet das Geschäft Schwung und trifft selten die richtigen Punkte. Reservieren Sie einen stabilen Anteil Ihrer Kapazität, beheben Sie die wirkungsvollsten Punkte zuerst und verbinden Sie kleine Reparaturen mit Arbeiten an Funktionen im selben Bereich.

Was ist der Unterschied zwischen einer Erhebung technischer Schulden und einem Audit?

In der Praxis überschneiden sich die Begriffe. Beide sammeln Kennzahlen, prüfen Architektur, Code und Infrastruktur, befragen das Team und enden mit einem Verzeichnis der Befunde. Ein Audit ist eher eine einmalige, formellere Übung, während eine Erhebung eine leichtere, wiederkehrende Prüfung sein kann.

Wie erklären wir technische Schulden Beteiligten ohne technischen Hintergrund?

Nutzen Sie den Vergleich mit Finanzschulden: Abkürzungen haben jetzt Zeit gespart, kosten aber Zinsen in Form langsamerer Releases und höherer Kosten. Zeigen Sie dann zwei oder drei Posten aus dem Verzeichnis mit ihrer geschäftlichen Wirkung, etwa einen monatlichen Ausfall, der Ihr Betriebsteam Stunden kostet.

Sind alle technischen Schulden schlecht?

Nein. Eine bewusst gewählte Abkürzung, um rechtzeitig an den Markt zu kommen, kann ein vernünftiger Entscheid sein, solange sie festgehalten ist und Sie einen Plan haben, sie wieder aufzugreifen. Schaden richten die Schulden an, von denen niemand weiss.

Quellen

• the deviation of a system from its nonfunctional requirements
• 80% of technical debt will be architectural
• 93% of respondents currently experienced technical debt
• Dagstuhl seminar
• IBM describes
• 80% had delayed or canceled business-critical projects
• summarized by Asana
• trades one quality against another
• GainHQ’s audit guide
• IF4IT inventory model
• systematic literature review
• allocate about 15% of IT budgets
• spend on average 30% of IT budgets
• 51% of companies dedicate more than a quarter
• SonarSource describes
• automated technical website audit