MVP – Minimum Viable Product – ist eines dieser Wörter, die in jedem zweiten Angebot stehen und in jedem Projekt etwas anderes bedeuten. Für die einen ist es ein Klickdummy, für die anderen ein halb fertiges Produkt, für das man sich entschuldigen muss. Wir meinen etwas Drittes: eine bewusst kleine, aber ordentlich gebaute erste Version, die eine echte Aufgabe im Betrieb übernimmt. So verstanden ist der MVP-Ansatz der beste Weg, mit begrenztem Budget zu Individualsoftware zu kommen – wenn man an den richtigen Stellen kürzt.

Klein im Umfang, nicht in der Qualität

Die wichtigste Unterscheidung zuerst: Ein MVP spart am Funktionsumfang, nicht an der Substanz. Eine Anwendung mit drei Funktionen, die zuverlässig laufen, sauber gebaut sind und erweitert werden können, ist ein MVP. Eine Anwendung mit zehn Funktionen, die wackeln, ist ein Prototyp – und Prototypen haben die unangenehme Eigenschaft, in Produktion zu gehen und dort jahrelang zu bleiben.

Der Unterschied zeigt sich nicht am ersten Tag, sondern beim ersten Ausbau. Wer auf einem soliden Fundament weiterbaut, zahlt für Version zwei den normalen Preis. Wer auf einem Prototyp weiterbaut, zahlt zuerst für das Aufräumen und dann für Version zwei.

Den Kern finden: eine Aufgabe, ein Nutzerkreis

Ein tragfähiger MVP beantwortet eine einzige Frage: Welcher Ablauf tut heute am meisten weh? Das kann die Einsatzplanung sein, die in einer überforderten Excel-Datei lebt, die Auftragserfassung, die dreimal abgetippt wird, oder das Berichtswesen, das jeden Monat zwei Tage frisst.

Genau diesen einen Ablauf bildet die erste Version ab – vollständig, für die Leute, die täglich damit arbeiten. Alles, was daneben liegt, bleibt vorerst draußen. Das klingt banal, ist aber der Punkt, an dem die meisten Budgets kippen: aus „ein Werkzeug für die Disposition“ wird im Gespräch schnell „und die Buchhaltung bräuchte auch noch“, und drei Wünsche später kostet das Projekt das Dreifache. Dass wachsender Umfang kein Kleinbetriebsproblem ist, zeigt eine Studie von McKinsey und der Universität Oxford (2012) über 5.400 große IT-Projekte: Sie lagen im Schnitt 45 Prozent über dem Budget und lieferten 56 Prozent weniger Nutzen als geplant.

Was in Version 1 nicht hineingehört

Dass großzügig mitbestellte Funktionen später brachliegen, ist keine Vermutung: Standish-Group-Chairman Jim Johnson zeigte auf der XP-Konferenz 2002 Auswertungen von vier internen Unternehmensanwendungen, in denen 64 Prozent der Funktionen selten oder nie genutzt wurden. Vier Anwendungen sind eine kleine Stichprobe, aber die Richtung deckt sich mit dem, was wir beim Aufräumen gewachsener Systeme vorfinden. Ein paar Kandidaten, die fast immer warten können – und in der ersten Version mehr kosten als nützen:

Ausgefeilte Rollen und Rechte: Am Anfang reicht oft die Unterscheidung zwischen zwei, drei Nutzergruppen. Ein feingranulares Berechtigungskonzept lässt sich nachrüsten.
Dashboards und Auswertungen: Nach drei Monaten echten Daten weiß man, welche Auswertungen tatsächlich gebraucht werden. Vorher wird geraten.
Anbindungen an jedes Nachbarsystem: Die eine Schnittstelle, die tägliches Abtippen erspart, gehört hinein. Die drei anderen, die „irgendwann praktisch wären“, nicht.
Sonderfälle, die zweimal im Jahr vorkommen: Für die darf es am Anfang einen manuellen Weg geben.

Wo Kürzen verboten ist

Drei Dinge lassen sich später nur teuer korrigieren, deshalb gehören sie auch in die kleinste erste Version: ein durchdachtes Datenmodell, denn die Struktur der Daten überlebt jede Oberfläche und jede Umbauwelle; eine ordentliche Zugangs- und Sicherheitslösung, denn „Login bauen wir später richtig“ rächt sich zuverlässig; und die Eigentumsfrage, also Code, der Ihnen gehört, mit Dokumentation, sodass Sie den Dienstleister wechseln könnten.

Automatisierte Tests für die Kernlogik gehören ebenfalls dazu: Sie sorgen dafür, dass Version zwei nicht kaputt macht, was Version eins konnte. Wer hier spart, spart am Fundament des Hauses, um am Vorhang zu investieren.

Was „kleines Budget“ konkret heißt

Eine ehrliche Hausnummer: Eine fokussierte erste Version – ein Kernablauf, wenige Nutzergruppen, eine Anbindung, sauber gebaut – liegt bei uns typischerweise im Bereich von 10.000 bis 25.000 Euro und ist in vier bis zehn Wochen produktiv. Deutlich darunter wird es schwierig, die eben genannten Fundamente ernst zu nehmen; deutlich darüber ist es meist kein MVP mehr, sondern ein Projekt, das sich als MVP verkleidet hat.

Wichtig ist die Kostenkontrolle über den Start hinaus: Vereinbaren Sie vorab, was passiert, wenn unterwegs neue Wünsche auftauchen. Bei uns läuft das über eine Festpreis-Option, bei der Änderungen transparent bepreist werden, bevor sie umgesetzt werden – so bleibt der MVP klein, weil jede Erweiterung eine bewusste Entscheidung ist statt eines schleichenden Anbaus.

Nach dem Start: erst beobachten, dann ausbauen

Die ersten Wochen im echten Betrieb sind wertvoller als jedes Konzeptpapier. Jetzt zeigt sich, welche Funktion täglich benutzt wird, wo die Leute hängen bleiben und welcher der zurückgestellten Wünsche wirklich fehlt – und welcher still verschwindet, weil ihn niemand vermisst.

Der Ausbau folgt dann der Nutzung, nicht der ursprünglichen Wunschliste. Das ist der eigentliche Gewinn des MVP-Ansatzes: Sie geben das größere Geld erst aus, wenn die Anwendung bewiesen hat, dass sie trägt, und Sie wissen dann deutlich genauer, wofür.