Minimum Viable Product im Projektmanagement umsetzen MVP: der agile Tausendsassa!

MVP: der agile Tausendsassa!

Die Entwicklung mittels Minimum Viable Product (MVP) ermöglicht, den Kundennutzen stets im Blick zu behalten und Anforderungen entsprechend umzusetzen. Marcus Funk und Christin Domin zeigen, wie Sie den MVP-Ansatz erfolgreich in Ihrem Projekt anwenden.

Management Summary

Minimum Viable Product im Projektmanagement umsetzen MVP: der agile Tausendsassa!

MVP: der agile Tausendsassa!

Die Entwicklung mittels Minimum Viable Product (MVP) ermöglicht, den Kundennutzen stets im Blick zu behalten und Anforderungen entsprechend umzusetzen. Marcus Funk und Christin Domin zeigen, wie Sie den MVP-Ansatz erfolgreich in Ihrem Projekt anwenden.

Management Summary

Wir empfehlen zum Thema Priorisieren
2 Tage
05.12.2024
545,00,-
Deep Reading - Schneller, klüger und nachhaltiger lesen

In kürzester Zeit anspruchsvolle Fachtexte lesen und verstehen –  steigern Sie in nur zwei Tagen Ihre Lesegeschwindigkeit und Aufnahmefähigkeit! Mehr Infos

Dass Wandel und Fortschritt längst wichtige Schlüsselfaktoren für erfolgreiche Unternehmen geworden sind, ist kein Geheimnis. Auch die Softwareentwicklung macht Unternehmen mit digitalen Produkten zukunfts- und wettbewerbsfähig und muss inzwischen immer höhere Erwartungen erfüllen und einen echten Wert stiften. Um das zu erreichen und qualitativ hochwertige und erfolgreiche digitale Anwendungen zu entwickeln, kommt es auch stark darauf an, wie Unternehmen sich organisieren oder Projekte durchführen. Auch hier fand in den letzten Jahren ein starker Wandel statt.

Legte man vor 10 Jahren noch den größten Wert auf gründliche Vorarbeit und Dokumentation, so treiben uns jetzt die Bedürfnisse der Nutzer und der sich ständig wandelnde Wettbewerb mehr denn je an. Die kontinuierlich wachsende Konkurrenz digitaler Produkte sorgt dafür, dass es längst nicht mehr ausreicht, "was Digitales zu machen". "First Mover" zu sein, ist inzwischen schwer (wenn auch nicht unmöglich). Längst gibt es für vieles eine Alternative, auch immer noch nicht-digitale Substitute. Um heute zu begeistern, müssen digitale Anwendungen genau die Bedürfnisse des Kunden erfüllen und seinen Nerv treffen.

Nutzerzentrierung war seit jeher bei FLYACTS das wichtigste Kriterium bei der App-Entwicklung. Die Antwort auf die Frage, wie wir das erreichen können, fanden wir in der MVP Methode. Die MVP Methodik bietet Unternehmen, Start-ups und Organisationen die Chance, wirklich das zu entwickeln, was gefragt ist, und zwar ohne das Risiko, zu viel Zeit, Geld oder Aufwand in die Entwicklung eines Produktes zu stecken, das im Endeffekt nicht wirklich überzeugt. Je anspruchsvoller die Vision, je komplexer das Produkt und je abstrakter das Ziel, umso wichtiger ist es, die Erfahrung und Meinung des Kunden zu kennen.

Unsere Erfahrung der letzten Jahre mit dem Minimum Viable Product in der Softwareentwicklung hat uns verdeutlicht, dass ein erfolgreicher Einsatz der MVP-Methode mehr erfordert als die Umsetzung der Theorie. Bei der Vorgehensweise nach MVP handelt es sich nicht nur um ein "Anti-Wasserfall-Modell" oder um Prototyping. Es bedarf eines bestimmten Mindsets und einer konkreten Vorgehensweise. Nicht nur die Entwicklungsabteilung, sondern auch das Projektmanagement sollte sich deshalb eingehend mit der MVP Methodik beschäftigen und diese verinnerlichen.

MVP – Was es ist und was es kann

Wenn wir ein Produkt nach der MVP Methodik entwickeln, so versuchen wir stufenweise und datenbasiert zum jeweils nächsten Entwicklungsschritt zu gelangen und uns dem Idealzustand des Anwenders (der Software) bzw. des Kunden anzunähern. Im Gegensatz zur Wasserfallmethode bestimmt bei der MVP Entwicklung nicht das Angebot die Nachfrage. Es entscheidet der Wunsch des Nutzers, was entwickelt wird. Und das muss natürlich zuvor hinsichtlich der Erfolgsaussichten geprüft werden. Das ist möglich, indem wir von Anfang an die Probleme, Wünsche und Vorstellungen des Nutzers berücksichtigen und ihm ein Produkt liefern, das möglichst genau seinen Vorstellungen und Wünschen entspricht. Schritt für Schritt entsteht so aus einem Minimum Viable Product (MVP) das perfekte Produkt: der Kundenliebling. Grundlegend notwendige Produkteigenschaften werden kontinuierlich so erweitert, dass der Kunde am Ende alle seine Wünsche in einem Produkt vereint sieht.

