Wie verwaltest du technische Schulden auf organisatorischer Ebene?

Question

Accepted Answer

Auf organisatorischer Ebene ist technische Schuld ein **Portfolio, das verwaltet werden muss**, nicht ein Aufgabenbestand, der eliminiert werden muss. Das Ziel ist nicht null Schuld; es geht darum, die Schuld auf einem Niveau zu halten, bei dem sie Geschwindigkeit, Zuverlässigkeit oder die Fähigkeit zur Strategieumsetzung nicht gefährdet.

## Wie man darüber denkt

```text
MAKE DEBT VISIBLE AND PRIORITIZED
- Inventory the debt that actually hurts (slows delivery, causes incidents)
- Classify: strategic (deliberate) vs accidental vs decay/rot
- Quantify impact in business terms (velocity, downtime, churn risk)
- Allocate a steady % of capacity to paydown (commonly 15-25%)
```

Nicht alle Schulden sind es wert, zurückgezahlt zu werden. Schuld in einem stabilen, selten geänderten System kann ignoriert werden; Schuld in einem heißen, schnell wechselnden Bereich sollte zuerst bezahlt werden.

## Konkretes Beispiel

Ein CTO führt eine Regel ein, dass 20 % der Kapazität jedes Teams für Zuverlässigkeit und Schulden verwendet werden, und zielt dann auf die drei Systeme, die 80 % der Vorfälle verursachen, statt sie überall dünn zu verteilen.

## Trade-offs und Fallstricke

- **Fallstrick:** ein "großes Umschreiben" zur Beseitigung aller Schulden, das normalerweise zu Überläufern führt und Schulden neu schafft.
- **Fallstrick:** es niemals zurückzuzahlen, bis die Geschwindigkeit zusammenbricht.
- Schuld nur als Engineering-Problem zu verstehen, schlägt fehl; verknüpfe es mit Geschäftsergebnissen, um Zustimmung zu erhalten.

## Warum es wichtig ist

Unverwaltete technische Schuld wächst lautlos, bis Features Monate dauern und Vorfälle zunehmen.

Die Verwaltung als bewusstes Portfolio hält die Organisation über Jahre schnell und zuverlässig und wandelt eine abstrakte Engineering-Sorge in einen quantifizierten Geschäftskompromiss um, über den die Führung nachdenken kann.