Das MVP richtig zuschneiden

„Minimum Viable Product" ist einer der am häufigsten missverstandenen Begriffe in der Produktentwicklung. In der Praxis bedeutet er meistens: dasselbe Produkt, nur mit weniger Sorgfalt gebaut. Das ist fast das Gegenteil dessen, was gemeint war.

Ein gutes MVP ist nicht eine schlechtere Version des ganzen Produkts. Es ist ein kleinerer Ausschnitt in voller Qualität. Der Unterschied klingt akademisch und entscheidet darüber, ob aus Version eins etwas wachsen kann oder ob sie in achtzehn Monaten weggeworfen wird.

Der Schnitt läuft entlang der Nutzer, nicht der Funktionen

Die übliche Herangehensweise: Man nimmt die Funktionsliste und streicht die Hälfte. Das Ergebnis ist ein Produkt, das für niemanden vollständig funktioniert. Jeder Nutzer stößt irgendwo an eine Lücke.

Der bessere Schnitt verläuft quer dazu: Eine Nutzergruppe, ein Ablauf, vollständig.

Bei einer Kita-App hieße das nicht: Nachrichten ja, Krankmeldung ja, Essensanmeldung nein, Kalender halb. Sondern: Eltern können ihr Kind krankmelden, und zwar vollständig – mit Bestätigung, mit Sichtbarkeit im Gruppenbuch, mit automatischer Abbestellung des Essens. Das ist ein Ablauf, der von Anfang bis Ende funktioniert. Wenn er funktioniert, hat die Einrichtung einen echten Nutzen und ist bereit, den Rest abzuwarten.

Eine halbe Essensanmeldung dagegen hilft niemandem und erzeugt Misstrauen gegen alles, was danach kommt.

Die Prüffrage lautet also nicht „welche Funktionen sind wichtig?", sondern: „Welcher einzelne Ablauf, wenn er morgen funktionierte, würde den Alltag spürbar verbessern?"

Was fast immer in Version eins gehört

Es gibt einen Sockel, der sich nicht sinnvoll verschieben lässt – nicht weil er beeindruckt, sondern weil er sich später nur mit Umbau nachrüsten lässt:

• Anmeldung und Rechteprüfung, auch wenn es zu Beginn nur zwei Rollen gibt. Die Prüfung muss an einer Stelle liegen.
• Mandantentrennung bei allem, was mehrere Organisationen nutzen werden. Nachträglich einzuziehen bedeutet, jede Abfrage anzufassen.
• Ein tragfähiges Datenmodell für den abgebildeten Ausschnitt. Nicht für alles, was kommen könnte – aber sauber für das, was da ist.
• Sicherungen, die zurückgespielt wurden. Ab dem ersten echten Nutzer sind die Daten nicht mehr ersetzbar.
• Ein Weg, Neues auszuliefern, der reproduzierbar ist.

Das ist der Teil, der Kunden schwer zu vermitteln ist, weil er in keinem Bildschirmfoto auftaucht. Er macht trotzdem zwanzig bis dreißig Prozent des Aufwands aus. Wer ihn streicht, spart nicht – er verschiebt die Kosten und erhöht sie dabei.

Was gut warten kann

Umgekehrt gibt es viel, das sich problemlos später ergänzen lässt, weil es an der Oberfläche sitzt und nicht am Fundament:

• Auswertungen und Statistiken. Solange die Ereignisse sauber gespeichert werden, lässt sich jede Auswertung nachträglich bauen. Der übliche Fehler ist nicht, sie wegzulassen, sondern die Daten nicht zu erfassen, aus denen sie später entstehen.
• Feineinstellungen. Individuelle Benachrichtigungszeiten, eigene Farbschemata, konfigurierbare Ansichten. Fast immer weniger wichtig, als im Workshop behauptet.
• Weitere Nutzergruppen. Wenn Rechte sauber abstrahiert sind, ist eine neue Rolle eine überschaubare Ergänzung.
• Zweite Plattform. Erst eine App, die funktioniert, dann die andere.
• Schnittstellen zu Drittsystemen. Fast immer aufwendiger als gedacht und selten am Anfang nötig. Ein Export als Datei überbrückt erstaunlich lange.
• Mehrsprachigkeit. Aber: Wenn sie absehbar kommt, sollte man Texte von Anfang an nicht fest im Code verdrahten. Das kostet zu Beginn Stunden statt später Wochen.

Die letzte Klammer ist das Muster hinter dem ganzen Abschnitt: Nicht alles bauen, aber nichts verbauen.

Abkürzungen: welche vertretbar sind

Unter Zeitdruck werden Abkürzungen genommen. Manche sind vernünftig, andere erzeugen Schulden, die mit Zinsen zurückgezahlt werden.

Vertretbar:

