Prototypen gehören nicht in den Straßenverkehr

Gerade bei Software ist es wichtig, dass sie sich in ein bestehendes System einfügt. Sind einzelne Komponenten hastig zusammengestrickt können selbst gefühlt unbedeutende Teile das gesamte Konstrukt zum Einsturz bringen, indem es sich und andere Teile im Prozess destabilisiert. Im Eifer eines neuen Projektes wird trotzdem häufig schlechtere Qualität und fehlende Qualitätssicherung in Kauf genommen um schneller auf den Markt zu reagieren. Doch was passiert danach?

Robert C. Martin aka Uncle Bob, ein renommierter Softwarearchitekt, beschreibt den Zyklus so, dass aufgrund der fehlenden QS häufig Wartungsarbeiten notwendig werden die Zeit kosten. Die fehlende Softwarequalität nachzuziehen jedoch – dafür ist keine Zeit da, denn es müssen ja neue Funktionen umgesetzt werden, weiter auf den Markt reagiert werden. Doch durch die Wartungsarbeiten kommt das Team mit neuen Funktionen nur langsam voran, wenn es die notwendigen Qualitätssicherungsmaßnahmen einhält. Unter Druck des Management wird auch der neue Code hastig zusammengeworfen. Es entstehen mehr schlecht wartbare Komponenten, der Wartungsaufwand steigt, das Tempo geht weiter in den Keller, der Leistungsdruck steigt, die Qualität wird schlechter, es entstehen mehr schlecht wartbare Komponenten… Auf diesem Weg haben sich viele Projekte in die selbst verschuldete Obsolenz entwickelt.

Es ist eine Imperative für die Geschäftsfähigkeit eines Projektes das die Qualität nachhaltig berücksichtigt wird. Dabei ist es völlig legitim, sich gegen softwaretechnische Überlegungen, Architektur, QS und Testing zu entscheiden. Das Ergebnis ist dann allerdings kein Produkt sondern ein Prototyp, der genutzt werden kann um Erkenntnisse über Lebensfähigkeit und Bedürfnisse eines Marktes zu erforschen. Doch als vollwertiges Produkt kann er nicht bezeichnet und verwendet werden und es ist sehr wichtig diesen Kompromiss im Vorfeld zu vereinbaren und sich Ressourcen für die tatsächliche Entwicklung des Produktes zu reservieren. Der Prototyp wandert ganz oder teilweise in die Tonne. Nachfolgend eine empfohlene Gliederung.

Dummy

Repräsentiert die Idee grafisch, und kann dazu verwendet werden mit Kunden den Flow des späteren Produktes zu verstehen.
Aufwand: wenige Stunden

Prototyp

Um bereits ein besseres Verständnis und eine erste Logik zu testen können Prototypen helfen, die in kurzer Zeit und ohne jede Qualitätssicherung umgesetzt werden. Auch wenn der Ansatz sich als richtig herausstellt, werden wenn überhaupt nur Teile eines Prototypen übernommen die qualitativ vertretbar sind. Grundsätzlich werden hier Fehler in Kauf genommen.
Aufwand: wenige Tage

Minimum Viable Product / Pilot

Architektonische Überlegungen fließen in das erste Produkt ebenso ein wie eine komplette Qualitätssicherung. Vom tatsächlich ausgelieferten Produkt unterscheidet sich das Minimum Viable Product nur noch durch die Anzahl der Funktionen, nicht durch deren Qualität. Bekannte Fehler werden nicht toleriert; statt 10 halbfertigen Funktionen werden 5 vollständige Funktionen eingebaut. Die Konzentration auf das Wesentliche hilft, schnell etwas für den Kunden Nutzbares vorzeigen zu können und das die wertvollsten Funktionen zuerst umgesetzt werden.

Aufwand: Wochen-Monate

Finales Produkt

Das Feedback aus dem Produktmanagement wird so lange weiter in neuen Funktionen umgesetzt, bis das Produkt den gewünschten Umfang erreicht, der es für die Allgemeinheit wertvoll macht. Eventuell finden in dieser Phase noch Individualisierungen statt.