MVP entwickeln lassen: Warum ein Prototyp oft besser startet als ein Lastenheft

Ein Satz fällt in vielen Projektgesprächen früh: „Wir schreiben erst mal alles auf, dann kann ein Angebot kommen.“ Er klingt vernünftig. Wer ein Haus baut, will schließlich Pläne sehen, bevor der Bagger anrollt. Bei Software trägt der Vergleich nur begrenzt, denn ein Haus lässt sich nach dem Einzug schlecht um ein Stockwerk verschieben, ein Eingabeformular schon eher.

Angenommen, ein Betrieb mit zwanzig Beschäftigten will seine Auftragsverwaltung ablösen. Die Geschäftsführung und zwei Teamleiter schreiben über sechs Wochen ein Lastenheft. Es hat achtzig Seiten, Rollenmodelle, Statusdiagramme und eine Liste mit mehr als hundert Muss-Kriterien. Alle sind stolz darauf, und niemand hat währenddessen mit den Kollegen gesprochen, die am Tresen und am Telefon tatsächlich damit arbeiten werden.

Ein Dokument kann beschreiben, was man sich vorstellt, aber nicht zeigen, ob die Vorstellung im Alltag trägt. Dieser Unterschied wird später teuer, und er hat wiederkehrende Ursachen.

Es gibt dafür wiederkehrende Mechanismen. Der erste: Menschen beschreiben den Sollzustand ihrer Arbeit, nicht den tatsächlichen. Der Zettel am Monitor, die private Excel-Liste, der Anruf bei der Kollegin, die „das immer weiß“, tauchen im Lastenheft nicht auf, weil sie als Umweg gelten. Dabei tragen genau diese Umwege häufig den Betrieb.

Der zweite Mechanismus ist Vollständigkeitsdruck. Ein Dokument dieser Größe soll alles regeln, also wird jeder Sonderfall aufgenommen, der irgendjemandem einfällt. Seltene Fälle erhalten dasselbe Gewicht wie den täglichen Normalfall. Am Ende ist unklar, was wirklich wichtig ist, und ein Angebot muss alles gleich behandeln. Der dritte Mechanismus ist unscheinbarer: Wer ein Feld beschreibt, sieht nicht, wie es sich anfühlt, es zwanzigmal am Tag auszufüllen.

Hinzu kommt die Sprache. Ein Satz wie „Das System soll Aufträge flexibel verwalten“ lässt sich auf zehn Arten umsetzen, und alle zehn sind formal korrekt. Der Streit entsteht erst bei der Abnahme, wenn jede Seite ihre Lesart für die richtige hält. Das Dokument hat dann Rechtswirkung, aber keine Klärungskraft.

Typische Fehlerbilder, die sich daraus ergeben, sehen so aus:

Vor jeder Entscheidung über Vorgehen und Vertrag lohnt eine nüchterne Bestandsaufnahme, was an dem Vorhaben unsicher ist. Technische Machbarkeit ist es bei den meisten betrieblichen Anwendungen selten. Formulare, Listen, Rollen, Benachrichtigungen und Schnittstellen zu gängigen Systemen sind gelöst. Unsicher sind fast immer Annahmen über Menschen und Abläufe: Wird das Team die Software nutzen, und stimmt das Bild vom Prozess?

Diese Frage lässt sich als Kern-Hypothese formulieren, in einem Satz, der falsch sein kann. Etwa: „Wenn Aufträge auf dem Smartphone in unter einer Minute erfasst werden können, hören die Kollegen im Außendienst auf, Zettel zu führen.“ Das ist testbar, und es sagt zugleich, was man nicht bauen muss, um den Test durchzuführen. Rechnungsstellung, Reporting und Rechteverwaltung gehören nicht zum Test.

Aus der Hypothese folgt der kleinste nützliche Umfang. „Nützlich“ ist dabei das entscheidende Wort. Ein Minimum, das niemand im Alltag verwenden kann, liefert keine Erkenntnis, und Nutzer geben ihm nur die Aufmerksamkeit, die sie einem Demo-Termin schenken. Der Kern muss echte Arbeit tragen können, wenn auch nur in einem Ausschnitt: ein Team, ein Auftragstyp, ein Standort.

Hilfreich ist, die Risiken ausdrücklich zu gewichten, bevor Umfang festgelegt wird. Die folgende Darstellung zeigt eine solche Gewichtung für ein gedachtes Vorhaben dieser Art.

Die Alternative zum Lastenheft ist kein Verzicht auf Planung, sondern eine andere Reihenfolge. Zuerst wird die größte Unsicherheit mit dem kleinstmöglichen Aufwand ausgeräumt, danach wird entschieden, was gebaut wird. Das spart nicht automatisch Geld. Es verschiebt Ausgaben von der Annahme zur Erkenntnis, und das ist der eigentliche Gewinn.

