Welchen Wert hat Qualität?

1. Juni 2016 IT Management

Software-Entwicklung von hoher Qualität? Das behaupten viele zu können. Aber was macht gute Qualität mit Blick auf Programmierung aus?

Beim Einkaufen höre man ja die tollsten Sprüche: “Qualität hat ihren Preis”, säuselt die Dame im TV-Spot und rümpft die Nase, “das macht mich echt fuchsig.” Mich auch. Ist billiger als andere wirklich das einzige Qualitätsmerkmal, das zählt?

Wer zu billig kauft, kauft doppelt

Ausschreibungen im öffentlichen Bereich funktionieren schon lange so: Da wird nur auf den Preis geachtet, und darauf, dass der so ausgewählte billigste Anbieter dennoch bestätigt, alle gestellten Anforderungen zu erfüllen. Damit tut der Einkäufer der Sache keinen Gefallen, sondern schützt sich nur selbst vor dem Vorwurf, falsch eingekauft zu haben. Das Prinzip heisst cover your ass. Der gewünschte Spareffekt stellt sich nur selten ein, am Ende sind die Kosten doch wieder höher als geplant.

Komischerweise ist es gerade die so auf Rationalität getrimmte Software-Branche, in der man in der Realität besonders gern bereit ist, in Bezug auf Qualität auf beiden Augen blind zu sein. Defizite bei Planung, Ausführung und Betrieb, aber auch Datenschutz und Sicherheit werden nach Möglichkeit so lange ignoriert, bis das Kind im Brunnen liegt. Dann ist es wichtig, als Betreiber möglichst nicht selbst schuld zu sein – aus dem Grund haben Auftraggeber umfangreiche Verträge mit Subunternehmern und Sub-Subunternehmern, deren einziger Zweck zu sein scheint, Verantwortung so lange zu delegieren, bis niemand mehr dafür aufkommen muss.

Das kannste schon so machen

Gute Qualität ist das Vorhandensein gewünschter Eigenschaften. Richtig ist: Es macht keinen Sinn, aus Anbietersicht vermeintliche Qualität zu definieren, solange der Anwender daraus keinen Nutzen zieht. Wenn wir Schuhe kaufen, dann ist “gute Qualität” zb deren Haltbarkeit oder Passform. Gute Softwarequalität ist nicht so einfach mit den Händen zu greifen. Aber woran kann man gute Qualität in der Softwareentwicklung dann erkennen?

• Planbarkeit: Über die Beschreibung des Weges erhalten wir früh im Prozess die Gewissheit, dass das gewünschte Ergebnis erreicht werden kann.
• Anwendbarkeit: Das Produkt eignet sich in besonderer Weise für den gewünschten Zweck und erfüllt die tatsächlichen Anforderungen.
• Wirtschaftlichkeit: Entwicklungs-, Anschaffungs- und Betriebskosten bleiben im vereinbarten Rahmen
• Risikominimierung: Fachliche & rechtliche Risiken sowie Informationsverlust wird auf verschiedenen Ebenen aktiv und passiv entgegengewirkt

… aber dann isses halt Kacke

Soweit zur Theorie. In der Praxis wird gefrickelt¹ was das Zeug hält. Projektplanung per Excel muss man noch zu den solideren Wegen zählen, alternativ werden so lange Anforderungen über den Zaun gerufen, bis der Stakeholder aufhört zu meckern. Prototypen, Wireframes, user stories… lieber nicht. Tickets, Meilensteine, Versionierung, code review oder continuous integration? Fehlanzeige. Unit- und Integration tests, Testpläne und -daten? Liefern wir nach. Backup & Monitoring? Kein Budget. Regelmäßige Softwarewartung, um Software Erosion vorzubeugen? Das geht auch ohne.

Geschludert wird vom Startup bis zum Weltkonzern. Gerechtfertigt wird das damit, dass ja doch alles läuft, irgendwie. Was aber nur stimmt, wenn man die kleineren und größeren auftretenden Katastrophen außer Acht lässt. Warum haben wir uns nicht nur im Enterprise-Umfeld längst daran gewöhnt, dass Software länger dauert, mehr kostet und man es bei Fehlern einfach nochmal probiert? Muss das wirklich so sein? Have you tried turning it off and on again?

Qualität ist keine Frage des Budgets

Weil man Software halt so schlecht greifen kann, müssen wir uns besonders anstrengen, damit ein Softwareprojekt am Ende gelingt. Dazu dienen die ganzen Qualitätsmaßnahmen. Halb ernst, halb sarkastisch beschreibt der Bus-Faktor die kleinste Anzahl von Teammitgliedern, die ausfallen müssen, um das Projekt zu gefährden. Ermitteln Sie die Zahl mal für Ihre Projekte: Ist sie eins, gibt es also eine einzelne Person, deren Leistungsfähigkeit das gesamte Projekt beeinflusst? Weil die Person vielleicht spezielles Wissen hat, bei ihr alle Fäden zusammenlaufen?

Ist bei Ihnen Softwareentwicklung ein “hemdsärmeliger” Prozess, der sich durch viel individuelle Arbeit, geringe Transparenz und viel trial and error auszeichnet?

Dann sollten Sie handeln. Sprechen Sie uns an.