Das Minimum Viable Product (MVP) – Zentrierung auf die Nutzenden spart Kosten
Wer mit erdfisch ein agiles Webprojekt entwickelt, hat mit Sicherheit schon den Begriff „MVP“ gehört. Sei es während der Anforderungsfindung, bei der Budgetgestaltung oder im laufenden Projekt – wir wenden den Begriff und auch die Methode MVP mit Leidenschaft an und schätzen deren Vorteile.
Was ist ein MVP?
Das „Minimum Viable Product“ bedeutet übersetzt in etwa so etwas wie die "einfachste nutzbare Form eines Produkts". Übertragen auf unsere Domäne der Webentwicklung ist das so zu verstehen, dass wir uns damit befassen, welche Funktionen das Websystem mindestens beinhalten muss, damit es wenigstens testbar oder sogar schon öffentlich nutzbar ist.
Was sind die Vorteile eines MVP
Die Implementierung eines MVP hat folgende Vorteile:
- Die Entwicklung konzentriert sich zuerst auf die essenziell wichtigsten Bestandteile des Systems. So wird strukturiert und nach Priorität absteigend gearbeitet.
- Es entsteht schon nach einem Teil der Projektlaufzeit eine nutzbare erste Version – bei Produkten wird auch gerne von einer „schnellen Markteinführung“ gesprochen.
- Diese vereinfachte Version des Projekts wird zeitnah getestet und mit Feedback versehen, welches wiederum in den weiteren Entwicklungsprozess einfließt, um das Endergebnis noch besser zu machen. Es entsteht eine Nutzerzentrierung, welche wiederum die Effektivität des Projekts maximiert.
- Einzelne Funktionen des Gesamtprojekts können nach erfolgtem User Feedback auf einen späteren Zeitpunkt verschoben, vereinfacht oder verworfen werden. Dadurch kann sich das benötigte Budget für das Endprodukt verringern.
Wozu brauchen wir ein MVP?
Erinnern wir uns kurz zurück an verschiedene Erfahrungen aus der agilen Projektentwicklung, die erdfisch schon in der Vergangenheit erläutert hatte:
- Normalerweise steht der endgültige Scope nicht vorher bis in jedes Detail fest, sondern wurde gemeinsam grob umrissen und vorkonzeptioniert - im Discovery Workshop
- Der Preis des Projekts kann fest stehen. Wenn ein agiles Projekt vorliegt, muss das Endergebnis an diesen Preis angepasst werden.
- Wenn Funktionen fertig konzeptioniert und schriftlich angeboten wurden, während der Umsetzung aber zuvor unbekannte Anforderungen entstehen, die im Budget keinen Platz mehr haben, kann Scope Creep entstehen. Dies erzeugt unnötige Mehrkosten, die sich mit einem MVP vermeiden lassen.
Würde man also ohne die Einplanung eines MVP „drauf los“ entwickeln und unreflektiert alle Features umsetzen, könnte es schnell passieren, dass man sich in eine von mehreren möglichen Sackgassen bewegt: Entweder das Budget kann nicht den kompletten gewünschten Scope abbilden, weil dieser sich gegenüber den initialen Annahmen vergrößert hat, oder die Nutzenden des Systems können nach der Fertigstellung damit nicht arbeiten, weil ihr Feedback nicht frühzeitig berücksichtigt wurde. Im schlimmsten Fall wurde die Business-Logik nicht zur Genüge abgebildet, sodass die Geschäftsprozesse nicht aufrechterhalten werden können.
Wie nutzen wir das MVP?
Bei passenden agilen Projekten bekommen die MVP-Tickets den höchsten Prioritätslevel und werden zuerst bearbeitet. Sie werden eindeutig abgegrenzt und als feststehendes Set gelistet. So entsteht ein Meilenstein der Projektumsetzung. Einzelne Features können schon zwischendurch teilabgenommen werden.
Das MVP geht nach erfolgten Zwischenabnahmen live oder zumindest in eine testfähige „PreLive“ Umgebung, die öffentlich einsehbar sein kann, aber nicht muss. Eine vom Kunden ausgewählte Testgruppe prüft den Zwischenstand und gibt ausführliches schriftliches Feedback. Insbesondere fehlende oder als überflüssig wahrgenommene Funktionalitäten sind dabei interessant. Währenddessen kann die Entwicklung an den nächsthöheren Funktionen in der Prioritätenliste von erdfisch bereits fortgesetzt werden.
Die Sammlung der Feedbacks gibt Aufschluss darüber, was für Funktionen schmerzlich vermisst werden oder welche möglicherweise auch überhaupt nicht notwendig sind. Daraufhin wird die Priorisierung des Gesamtprojekts erneut überarbeitet, sodass bis zum Abschluss die wichtigsten Features zuerst bedacht werden, welche ein langfristiges user engagement sicherstellen.
Nehmen wir zwei fiktive Beispiele an.
Die Kundinnen A und B möchten jeweils einen neuen Web-Shop entwickeln lassen. Beide Shops haben initial die Features „Hauptnavigation“ und „Suchfunktion“ im Backlog.
Kundin A definiert einen Funktionsumfang, der abgebildet werden soll. Sie lässt sich zu ihrem Budget Festpreisangebote einholen und wählt am Ende den Dienstleister mit dem geringsten Stundensatz. Gemeinsam werden die Anforderungen in Tickets gegossen und es wird losgelegt. Während der Entwicklungsarbeiten und Zwischenabnahmen „scope creept“ Kundin A immer wieder neue Anforderungen in die Tickets. Sie benennt später implizite Anforderungen, die in ihrem Kopf klar gewesen waren, jedoch nie in den Tickets aufgeführt wurden. Beispielsweise ist sie davon überzeugt, dass eine Volltextsuche mit komplexen Sortier- und Filtermöglichkeiten enthalten sein muss. Das Endergebnis ist, dass das Budget nicht ausreicht. Sie muss für einige der Features eine Nachbeauftragung vornehmen und die Deadline für den Launch wird überzogen. Im Betrieb stellt sich heraus, dass die Nutzer:innen des Shops die Sortier- und Filterfunktionen der Suche überhaupt nicht verwenden, weil es dafür nicht genügend Produkte gibt. Gleichzeitig führt die Navigation immer wieder zu Verwirrung. Somit schrumpft der Umsatz, aber die Kosten für die Entwicklung sind gestiegen.
Kundin B wählt den Dienstleister nach dessen Erfahrung und Expertise aus. In der Discovery-Phase werden alle Anforderungen priorisiert und es wird eine MVP-Grenze definiert. Nachdem das MVP fertiggestellt ist, geht es live. Kundin B gewährt ihren Endkund:innen einen Early Adopter Rabatt und bittet im Gegenzug um Feedback. Schon jetzt beginnt der Shop, Umsatz einzuspielen. Durch die Testphase und das Feedback stellt sich heraus, dass eine übersichtlichere und einfachere Navigation von vielen gewünscht wird. Die eingeplanten Sortier- und Filterfunktionen für die Suche hätten dagegen niemandem gefehlt, da das Produktsortiment ohnehin recht übersichtlich ausfällt. Als Ergebnis priorisiert Kundin B die Verbesserung der Navigation höher und entfernt die komplexen Funktionen der Suche aus dem Scope des Gesamtprojekts. Sie erhält einen übersichtlichen und maßgeschneiderten Shop, der die Usability-Bedarfe Ihrer Endkund:innen genau bedient. Gleichzeitig spart sie 25 % des agilen Budgets ein, weil die Suche mit einem aufwändigen Apache Solr Server entfallen ist.
Warum ist Drupal besonders gut geeignet, um ein MVP zu entwickeln?
Drupal ist das quelloffene CMS, auf welches wir erdfische uns spezialisiert haben. Es gilt in der Welt der Webentwicklung als besonders vielfältig, flexibel und erweiterbar. Zusätzlich zum großen Funktionsumfang des „Drupal Core“ kann dieser mit einer riesigen Vielfalt von „Contrib“ Modulen erweitert werden.
Drupal ist daher bestens geeignet, um mit einem beliebigen Funktionsumfang launchen zu können, der später immer grenzenlos erweitert werden kann. Die umsetzende Agentur muss nur die Skalierfähigkeit der Lösungen immer im Blick behalten.
So ist auch die Entwicklung einer frühen MVP-Version eines Web-Projekts mit Drupal problemlos möglich, welche später in jede erdenkliche Richtung ausgebaut werden kann.
Ist ein MVP das Gleiche wie ein Prototyp?
Kurz gesagt: Nein, aber hier besteht Verwechslungsgefahr. Ein Prototyp ist eine große Stufe unter dem MVP. Wir sagen zum Prototyp oft auch „Proof of Concept“ (PoC). Damit ist kein MVP, sondern eine frühe Version einer Funktion oder eines Funktionssets gemeint, die nur zeigen soll, ob der gewählte technische Ansatz funktioniert. Oft wird beim PoC noch komplett ohne Frontend, Styling oder UX-Anpassungen gearbeitet, sondern die pure Funktionalität wird überprüft. Ein MVP dagegen bezeichnet – wie schon beschrieben – eine vollständig nutzbare erste Version des Endprodukts, welche die wesentlichen Geschäftsprozesse abbilden kann.
Fazit
Iterative Entwicklung ist grundsätzlich ein wichtiges Mittel in agilen Projekten. Drupal ist bestens geeignet, um zu beliebiger Zeit jede erdenkliche Erweiterung an einem System vorzunehmen. Dies wird besonders vorteilhaft und budgetschonend eingesetzt, indem man ein Projekt zu Beginn auf den wichtigen Meilenstein des „Minimum Viable Product“ ausrichtet und die daraus gewonnenen Erkenntnisse ins restliche Projekt einfließen lässt.
Auch wenn das MVP nicht im beschriebenen Maß als Teil des Gesamtprojekts umgesetzt werden kann – etwa weil das Budget initial ohnehin nur ein MVP-nahes Projekt ermöglicht – so ist dennoch in jedem Fall eine regelmäßige Besinnung auf die Fragen „Was benötige ich mindestens, damit meine Geschäftsprozesse funktionieren?“ oder auch „Welche Funktionen könnten ‚nice-to-have‘ sein?“ ein probates Mittel, um unnötige Kostenfaktoren auszuklammern.
Henjo Völker