Ein Klickprototyp ist dabei die leichteste Stufe. Er besteht aus gestalteten Bildschirmen, die sich verlinken lassen, ohne dass dahinter Logik oder Daten arbeiten. Er eignet sich, um Abläufe, Begriffe und Reihenfolgen zu prüfen, und lässt sich in Tagen statt Wochen erstellen. Er eignet sich nicht, um Belastung, Datenqualität oder Alltagstauglichkeit zu beurteilen, denn niemand arbeitet mit Attrappen so, wie er mit einem echten System arbeiten würde.

Ein lauffähiger MVP geht einen Schritt weiter. Er speichert echte Daten, hat eine Anmeldung und läuft im Alltag, wenn auch mit wenigen Funktionen. Wer einen MVP entwickeln lassen möchte, sollte deshalb von Beginn an klären, ob ein Klickprototyp ausreicht oder ob die Hypothese nur mit Echtbetrieb prüfbar ist. Meist hilft eine Kombination: erst der Prototyp für den Ablauf, dann der MVP für den Dauertest.

Wichtig ist auch die Gegenseite. Ein MVP-Vorgehen ist nicht überall die richtige Wahl. Bei stark regulierten Prozessen, festen Normvorgaben oder Ersatz einer bestehenden Software mit genau definiertem Funktionsumfang kann ein ausführliches Pflichtenheft sinnvoll sein. Auch dann lohnt aber ein kleiner Prototyp für die riskantesten Bildschirme.

Der Zuschnitt beginnt mit einer Beobachtung statt einer Anforderungsliste. Wir würden einen halben Tag im Betrieb verbringen, zwei oder drei Menschen bei der Arbeit begleiten und den Ablauf so notieren, wie er tatsächlich verläuft: mit Unterbrechungen, Rückfragen, Notizzetteln. Daraus entsteht kein Dokument, sondern eine kurze Liste von Momenten, in denen die heutige Lösung scheitert.

Aus diesen Momenten wird der Kern abgeleitet. Als Faustregel dient die Frage, ob ein Ausschnitt für sich allein einen Nutzen stiftet. Ein Auftrag erfassen und einem Mitarbeiter zuweisen kann ein solcher Ausschnitt sein. Ein Auftrag erfassen, aber noch nicht abrechnen, ist es vermutlich auch. Eine Abrechnung ohne Erfassung ist es nicht. So entsteht eine Schnittlinie durch den Prozess, die ein Stück Ende-zu-Ende-Arbeit enthält, statt alle Schichten gleichmäßig ein wenig.

Die Entscheidung, was nicht gebaut wird, gehört gleichwertig dazu. Wir führen deshalb eine kurze „Noch-nicht-Liste“, in der bewusst zurückgestellte Funktionen stehen, jeweils mit dem Grund. So bleibt nachvollziehbar, dass etwas nicht vergessen, sondern verschoben wurde, und die Liste wird später zur Grundlage der Ausbauplanung.

Mehrere Ausbaustufen lassen sich als Schichten darstellen, die aufeinander aufbauen, jede mit eigenem Lernziel.

Ein verbreiteter Einwand lautet, ein MVP sei ein Wegwerfprodukt, das später komplett neu geschrieben werden muss. Das stimmt, wenn man ihn so baut. Es stimmt nicht zwingend. Entscheidend ist, wo gespart wird. Gespart wird bei Umfang, Optik und Sonderfällen, nicht bei Datenmodell, Zugriffsschutz und Nachvollziehbarkeit. Ein sauberes Datenmodell lässt sich ausbauen, ein chaotisches nur ersetzen.

Praktisch setzen wir auf bewährte, verbreitete Bausteine: eine relationale Datenbank, eine Weboberfläche, die auf dem Smartphone und am Rechner läuft, Anmeldung über etablierte Verfahren, regelmäßige Datensicherung. Auf Eigenentwicklungen für Standardprobleme wie Passwortverwaltung oder Versand von E-Mails wird verzichtet. Das senkt nicht nur den Aufwand, sondern macht den Übergang in den späteren Ausbau einfacher, weil andere Entwickler die Bausteine kennen.

Die Arbeit läuft in kurzen Zyklen. Auf eine Vorführung folgt eine Nutzung durch echte Anwender, danach eine Auswertung und die Entscheidung über den nächsten Schnitt. Eine Version geht nach wenigen Wochen in den Alltag, nicht erst nach dem Abschluss aller Funktionen. Zur Nachvollziehbarkeit gehört, dass jede Änderung in einer Versionsverwaltung dokumentiert ist und das Team auf einer Testumgebung ausprobieren kann, bevor etwas live geht.

