Technische Schulden sind eine Karte, kein Backlog

Jedes Engineering-Team, mit dem ich gearbeitet habe, hat ein Backlog für technische Schulden. Fast keins davon zahlt jemals etwas zurück.

Das liegt nicht daran, dass Engineers faul oder das Produktmanagement feindselig wäre. Es liegt daran, dass das Artefakt selbst falsch ist. Ein Backlog aus Schuld-Items, nach irgendeiner Form von “Engineering-Schmerz” sortiert, ist aus Sicht aller, die das Budget halten, nicht umsetzbar. Es wirkt wie eine Liste teurer Gefälligkeiten, um die das Engineering-Team das Geschäft bittet, und so bleibt es liegen, wächst, während Feature-Arbeit immer wieder priorisiert wird.

Die Lösung: Hören Sie auf, technische Schulden als Backlog von Aufgaben zu behandeln, und fangen Sie an, sie als Karte von Geschäftsrisiken zu behandeln. Eine Karte zeigt, wo die Drachen sitzen, wie nah sie an der Straße sind und was passiert, wenn Sie in einen hineinlaufen. Ein Backlog zeigt nur eine Liste von Höhlen zum Erkunden, in keiner bestimmten Reihenfolge, ohne Hinweis darauf, was in welcher steckt. (Ward Cunningham, der die Schulden-Metapher in seinem OOPSLA-Erfahrungsbericht von 1992 geprägt hat, hat sie immer als Risikogespräch gerahmt, nicht als To-do-Liste. Irgendwo zwischen ihm und dem typischen Jira-Board ist dieser Rahmen flachgedrückt worden.)

In diesem Essay geht es darum, wie Sie diese Karte zeichnen, wie Sie sie nutzen, um die Arbeit zu finanzieren, und wie Sie sie ehrlich halten, während sich das System entwickelt.

#Warum die Backlog-Rahmung scheitert

Die Backlog-Rahmung scheitert aus drei strukturellen Gründen, die fast überall auftauchen:

1. Das Publikum kann es nicht lesen. Ein Backlog-Eintrag wie “Refactoring von OrderProcessor, um die statische Abhängigkeit von LegacyTaxCalculator zu entfernen” sagt dem CFO nichts darüber, ob das Unternehmen Kunden verlieren wird. Das ist Engineer-zu-Engineer-Sprache, einer Entscheidungsinstanz ohne Engineering-Hintergrund vorgelegt.
2. Die Kosten sind sichtbar, das Risiko nicht. Backlog-Einträge bekommen grobe Schätzungen (“zwei Sprints, vielleicht drei”). Sie bekommen fast nie einen Dollarwert für das Nichtstun angeheftet. Das Gespräch wird zu “zwei Sprints für X ausgeben” gegen “Feature Y ausliefern”, und Feature Y gewinnt immer, weil Feature Y einen Umsatz-Case dabei hat.
3. Die Liste schrumpft nie. Jedes Quartal fügt das Team neue Einträge schneller hinzu, als es alte entfernt. Nach achtzehn Monaten hat das Backlog 400 Einträge und niemand glaubt, dass das Team sie jemals durcharbeitet, das Team eingeschlossen. Das Artefakt verliert an Glaubwürdigkeit, dann an Aufmerksamkeit, dann an seinem Slot im Meeting.

Die Kartenrahmung behebt alle drei. Eine Karte wird von denselben Leuten gelesen, die Risikoregister und Incident Reports lesen. Eine Karte zeigt den Blast Radius neben den Kosten. Eine Karte muss nicht jedes Schlagloch in der Stadt auflisten, nur die, die den Verkehr auf den Hauptrouten blockieren.

#Was eine Schulden-Karte tatsächlich enthält

Die Karte, die ich für Kunden zeichne, hat fünf Ebenen. Keine davon braucht ausgefallenes Tooling. Für die erste Version reicht ein Whiteboard-Foto.