Mit Hilfe der MVP Entwicklung können wir Innovation entwickeln, bei der das Risiko einer Fehlentwicklung so gering wie möglich gehalten wird. Die ständige Rückversicherung beim Kunden und das Nachjustieren der Anforderungen sorgen dafür, dass immer nur das entwickelt wird, was gewünscht und notwendig ist.

Ein weiterer Grund, weshalb die MVP Entwicklung so erfolgversprechend ist, ist die Tatsache, dass wir in kleinen Schritten vorgehen. So lassen sich schnell, ohne zu viel Energie und Zeit in unnütze Arbeit zu stecken, gute Ergebnisse erzielen. Über das Ziel hinaus zu schießen oder – noch schlimmer – es aus den Augen zu verlieren, wird beinahe unmöglich.

Anhand dieser Grafik (s. Bild 1), die auf der MVP Darstellung von Henrik Kniberg basiert, möchten wir veranschaulichen, was MVP im Kern bedeutet, worauf es ankommt und was MVP von der Wasserfallmethode und der Prototypenentwicklung unterscheidet:

Was an der MVP wirklich anders ist - eine nach H. Kniberg adaptierte und angepasste Darstellung
Bild 1: Was an der MVP wirklich anders ist - eine nach H. Kniberg adaptierte und angepasste Darstellung

Das könnte Sie auch interessieren

Alle Kommentare (6)

Guest

Was sie beschreiben ist agile, iterative Produktentwicklung. Dort ist das MVP natürlich auch relevant, aber das ganze als "MVP Methode" zu verkaufen entspricht keiner mir bekannten gängigen Definition von MVP.

MVP als Begriff sowie Sinn und Zweck davon ist mittlerweile eigentlich gut dokumentiert und etabliert. Gleichzeitig gibt es immer wieder Missverständnisse dazu (auch in meiner Unternehmung) . Wenn sie jetzt den Begriff kreativ neu auslegen und sogar noch zu einer vollständigen Methodik befördern, tun Sie der Community keinen Gefallen ;-)

Hallo Herr Matter,
vielen Dank für Ihren Kommentar - natürlich haben Sie Recht, dass die Autor*innen die Theorien von MVP und Scrum und Lean nicht im Reinformat und nach Lehrbuch anwenden.
Aber Projektmanagement ist nun mal Praxis, in der es darum geht, Ergebnisse zu bewirken. Uns Projektmanagern wird da ein großer Gemischtwarenladen an Methoden, Strategien, Vorgehensweisen usw. angeboten. Und da ist es ganz natürlich, dass man sich dessen bedient, was auf die eigene Situation am besten passt. Und dies dann auch wieder auf individuelle Art und Weise kombiniert. Das mag man "Cherry Picking" nennen - aber was soll daran schlecht sein?
Auf diese Weise entstehen neue Erfahrungen und neue Vorgehensweisen, die der Community vorgestellt werden, zur Diskussion, zur Auseinandersetzung, vielleicht auch zur Nachahmung und Weiterentwicklung.
Genau das ist das Ziel und die Vision des projektmagazins: Eine Plattform sein für Erfahrungen aus der Praxis für die Praxis.
Für Sie mag das beschriebene Vorgehen nicht passend oder sinnvoll sein, vielleicht ist es für andere eine wertvolle Anregung?
Und vielleicht wollen auch Sie mit der Community Ihre Erfahrungswerte teilen? Sie stoßen bei uns in der Redaktion auf offene Ohren.
Beste Grüße und viel Erfolg in Ihren Projekten!

Hallo Herr Angermeier

Fair enough, natürlich ist es sinnvoll sich aus den verfügbaren Methoden das herauszupicken / kombinieren was gerade am besten passt. Kein Thema. Wenn sie aber etablierte, normierte Begrifflichkeiten ohne erkennbaren Grund einfach nach eigenem Gutdünken neu definieren, dann stiftet das unnötige Verwirrung bei Projektmitarbeitern und Stakeholdern.

Ich mache ein konkretes Beispiel, das vielleicht auch illustriert wieso mir das wichtig ist: Ich bin hart dafür am kämpfen, dass in meiner Unternehmung ein MVP primär als Learning Vehicle verstanden wird. Wie kann man mit dem geringsten Aufwand herausfinden, ob die aufgestellten Benefit Hypothesen tatsächlich zutreffend sind? Vielleicht ist dafür ein limitierter Produktlaunch nötig, hoffentlich(!) reicht aber auch ein Papier Prototyp den ich ein paar Kunden zeige. Wir machen den MVP um zu lernen, nicht um schon das grosse Geld zu verdienen! Wenn sich zeigt dass wir mit den Hypothesen falsch lagen, dann stoppen wir, no hard feelings. --> Damit steure ich vor allem auch die Erwartungshaltung von Stakeholdern.

