Rule of Ten: Darum ist Prävention wichtiger als Revision

Man stelle sich folgendes Szenario vor: Ein intensives Softwareprojekt wird endlich abgeschlossen, der Go-Live verläuft reibungslos und die Projektmitglieder erholen sich tagelang von der wohlverdienten Projektabschluss-Party. Also alles im grünen Bereich - bis dann ein paar Wochen später ein grober Fehler in der Applikation gefunden wird. Der Albtraum von allen Stakeholdern.

Wenn ein Fehler erst zu diesem späten Zeitpunkt gefunden wird, dann kostet die Behebung beispielsweise - jetzt mal ganz einfach gesagt fürs Verständnis - 100 Euro. Zu diesen 100 Euro zählen dann nicht nur die Kosten für die Behebung des Fehlers, sondern auch die Unzufriedenheit und mögliche Rufschädigung des Unternehmens. Hätte man den Fehler früher entdeckt - beispielsweise bei einem Sprint-Review - hätte die Behebung nur 10 Euro gekostet. Und hätte man diesen Fehler schon während der Entwicklung entdeckt? Dann hätten sich die Kosten für die Behebung wohl nur auf einen einzigen Euro belaufen, und es hätte keine potenziell unzufriedene Stakeholder, Rufschädigungen oder andere ärgerliche Folgen gegeben.

Dies ist die sogenannte “Rule of Ten” oder “1/10/100” Regel: Fehler sind mit jedem abgeschlossenen Produktlebenszyklus zehnmal teurer zu beheben. Dass an dieser Regel etwas dran ist - das mussten ehrlicherweise auch wir in der Vergangenheit schon erfahren. Doch wie verhindern wir das heute?

Wir haben nicht einfach aufgehört, Fehler zu machen: Erstens macht jeder Fehler. Zweitens sind sie nicht absichtlich und deshalb kann man sie auch nicht einfach so abstellen. Drittens lernt man mit dem richtigen Umgang von ihnen, weshalb Fehler nicht immer etwas Schlechtes sind. Deshalb geht es darum, so schnell wie möglich Fehler zu finden und zu korrigieren. Und zwar, bevor man in den nächsten Zyklus oder Sprint rutscht und sich die Behebungskosten verzehnfachen; Stichwort Prävention. Dies erreichen wir durch kompromisslose Qualitätsstandards und strenges Qualitätsmanagement.

Diese Standards reichen von Technologiewahl und DevOps bis zu Workflows und Codequalität. Beispielsweise wird unser Code immer vollautomatisch vom Tool Sonar analysiert: Ist der Code für unsere Standards zu komplex und muss daher vereinfacht werden? Oder gibt es irgendwelche Sicherheitslücken oder Bugs? Anschließend muss noch ein weiteres Teammitglied den Code kontrollieren und freigeben, und erst dann landet er auch wirklich im finalen Projekt. Zusätzlich verwenden wir auch Unit-Tests, wodurch wir die gewünschte Funktion der Komponenten gewährleisten. Mehr zu unseren Qualitätsstandards und unserer Arbeitsweise findest du übrigens hier.

Als “Your partner in crime” setzen wir auf eine langfristige Zusammenarbeit. Und wie die “Rule of Ten” schön veranschaulicht, profitieren von unserer Qualität langfristig nicht nur die Geldbörsen und das Image unserer Kunden, sondern auch die Kunden von unseren Kunden. Beispiele hierfür sind unsere eindrucksvollen Projekte mit ZIMA oder amKumma, die wir nach diesen beschriebenen Standards umgesetzt haben - und auch immer noch umgesetzt werden.