Technische Schulden in kleinen Firmen: Was zuerst angehen?

„Technische Schulden" klingt nach einem Problem großer Softwarefirmen. Tatsächlich haben auch kleine Firmen welche: das WordPress-Plugin, das seit drei Jahren kein Update bekommen hat, die Excel-Tabelle mit Makros, die nur eine Person versteht, der Server, auf dem eine PHP-Version läuft, für die es keine Sicherheitsupdates mehr gibt.

Der Begriff beschreibt gut, worum es geht. Eine Abkürzung spart heute Zeit und kostet später Zinsen, in Form von Fehlern, Ausfällen und Änderungen, die länger dauern als nötig. Wie bei echten Schulden ist das nicht grundsätzlich schlecht. Problematisch wird es, wenn niemand weiß, wie hoch sie sind und welche davon teuer werden.

Woran man technische Schulden erkennt

Sie müssen den Code nicht lesen können, um Hinweise zu sehen. Typische Symptome im Alltag:

• Kleine Änderungen dauern unerwartet lange, und die Begründung lautet oft „Das hängt mit vielem zusammen".
• Nach Updates geht regelmäßig etwas anderes kaputt.
• Bestimmte Aufgaben kann nur eine einzige Person erledigen.
• Niemand traut sich, ein bestimmtes System anzufassen.
• Fehler tauchen auf, verschwinden und tauchen wieder auf.
• Die Antwort auf „Wie wird das ausgerollt?" beginnt mit „Da muss man aufpassen …".

Eine Bestandsaufnahme in einer Stunde

Bevor Sie priorisieren, brauchen Sie eine Liste. Gehen Sie Ihre Systeme durch und notieren Sie alles, was Ihnen oder Ihrem Team Bauchschmerzen bereitet. Hilfreiche Fragen:

1. Welche Software läuft in einer Version, die vom Hersteller nicht mehr unterstützt wird? Die Seite endoflife.date listet Unterstützungszeiträume für viele Produkte, etwa PHP, Node.js, Python oder Datenbanken.
2. Gibt es für jedes wichtige System eine Datensicherung, die schon einmal testweise wiederhergestellt wurde?
3. Welche Abläufe hängen an einer einzelnen Person?
4. Wo stehen Zugangsdaten an Orten, an denen sie nicht stehen sollten?
5. Welche Teile der Software haben keine Tests und werden trotzdem regelmäßig geändert?
6. Welche manuellen Schritte werden regelmäßig vergessen oder falsch gemacht?

Für Code helfen automatische Prüfungen: npm audit, composer audit oder pip-audit zeigen bekannte Sicherheitslücken in Abhängigkeiten. Bei WordPress zeigt das Dashboard unter „Website-Zustand" veraltete Komponenten an.

Nach Risiko ordnen, nicht nach Ärger

Die Liste wird länger sein, als Ihnen lieb ist. Nicht alles muss behoben werden. Ordnen Sie jeden Punkt nach zwei Fragen:

• Was passiert im schlimmsten Fall? Datenverlust, Sicherheitsvorfall, Ausfall des Shops, oder nur Ärger?
• Wie wahrscheinlich ist das? Ein öffentlich erreichbares System mit bekannter Sicherheitslücke ist wahrscheinlicher betroffen als ein internes Werkzeug.

Daraus ergibt sich eine einfache Matrix:

	Folge gering	Folge schwer
Wahrscheinlich	Einplanen, wenn ohnehin an der Stelle gearbeitet wird	Sofort angehen
Unwahrscheinlich	Liegen lassen und notieren	Absichern, z. B. durch Backup oder Überwachung

Was dabei oft herauskommt: Die Dinge, die im Alltag am meisten nerven, sind nicht unbedingt die gefährlichsten. Eine umständliche Oberfläche ist lästig. Ein fehlendes Backup kann existenzbedrohend sein, fällt aber erst auf, wenn es zu spät ist.

Eine sinnvolle Reihenfolge