Zur Absicherung dienen wenige, bewusst gewählte Prüfungen. Die Kernabläufe erhalten automatisierte Tests, damit spätere Änderungen sie nicht unbemerkt beschädigen. Für Daten gilt, was auch für größere Systeme gilt: Sicherungen müssen nicht nur laufen, sondern einmal testweise zurückgespielt worden sein. Alles Weitere, etwa ein ausgefeiltes Rechtekonzept, folgt, wenn der Kern trägt.

Kaum eine Frage wird so emotional geführt wie diese. Der Festpreis verspricht Sicherheit, Zeit und Material verspricht Flexibilität, und beide Versprechen sind nur halb wahr. Ein Festpreis ist belastbar, wenn die Leistung genau beschrieben ist. Je unklarer die Anforderung, desto mehr Puffer rechnet der Anbieter ein, oder desto mehr Streit entsteht später darüber, was „enthalten“ war. Der Festpreis verlagert das Risiko, er beseitigt es nicht.

Zeit und Material ist ehrlicher, wenn das Ziel noch nicht feststeht. Sie zahlen für tatsächlich geleistete Arbeit und behalten die Steuerung. Der Preis dafür ist Disziplin auf Ihrer Seite: Ohne Obergrenze, regelmäßige Zwischenstände und klare Priorisierung kann sich ein Projekt leise ausdehnen. Wer es nutzt, sollte einen Rahmen setzen, etwa ein Budget pro Zyklus mit anschließender Entscheidung über den nächsten.

Als Mittelweg bewährt sich ein gestuftes Modell. Der Test, also Beobachtung, Prototyp und erster MVP, wird als überschaubares Paket mit festem Umfang und festem Preis vereinbart, weil er sich vorab beschreiben lässt. Der Ausbau danach läuft in Zyklen, jeweils mit einer Obergrenze und einer klaren Freigabe. So gibt es an jeder Stelle einen Ausstieg, und die Entscheidung über das große Budget fällt mit Wissen statt mit Hoffnung.

Ehrlich gehört auch dazu, dass dieses Modell Nachteile hat. Die Gesamtkosten stehen am Anfang nicht fest. Wer intern eine feste Summe für die Budgetfreigabe braucht, kann sie als Spanne nennen, die nach dem Test enger wird. Und ein gestuftes Vorgehen setzt voraus, dass Sie Zeit für Rückmeldungen haben. Fehlt sie, hilft auch der beste Vertrag nicht.

Änderungen sind in einem iterativen Projekt der Normalfall, nicht die Störung. Das macht ein Änderungsmanagement nicht überflüssig, sondern notwendig, denn ohne Regeln wird aus Beweglichkeit Beliebigkeit. Bewährt hat sich eine kurze Liste, in der jede Änderung mit Grund, geschätztem Aufwand und Auswirkung auf Termin oder Budget steht, und eine Person auf Ihrer Seite, die Prioritäten entscheidet. Mehrere Entscheider mit unterschiedlichen Wünschen sind das häufigste Risiko in solchen Projekten.

Auch die Abnahme braucht eine andere Form. Statt eines einzelnen Termins am Ende gibt es Abnahmekriterien pro Zyklus, die so formuliert sind, dass man sie beobachten kann. „Die Software ist benutzerfreundlich“ ist keines. „Ein neuer Mitarbeiter erfasst nach zehn Minuten Einweisung einen Auftrag ohne Hilfe“ ist eines. Solche Kriterien lassen sich im Alltag prüfen und verhindern den Streit über Lesarten.

Ein weiterer Sonderfall ist der Datenbestand. Sollen Altdaten übernommen werden, zeigt sich oft erst im Test, wie uneinheitlich sie sind: doppelte Kunden, Freitext statt Auswahl, fehlende Pflichtangaben. Wir empfehlen, Daten früh mit einem kleinen Auszug zu importieren, weil die Bereinigung sonst unterschätzt wird. Gleiches gilt für Schnittstellen zu Fremdsystemen, deren Verhalten erst in der Praxis wirklich bekannt wird.

Schließlich gibt es den Fall, dass die Hypothese sich als falsch erweist. Das ist ein gutes Ergebnis, auch wenn es sich nicht so anfühlt. Man hat mit begrenztem Einsatz erfahren, dass der geplante Weg nicht trägt, und kann umsteuern oder sich gegen das Vorhaben entscheiden. Dafür sollten Sie im Vorfeld festlegen, woran man das erkennt, sonst wird jede Rückmeldung als Bestätigung gelesen.

