Die Situation
Es gibt eine Liste, die jedes Team kennt. Manchmal steht sie in einem Projektmanagement-Tool. Manchmal in einem Google Doc. Manchmal nur in den Köpfen der Beteiligten. Auf dieser Liste stehen Dinge wie: „Das Kontaktformular auf der englischen Seite schickt keine Bestätigungsmail.“ Oder: „Die mobile Ansicht der Produktseiten hat seit dem letzten Update einen Darstellungsfehler.“ Oder: „Das Plugin für die Versandkostenberechnung wird seit zwei Jahren nicht mehr weiterentwickelt.“
Jeder Punkt auf dieser Liste hatte einmal einen Moment, in dem jemand gesagt hat: „Wir beheben das später.“ Das war in dem Moment eine verständliche Entscheidung. Es gab Dringenderes. Das Budget war für andere Dinge eingeplant. Der Fehler war ärgerlich, aber nicht kritisch. Später war die vernünftige Antwort.
Das Problem mit „später“ ist nicht, dass es nie kommt. Manchmal kommt es. Das Problem ist, dass die Liste nie kürzer wird. Für jeden Punkt, der irgendwann abgearbeitet wird, kommen zwei neue hinzu. Nach einem Jahr hat die Liste 15 Einträge. Nach drei Jahren 40. Und irgendwann ist die Liste keine Aufgabensammlung mehr. Sie ist eine Beschreibung des Systemzustands. Sie beschreibt nicht, was noch zu tun ist, sie beschreibt, was das System geworden ist.
Wir sehen diese Listen regelmäßig. Nicht bei Unternehmen, die ihre Website vernachlässigen, sondern bei Unternehmen, die aktiv an ihrer Website arbeiten, die regelmäßig Content veröffentlichen, die Kampagnen fahren und Umsatz über den Shop generieren. Die Liste existiert nicht wegen mangelndem Engagement. Sie existiert, weil „später“ die Standardantwort auf alles ist, was nicht unmittelbar brennt.
Der Mechanismus
Technische Schulden funktionieren wie Zinseszins, nur in die falsche Richtung.
Wenn ein Entwickler eine Abkürzung nimmt, um eine Funktion schneller zu liefern, entsteht eine Abhängigkeit. Vielleicht wird eine Lösung gewählt, die funktioniert, aber nicht der vorgesehene Weg ist. Vielleicht wird ein Plugin zweckentfremdet, weil die individuelle Entwicklung zu lange gedauert hätte. Vielleicht wird eine Datenbankabfrage geschrieben, die bei 500 Produkten funktioniert, aber bei 5.000 spürbar langsam wird.
Jede dieser Entscheidungen ist für sich genommen handhabbar. Das Problem beginnt, wenn die nächste Entwicklung auf dieser Abkürzung aufbaut. Der nächste Entwickler sieht die bestehende Lösung, versteht sie als gewollt und baut darauf auf. Eine weitere Abkürzung kommt hinzu. Und eine weitere. Nach zwei Jahren bestehen Teile des Systems aus Schichten von Kompromissen, die aufeinander aufbauen, ohne dass jemand die unterste Schicht noch versteht.
Kontext verblasst mit der Zeit. Der Entwickler, der die ursprüngliche Entscheidung getroffen hat, weiß vielleicht noch, warum. Sechs Monate später, nach zwei anderen Projekten, erinnert er sich vage. Nach einem Jahr hat er das Unternehmen gewechselt. Und der neue Entwickler steht vor Code, der funktioniert, aber dessen Logik sich nicht erschließt. Ihn zu verändern, fühlt sich riskant an, weil die Zusammenhänge unklar sind. Also wird er in Ruhe gelassen. Und die nächste Schicht wird obendrauf gebaut.
„Später“ wird dadurch exponentiell teurer. Was heute eine Stunde Arbeit wäre, ein Plugin sauber ersetzen, eine Datenbankabfrage optimieren, eine veraltete Funktion aktualisieren, kostet in sechs Monaten drei Stunden, weil andere Dinge darauf aufgebaut haben. In einem Jahr sind es acht Stunden, weil der Kontext weg ist und alles erst verstanden werden muss, bevor es verändert werden kann. Und in drei Jahren steht möglicherweise die Frage im Raum, ob ein vollständiger Umbau wirtschaftlicher wäre als die Reparatur.
Die Konsequenzen
Die Kosten technischer Schulden verteilen sich auf drei Bereiche, die selten gemeinsam betrachtet werden.
Der erste Bereich sind Notfall-Reparaturen. Systeme, die auf Kompromissen aufgebaut sind, brechen nicht gleichmäßig. Sie brechen an der schwächsten Stelle, zum ungünstigsten Zeitpunkt. Das Plugin, das seit zwei Jahren auf der „Später“-Liste steht, funktioniert nicht mehr nach einem WordPress-Core-Update. Aber es ist nicht nur das Plugin, es ist das Plugin plus die Custom-Funktion, die darauf zugreift, plus die Schnittstelle, die von dieser Custom-Funktion abhängt. Was als Plugin-Problem beginnt, wird zu einem Vormittag ohne funktionierenden Bestellprozess.
Notfall-Reparaturen kosten nicht nur die direkten Arbeitsstunden. Sie kosten Konzentration. Das Team, das den Fehler behebt, arbeitet nicht an dem, woran es eigentlich arbeiten sollte. Der Geschäftsführer, der den Ausfall erklärt, führt nicht das Gespräch, das er führen wollte. Die Energie, die in die Schadensbegrenzung fließt, fehlt an anderer Stelle.
Der zweite Bereich sind verpasste Gelegenheiten. Ein konkretes Beispiel: Ein Unternehmen plant eine Marketing-Kampagne mit einem befristeten Rabattcode und einer speziellen Landingpage. Der Entwickler stellt fest, dass die Rabattfunktion in WooCommerce nicht so arbeitet wie erwartet, weil ein anderes Plugin die Preisberechnung überschreibt, ein Plugin, das vor zwei Jahren als Workaround installiert wurde und nie ersetzt wurde. Die Kampagne kann nicht wie geplant starten. Entweder wird sie verschoben, oder sie startet ohne den Rabattcode. In beiden Fällen kostet „wir beheben das später“ nicht in der Zukunft, sondern jetzt.
Diese Situationen summieren sich. Features, die nicht umgesetzt werden. Integrationen, die warten. Verbesserungen, die möglich wären, aber im aktuellen Systemzustand zu riskant erscheinen. Es entsteht eine unsichtbare Grenze dessen, was das Unternehmen digital tun kann, nicht definiert durch den Markt oder die Strategie, sondern durch den technischen Zustand des eigenen Systems.
Der dritte Bereich ist die Frustration im Team. Entwickler, die ständig um Probleme herum arbeiten, statt sie zu lösen, verlieren die Verbindung zu ihrer eigentlichen Kompetenz. Statt saubere Lösungen zu bauen, schreiben sie Workarounds für Workarounds. Das ist nicht die Arbeit, für die sie sich entschieden haben. Und es ist nicht die Arbeit, bei der sie bleiben.
Das Muster, das entsteht, sieht von außen betrachtet so aus: Marketing-Kampagnen werden verzögert. Features werden auf das nächste Quartal verschoben. Strategische Entscheidungen werden nicht vom Markt oder von der Geschäftsführung bestimmt, sondern von der technischen Realität. Das System gibt vor, was möglich ist, nicht umgekehrt.
Was es verändert
Der Impuls, den die meisten Teams haben, wenn sie das Problem erkennen, ist: „Wir müssen alles aufräumen.“ Ein großer Rewrite. Ein kompletter Umbau. Alles auf einmal richtig machen. Dieser Impuls ist nachvollziehbar, aber er ist in den meisten Fällen nicht der richtige Ansatz. Große Rewrites sind teuer, sie dauern lange, und sie enden oft in einer neuen Version des Systems, die andere Kompromisse enthält als die alte, aber nicht weniger.
Was den Unterschied macht, ist nicht Perfektion. Es ist Bewusstsein. Teams, die aufhören, technische Schulden unsichtbar anzuhäufen, und anfangen, sie bewusst zu managen, verändern die Dynamik grundlegend.
Der erste Schritt ist, Kompromisse zu dokumentieren, wenn sie entstehen. Nicht in einer umfassenden technischen Dokumentation, sondern in einer einfachen Notiz: „Wir haben Plugin X als Workaround für Y installiert. Eigentliche Lösung wäre Z. Geschätzter Aufwand für die eigentliche Lösung: 4 Stunden.“ Wenn diese Notiz existiert, ist der Kompromiss sichtbar. Er kann geplant werden. Er wird nicht vergessen.
Der zweite Schritt ist kontinuierliche, kleine Wartung statt großer Notfall-Umbauaktionen. Jedes Update-Fenster, jeder Sprint, jeder Wartungszyklus enthält ein kleines Budget an Zeit für die Reduktion technischer Schulden. Nicht die gesamte Liste auf einmal, sondern der Eintrag, der am meisten Reibung erzeugt. Über Monate wird die Liste kürzer, nicht weil ein großes Projekt sie abarbeitet, sondern weil das Abarbeiten Teil der normalen Arbeit geworden ist.
Der dritte Schritt ist eine einfache Regel, die erstaunlich wirksam ist: Wenn eine Korrektur weniger als 15 Minuten dauert, wird sie sofort gemacht. Nicht auf die Liste geschrieben. Nicht für „später“ eingeplant. Sofort. Diese Regel verhindert, dass die einfachsten Probleme überhaupt auf die Liste landen. Und sie verändert die Haltung gegenüber kleinen Mängeln, von Aufschub zu Erledigung.
Wie es weitergeht
Wenn Ihre „Später“-Liste lang geworden ist, oder wenn Sie vermuten, dass es Dinge auf dieser Liste gibt, die Sie noch gar nicht kennen, dann ist eine strukturierte Bestandsaufnahme ein sinnvoller Startpunkt.
In unserer 90-minütigen Bestandsaufnahme gehen wir gemeinsam mit Ihnen durch Ihr System. Nicht um alles aufzulisten, was nicht perfekt ist, sondern um die Einträge zu identifizieren, die das größte Risiko oder die größte Bremswirkung haben. Sie bekommen ein klares Bild davon, was sofort Aufmerksamkeit verdient, was eingeplant werden kann und was tatsächlich warten darf.
Bestandsaufnahme vereinbaren →
Falls Sie lieber erst eine Frage klären möchten, schreiben Sie uns über unser Kontaktformular. Wir melden uns innerhalb von zwei Werktagen.