So, jetzt habe ich hart dafür gekämpft dass meine Stakeholder vom MVP noch nicht zwingend marktfähige Produkte erwarten und verstehen dass wir "nur" rausfinden wollen ob die Hypothesen korrekt sind. Yay! Jetzt kommen Sie neu ins Unternehmen, starten auch ein Vorhaben und verwenden den Begriff MVP völlig anders, erklären z.B. (Zitat) "Ein MVP ist niemals fertig". WTF? Ich dachte wir betreiben nur minimalen Aufwand um die Benefit Hypothesen zu validieren? Stakeholder und Mitarbeiter sind verwirrt... wo ist da der Mehrwert?

Und mit Verlaub, wenn Sie solche Aussagen in einem Umfeld machen mit einer gewissen Maturität im Agile Beeing & Agile Doing, haben Sie sich von Anfang an selber diskreditiert. MVP ist kein Begriff den jeder selber definieren soll, genauso wie Sie etablierte Begriffe wie Story, Sprint oder Burndown Chart nicht einfach mal neu definieren. Bitte einfach froh sein dass es schon ein etabliertes Verständnis darüber gibt und einfach anwenden, danke ;-)

Profile picture for user Angermeier
Georg
Angermeier
Dr.

Antwort auf von Gast (nicht überprüft)

Hallo Herr Matter,
vielen Dank für Ihr mit viel Herzblut vorgetragenes Plädoyer und für die kurze Beschreibung Ihrer Anwendung des MVP-Konzepts.
Sie stellen wunderbar dar, wie Sie in Ihrem Umfeld eine passende, nutzenstiftende und rundum sinnvolle Interpretation von "Minimum Viable Product" entwickelten und erfolgreich einsetzen. Das ist doch wunderbar!
Wieso sollten andere Unternehmen nicht auch zu ihrer eigenen, passenden Interpretation finden dürfen, diese verwenden und dann zum Nutzen aller darüber berichten?
In einem Punkt muss ich Ihnen nämlich ganz einfach widersprechen: "Miniumum Viable Product" ist weder genormt noch herrscht ein einheitliches Verständnis dafür. Wenn wir zu Eric Ries zurückgehen, versteht er im Kernprozess "Build-Measure-Learn" von Lean Startup unter dem MVP schon ein wenig mehr als nur ein Mockup. Und eine einfache Recherche nach den "Definitionen" oder besser Interpretationen von MVP im Internet liefert doch eine erfrischende Bandbreite.
Als Kritik am obigen Beitrag könnte man vorbringen, dass das vorgestellte Konzept sich eher an einem "Minimum Marketable Product" orientiert. Das wäre eine Anregung an die Autor*innen, ihr Konzept zu überdenken und weiterzuentwickeln, was sie ganz sicher ohnehin beständig tun.
Die Einladung steht selbstverständlich: Gerne publizieren wir auch Ihre Erfahrungen, Best Practices und Ideen.
Ich freue mich darauf, von Ihnen zu hören.
Beste Grüße und viel Erfolg in Ihren Projekten!

Frank
Forsten

Mal abgesehen davon, daß hier wieder das typische MVP-Bildchen vom Roller zum Hubschrauber gezeigt wird, welches keiner Diskussion standhält, findet sich als Beispiel eine App mit einfachen Funktionen. Wo bleiben mal Beispiele für Transaktionssystem (ERP) oder Projekte mit Schnittstellen zwischen verschiedenen Anwendungen?

Lieber Herr Forsten,
vielen Dank für Ihren Kommentar! Natürlich haben Sie recht, dass hier nur einfache Beispiele stehen.
So ist das eben mit einem MVP = Minimum Viable Product.
ERPs sind keine neuen Produkte auf dem Markt, sondern überaus weit entwickelte Produkte, bei denen es gar keinen Sinn hat, mit einem "Tretroller" zu starten.
Für komplexe Produktentwicklungen gibt es entsprechend aufwendigere Vorgehensweisen, beispielhaft möchte ich hier auf den Mehrteiler zum Thema Requirements Engineering verweisen:
https://www.projektmagazin.de/artikel/requirements-engineering-fuer-pro…
Projektmanagement ist eben äußerst vielfältig und nicht jedes Werkzeug ist für jede Aufgabe geeignet.
Haben Sie Erfahrungen mit entsprechenden Methoden und Werkzeugen? Wir freuen uns sehr auf einen Vorschlag für einen Beitrag von Ihnen!
Viel Erfolg in Ihren Projekten,
Georg Angermeier