Ebene 1: Das Terrain. Das System auf der Ebene von Bounded Contexts oder Hauptmodulen. Nicht Klassen. Nicht Services. Die Handvoll Bereiche, die ein Nicht-Engineer auf die Frage, was das System tut, benennen würde. Für einen typischen Symfony-Monolithen schaue ich meistens auf sechs bis zwölf Regionen: Ordering, Billing, Identity, Content, Search, Admin, Integrations und so weiter.

Ebene 2: Die Pfade. Das sind die Kunden- oder Umsatzpfade, die das Terrain überqueren. “Ein neuer Nutzer registriert sich und schließt seinen ersten Kauf ab” ist ein Pfad. “Eine Rechnung wird erzeugt und verschickt” ist ein Pfad. Jeder Pfad überquert mehrere Regionen. Pfade sind wichtig, weil auf ihnen Wert durch das System fließt, und damit auch Risiko.

Ebene 3: Die Gefahrenstellen. Das sind die tatsächlichen Schuld-Items, aber auf die Karte gesetzt statt aufgelistet. Eine Gefahrenstelle hat einen Ort (welche Region, welcher Pfad), eine Schwere (kritisch, signifikant, beherrschbar, gering) und eine Beschreibung, die die geschäftliche Konsequenz nennt, nicht den technischen Zustand. “Order-Bestätigung kann unter Last den Rabattcode stillschweigend verlieren” ist eine Gefahrenstelle. “Methode zu lang” ist keine.

Ebene 4: Der Blast Radius. Für jede kritische oder signifikante Gefahrenstelle markieren Sie, welche Pfade blockiert oder beeinträchtigt werden, wenn die Gefahrenstelle auslöst. Das ist der Teil, den die meisten Teams auslassen, und der Teil, der das Geschäft am meisten interessiert. Eine Gefahrenstelle, die den Signup-to-Purchase-Pfad blockiert, gehört in eine andere Kategorie als eine, die einen internen Admin-Export kaputtmacht.

Ebene 5: Die Legende. Schwere ist nicht subjektiv. Definieren Sie die Kriterien vorab, damit sich zwei Engineers, die dieselbe Gefahrenstelle betrachten, auf ihre Farbe einigen.

Hier die Legende, die ich benutze. Passen Sie die Dollarbeträge und Ausfalltoleranzen an Ihr Geschäft an; die Struktur ist das, was zählt.

• Kritisch (rot). Eine Gefahrenstelle, die in den nächsten sechs Monaten einen kundensichtbaren Vorfall ausgelöst hat oder mit hoher Wahrscheinlichkeit auslösen wird, messbar in Umsatz, regulatorischer Exposition oder Sicherheit. Die Wiederherstellung braucht eine ungeplante Engineering-Reaktion. Beispiele: Datenkorruptionspfade, Race Conditions in Payments, fehlende Autorisierungsprüfungen auf Tenant-skopierten Ressourcen.
• Signifikant (orange). Eine Gefahrenstelle, die Feature-Arbeit in einer Region, die das Geschäft für die nächsten zwei Quartale roadmapped hat, materiell verlangsamt. Die Wiederherstellung ist geplant, aber die Kosten wachsen monatlich. Beispiele: Eine Legacy-Integration, um die jedes neue Feature einen Umweg nehmen muss, eine Test-Suite, die 40 Minuten braucht und deshalb zunehmend übersprungen wird, ein Entity-Graph, an dem sich kein Engineer sicher fühlt, Änderungen vorzunehmen.
• Beherrschbar (gelb). Eine Gefahrenstelle, die Reibung erzeugt, aber nicht blockiert. Das Team hat funktionierende Muster, damit zu leben. Sie verdient es, getrackt zu werden, aber nicht zwingend bearbeitet. Beispiele: inkonsistente Benennungskonventionen, teilweise Testabdeckung in einem stabilen Bereich, eine deprecated Bibliotheksversion, die noch funktioniert.
• Gering (grün). Eine Gefahrenstelle ohne aktuellen geschäftlichen Impact. Überwiegend ästhetisch oder nebensächlich. Dokumentiert der Vollständigkeit halber, nicht zum Handeln. Beispiele: veraltete Kommentare, Formatierungsabweichungen, ungenutzte Konfigurationsschlüssel.