Ein MVP-Vorgehen verbessert die Entscheidungsgrundlage, nicht automatisch das Ergebnis. Was Sie erwarten dürfen, ist, dass die größten Fehlannahmen früher auffallen, als es bei einem vollständig vorab geplanten Projekt der Fall wäre. Ob das am Ende Geld oder Zeit spart, hängt vom Vorhaben, vom Team und von der Qualität der Zusammenarbeit ab. Prozentzahlen für Einsparungen können wir seriös nicht nennen.

Messen lässt sich der Nutzen an Indikatoren, die nahe am Alltag liegen. Dazu zählen die Zeit für den Kernvorgang gegenüber dem bisherigen Weg, die Zahl der Rückfragen und Korrekturen pro Vorgang, der Anteil der Vorgänge, die tatsächlich im System statt auf Zetteln oder in Tabellen entstehen, sowie die freiwillige Nutzung nach der Einführungsphase. Vor Beginn sollte der heutige Stand grob erhoben werden, sonst fehlt der Vergleich.

Rechnen Sie mit mehreren Wochen Beobachtungszeit, bevor sich Muster zeigen. Die ersten Tage sind von Neugier und Anlaufproblemen geprägt, aussagekräftig wird die Nutzung erst, wenn der Reiz des Neuen vorbei ist. Auch das ist ein Grund, den Test nicht zu kurz anzusetzen. Hilfreich ist zudem, nach der Beobachtungsphase mit den Anwendern zu sprechen, die das System meiden: Ihre Gründe zeigen oft genauer als jede Statistik, welche Annahme nicht getragen hat und ob sie sich durch Anpassung oder nur durch Verzicht beheben lässt.

Nicht garantieren lässt sich, dass der MVP später ohne Umbau zur Gesamtlösung wächst, dass alle Beteiligten die Software annehmen oder dass der Gesamtpreis unter einer bestimmten Marke bleibt. Zugesagt werden kann ein nachvollziehbares Vorgehen, ehrliche Zwischenstände und die Möglichkeit, an definierten Punkten auszusteigen.

Der wichtigste Gedanke ist, dass Klarheit aus Gebrauch entsteht, nicht aus Beschreibung. Das heißt nicht, dass Beschreibungen wertlos wären. Ein knappes Dokument mit Zielbild, Kern-Hypothese, Noch-nicht-Liste und Abnahmekriterien hat sich als Arbeitsgrundlage oft besser bewährt als ein umfassendes Lastenheft, weil es Entscheidungen festhält, ohne Annahmen als Tatsachen auszugeben.

Die zweite Erkenntnis betrifft die Beteiligung. Nutzer früh einzubinden, bedeutet nicht, sie in Workshops zu setzen, sondern ihnen etwas Greifbares zu geben und ihre Reaktion zu beobachten. Schon ein Klickprototyp, den eine Kollegin fünf Minuten lang bedient, liefert oft mehr als ein Tag Anforderungsgespräche. Ebenso wichtig ist, nicht nur die Begeisterten zu fragen, sondern auch die Skeptischen, denn deren Einwände sind meist konkreter und betreffen genau die Stellen, an denen der Alltag das System später auf die Probe stellt.

Drittens sollte jede Entscheidung über Umfang eine begründete Absage enthalten. Ein MVP, der alles ein bisschen kann, ist kein MVP. Wer Funktionen nur hinzufügt und nie streicht, baut ein Lastenheft in Code. Hilfreich ist eine feste Regel: Für jede neue Funktion wird benannt, welche Annahme sie prüft und woran man das erkennt.

Ein Lastenheft ist kein Fehler, aber es ist oft der falsche erste Schritt. Wenn Sie nicht sicher sind, ob das Team eine neue Software annehmen wird und ob das Bild vom Prozess stimmt, ist ein kleiner, nutzbarer Kern die günstigere Art, es herauszufinden. Wer einen MVP entwickeln lassen möchte, kauft vor allem eine belastbare Antwort auf die Frage, was wirklich gebaut werden sollte.

Der nächste Schritt ist überschaubar. Formulieren Sie in einem Satz, was sich im Alltag ändern soll, und notieren Sie, woran Sie es erkennen würden. Ergänzen Sie drei Dinge, die Sie ausdrücklich noch nicht brauchen. Mit dieser halben Seite lässt sich ein Gespräch führen, das mehr leistet als ein langes Dokument. Wir schauen uns das gern mit Ihnen an und sagen klar, ob ein MVP-Vorgehen für Ihr Vorhaben passt oder ob ein klassisches Pflichtenheft die bessere Wahl ist.