• Eine einfache Oberfläche ohne ausgefeilte Übergänge
• Konfiguration in der Datenbank statt in einer Verwaltungsoberfläche – solange jemand sie ändern kann
• Manuelle Vorgänge, die später automatisiert werden, etwa das Anlegen neuer Organisationen von Hand
• Tests nur an den kritischen Stellen statt überall
• Ein Bericht als einfacher Datei-Export statt als Auswertungsansicht

Nicht vertretbar:

• Rechteprüfung in der Oberfläche statt im Server. Das ist keine Abkürzung, das ist eine Sicherheitslücke.
• Fehlende Mandantentrennung. Der Umbau betrifft später alles.
• Keine Sicherungen. Braucht keine Begründung.
• Passwörter oder Zugangsdaten im Code. Landet im Repository und ist dort dauerhaft.
• Ein Datenmodell, das den fachlichen Kern falsch abbildet. Alles andere lässt sich umschreiben, gewachsene Daten nicht.

Die Trennlinie verläuft dort, wo eine Entscheidung später nur durch Migration von Daten oder durch Anfassen aller Stellen korrigierbar ist. Was sich lokal ändern lässt, darf provisorisch sein.

Der Zuschnitt in der Praxis

So gehen wir im Erstgespräch vor:

Schritt 1: Den Ablauf benennen. Nicht Funktionen sammeln, sondern den einen Ablauf finden, der den größten Schmerz löst. Meist gibt es zwei oder drei Kandidaten. Die Frage, die entscheidet: Welcher davon wird am häufigsten durchlaufen?

Schritt 2: Die Nutzergruppen begrenzen. Wer muss ihn ab Tag eins durchlaufen können? Oft reichen zwei Gruppen, wo anfangs fünf genannt wurden.

Schritt 3: Sonderfälle sammeln und vertagen. Jeder Sonderfall wird notiert, keiner wird gebaut, bis der Hauptweg steht. Diese Liste ist zugleich die Grundlage für Version zwei.

Schritt 4: Den Sockel dazurechnen. Anmeldung, Rechte, Mandanten, Sicherungen, Auslieferung. Dieser Teil steht nicht zur Diskussion.

Schritt 5: Gegenrechnen. Passt das in den Rahmen? Wenn nicht, wird der Ablauf kleiner geschnitten – nicht der Sockel.

Der fünfte Schritt ist der, an dem es unangenehm wird. Er ist auch der wichtigste.

Woran man ein zu großes MVP erkennt

Drei Warnzeichen, die zuverlässig sind:

Die Funktionsliste hat mehr als zehn Punkte. Dann ist es kein MVP, sondern Version 1.0 mit anderem Namen.

Es gibt mehr als drei Nutzergruppen. Jede zusätzliche Gruppe bedeutet eigene Ansichten, eigene Rechte, eigene Testfälle.

Der Zeitplan liegt über vier Monaten. Nicht weil länger unmöglich wäre, sondern weil sich in vier Monaten die Annahmen ändern. Was nach acht Monaten fertig wird, ist gegen Anforderungen gebaut, die es so nicht mehr gibt.

Nach dem Launch

Der wertvollste Moment im ganzen Projekt ist die erste Woche mit echten Nutzern. Was dann passiert, kann kein Workshop vorwegnehmen.

Regelmäßig stellen sich zwei Dinge heraus: Eine Funktion, um die lange gerungen wurde, wird kaum benutzt. Und eine Kleinigkeit, die niemand erwähnt hatte, stellt sich als das eigentliche Hindernis heraus.

Deshalb gehört nach dem Launch eine Phase eingeplant, in der nachgebessert wird – bei uns etwa vier Wochen. Nicht für neue Funktionen, sondern für die Reibungspunkte, die erst im Alltag sichtbar werden. Wer direkt in Version zwei springt, baut auf einem Fundament weiter, dessen Schwächen er noch nicht kennt.

Warum sich der enge Schnitt doppelt lohnt

Ein kleineres MVP ist nicht nur billiger in der Entwicklung. Es ist dauerhaft billiger.

Jede Funktion, die existiert, will gepflegt werden: bei jeder Aktualisierung von Abhängigkeiten, bei jedem Systemwechsel, bei jedem Umbau. Wer zwanzig Funktionen baut, von denen sieben kaum genutzt werden, zahlt fünf Jahre lang für zwanzig.

Das ist das stärkste Argument für den engen Schnitt, und es kommt in den seltensten Angebotsgesprächen vor: Nicht gebaute Funktionen verursachen keine Folgekosten.

Der Rest lässt sich nachbauen – wenn sich herausstellt, dass er gebraucht wird. In der Praxis stellt sich das bei etwa der Hälfte der ursprünglich gewünschten Funktionen nie heraus.

Prototyp, MVP und Pilot sind drei verschiedene Dinge

Die drei Begriffe werden durcheinandergeworfen, und daraus entstehen falsche Erwartungen.