Die Disziplin, die diese Legende erzwingt, ist der ganze Punkt. Wenn eine Gefahrenstelle “kritisch” ist, Sie aber keinen kundensichtbaren Fehlermodus beschreiben können, ist sie nicht kritisch, sondern signifikant. Wenn eine Gefahrenstelle “signifikant” ist, aber kein roadmapped Feature ihre Region berührt, ist sie beherrschbar. Die Legende gibt Ihnen ein Vokabular, das den Umzug vom Engineering-Raum in den Board-Raum übersteht. (Eine verwandte Unterscheidung, die Sie kennen sollten, ist Fowlers Technical Debt Quadrant, der besonnene von leichtsinnigen und bewusste von versehentlichen Schulden trennt. Nützlich, wenn Sie der Führung erklären müssen, dass nicht alle Schulden Nachlässigkeit sind.)

#Wie man die Karte tatsächlich zeichnet

Wenn ich das zum ersten Mal mit einem Team mache, dauert es eine Woche. Beim dritten quartalsweisen Refresh dauert es einen Tag.

Schritt eins: die Regionen auflisten. Holen Sie die Senior-Engineers und eine Person aus dem Produkt in einen Raum. Whiteboarden Sie die Regionen. Streiten Sie über die Grenzen. Das Streiten ist die Arbeit; das Diagramm ist das Artefakt. Sie suchen etwa zehn Kästen, die alle benennen können.

Schritt zwei: die Pfade nachzeichnen. Nehmen Sie die vier oder fünf Kundenpfade, die den meisten Umsatz treiben oder die meiste Support-Last verursachen. Zeichnen Sie sie als farbige Pfeile über die Regionen. Sie werden entdecken, dass eine oder zwei Regionen auf jedem Pfad liegen. Diese Regionen sind Ihre strukturellen Risiko-Konzentratoren.

Schritt drei: vorhandenes Wissen einsammeln. Sie brauchen kein neues Audit. Sie haben bereits eines an drei Stellen: den Postmortems der letzten zwölf Monate, den “das sollten wir irgendwann fixen”-Slack-Nachrichten, die Senior-Engineers geschrieben haben, und den Einträgen im bestehenden Backlog, die länger als zwei Quartale dort liegen. Triagieren Sie alle drei Quellen in Gefahrenstellen und platzieren Sie sie auf der Karte.

Schritt vier: Schwere einfärben. Nutzen Sie die Legende streng. Wenn Sie die geschäftliche Konsequenz nicht in einem Satz formulieren können, ist die Gefahrenstelle nicht rot. Die Disziplin, den Konsequenzsatz zu schreiben, verwandelt das Artefakt von einer Engineering-Wunschliste in ein Risikoregister.

Schritt fünf: Blast Radius nachzeichnen. Markieren Sie für jede rote und orange Gefahrenstelle die Pfade, auf denen sie liegt. Das ist die Brücke von “das Engineering ist besorgt” zu “das Geschäft sollte besorgt sein”.

Am Ende von Schritt fünf haben Sie ein einseitiges Artefakt, das Ihnen drei Dinge auf einen Blick verrät: wo die gefährlichen Orte sind, welche Kundenpfade von diesen Orten abhängen und wie jede Gefahrenstelle wahrscheinlich scheitert. Das ist eine Karte.

#Wie ein Gefahrenstellen-Eintrag tatsächlich aussehen sollte

Die Gefahrenstellen auf der Karte brauchen ein Begleitdokument. Eines pro Gefahrenstelle, nicht mehr als eine halbe Seite. Das Format, auf das ich mich nach ein paar Iterationen festgelegt habe:

### Gefahrenstelle: Order-Bestätigung verwirft unter Last stillschweigend Rabattcodes

**Ort:** Ordering-Region, auf dem Signup-to-Purchase-Pfad.

**Schwere:** Kritisch (rot).

