Der Satz “Wir bräuchten erst mal nur ein MVP” fällt in vielen Erstgesprächen. Leider unterscheidet sich oft, was wir, also unsere Entwickler, darunter verstehen von dem, was unsere Kunden eigentlich meinen. Ist damit gemeint, dass man erstmal mit einem überschaubaren Risiko klein anfangen will? Soll möglichst bald etwas “echtes” vorgezeigt werden? Geht es darum zu verifizieren, dass eine Schnittstelle überhaupt die notwendigen Daten liefert? 

Alle drei Erwartungen sind grundsätzlich richtig, beschreiben aber drei verschiedene Dinge, deren Preis weit auseinanderliegt. Zwischen dem günstigsten und dem teuersten liegt in der  Individualentwicklung schnell ein Faktor zehn. 

Der Reihenfolge nach:

Der Proof of Concept: Geht das technisch überhaupt?

Ein Proof of Concept ist ein Risikotest. Er richtet sich an die Technik, nicht an Nutzer. Typische Anlässe aus unserer Praxis: 

• Eine Schnittstelle zu einem Fremdsystem ist zwar dokumentiert, aber niemand weiß, ob sie die benötigten Daten wirklich liefert. 
• Ein Messverfahren soll auf mobiler Hardware laufen, und die Frage ist, ob die Performance reicht. 
• Ein KI-Modell soll Bilder klassifizieren, aber es ist unklar, ob die Qualität des vorhandenen Trainingsmaterials ausreicht.
• Es sollen Daten aus einem Altsystem migriert werden, die sich seit 12 Jahren niemand mehr angeschaut hat.

In all diesen Fällen hilft ein Proof of Concept, eine Annahme zu prüfen, die sonst ein Projekt kippen könnte. 

Was dabei bewusst fehlt, ist eine grafische Bedienoberfläche (also: ein UI), Fehlerbehandlung, Berechtigungen, Mehrbenutzerfähigkeit, kurz: alles, was ein System betriebsfähig macht. Oft ist ein Proof of Concept ein Skript, das nur eine Sache tut, ein Log schreibt, eine Dauer misst … Das Ergebnis ist deshalb auch kein Produkt, sondern entweder ein Ja, tragfähig; Nein, geht so nicht; oder Ja, aber unter den folgenden Bedingungen. Der Code wird danach meist weggeworfen, oder zumindest nur (in sehr kleinen) Teilen wiederverwendet. 

Größenordnung: Wenige Tage bis wenige Wochen.

Der Prototyp: Verstehen wir uns richtig?

Ein Prototyp ist ein Mittel zur Kommunikation. Er richtet sich an Menschen, um Missverständnisse aus der Welt zu schaffen. 

Anforderungsdokumente haben, auch wenn sie noch so detailliert sind, die unangenehme Eigenschaft, dass selbst wenn alle Beteiligten ihnen zustimmen, trotzdem jeder ein anderes Bild im Kopf hat. Das fällt meist dann auf, sobald es etwas zu sehen gibt. 

Um diesen Moment nach vorne zu ziehen, kann ein Prototyp als bedienbare Anwendung mit realistischen Beispieldaten, aber oft ohne echtes Backend, Abhilfe schaffen. Man kann durch zentrale Abläufe klicken und die tatsächlichen Anwender merken schnell, dass der wichtigste Arbeitsschritt vier Klicks zu weit hinten liegt. Auch kann das User Interface hier getestet werden: passen die Farben und Schriften, ist alles leserlich, ist der Ablauf nachvollziehbar oder geht wichtige Information unter?

Die Rechnung dahinter ist einfach, ein Missverständnis, das im Prototyp auffällt, kann in einem weiteren Workshop ausgebügelt werden. Fällt dasselbe Missverständnis im Abnahmetest auf, muss im ungünstigsten Fall die Datenmodellierung überarbeitet werden. 

Genau deshalb starten wir Projekte mit noch unscharfen Anforderungen bewusst mit Workshops und Rapid-Prototyping-Phasen. 

Größenordnung: wenige Wochen

Das MVP: Will das jemand nutzen?

Das Minimum Viable Product ist der einzige der drei Begriffe, bei dem echte Nutzer mit echten Daten arbeiten. Damit ist es der einzige, der in Betrieb geht. 

Beim MVP entsteht der eigentliche Kostensprung. Sobald Menschen produktiv mit einer Anwendung arbeiten, kommt alles dazu, was in Prototyp und Proof of Concept gefehlt haben: Authentifizierung und Rollenkonzept, Datenschutz und Löschkonzepte, Verschlüsselung, Backup und Wiederherstellung, Monitoring, Deployment-Prozesse, Protokollierung, Support, Barrierefreiheit. 