Ein Prototyp beantwortet eine Frage. Ist dieser Ablauf verständlich? Lässt sich diese Schnittstelle überhaupt anbinden? Er wird gebaut, um etwas herauszufinden, und danach weggeworfen. Ein Prototyp braucht keine Sicherungen, keine Rechteprüfung und keine saubere Struktur – er darf ein Wegwerfprodukt sein, und genau das macht ihn schnell und billig.

Der Fehler passiert, wenn ein Prototyp in Produktion geht, weil er ja schon läuft. Dann trägt man alle Abkürzungen jahrelang mit.

Ein MVP ist die erste echte Version. Es geht an reale Nutzer mit realen Daten. Es braucht den Sockel. Es wird nicht weggeworfen, sondern erweitert.

Ein Pilot ist ein MVP im Einsatz bei einem ausgewählten Kunden, mit der ausdrücklichen Abrede, dass gemeinsam nachgeschärft wird. Der Unterschied zum MVP ist nicht technisch, sondern vertraglich: Beide Seiten wissen, dass noch nicht alles rund ist, und der Preis spiegelt das.

Vor dem ersten Gespräch sollten Sie wissen, welches der drei Sie eigentlich brauchen. Ein Prototyp für 5.000 € und ein MVP für 35.000 € sind keine Alternativen zum selben Ziel – es sind Antworten auf verschiedene Fragen.

Messen statt raten

Ein MVP ist kein Selbstzweck. Es soll eine Annahme prüfen. Diese Annahme sollte vor dem Bauen aufgeschrieben werden, sonst ist hinterher nicht entscheidbar, ob es funktioniert hat.

Gute Annahmen sind konkret und widerlegbar. „Die Software wird gut ankommen" ist keine. „Mindestens zwei Drittel der Betreuungskräfte erfassen ihre Zeiten nach vier Wochen in der App statt auf Papier" ist eine.

Damit einher geht eine kleine technische Vorkehrung: Man muss messen können. Dafür braucht es keine Analysewerkzeuge von Drittanbietern – es reicht, die fachlichen Ereignisse ohnehin zu speichern, die man später auszählen will. Wer Ereignisse speichert, kann jede Auswertung nachträglich bauen. Wer nur Zustände speichert, kann es nicht.

Drei bis fünf solcher Kennzahlen genügen. Mehr werden nicht angeschaut.

Festpreis und MVP passen gut zusammen

Ein verbreitetes Missverständnis lautet, ein MVP sei zu unklar für einen Festpreis. Das Gegenteil stimmt: Gerade weil der Umfang klein und scharf geschnitten ist, lässt er sich verlässlich kalkulieren.

Voraussetzung ist eine Leistungsbeschreibung, die auch sagt, was nicht dabei ist. Der Abschnitt mit den ausgeschlossenen Punkten ist der wertvollste im ganzen Dokument – er verhindert, dass aus „das ist doch selbstverständlich dabei" ein Streit wird.

Dazu gehört ein geregeltes Verfahren für Änderungswünsche: schriftlich festhalten, mit Aufwand und Terminwirkung bewerten, erst nach Freigabe umsetzen. Das klingt bürokratisch und ist das Gegenteil davon – es macht Änderungen möglich, ohne dass jemand das Gefühl hat, übervorteilt zu werden.

Ohne dieses Verfahren endet jedes Festpreisprojekt an derselben Stelle: bei der Frage, ob eine Anforderung schon im Angebot enthalten war.

Der häufigste Einwand

„Wenn wir so wenig bauen, versteht der Kunde den Nutzen nicht."

Dieser Einwand kommt oft, und er verwechselt zwei Dinge. Ein MVP muss nicht wenig können. Es muss wenig umfassen und das, was es umfasst, vollständig können.

Ein Ablauf, der von Anfang bis Ende funktioniert, überzeugt jeden. Fünf Abläufe, die alle irgendwo abbrechen, überzeugen niemanden – und erzeugen zusätzlich den Eindruck, dass die Software unfertig ist.

Wenn Sie vor der Wahl stehen, ist die Frage also nicht, wie viel Sie zeigen können. Es ist die Frage, welchen einzelnen Vorgang Sie so gut machen können, dass niemand mehr zurückwill.

Die Kurzfassung

Ein MVP ist ein kleinerer Ausschnitt in voller Qualität, nicht dasselbe Produkt mit weniger Sorgfalt. Der Schnitt verläuft entlang eines Ablaufs, nicht entlang einer Funktionsliste. Der unsichtbare Sockel – Anmeldung, Rechte, Mandanten, Sicherungen, Auslieferung – steht nicht zur Disposition, auch wenn er zwanzig bis dreißig Prozent des Aufwands ausmacht.

Und die Zahl, die das Ganze zusammenhält: Was Sie nicht bauen, kostet Sie fünf Jahre lang keine Wartung.