Für die meisten kleinen Firmen ist diese Reihenfolge ein guter Ausgangspunkt.

1. Sicherheit und Daten

• Backups einrichten und eine Wiederherstellung testen.
• Sicherheitsupdates für öffentlich erreichbare Systeme einspielen: Website, Shop, Kundenportal, Server.
• Zugangsdaten aus Code, Tabellen und E-Mails entfernen und erneuern.
• Alte Benutzerkonten ehemaliger Mitarbeiter und Dienstleister löschen.

2. Abhängigkeit von Einzelpersonen

• Die wichtigsten Abläufe so dokumentieren, dass eine zweite Person sie ausführen kann.
• Zugänge in einen Passwortmanager der Firma überführen.
• Code in ein Repository im Firmenkonto bringen.

3. Fehler, die regelmäßig wiederkommen

• Wiederkehrende Fehler an der Ursache beheben, nicht jedes Mal das Symptom.
• Für diese Stellen einen Test schreiben, damit der Fehler nicht zurückkommt.

4. Bremsen bei Änderungen

• Veraltete Frameworks schrittweise aktualisieren.
• Stellen, die häufig geändert werden, mit Tests absichern.
• Manuelle Schritte beim Ausrollen automatisieren.

Was in dieser Liste bewusst fehlt: „Alles neu schreiben". Eine Neuentwicklung kann richtig sein, wenn ein System nicht mehr sicher betrieben werden kann. Sie ist aber selbst ein großes Risiko, weil während der Entwicklung zwei Systeme gepflegt werden müssen und das neue anfangs eigene Fehler mitbringt.

Schulden in kleinen Raten abbauen

Kleine Firmen haben selten ein Budget für ein „Aufräumprojekt". Das ist auch nicht nötig. Wirksamer ist es, Schulden in kleinen, abgeschlossenen Schritten abzubauen:

• Pfadfinderregel: Wer an einer Stelle arbeitet, hinterlässt sie etwas besser, als er sie vorgefunden hat. Ein Test mehr, eine veraltete Abhängigkeit weniger.
• Feste Raten: Ein kleiner, regelmäßiger Anteil der Entwicklungszeit oder des Budgets geht in den Abbau, statt ihn aufzuschieben, bis es brennt.
• Abgegrenzte Aufgaben: „PHP von 7.4 auf eine unterstützte 8.x-Version aktualisieren, Website funktioniert danach unverändert" ist eine prüfbare Aufgabe. „Code modernisieren" ist es nicht.

Der letzte Punkt ist der wichtigste. Technische Schulden lassen sich am besten abbauen, wenn jeder Schritt ein klares Ergebnis hat, das man prüfen kann. Wie man solche Ergebnisse beschreibt, steht im Beitrag Abnahmekriterien schreiben, die man wirklich prüfen kann.

Mit Dienstleistern über Schulden sprechen

Wer externe Entwickler beauftragt, hört oft Sätze wie „Das sollte man eigentlich mal grundsätzlich angehen". Das ist häufig berechtigt, hilft Ihnen aber nur, wenn daraus eine Entscheidungsgrundlage wird. Bitten Sie um drei Angaben:

1. Was genau ist das Problem? In einem Satz, ohne Fachbegriffe.
2. Was passiert, wenn wir nichts tun? Konkret: ein Risiko, ein wiederkehrender Aufwand, eine Grenze, an die Sie stoßen werden.
3. Was wäre der kleinste sinnvolle Schritt? Nicht der vollständige Umbau, sondern das erste abgeschlossene Ergebnis.

Mit diesen Antworten können Sie den Punkt in Ihre Matrix einordnen. Ohne sie bleibt es ein Gefühl, und Gefühle lassen sich schlecht gegen andere Prioritäten abwägen.

Umgekehrt gilt: Wenn ein Dienstleister bei einer kleinen Aufgabe auf ein ernstes Problem stößt, etwa eine Sicherheitslücke oder ein fehlendes Backup, sollte er es Ihnen mitteilen, auch wenn es nicht zum Auftrag gehört. Ob und wann es behoben wird, entscheiden Sie.