**Geschäftliche Konsequenz:** Kunde zahlt vollen Preis, sieht vollen Preis
in der Bestätigungsmail, Support-Ticket folgt. Umsatz wird eingenommen,
aber Vertrauen geht verloren. Wir haben das bei aktuellem Traffic rund
12-mal pro Quartal gesehen; mit der Frühjahrskampagne, deren Traffic sich
voraussichtlich verdreifacht, erwarten wir rund 36 Vorfälle pro Quartal,
jeweils ~30 Minuten Support-Zeit und entweder eine Erstattung oder einen
Goodwill-Credit.

**Warum sie existiert:** Der Rabattcode wird in einer separaten Transaktion
vom Warenkorb-Finalisieren aufgelöst. Unter DB-Contention läuft die zweite
Transaktion in einen Timeout und wird stillschweigend mit einem veralteten
Warenkorb-Kontext wiederholt.

**Was das Entfernen kostet:** Ungefähr 2 Engineer-Wochen. Berührt Order,
DiscountResolver und den Stripe-Webhook-Handler. Hat Testabdeckung für
den Happy Path; wir würden als Teil des Fixes Load-Tests ergänzen.

**Was das Nicht-Entfernen kostet:** ~36 Vorfälle pro Quartal auf dem neuen
Traffic-Level, ~18 Stunden Support-Zeit, ~$1,800 in Erstattungen. Plus
Vertrauenskosten, die nicht modelliert sind.

Dieses Format leistet, was ein Backlog-Eintrag nicht kann. Eine Finanzperson kann es lesen. Eine Produktperson kann es gegen die Kampagnenzeitleiste legen. Ein Engineer kann es scopen. Und die Kosten-des-Nichtfixens stehen im Dokument, in derselben Einheit wie die Kosten-des-Fixens.

Wenn das für jede rote und orange Gefahrenstelle nach viel klingt: ja. Das ist der Punkt. Wenn Sie den Case nicht auf einer halben Seite machen können, haben Sie noch keinen Case, und die Karte ist ehrlicher, wenn die Gefahrenstelle weggelassen wird, als wenn sie auf Glaubensbasis aufgenommen wird.

#Wie die Karte finanziert wird

Die Karte ist das Finanzierungsinstrument. Sobald sie existiert, werden drei Dinge möglich, die mit einem Backlog unmöglich waren.

Kontinuierliche Risikozuweisung. Statt um “20% Kapazität für Tech Debt” zu bitten, bitten Sie um Budget gezielt für die roten Gefahrenstellen, mit den Kosten-des-Nichtfixens auf dem Blatt. Das Gespräch verschiebt sich von “Engineering will Tech-Debt-Zeit” zu “Wir schauen auf $7,200 pro Quartal Vorfallskosten auf dem Signup-Pfad; wollen wir zwei Engineer-Wochen ausgeben, um das zu beseitigen?” Das ist dasselbe Gespräch, das das Geschäft über Versicherung, Infrastruktur und Compliance führt. Es ist auf dieselbe Weise finanzierbar.

Bündelung von Schulden mit Feature-Arbeit. Wenn ein roadmapped Feature eine Region mit einer gelben Gefahrenstelle berührt, bekommt das Feature-Ticket den Cleanup der Gefahrenstelle angehängt. Der Cleanup ist keine separate Bitte, sondern eine Voraussetzung dafür, dass das Feature sicher ausgeliefert werden kann. Das ist der hebelwirksamste Weg, die Karte tatsächlich zu verkleinern, und er braucht die Karte, damit die Bündelungsentscheidung sichtbar ist.

Nein sagen zu falschen Schulden. Engineers wollen oft Dinge refaktorieren, die nicht wirklich riskant, sondern nur unelegant sind. Die Karte gibt Ihnen ein verteidigungsfähiges “Nein”. Wenn das vorgeschlagene Refactoring auf einer Region ohne Gefahrenstelle auf irgendeinem Pfad liegt, verdient es sein Budget nicht gegen die Arbeit, die es verdient. Die Karte schützt das Team vor sich selbst, zusätzlich dazu, dass sie den Case fürs Geschäft macht.

