Wie viele Bugs habt ihr im Backlog?

Bei allen Software-Projekten die ich bisher gesehen habe wächst der Backlog mit Bugs immer weiter. Meistens werden unkritische Probleme verschoben/vertagt und erst gar nicht angegangen. So häuft sich ein Haufen kleinerer Mini-Problemchen, die nicht gelöst werden.

Um nicht in einer endlosen Schleife der Depriorisierung zu landen verfolgen wir einen anderen Ansatz:

Unser Ziel ist es, diese Menge von Bugs bei annähernd Null zu halten.

In der Ladeinfrastruktur geht es um absolute Stabilität von SaaS Services, deshalb ist unserer höchste Priorität eine hohe Qualität zu gewährleisten. Ein Bug in unserer Plattform ist kein kosmetisches Problem. Er kann bedeuten, dass ein reale Kunden vor Ladesäulen stehen und nicht weiterkommen.

Wir kennen das Problem aus unserer Shared-Mobility Vergangenheit, da ging es, genau wie bei Ladesäulen, darum das die paar Minuten die der User in der Applikation verbringt so stabil wie möglich verlaufen, sodass der Nutzer Vertrauen in die Lösung aufbauen kann und diese immer wieder benutzt.

Warum das bei Ladeinfrastruktur keine Kür ist

Jeder Bug in unserer Lade-Plattform kostet unseren Kunden Geld und Vertrauen. Ladeinfrastruktur ist keine Web-App, bei der man mal eben einen Tab neu laden kann. Der Status der Säule muss jederzeit verfügbar und transparent sein, wenn Probleme auftreten müssen diese nachvollziehbar für den Endkunden sein um diesem auch die Möglichkeit zu geben das Problem vor Ort selbst zu lösen. Wobei die optimale User-Experience natürlich sein sollte, dass erst gar kein Problem auftritt.

Ein konkretes Szenario: 50 neue Ladepunkte gehen ans Netz, die Pressemitteilung ist raus, das CPMS reportet alle Säulen als "online" – und dann hakt das Endkundenprodukt, der QR-Code scannt nicht oder die App stürzt ab, weil diese vorher unzureichend am Kunden getestet wurde. Was bleibt, ist ein Reputationsschaden, den keine Kampagne wieder geradebiegt. Ein CPMS welches die Säule stabil "online" hält ist nur der erste Schritt, sobald das gegeben ist MUSS eine top Experience für den Endkunden gegeben sein, der CPMS Systeme gar nicht kennt und eine Hardware Verfügbarkeit wie an der Zapfsäule erwartet.

Software-Qualität ist in dieser Branche deshalb kein Nice-to-have. Sie ist die Voraussetzung dafür, dass physische Infrastruktur und Endkunden-Applikationen auch tatsächlich zuverlässig funktionieren.

Der Kern der Idee

Inspiriert hat uns unter anderem Linear aus dem Product Management Bereich. Sie haben gezeigt, dass man Qualität konsequent priorisieren kann, ohne dabei langsamer zu werden. Eigentlich ist die Grundidee simpel:

Einen Bug zu fixen kostet gleich viel Aufwand, ob man es heute tut oder in sechs Monaten. Nur: Wenn du es heute tust, haben ab morgen alle Nutzer ein besseres Erlebnis. Warum also warten?

„Ein wachsender Bug-Backlog ist oft ein Zeichen dafür, dass Qualität nicht wirklich Priorität hat. Wir wollen es anders machen."

In der Praxis heißt das: Jeder Bug wird entweder zeitnah gefixt oder bewusst als „Won't Fix" geschlossen. Dazwischen gibt es nichts. Kein „schauen wir später an", kein stilles Verschieben auf nächstes Quartal, sondern klare Kommunikation an unseren Kunden, damit dieser auch klar an seine Kunden kommunizieren kann.

Wie wir das konkret umsetzen

Die Umsetzung ist weniger komplex, als man erwarten würde. Drei Prinzipien tragen das Ganze:

Triage bei Eingang

