Wenn wir heute Online Projekte lancieren, sollten wir etappenweise vorgehen. Zügig und effizient eine Beta Version ausrollen und dann Schritt für Schritt Funktionalität nachliefern. Releast 0.x Versionen und nicht erst 1.0er!

 

Elefantengeburt

Bei den meisten Online Projekten an denen ich bisher mitarbeiten durfte, wurde die Releaseplanung so ausgelegt, dass man das Produkt fixfertig plant, spezifiziert und umsetzt. Man geht direkt mit der Version 1.0 produktiv. Das vollständige Produkt ist damit lanciert. Kleine Verbesserungen der bestehenden Funktionalität werden in unregelmässigen Zeitabständen nachgeschoben. So dauert die Entwicklung einer Version 1.0 oft mehr als ein Jahr. Eine Ewigkeit in der schnelllebigen Online Welt. Das Produkt ist beim Release bereits veraltet. Erst wenn genügend neue Funktionalität angefordert ist, um einen weiteren Release zu füllen, wird die Entwicklung wiederaufgenommen. All zu oft wird dieser Release 1.1 dann erst nach einem weiteren Jahr produktiv geschaltet, da die gesamte Projektorganisation nicht auf schnelle Launches und kurze Zyklen eingestellt ist.

Dieses Vorgehen stammt natürlich aus der Zeit der Wasserfall-Entwicklung. Ein Schritt folgt dem nächsten. Es werden ausgewachsene Elefanten geboren.  Nutzer-Feedback (z.B. durch Usability Tests) wird erst eingeholt, wenn die Version 1.0 ausgerollt ist. Die Nachteile sind offensichtlich. Die Entwicklung ist träge.  Der Produktinhaber kann über die Zeit der Entwicklung (im schlimmsten Fall mehrere Jahre) nichts dazulernen.

 

Mut zur 0.x

Im Zeitalter agiler Entwicklung etabliert sich nach und nach eine neue Releasestrategie. Man releast relativ schnell eine Beta Version, also eine 0.x Version des Produktes: Eine Grundfunktionalität (Kernfunktionalität des Produktes) wird nach kurzer Entwicklungszeit gelauncht. Die Weiterentwicklung schliesst nahtlos an. Learnings aus den 0.x Releases fliessen unmittelbar in die aktuelle Entwicklung ein. Ergebnisse aus der Nutzerforschung haben unmittelbare Auswirkung auf die Entwicklung. Folgereleases finden in regelmässigen Abständen statt.

 

Schnellbootprinzip

Ich denke, dass man bei der Entwicklung von Online Projekten noch einen Schritt weiter gehen kann. Die agile Methodik gibt es uns vor: nach jedem Sprint soll ein auslieferbares Stück Software zur Verfügung stehen. Warum also nicht hingehen und sagen, nach 1-3 Sprints releasen wir eine neue Funktionalität. Lasst uns einfach etwa ausprobieren. Was beim Nutzer ankommt und erfolgreich ist, bleibt bestehen. Was auf weniger Anklang stösst, nehmen wir wieder aus der Anwendung raus. Trial and error.

Ich nenne es das Schnellbootprinzip, weil es sich verhält wie ein Hochseeschiff gegenüber einem Schnellboot. Der Dampfer ist träge, schwer und braucht viel Raum und Zeit, um den Kurs zu ändern. Ein Schnellboot hingegen ist schnell wendig und kann den Kurs jederzeit ändern. Warum setzten Greenpeace für ihre Aktionen auf Schnellboote? Sie sind schnell, wendig und günstig. Greenpeace kann vom Mutterschiff aus mehrere Schnellboote gleichzeitig einsetzten, Manöver ausprobieren, grosse Walfängerschiffe von allen Seiten her attackieren. Und sollte mal ein Schnellboot keinen Erfolg haben,  ist der Verlust verkraftbar und ein anderes Boot kann die Mission erfüllen.

In der Praxis wenden schon viele innovative Projekte eine solche Release-Methodik an. Dazu wird es hier in Kürze einen Gast-Post der Projektleiterin von one100 geben.

 

Fazit

Wenn wir Online Produkte nach dem Schnellbootprinzip entwickeln, stellen wir sicher, dass das Produkt stets auf der höhe der Zeit ist, den Bedürfnissen der Nutzer gerecht wird und wir die Weiterentwicklung kosteneffizient vorantreiben können. Das Prinzip von “trial and error” bringt uns langfristig bessere Resultate und einen nachhaltigeren Erfolg als der Versuch von Anfang an alles “richtig” zu machen. Wir bleiben agil und können auf Veränderungen reagieren.