#Wie man die Karte ehrlich hält

Eine Karte, die einmal gezeichnet und nie aktualisiert wird, wird schlimmer als gar keine Karte, weil die Leute anfangen, Entscheidungen gegen ein veraltetes Bild zu treffen. Drei Rituale halten sie ehrlich.

Vierteljährlicher Refresh. Einmal pro Quartal setzen sich dieselben Engineers und die Produktperson für einen halben Tag zusammen. Gehen Sie die Legende durch. Färben Sie Gefahrenstellen um, die sich verschoben haben (kritisch zu signifikant, wenn der Blast Radius geschrumpft ist; signifikant zu kritisch, wenn der Traffic gewachsen ist). Fügen Sie neue Gefahrenstellen aus den Vorfällen des Quartals hinzu. Entfernen Sie behobene mit kurzem Feiern.

Incident-getriebene Updates. Jeder Postmortem endet mit einer einzigen Frage: Ändert dieser Vorfall die Karte? Wenn ja, aktualisieren Sie die Karte im Postmortem-Dokument, noch bevor das Meeting endet. Die meisten Vorfälle werden offenbaren, dass eine bestehende gelbe Gefahrenstelle eigentlich orange war oder dass eine Region, die Sie für sicher gehalten haben, einen bisher unsichtbaren Pfad darüberlaufen hat.

Roadmap-Review. Wenn ein neues Feature gescoped wird, ist die erste Frage: Welche Regionen berührt es, und welche Gefahrenstellen liegen dort? Wenn das Feature eine rote Gefahrenstelle berührt, ist das Feature nicht gescoped, bevor die Gefahrenstelle entweder vorher behoben oder vom Feature-Sponsor schriftlich als bekanntes Risiko akzeptiert wird. Das macht die Karte zu einem aktiven Gate, nicht zu einem passiven Dokument.

#Wie das nach sechs Monaten aussieht

Ein Team, das die Kartenrahmung übernimmt, zeigt meist dieselbe Entwicklung.

Monat eins. Die Karte ist grob. Schwere-Farben sind inkonsistent. Die ersten Gefahrenstellen-Dokumente brauchen länger zu schreiben als erwartet. Es wird viel über “ist das rot oder orange?” gestritten, was unbequem, aber produktiv ist.

Monat drei. Die Legende hat sich stabilisiert. Das Team hat seine ersten drei oder vier roten Gefahrenstellen retiret, zwei davon als Teil von Feature-Arbeit, eine als eigenständiger Fix. Die Nicht-Engineering-Stakeholder beginnen, die Karte in Roadmap-Meetings beim Namen zu nennen.

Monat sechs. Die Karte ist das Artefakt, mit dem das Team in jedem Quartalsplanungsgespräch über Engineering-Risiken spricht. Das Backlog unbehandelter Schulden-Einträge ist kleiner als zuvor, nicht weil mehr gefixt wurde (obwohl auch das), sondern weil Einträge, die sich ihren Platz auf der Karte nicht verdient haben, still geschlossen wurden. Das Team verbringt weniger Zeit damit, über das “Tech-Debt-Budget” zu streiten, und mehr Zeit damit, zu entscheiden, welche rote Gefahrenstelle als nächstes retiret wird.

Die Veränderung ist nicht, dass mehr Arbeit erledigt wird. Die Veränderung ist, dass die Arbeit, die erledigt wird, die Arbeit ist, die für das Geschäft am wichtigsten ist, und dass sich alle einig sind, was das ist.

#Typische Einwände und wie Sie damit umgehen

Ich habe diese Rahmung genug Teams vorgestellt, dass ich eine kurze Liste der wiederkehrenden Einwände habe.