Neue Schulden bewusst aufnehmen

Nicht jede Abkürzung ist ein Fehler. Wenn ein Angebot bis Freitag online sein muss, kann eine provisorische Lösung richtig sein. Entscheidend ist, dass sie als Provisorium bekannt ist. Notieren Sie solche Entscheidungen in derselben Liste, mit einem Datum, bis zu dem sie ersetzt sein sollen. Schulden, die man bewusst aufnimmt und notiert, sind beherrschbar. Gefährlich sind die, von denen niemand weiß.

Eine Vorlage für Ihre Liste

Punkt:              PHP 7.4 auf dem Webserver
Betroffen:          Website, Kontaktformular
Schlimmster Fall:   Sicherheitslücke ohne verfügbares Update
Wahrscheinlichkeit: mittel (öffentlich erreichbar)
Nächster Schritt:   Update auf unterstützte Version auf Staging testen
Ergebnis prüfbar:   Alle Seiten und das Formular funktionieren wie bisher

Eine solche Liste mit zehn bis zwanzig Einträgen, einmal im Halbjahr durchgesehen, ist für die meisten kleinen Firmen ausreichend.

Häufige Fragen

Was sind technische Schulden?

Abkürzungen in Software und IT, die heute Zeit sparen und später Zinsen kosten, in Form von Fehlern, Ausfällen und Änderungen, die länger dauern als nötig. Beispiele sind veraltete Plugins, eine PHP-Version ohne Sicherheitsupdates oder eine Excel-Tabelle mit Makros, die nur eine Person versteht. Problematisch werden sie vor allem, wenn niemand weiß, wie hoch sie sind.

Womit sollte eine kleine Firma beim Abbau technischer Schulden anfangen?

Mit Sicherheit und Daten: getestete Backups, Sicherheitsupdates für öffentlich erreichbare Systeme, Zugangsdaten an den richtigen Ort und alte Benutzerkonten löschen. Danach folgen die Abhängigkeit von Einzelpersonen, wiederkehrende Fehler und schließlich die Bremsen bei Änderungen. Ordnen Sie dabei nach Risiko, nicht danach, was im Alltag am meisten nervt.

Sollten wir das alte System nicht einfach neu schreiben?

Nur, wenn es nicht mehr sicher betrieben werden kann. Eine Neuentwicklung ist selbst ein großes Risiko, weil während der Entwicklung zwei Systeme gepflegt werden müssen und das neue anfangs eigene Fehler mitbringt. Meist ist es wirksamer, die Schulden in kleinen, prüfbaren Schritten abzubauen.

---

Eine solche Liste lässt sich fast eins zu eins als Backlog führen. Bei uns schreiben Sie jeden Punkt als Karte auf Ihr Board, etwa ein Framework-Update, einen wiederkehrenden Fehler, einen fehlenden Test, eine Abhängigkeit, die ersetzt werden muss, oder einen manuellen Ablauf, der heute an einer einzelnen Person hängt, und legen die Reihenfolge nach Ihrer Matrix fest. Sobald wir eine Karte starten, stehen Umfang und Abnahmekriterien darauf, ganz im Sinne der Zeile „Ergebnis prüfbar“ aus der Vorlage. Geliefert wird 48 Stunden nach Start, gezählt von Montag 8 Uhr bis Freitag 16 Uhr, als Pull Request, auf Staging oder als deaktivierter Workflow, nie direkt in Ihre Produktion; größere Punkte teilen wir in mehrere Karten auf. Jede Lieferung prüft und gibt ein Senior-Entwickler frei, bevor sie zu Ihnen geht. Den ersten Punkt erledigen wir als kostenlose erste Aufgabe, die weiteren im Prozess-Abo in Ihrer Reihenfolge. Typische Aufgaben mit Umfang und Abnahmekriterien finden Sie im Leistungskatalog.