Ralf Kretzschmar-Auer

Minimum Viable Product – Was wirklich damit gemeint ist

Eines der Ziele agilen Vorgehens ist, unnötige Entwicklungsaufwände zu vermeiden. In früheren Zeiten der IT (also ungefähr vor zehn Jahren), war es allgemein üblich, ein neues Projekt vollständig auszuspezifizieren, bevor es an die Implementierung ging. Oftmals haben sich ganze Heerschaaren von Mitarbeitern überlegt, wie das System aussehen sollte, haben spezifiziert bis (vermeintlich) alles klar war – und dann ging es ganz nach der damals üblichen Wasserfallmethode an die Entwicklung.

Dummerweise hat dieses Ideal nie funktioniert. Wir Menschen sind zwar große Klasse im Aufschreiben von Ideen, aber leider nur ziemliches Mittelmaß, was die Vorstellungskraft betrifft. Und so kam es, wie es kommen musste: Das hoch gelobte System wurde in Betrieb genommen und anschließend erst mal generalüberholt. Das, was da mit viel Aufwand in Betrieb genommen wurde, war allzu oft nicht das, was der Auftraggeber sich vorgestellt hatte. Oder was die Endkunden benutzen wollten. Oder beides.

Eine Idee, um diesem Problem aus dem Weg zu gehen, ist die eines minimal realisierbaren Produkts, englisch Minimum Viable Product oder kurz MVP. Statt alles bis aufs Letzte zu untersuchen, versucht man dabei, erst einmal einen Teilbereich zu finden und für diesen Teilbereich eine hinreichend gute Lösung zu entwickeln. „Hinreichend gut“ bedeutet in diesem Zusammenhang, dass sie das Problem löst, für die Kunden attraktiv ist – und das zu möglichst geringen (Einstands-)Kosten.

Während Planung und Entwurf versucht man also nicht mehr, eine möglichst perfekte Anwendung hinzustellen, sondern man schaut ganz bewusst darauf, wo man Grenzen zieht. Ziel ist es, die Standardfälle gut und mit angemessenem Aufwand zu lösen – und nicht die Sonderfälle, die ein, zweimal im Monat vorkommen. Für die geht man einen anderen, kostengünstigeren Weg.

Was sind die Maßstäbe für ein solches MVP? Zunächst gilt einfach die 80/20 Regel: 80% der Nutzung können mit 20% des Systems erledigt werden. Man ermittelt die typischen Nutzungsfälle und konzentriert sich zunächst auf sie. Für die restlichen Fälle wird auf einfache Lösungen zurückgegriffen, beispielsweise einen Verweis des Kunden an das Callcenter (der ja auch nach der Einführung des neuen Systems funktionieren wird). Im Weiteren verzichtet man zum Beispiel darauf, das neue System sofort perfekt an bestehende Systeme anzuschließen oder gar ganze Prozesse im Unternehmen umzubauen. Stattdessen geht man andere Wege – bis hin zu einer (für den Kunden nicht sichtbaren) Mail in das Callcenter und anschließender Handarbeit.

Ganz Mutige bauen dafür sogar erst einmal einen Prototyp, vielleicht mit PHP statt einer vollausgebauten Java-Anwendung, und schauen, ob die Idee überhaupt zündet – wohlwissend, dass der Protoyp bei Erfolg weggeworfen und durch ein „richtiges“ System ersetzt wird. Ein Ansatz, der sich schon 1995 bei Fred Brooks findet: „Plan to throw one away, you will do anyway.“

Keine Abstriche sollte man an der Qualität des MVPs machen. „Mach es so einfach wie möglich, aber nicht einfacher“ (Albert Einstein): Eigenschaften wie gute Ergonomie, Skalierbarkeit, Fehlertoleranz oder Resilienz – kurz alles, was dafür sorgt, dass im Betrieb keine peinlichen Pannen zu erleben sind, gehören selbstverständlich dazu.

Last, not least: Eine gute Architektur und neue Plattformen wie die Cloud Foundry helfen uns dabei. Sollte die neue Anwendung unerwartet zum Hit werden, kann sie schnell skaliert werden.

Blog moderation guidelines and term of use