“Das ist nur ein Risikoregister mit Zusatzschritten.” Ja, teilweise. Die beiden Unterschiede sind, dass es räumlich ist (Gefahrenstellen werden auf Regionen und Pfaden platziert, nicht nur aufgelistet) und dass es dem Engineering gehört, nicht einer separaten Risikofunktion. Die räumliche Dimension ist das, was Sie Konzentrationen sehen und Schulden mit Feature-Arbeit bündeln lässt. Die Engineering-Eigentümerschaft ist das, was die Einträge ehrlich hält.

“Unsere Schulden sind zu verstrickt zum Kartieren.” Dann wird die Karte hässlich, mit überlappenden Gefahrenstellen und geteilten Blast Radii, und das wird Ihnen etwas Wichtiges sagen: Ihr eigentliches Problem sind nicht die einzelnen Gefahrenstellen, sondern das Fehlen sauberer Regionen. Das explizit zu kartieren, ist der erste Schritt, es zu beheben. Eine unordentliche Karte ist mehr wert als ein sauberes Backlog.

“Was ist mit den kleinen Sachen?” Lassen Sie sie von der Karte weg. Nicht jeder Papierschnitt braucht Sichtbarkeit auf Board-Ebene. Gelbe und grüne Gefahrenstellen leben in einem separaten, leichtgewichtigeren Tracking-System, und das Team arbeitet sie ab, wenn angrenzende Feature-Arbeit sie günstig adressierbar macht. Die Karte ist für die Dinge, die ein Gespräch rechtfertigen.

“Das braucht Zeit, die wir nicht haben.” Die erste Karte zu zeichnen, dauert eine Woche. Sie zu pflegen, einen Tag pro Quartal. Das Team verbringt bereits mehr Zeit als das mit schuldenbezogenen Gesprächen, die ins Leere laufen. Die Karte lenkt diese Zeit auf ein produktives Artefakt um.

#Wann diese Rahmung nicht passt

Die Karte ist nicht immer das richtige Werkzeug. Lassen Sie sie weg, wenn:

• Das Team kleiner als vier Engineers ist und das System unter 50.000 Zeilen hat. In dieser Größenordnung halten Sie die Karte im Kopf, und die Formalität ist Overhead.
• Sie sechs Monate vor der Ablösung des Systems stehen. Eine Schulden-Karte für Code, der gleich gelöscht wird, ist die Zeit nicht wert. Schreiben Sie einfach die operativen Gefahrenstellen auf und triagieren Sie Vorfall für Vorfall.
• Die Organisation Risikoarbeit tatsächlich nicht finanziert. Wenn das Geschäft wiederholt gezeigt hat, dass es unter keiner Rahmung gegen Risiko budgetieren wird, wird die Karte daran nichts ändern. Sie haben ein Kulturproblem, kein Backlog-Problem, und das ist ein anderer Essay.

Für alle anderen ist die Karte das Artefakt, das die Arbeit finanzierbar, das Gespräch ehrlich und das System langsam sicherer macht.

Wenn Sie auf ein verstricktes Backlog schauen und ein System, an dem Änderungen sich nicht mehr sicher anfühlen, ist mein Technical-Debt-Engagement genau um diese Karte herum gebaut. Ein zweiwöchiger Kartierungs-Sprint, ein bepreistes Register roter und oranger Gefahrenstellen und ein Neunzig-Tage-Plan, die wichtigsten davon zu retiren.

#Referenzen

• The WyCash Portfolio Management System von Ward Cunningham: der OOPSLA-Erfahrungsbericht von 1992, der die Metapher der technischen Schulden einführte, von Anfang an als Risikogespräch gerahmt.
• Technical Debt von Martin Fowler: Bliki-Eintrag mit Fowlers gründlicher Neufassung des Konzepts und weiterführender Lektüre zu Cunninghams ursprünglicher Rahmung.
• Technical Debt Quadrant von Martin Fowler: die Achsen besonnen/leichtsinnig und bewusst/versehentlich, nützlich um der Führung zu erklären, dass nicht alle Schulden Nachlässigkeit sind.
• Postmortem Culture: Learning from Failure, Google SRE Book: die kanonische Referenz für schuldfreie Postmortems und Incident-Review als Lernschleife.