MVP-Entwicklung: die kleinste Version, die eine Annahme prüft

Die MVP-Entwicklung baut die kleinste lauffähige Version eines Produkts, mit der sich eine zentrale Annahme an echten Nutzern prüfen lässt. Eine Kernfunktion, ein Nutzerkreis, ein messbares Kriterium, danach eine Entscheidung: ausbauen, umbauen oder einstellen. Für etablierte Unternehmen ist das ein Werkzeug gegen teure Fehlentscheidungen.

MVP-Entwicklung: was ein MVP ist und was nicht

Minimum Viable Product bedeutet: gerade genug, um im Betrieb zu bestehen. Der Begriff stammt aus der Gründerszene, taugt aber ebenso für ein Kundenportal, ein internes Werkzeug oder eine erste Automatisierung im Mittelstand. Der Zweck ist Erkenntnis, nicht Vollständigkeit.

Abzugrenzen ist das MVP von zwei Nachbarn. Ein Klickmodell zeigt eine Idee und verschwindet danach in der Ablage; ein MVP läuft mit echten Daten und echten Nutzern. Und eine abgespeckte Fassung mit halb fertigen Funktionen ist ebenfalls kein MVP: Die eine Funktion, die vorhanden ist, muss verlässlich arbeiten, sonst misst man Fehler statt Nachfrage.

Den Umfang festlegen: Kernfunktion statt Wunschliste

Die schwierige Arbeit liegt vor der ersten Codezeile und besteht im Streichen. Vier Schritte haben sich bewährt:

1. Die Annahme in einem Satz. Zum Beispiel: Der Außendienst erfasst Aufträge mobil, wenn das schneller geht als auf Papier. Prüfbar formuliert, nicht als Ziel.
2. Den Nutzerkreis eingrenzen. Ein Standort, ein Team, eine Kundengruppe – die Gruppe, die das Problem am stärksten spürt.
3. Den kürzesten Weg zum Nutzen zeichnen. Welche Schritte muss jemand gehen, damit die Annahme geprüft ist? Alles daneben kommt auf die Liste für später.
4. Handarbeit zulassen. Seltene Fälle darf am Anfang ein Mensch erledigen; eine Stornierung per E-Mail ersetzt vorerst die Stornofunktion.

Ein guter Test: Passt die Beschreibung auf eine Seite? Wenn nicht, ist der Umfang zu groß. Wie eine vollständige Beschreibung aufgebaut wird, zeigt Lastenheft und Pflichtenheft; für diesen Fall genügt die Kurzform.

Ablauf einer MVP-Entwicklung in vier Etappen

• Umfang und Kriterium. Annahme, Nutzerkreis, Erfolgsmaß und eine ausdrückliche Liste dessen, was bewusst fehlt.
• Architektur in Grundzügen. Datenmodell, Zugänge zu bestehenden Systemen, Betriebsumgebung – nur so viel, wie der erste durchgehende Pfad braucht.
• Umsetzung in kurzen Runden. Nach jeder Runde ein lauffähiger Stand, den der Fachbereich anfassen kann.
• Pilotbetrieb und Auswertung. Einführung bei der Pilotgruppe mit einem festen Rückkanal, danach Abgleich mit dem Erfolgsmaß und Entscheidung.

Vertraglich passt dazu ein Vorhaben mit klar beschriebenem Ergebnis je Etappe; welches Abrechnungsmodell dazugehört, behandelt Festpreis oder Tagessatz.

Technische Entscheidungen, die später zählen

Minimal bezieht sich auf den Funktionsumfang, nicht auf die Qualität des Fundaments. Drei Weichen lassen sich später nur teuer stellen:

• Datenmodell. Tabellen und Beziehungen folgen den Fachbegriffen, nicht der ersten Bildschirmmaske. Ein sauberes Modell überlebt jede Oberfläche.
• Zugänge zu Nachbarsystemen. Daten aus Shop, CRM oder Warenwirtschaft werden über definierte Schnittstellen gelesen statt über Exporte, siehe API-Integration.
• Betriebsfähigkeit. Versionsverwaltung, automatische Auslieferung, Protokollierung und Sicherungen kosten am Anfang wenig und entscheiden darüber, ob das Ergebnis nach einem Erfolg wachsen kann.

Bewusst später kommen: Feinschliff der Oberfläche, ausgefeilte Rollenmodelle, Mehrsprachigkeit, Auswertungen. Wer hier früh investiert, bezahlt Funktionen, die nach der Auswertung womöglich niemand braucht.

Wie man den Erfolg misst

Das Erfolgsmaß steht vor dem Start fest. Brauchbare Maße beobachten Verhalten: Wie viele Pilotnutzer nutzen die Funktion nach der ersten Zeit weiter, wie lange dauert ein Vorgang jetzt, wie viele Vorgänge laufen ohne Handarbeit durch. Zufriedenheitsumfragen ergänzen das, ersetzen es aber nicht – Zustimmung im Gespräch und Nutzung im Alltag fallen häufig auseinander.

Ebenso wichtig ist die Konsequenz: Ohne vorher vereinbarte Folge – bei welchem Ergebnis wird ausgebaut, bei welchem eingestellt – wird aus dem Versuch eine Dauerbaustelle.

Typische Fehler

• Aufblähen. Jede Abteilung ergänzt eine Funktion, aus dem Versuch wird ein Großprojekt ohne Lernphase.
• Fundament sparen. Ohne Tests und Struktur entsteht ein Wegwerfstück, das trotzdem weiterbetrieben wird – der Anfang technischer Schulden.
• Kein echter Betrieb. Was nur in Vorführungen läuft, prüft nichts.
• Keine Entscheidung. Die Auswertung liegt vor, aber niemand zieht die Folgerung.

Wir setzen solche Vorhaben als erste Etappe eines größeren Aufbaus um: mit eigenem Liefergegenstand, eigenen Abnahmekriterien und einer Auswertung, die zur Entscheidung führt. Was dazugehört, steht auf der Seite App-Entwicklung.