Was ist technische Schulden (und haben Sie zu viele davon?)
Früh in meiner Karriere als frischgebackener Associate Product Manager, als ich das erste Mal von technischer Schuld (auch Tech Debt genannt) hörte, war ich mir nicht ganz sicher, was das bedeutete. Lustigerweise dachte ich, es handele sich um einen Kredit, den wir aufgenommen hatten, um Software von Drittanbietern zu kaufen, und ich verwendete diesen Begriff für zwei oder drei Wochen fälschlicherweise mit großem Selbstbewusstsein. Stellen Sie sich mein Entsetzen vor, als meine Entwickler mich nach dem Standup beiseite nahmen, um mich sanft zu korrigieren!
Um uns allen also ein peinliches Erlebnis auf der Arbeit zu ersparen und um bei unseren Entwicklern an Ansehen zu gewinnen, werfen wir einen Blick darauf, was technische Schuld ist und warum wir als Product Manager darauf achten sollten.
Was ist technische Schuld und wann wird sie zum Problem?
Softwareentwicklung dreht sich immer darum, den Funktionsumfang des Produkts gegen eine hohe Code-Qualität auszubalancieren. Auf dem Weg dorthin nehmen wir manchmal Abkürzungen, um den Entwicklungsprozess zu beschleunigen—diese Abkürzungen nennt man technische Schuld oder Tech Debt.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Wann ist es sinnvoll, technische Schuld in Kauf zu nehmen und wann wird sie zur tickenden Zeitbombe? Um diese Frage zu beantworten, werfen wir einen Blick in die Geschichte der technischen Schuld.
Was ist technische Schuld?
Ward Cunningham, der den Begriff geprägt hat, vergleicht technische Schuld mit finanzieller Verschuldung—es ist in Ordnung, gegen zukünftige Entwicklungsgeschwindigkeit und Stabilität zu "leihen", aber letztlich müssen wir diese Schuld wieder tilgen. Es ist ein Konzept, das jedes Entwicklungsteam verstehen sollte und das jeder Product Manager bei Produktentscheidungen berücksichtigen sollte.
Tech Debt hilft uns, Produkte vorzeitig zu veröffentlichen und schneller in die Hände der Kunden zu bringen. Aber wir müssen die "Schuld" irgendwann tilgen, indem wir in die Qualität unseres Codes investieren.
Idealerweise sollten wir aktiv entscheiden, ob wir technische Schuld nutzen oder vermeiden wollen. Ähnlich wie bei finanziellen Schulden wollen wir später nicht von unerwarteten Kosten überrascht werden!
Eine vereinfachte Definition von technischer Schuld
Technische Schuld (in manchen Teams auch als "Code Debt" bezeichnet) beschreibt die impliziten Kosten künftiger Nacharbeiten, die anfallen, wenn man sich für eine kurzfristige Abkürzung anstelle eines besseren, aber aufwändigeren Ansatzes entscheidet. Es ist wie die Zinsen auf einen Kredit—die Kosten der technischen Schuld wachsen mit der Zeit.
Ein Vergleich, den ich gerne verwende, ist das Rasieren eines Bartes. Wenn ich wenig Zeit habe und mich schnell rasiere, wird das Ergebnis vermutlich nicht ganz sauber sein, und ich muss später nochmal nachbessern.
Der Zeit- und Arbeitsaufwand für beide Rasuren—die erste und das spätere Nachbessern—wird insgesamt höher sein, als wenn ich es beim ersten Mal ordentlich gemacht hätte.
Aber manchmal, wenn die Zeit drängt, bleibt uns nichts anderes übrig, als die schnelle Rasur in Kauf zu nehmen!
Vergleich von finanzieller Schuld und technischer Schuld
Um dieses Konzept zu veranschaulichen, tauchen wir etwas tiefer in den Vergleich zwischen finanzieller und technischer Schuld ein. Schließlich müssen Product Manager sowohl finanzielle als auch technische Aspekte eines Produkts verstehen!
Vorteile von finanzieller Schuld: Finanzielle Schuld ermöglicht Hebelwirkung. Durch das Leihen von Geld erhält man das Kapital, um Wachstumschancen zu nutzen. Außerdem erlaubt finanzielle Schuld den direkten Zugang zu Ressourcen oder Vermögenswerten, ohne sofort zahlen zu müssen.
Nachteile von finanzieller Schuld: Finanzielle Schuld bringt viele verschiedene Arten von Kosten mit sich. Zinszahlungen können sich mit der Zeit summieren und die Rentabilität mindern. Und eine schlechte Verwaltung finanzieller Schulden kann zu Instabilität führen.
Darüber hinaus kann eine Verschuldung die finanzielle Flexibilität einschränken und uns daran hindern, bestimmte Wege in der Zukunft einzuschlagen. Und die Nichterfüllung finanzieller Verpflichtungen kann dem Ruf einer Organisation schaden.
Vorteile von technischer Schuld: Technische Schuld ermöglicht eine schnellere anfängliche Produktentwicklung, was hilft, enge Termine einzuhalten oder Marktchancen zu ergreifen. Und ähnlich wie bei finanzieller Hebelwirkung kann die Aufnahme technischer Schuld die anfänglichen Entwicklungskosten senken.
Nachteile von technischer Schuld: Wie sich bei finanziellen Schulden Zinsen aufaddieren, wächst auch technische Schuld, wenn neue Funktionen oder Änderungen auf bereits bestehenden Abkürzungen aufbauen, was die künftige Entwicklung komplexer und teurer macht. Außerdem führt technische Schuld häufig zu einer schlechteren Codequalität und damit zu höheren Wartungskosten im Laufe der Zeit.
Technische Schuld kann die Fähigkeit eines Produkts beeinträchtigen, sich an neue Marktbedingungen anzupassen oder neue Funktionen zu integrieren. Nicht adressierte technische Schuld kann zu Systemausfällen, Sicherheitslücken oder Performance-Problemen führen, die sich negativ auf die Produktlebensfähigkeit auswirken.
Was bedeutet das für uns? Für finanzielle wie für technische Schulden gilt: Das Ziel ist nicht, Schulden grundsätzlich zu vermeiden. Vielmehr ist ein umsichtiges Management entscheidend.
Ein gewisses Maß an Schulden ist strategisch für Wachstum, aber wir müssen Schulden sorgfältig überwachen und steuern, um langfristige negative Folgen zu minimieren.
Beispiele für technische Schuld
Im Bereich Software Engineering begegnen Entwicklerteams regelmäßig technischer Schuld. Schauen wir uns ein paar der häufigsten Beispiele an.
Legacy-Code
Manche Teams nutzen veralteten Legacy-Code, um eine Funktion schnell herauszubringen. Dies kann zunächst die gewünschte Funktionalität bieten, erfordert später jedoch oft eine umfassende Überarbeitung, insbesondere wenn neue Funktionen hinzukommen. Ähnlich wie ein antikes Manuskript wurde Legacy-Code über Generationen von Entwicklern weitergegeben und trägt die Last der Geschichte.
Auch wenn er in seiner Blütezeit seinen Zweck hervorragend erfüllt hat, nagt der Zahn der Zeit an seiner Anpassungsfähigkeit und Wartbarkeit. Ausfälle und Bugs im Produktivbetrieb entstehen oft dann, wenn wir uns zu sehr auf Legacy-Code verlassen!
Hartcodierung
Hartcodierung bezeichnet die Praxis, spezifische Werte oder Konstanten direkt im Code zu verankern, anstatt konfigurierbare Einstellungen zu nutzen.
Obwohl dieser Ansatz kurzfristig eine schnellere Entwicklung ermöglichen kann, führt er häufig später zu Komplikationen. Stellen Sie sich vor, ein hartcodierter Wert, wie z. B. ein Dateipfad oder eine Timeout-Grenze, muss in einem großen Codebestand geändert werden. Dies kann schnell zu einer zeitaufwendigen und fehleranfälligen Aufgabe werden, die Wartbarkeit und Flexibilität der Software gefährdet.
Um diese Falle zu vermeiden, sollten Entwickler auf konfigurierbare Optionen setzen, um die Anpassungsfähigkeit ihres Codes zu verbessern.
Code-Duplikation
Code-Duplikation tritt auf, wenn ähnliche oder identische Code-Schnipsel an mehreren Stellen im Projekt erscheinen. Anfangs mag dies wie eine praktische Abkürzung erscheinen und Zeit während der Entwicklung sparen. Doch wenn die Software wächst und sich die Anforderungen ändern, wird die Pflege und Aktualisierung zur komplexen Herausforderung.
Code-Duplikation erhöht nicht nur das Risiko für Fehler, sondern vervielfacht auch den Aufwand für zukünftige Weiterentwicklungen und Fehlerbehebungen. Das Streben nach Wiederverwendbarkeit von Code und der Verzicht auf redundanten Code sind grundlegende Prinzipien zur Lösung dieses Problems.
Fehlende Dokumentation
Dokumentation ist der rote Faden, der den Weg für heutige und zukünftige Entwickler erhellt. Das Fehlen umfassender Dokumentation ist vergleichbar mit dem Antritt einer komplexen Reise ohne Landkarte. Es beginnt oft mit dem Mangel an Inline-Kommentaren, die die Hintergründe bestimmter Code-Entscheidungen erklären, und steigert sich bis zu fehlenden Benutzeranleitungen und Systemarchitektur-Dokumentationen.
Während die Anfangsphase der Entwicklung oftmals reibungslos verläuft, können die langfristigen Folgen gravierend sein. Die Fehlersuche wird zu einer rätselhaften Aufgabe, der Wissenstransfer im Team wird erschwert, und das Skalieren des Projekts gleicht mitunter einer Labyrinthsuche im Dunkeln. Gründliche Dokumentation ist das Leuchtfeuer, das den weiteren Weg in der Software-Entwicklung erhellt.
Fehlende automatisierte Tests
Das Fehlen automatisierter Tests gleicht dem Auslaufen mit einem Boot, ohne vorher zu prüfen, ob es Löcher hat. Automatisierte Tests (inklusive Unit-, Integrations- und Regressionstests) sind die wachsamen Hüter von Codequalität und Stabilität.
Wenn sie fehlen, werden die Auswirkungen oft erst später bemerkt. Anfänglich verläuft die Entwicklung zügig und die Software scheint zu funktionieren. Doch mit wachsendem und sich weiterentwickelndem Codebestand tauchen unerwartete Probleme auf. Regressionen, bei denen ehemals funktionierende Features durch neue Änderungen kaputtgehen, werden alltäglich.
Ohne automatisierte Tests als Sicherheitsnetz ist das Team auf manuelle Tests angewiesen – ein zeitaufwendiger und fehleranfälliger Prozess. Wer von Beginn an auf automatisierte Tests setzt, steuert verlässlich durch den stürmischen Ozean der Softwareentwicklung.
Welche Rolle spielt technische Schuld im agilen Umfeld?
Ah, agile Entwicklung! Ihre Scrum-Methoden und Prinzipien aus dem Agilen Manifest setzen auf Wandel und Geschwindigkeit. Aber wo passt technische Schuld hinein? Immerhin wird technische Schuld in den Gründungsdokumenten von Agile nicht ausdrücklich erwähnt.
Hier ein Vergleich aus Star Wars – der Millennium Falke wurde von Han Solo und Chewbacca ständig gewartet, um stets einsatzbereit für neue Abenteuer zu bleiben. Genauso kümmert sich ein agiles Produktteam um technische Schulden, damit die Softwarequalität erhalten bleibt und heldenhafte Abenteuer für die Kunden möglich sind!
Wie nutzt und managt man technische Schuld?
In agilen Teams herrscht die Erkenntnis, dass manchmal technische Schuld in Kauf genommen wird, um Geschäftsanforderungen schnell zu erfüllen. Merken Sie sich: Technische Schuld ist nicht zwangsläufig etwas Schlechtes. Martin Fowler, ein Vordenker der agilen Softwareentwicklung, betont, dass es um Abwägungen geht. Manchmal nimmt man zu Beginn des Software-Produktlebenszyklus bewusst Schulden auf, um ein Konzept zu validieren oder schneller auf den Markt zu kommen.
Entscheidend ist das Management technischer Schuld. Sie sollte im Backlog dokumentiert, priorisiert und in zukünftigen Sprints angegangen werden. Dafür sind ein starkes Projektmanagement und ein gutes Verständnis darüber erforderlich, wie viel technische Schuld bislang aufgenommen wurde – insbesondere für Produktmanager.
Wann wird technische Schuld zum Problem?
Wenn Stakeholder sich der technischen Schulden nicht bewusst sind oder der Entwicklungsprozess stark auf Notlösungen beruht, sollten die Alarmglocken läuten. Warum?
- Sie sind unsichtbar: Ohne Metriken oder regelmäßige Code-Reviews können versteckte Schwachstellen auftreten.
- Sie beeinträchtigen die Benutzererfahrung: Wenn zugrunde liegende Probleme die Funktionalität beeinträchtigen, ist das nicht nur ein Problem der Entwickler; es wird zum Geschäftsrisiko.
- Sie behindern neue Funktionen: Programmierer, die im schlechten Code stecken, sind weniger produktiv – und die Kreativität nimmt ab.
- Sie stehen nicht auf der Produkt-Roadmap: Teams sollten sich der technischen Schulden bewusst sein und eine Strategie zum Umgang damit haben. Scheuen Sie sich nicht, auf externe Webinare und Ressourcen zurückzugreifen, um einen Aktionsplan zu entwickeln.
Wie man technische Schulden misst
Mit Hilfe von Tools wie DevOps-Praktiken und Automatisierung können Teams ihre Codebasis überwachen und ein Gespür für die bisher angesammelten technischen Schulden behalten. Im Folgenden habe ich zwölf verschiedene Möglichkeiten zusammengestellt, wie Sie technische Schulden verfolgen können.
Sie müssen nicht alle Methoden einsetzen! Betrachten Sie die Liste stattdessen als Startpunkt. Wählen Sie ein oder zwei Methoden aus, die Sie im nächsten Monat einführen, und steigern Sie dann nach und nach die Kompetenz Ihres Teams im Erfassen und Lösen technischer Schulden.
1) Statische Codeanalyse: Tools wie SonarQube, ESLint oder FindBugs können den Code automatisch auf verschiedene Probleme wie Komplexität, Code-Smells oder potenzielle Fehler untersuchen. Sie liefern quantitative Metriken zur Codequalität und zu technischen Schulden auf Basis vordefinierter Regeln und Schwellenwerte.
2) Testabdeckung des Codes: Wir können mit Tools wie JaCoCo oder Istanbul messen, wie viel des Codes durch automatisierte Tests abgedeckt ist. Niedrige Testabdeckung kann auf fehlende Tests und damit auf potenzielle technische Schulden hinweisen.
3) Peer-Code-Reviews: Durch Peer-Code-Reviews können Entwickler potenzielle technische Schulden erkennen und diskutieren. Zwei Köpfe sind besser als einer – das ist ein guter Weg, schlechte Code-Muster zu vermeiden! Teams können Checklisten oder Richtlinien verwenden, um die Codequalität zu bewerten und identifizierte Probleme zu dokumentieren. Zahl und Schwere der bei Reviews gefundenen Probleme dienen als qualitative Messgröße für technische Schulden.
4) Manuelle Code-Inspektionen: Entwickler und Teams können manuelle Code-Durchsichten oder Walkthroughs durchführen, um Bereiche zu identifizieren, die Refactoring benötigen. Oft prüfen erfahrene Entwickler den Code und dokumentieren Schwachstellen, da sie meist das beste Gespür für technische Designsünden haben.
5) Backlog technischer Schulden: Die Pflege eines Produkt-Backlogs oder einer Liste erkannter technischer Schulden ist eine gängige Praxis. Jedes Element sollte eine Beschreibung, eine Auswirkungenabschätzung und eine Priorisierung enthalten. Umfang und Priorität der Backlog-Einträge liefern eine qualitative Einschätzung der technischen Schuld.
6) Fehler- und Problemverfolgung: Die Analyse des Bug-Triage-Prozesses kann Aufschluss über Häufigkeit und Schwere der mit technischen Schulden verbundenen Probleme geben. Viele Fehlerberichte oder häufig wiederkehrende Probleme sind ein Hinweis auf zugrunde liegende technische Schulden.
7) Aufwandsschätzung und Story Points: Bei der Planung neuer Aufgaben oder User Stories kann das Entwicklungsteam den Aufwand zur Behebung technischer Schulden schätzen. Diese Aufwandsschätzung, oft in Form von Story Points in agilen Methoden, quantifiziert den zur Beseitigung technischer Schulden nötigen Aufwand.
8) Komplexitätsmetriken des Codes: Kennzahlen wie zyklomatische Komplexität, Anzahl der Codezeilen und Code-Churn liefern Hinweise auf die Komplexität und Wartbarkeit der Codebasis. Hohe Komplexität und zu häufige Änderungen bestimmter Bereiche deuten auf technische Schulden hin.
9) Nutzerfeedback: Nutzerfeedback und Support-Anfragen können indirekt auf technische Schulden hinweisen. Häufige Beschwerden über Systemleistung, Zuverlässigkeit oder unerwartetes Verhalten sind Anzeichen für zugrunde liegende Probleme, die adressiert werden müssen.
10) Metriken bei automatisierten Tests: Die Überwachung von Kennzahlen wie Ausführungszeit, Fehlerrate und instabilen Tests kann helfen, den Zustand der Testinfrastruktur zu beurteilen und Bereiche mit technischem Schuldenrisiko zu identifizieren.
11) Umfragen und Interviews: Durch Befragungen und Interviews mit Entwicklerteams lassen sich qualitative Erkenntnisse über das empfundene Ausmaß technischer Schulden und ihren Einfluss auf Produktivität und Codequalität gewinnen. Auch das Einholen von Stakeholder-Feedback kann dabei helfen, Bereiche mit erhöhtem Nachbesserungsbedarf zu erkennen.
12) Technical Debt Quadrant: Ein besonders nützliches Werkzeug ist das von Martin Fowler vorgestellte Technical Debt Quadrant. Es kategorisiert die Ursachen technischer Schulden in absichtlich/unabsichtlich sowie rücksichtslos/besonnen und hilft Teams, Abwägungen besser zu verstehen.
Neben diesen zwölf Möglichkeiten, technische Schulden zu messen, solltest du nicht zögern, Produktmanagement-Tools einzusetzen, um das Nachverfolgen und Lösen der technischen Schulden deines Teams zu unterstützen!
Technische Schulden abbezahlen
Wir haben viel darüber gesprochen, wie technische Schulden entstehen, aber wir sind noch nicht darauf eingegangen, wie man diese abbezahlt. Als Produktmanager ist es unsere Aufgabe, das Team dahingehend zu führen, wann es sinnvoll ist, technische Schulden zu begleichen, und wann es gerechtfertigt ist, weitere Schulden einzugehen.
Technische Schulden werden abbezahlt, wenn Entwickler den Code aktualisieren, um bereits bekannte Punkte technischer Schulden zu adressieren. Das kann eine Neugestaltung von Funktionen für mehr Effizienz, die Einführung automatisierter Tests oder die Bereitstellung ausführlicher Dokumentation zum Code umfassen.
Eine der besten Möglichkeiten, technische Schulden abzubauen, besteht darin, in jedem Sprint Zeit dafür zu reservieren, die Codebasis zu stärken und Schulden zu begleichen. Betrachte dies wie die monatlichen Raten einer Hypothek – je schneller wir diese abbezahlen, desto weniger Zinsen müssen wir insgesamt zahlen!
Eine gute Faustregel ist die 80/20-Regel. Das heißt: Rund 80 % der Zeit im Sprint werden für neue Features eingeplant, etwa 20 % für technische Investitionen und Verbesserungen.
Plane beim Schuldenabbau auch ein, diese entsprechend in deine Produkt-Roadmap zu integrieren.
Abschließende Gedanken zu technischen Schulden
Zusammengefasst: Das Management technischer Schulden ist nicht nur Sache der Entwickler. Auch Produktmanager, Agile-Teams und Business-Stakeholder sind gefragt.
Das Endziel? Die Auslieferung eines hochwertigen Softwareprodukts, das die Geschäftsziele erfüllt, ohne nicht tragbare Schulden anzuhäufen.
Ob du nun in die Tiefen der Softwareentwicklung eintauchst oder einfach verstehen möchtest, warum dein Entwicklungsteam ständig über Refactoring spricht: Das Verständnis und Management technischer Schulden ist dein Kompass.
Und egal, ob du am Anfang deiner Produktkarriere stehst oder schon ein „alter Hase“ im Produktmanagement bist – ein vertieftes Verständnis von technischem Fachjargon bringt dich fast immer weiter.
Ich hoffe, du vermeidest den Fehler, den ich zu Beginn meiner Karriere gemacht habe: Verlass dich nicht nur auf den Kontext, um unbekannte technische Konzepte zu erraten!
Nimm dir stattdessen die Zeit, dich zu informieren, greife auf externe Leitfäden wie diesen zurück und tausche dich mit deinen Entwicklern aus, um dein Wissen weiter auszubauen.
Für weitere Einblicke und Leitfäden rund ums Produktmanagement vergiss nicht, unseren Newsletter zu abonnieren!