Jeder Bug wird sofort triagiert. Egal ob er vom Kunden kommt, vom automatischen Monitoring oder aus dem Team selbst – er bekommt eine Severity-Stufe und einen Owner. Noch am selben Tag.

Klare SLAs

Wir haben uns interne Zeitfenster gesetzt:

Critical (P0): Fix innerhalb von 4 Stunden – wenn Ladevorgänge betroffen sind
High (P1): Fix innerhalb von 24 Stunden – bei wichtigen Funktionseinschränkungen
Normal (P2): Fix innerhalb von 5 Werktagen – kleinere Probleme ohne direkten Betriebsimpact

Morgens im Team gilt: Erst Bugs, dann Features. Immer. Das klingt unbequem, sorgt aber dafür, dass sich gar nicht erst ein Berg aufbaut.

Kein Bug-Backlog

Das ist das Prinzip, das am meisten Disziplin erfordert. Wir schieben Bugs nicht auf. Jeder Bug wird entweder zeitnah gelöst oder bewusst geschlossen – denn eine Liste, die über Monate wächst, arbeitet am Ende niemand mehr ab.

Transparenz statt Vertröstung

Unsere Zero-Bug-Policy ist kein internes Versprechen, das in einer Confluence-Seite verstaubt. Sie ist ein Versprechen an unsere Kunden.

Auf unserer öffentlichen Status-Page sieht jeder Kunde in Echtzeit, wie es um unsere Systeme steht – inklusive geplanter Wartungen und historischer Verfügbarkeit. Kein Verstecken hinter „wir kümmern uns drum".

Im worst Case Szenario müssen wir Feature Versprechungen verschieben. Wenn es wirklich soviele Bugs geben würde, dass das vorkommt. Aus unserer Perspektive ist das allerdings ein Trade-Off den wir dafür gerne eingehen. Eine bekannte stabile Experience des aktuellen Nutzungsumfangs für Endkunden hat absolute Priorität. Dem sollten sich auch unsere Kunden klar sein.

Nach größeren Incidents schreiben wir Post-Mortem-Reports: Was ist passiert, warum, und was ändern wir, damit es nicht wieder vorkommt. Die teilen wir mit den betroffenen Kunden. Und unser Monitoring schlägt in der Regel an, bevor überhaupt jemand ein Ticket öffnen muss.

Das verändert die Zusammenarbeit mit unseren Kunden grundlegend. Statt frustriert ein Ticket zu schreiben und Wochen zu warten, erleben sie, dass Probleme oft schon gelöst sind, bevor sie sie bemerken.

Was das mit dem Team macht

Eine Zero-Bug-Policy verändert nicht nur Prozesse. Sie verändert, wie ein Team Code schreibt.

Wenn jeder weiß, dass ein Bug nicht in irgendeinem Backlog verschwinden wird, sondern am nächsten Morgen auf dem eigenen Tisch landet, entsteht ein natürlicher Anreiz, sauberer zu arbeiten. Tests werden selbstverständlicher. Code-Reviews gründlicher. Nicht weil es eine Regel gibt, sondern weil die Konsequenz bei einem selbst spürbar ist. Wenn möglich der entsprechende Entwickler, der den Code geschrieben hat auch automatisch für's Bugfixen verantwortlich.

Das hat einen willkommenen Nebeneffekt: Ohne Bug-Altlasten bleibt deutlich mehr Zeit für Weiterentwicklung – neue Features statt alte Probleme.

Was das für eure Ladeinfrastruktur bedeutet

Wer Ladeinfrastruktur betreibt, ist darauf angewiesen, dass die Software dahinter zuverlässig funktioniert. Dass Ladesäulen erreichbar sind, Bezahlvorgänge durchgehen und die Systeme auch unter viel Last stabil bleiben.

Unsere Zero-Bug-Policy ist unser Weg, diesem Anspruch gerecht zu werden. Kein Marketing-Versprechen, sondern gelebte Praxis – sichtbar in unserer täglichen Arbeit, in Post-Mortems und in der Kommunikation mit unseren Kunden.

Wenn ihr eine Plattform sucht, bei der Qualität, Transparenz und Stabilität kein Lippenbekenntnis ist – lasst uns darüber sprechen.