Minimalumfang, das M in MVP, bedeutet vor allem, dass eine oder zwei Funktionen des Endproduktes vollständig umgesetzt werden, und nicht zehn Funktionen halb. Ein MVP, das andeutungsweise alle Wunschfunktion enthält, ist kein MVP, sondern ein unfertiges Vollprodukt, mit dem niemand richtig arbeiten kann.

Größenordnung: mehrere Monate bis Jahre.

Warum liegen die Budgets so weit auseinander?

Kostentreiber ist nicht der Funktionsumfang - ein Prototyp kann mehr Screens und Funktionen zeigen, als ein MVP - sondern die Betriebsfähigkeit. Alles, was zwischen “ich zeige, wie die Software später aussehen wird” und “die erste Abteilung arbeitet mit der neuen Software” steht, ist in Individualprojekten regelmäßig der größerer Teil des Aufwands, und ist in den Demos davor unsichtbar, weil diese Dinge dort keine Rolle spielen.

Welche der drei brauchen Sie?

Für die Entscheidung hilft die Frage: Was ist im Moment das größte Risiko?

• Die Technik. Eine Schnittstelle, eine Datenqualität, eine Performance-Annahme kann das Projekt kippen -> Proof of Concept
• Das Verständnis. Niemand kann präzise beschreiben, was benötigt wird, oder die Bedienbarkeit entscheidet über die Akzeptanz -> Prototyp
• Markt bzw. Organisation. Es ist offen, ob die Lösung angenommen oder, bei externen Endkunden, vom Endnutzer bezahlt wird -> MVP
• Kein nennenswertes Risiko. Bekannter Prozess, vergleichbare Systeme existieren, Anforderungen sind klar -> keines der drei, die Entwicklung kann direkt starten. Manchmal ist ein MVP dennoch eine gute erste Wahl. 

PoC, Prototyp und MVP schließen sich dabei nicht aus. In größeren Vorhaben stehen sie oft hintereinander oder nebeneinander, und auch mehrere Proof of Concept-Projekte für unterschiedliche Aspekte sind möglich. 

Teuer sind dabei vor allem die drei Missverständnisse bzw. Gefahren:

• Der Prototyp läuft doch schon.
  
  Der Prototyp sieht aus wie das fertige System, also wirkt das Projekt zu achtzig Prozent erledigt. Tatsächlich ist (teils) der sichtbare Teil gebaut, der aufwändige Teil noch nicht. Die Daten sind nur modelliert.

• Proof of Concept als Angebotsgrundlage.
  
  Ein Proof of Concept kann in zwei Wochen fertig sein, das Gesamtsystem sollte doch dann in zwei Monaten stehen? Hier liegt der Trugschluss darin, dass im Proof of Concept das weggelassen wurde, was Geld kostet: Sicherheit, Stabilität, Wartbarkeit.

• Das MVP wächst in der Planung.
  
  Zwischen Kickoff und Umsetzungsstart wandern noch drei Funktionen in den Scope des MVP, weil sie ja ohnehin gebraucht werden. Am Ende steht ein Vollprodukt mit MVP-Budget im Kopf aller Beteiligten.

Was vom Prototyp ins Produktivsystem übergeht

Realistisch werden Erkenntnisse, das Bedienkonzept und möglicherweise das Datenmodell übernommen. Der Code selten. 

Auch wenn das nach Verschwendung klingt, liegt die Ersparnis durch einen Prototypen nicht darin, dass Code wiederverwendet werden kann, sondern in Fehlentwicklungen, die vermieden werden. Ein Prototyp, der drei Wochen kostet, aber eine falsche Prozessannahme aufdeckt, hat sich in fast jedem Projekt gerechnet. 

Was sich wirklich lohnt, ist die Kontinuität in den Köpfen aller Beteiligten. Kommen Prototyp und Produktivsystem aus derselben Hand, entfällt der Wissensverlust an der Übergabe, und die Diskussionen aus dem Prototyping müssen nicht nochmal geführt werden.

Kurz zusammengefasst

Der Proof of Concept sichert eine technische Annahme ab. Der Prototyp sichert das gemeinsame Verständnis ab. Das MVP sichert die Annahme ab, dass jemand mit der Lösung arbeiten will. Nur das MVP geht in Betrieb und ist damit mit einem hohen Faktor deutlich teurer als PoC und Prototyp.

Wenn Sie gerade überlegen, welche dieser drei Fragen bei Ihnen offen ist: Genau diese Einordnung machen wir am Anfang jedes Projekts, bevor ein Angebot geschrieben wird. Kontaktieren Sie uns gerne. Wir freuen uns auf Ihre Anfrage.