Hias Wrba: Möglichkeiten statt Probleme

Mathias „Hias“ Wrba hat am 2. Tag der Modern RE in München eine Keynote zum Thema MVP – Minimum Viable Product – gehalten.

Die Keynote war sehr unterhaltsam, und ich habe einiges mitgenommen. Allerdings hatte der für mich wichtigste Punkt nichts mit MVP zu tun. Statt dessen machte er einen inspirierenden Vorschlag, nämlich bei Anforderungen weniger über Probleme und mehr über Möglichkeiten nachzudenken.

Was ist ein MVP?

Von dem „Problem“ des MVP hatte ich schon mal gehört. Es führt oft zur Verwirrung, dass es widersprüchliche Definitionen von MVP gibt. Eine Definition stammt von Frank Robinsion aus dem Jahre 2008. Demnach ist ein MVP:

MVP: Ein Produkt, dass so klein wie möglich ist aber groß genug, um Einsatz, Kundenzufriedenheit und Verkauf zu erzeugen (Frank Robinson)

Mit anderen Worten, ein MVP maximiert das Verhältnis von ROI und Risiko.

Dem Gegenüber steht die Definition von Eric Ries (Lean Startup):

MVP: So viele validierte Erkenntnisse wie möglich sammeln (Eric Ries)

Zu fragen wer recht hat ist müßig – es ist eine Frage der Definition. Aber daher ist es wichtig, dass alle im Team das selbe Verständnis von dem haben, was mit MVP gemeint ist. Ich war bisher ein Anhänger der ersten Definition und habe die zweite Prototyp genannt. Aber wie gesagt, wichtig ist ein gemeinsames Verständnis.

Ein sinnvoller Rat von Henrik Kniberg ist daher auch, den Begriff MVP am Besten zu vermeiden.

Building to earn vs. Building to learn

Drei Faustregeln

Wir brauchen MVPs, um in diesen Zeiten des schnellen Wandels, der Unsicherheiten, Komplexität und Unklarheit den Überblick zu behalten. Dazu hat uns Hias drei Faustregeln mit auf den Weg gegeben:

Da heute so viele Unsicherheiten herrschen, muss einerseits ein grobes Ziel im Auge behalten werden, dabei aber in kleinen Schritten entwickelt werden, mit häufigen Justierungen, bspw. durch Demos. Nicht weiter revolutionär, das ist ja die Idee hinter Agilität.

Auch dies ist nicht weiter Revolutionär: Der Ergebnis für den Nutzer sollte die Entwicklung treiben, nicht die Technologie oder die Wirtschaftlichkeit. Der Hintergrund ist, dass sich für etwas Nützliches sicher ein passendes Geschäftsmodell finden lässt, das dann auch die technische Umsetzung ermöglicht.

Diese Regel überraschte mich, und war – zumindest für mich – das Wertvollste aus der Keynote.

Es wird ja im Requirements Engineering immer gesagt, Problem und Lösung sollen sorgfältig voneinander getrennt werden. Das stimmt auch, doch ist das Problem wirklich ein Problem?

Als Beispiel führte er das „Problem“ der Energieknappheit an. Eine Lösung ist es, mehr Energie zu produzieren. Doch vielleicht ist das Problem gar keines, wenn bspw. der Energiebedarf gesenkt werden könnte.

Hier könnte man nun argumentieren, dass wir lediglich zwei mögliche Lösungen betrachten (Energie produzieren oder Verbrauch senken), und damit auch wieder in der klassischen Anforderungsanalyse stecken. Dennoch gefällt mir der Begriff „Möglichkeit“ wesentlich besser als „Problem“. Dieser Ansatz stammt übrigens vom Designer Host Rittel.

Fazit

Hias hat insbesondere durch seinen unterhaltsamen Stil eine kurzweilige Keynote gehalten. Das Gesagte war nicht wirklich neu, aber sicherlich ist es nicht verkehrt, sich diese Dinge wieder in Erinnerung zu rufen.