Wie sich Prototyp, Proof of Concept, MVP und Pilot unterscheiden

Foto des Autors
Werner Beckmann

Wenn verschiedene Beteiligte aus Marketing, Vertrieb, Fachabteilungen und Software-Entwicklung zusammensitzen und ein neues Produkt vorbereiten, dann kommt es häufig zu Diskussionen über die Richtung der ersten Schritte: Soll man mit einem Proof of Concept starten? Mit einem Piloten? Oder mit einem MVP (Minimum Viable Product)? Und wie unterscheiden sich die Ansätze überhaupt?

Seit einiger Zeit registrieren wir bei Conciso ein stark zunehmendes Interesse an Digitalisierungsvorhaben und an agilen Methoden zur Umsetzung der Vorhaben. In Gesprächen treffen wir häufig auf innovative Unternehmen, die mit großem Elan neuartige, digitale Produkte planen und erstellen.

Wenn verschiedene Beteiligte aus Marketing, Vertrieb, Fachabteilungen und Software-Entwicklung zusammensitzen und ein neues Produkt vorbereiten, dann kommt es häufig zu Diskussionen über die Richtung der ersten Schritte: Soll man mit einem Proof of Concept starten? Mit einem Piloten? Oder mit einem MVP (Minimum Viable Product)? Und wie unterscheiden sich die Ansätze überhaupt?

In diesem Beitrag geben wir eine kurze Übersicht.

Prototyp

Ein Prototyp in der Digitalisierung ist ein verwendbares Model und physisch oder in Form von Software „anfassbar“.

In der Entwicklung von Softwareprodukten verwenden Teams häufig folgende Formen:

Vertikaler Prototyp oder Durchstich: Mehrere Schichten, Komponenten oder Anwendungen werden miteinander verbunden, um die technischen Schwierigkeiten früh zu erkennen und zu lösen.

Horizontaler Prototyp, meist für User Interfaces (UI): Darstellung der Oberflächen, beispielsweise für eine Web-Anwendung oder für eine Smartphone-App. Häufig verwenden Teams hierfür bereits grundlegende Software-Elemente wie HTML-Seiten oder spezielle Prototyping-Tools wie Balsamiq. Für ein noch früheres Feedback setzen Entwickler auch Papier-basierte UI-Prototypen ein. Anwender vollziehen ihre Arbeitsweisen mit der Anwendung nach und geben erstes Feedback.

Prototypen werden meist nicht in Produktion eingesetzt, da Funktionsumfang und Stabilität nicht ausreichend sind.

Ziel

Mit einem Prototyp können Teams wesentliche Fragestellungen und Risiken beleuchten und Feedback einholen, beispielsweise:

  • Ist die Schnittstelle zum ERP-System transaktionssicher verwendbar? Welche neuen Erkenntnisse zu Datentypen und Abläufen erwarten das Team?
  • Ist die geplante Reihenfolge der Masken für die Anwender sinnvoll und nützlich? Wo treten Unklarheiten auf? Passen die verwendeten Elemente zu den bekannten Datenmengen, beispielsweise bei langen Listen?
  • Sind die Antwortzeiten des neuen JavaScript-Frameworks auf dem Smartphone tolerierbar?

Foto von commons.wikimedia.org

Proof of Concept

Ein Proof of Concept (PoC) ist eine Aktivität, die häufig mit einem Meilenstein als Projektabschnitt beendet wird. In der Regel erstellen Entwicklungsteams innerhalb des PoC Prototypen zur Demonstration der Machbarkeit relevanter Funktionalitäten oder Eigenschaften.

Im Gegensatz zu Prototypen umfasst der PoC häufig die Umsetzung größerer Funktionsblöcke sowie konzeptionelle Vorarbeiten, meist mit Beteiligung verschiedener Stakeholder. Ein PoC ist meist nicht für einen dauerhaften Produktivbetrieb geeignet.

Beispiele:

  • Die Außendienst-App kann auch offline verwendet werden.
  • Das geplante Smart-Home-Gerät lässt sich per Smartphone steuern.
  • Anwender können die Web-Anwendung auch während der Wartungszeiten des ERP verwenden.

Ziel

Mit einem PoC versucht ein Team in der Regel, den Nachweis der Machbarkeit für einen zentralen Aspekt des Produktes zu erbringen. Die Machbarkeit ist vor allem wichtig für Investoren und auch für interne Geldgeber zur Absicherung des Vertrauens in die Produktentwicklung.

Foto von commons.wikimedia.org

MVP – Minimum Viable Product

Ein MVP ist ein minimal funktionsfähiges Produkt mit folgenden Eigenschaften:

Minimum: Eingeschränkter Funktionsumfang, der durch strikte Priorisierung auf Basis von Kosten und Nutzen bestimmt wurde.

Viable: Das Produkt muss nutzbar und einsetzbar sein. Es wird real verwendet und muss daher die ausgewählten Prozesse unterstützen. Dabei ist der Umfang auf das Nötigste reduziert. Insbesondere darf es den beabsichtigten Nutzen nicht behindern oder erschweren.

Product: Das Produkt wird wirklich verwendet. Bei Web-Anwendungen melden sich Anwender beispielsweise mit echten Accounts an und bearbeiten reale Daten. Falls die Erkenntnisse aus dem Einsatz ein Abschalten der MVP-Anwendung erfordern, dann müssen Teams daher prüfen, wie mit vorhandenen Daten zu verfahren ist.

Ein MVP ist im Gegensatz zu einer Anwendung in der Pilotierung noch sehr vielen, auch wesentlichen Änderungen unterworfen. Häufig basiert die MVP-Erstellung auf den Erkenntnissen aus PoC und Prototypen.

Ziel

Mit einem MVP können Teams wertvolles Feedback von echten Anwendern bei realer Anwendung sammeln und daraufhin die Richtung der Produktentwicklung anpassen. Somit vermeiden sie Aufwand für Funktionalitäten, die für Anwender irrelevant sind.

Für Investoren ist das MVP ein zentrales Instrument, um die optimale Budget-Verwendung durch Experimente zur Validierung von Annahmen sicherzustellen.

Foto von unsplash.com

Pilot

Unter Pilot oder Pilotierung versteht man meistens einen zeitlich beschränkten Echtbetrieb eines Produktes mit einer ausgewählten Anwendergruppe. Oft ist in einem Piloten bereits eine signifikante Anzahl von Nutzern beteiligt. Anwender führen dabei echte Prozesse mit dem Produkt aus.

Ein Produkt in der Pilotierung hat einen höheren Reifegrad im Vergleich zum Prototyp oder zum MVP. In der Regel starten Teams eine Pilotierung erst dann, wenn sie anhand des Feedbacks zu einem oder mehreren MVPs das Produkt weiterentwickelt haben.

Genau wie beim MVP stellt sich auch bei einer Pilotierung die Frage, wie am Ende des begrenzten Zeitraums mit den Daten der Kunden verfahren wird – schließlich handelt es sich um echte Daten.

Ziel

Mit einer Pilotierung versucht man in der Regel, Kinderkrankheiten eines Produktes herauszufinden und den Betrieb zu stabilisieren. Durch die Einbindung der Zielgruppe erreichen Sie eine hohe Variation in Dateneingaben und Benutzungsweisen. Oft ist die Pilotierung die Vorstufe zur generellen Verfügbarkeit. Das Feedback der Anwender sollten Sie intensiv auswerten, auch wenn grundlegende Änderungen in dieser Phase meist sehr aufwändig und teuer sind. Durch die vorher durchgeführten Experimente mit MVPs sichern Sie Ihre Annahmen jedoch bereits ab, so dass Ihrer Produkteinführung nichts mehr im Wege steht.

Foto von unsplash.com

MVP done smart

Haben Sie für Ihr Vorhaben schon ein MVP konzipiert? Oft ist es gar nicht so einfach, im Spannungsfeld aus Visionen, Funktionswünschen und Budget-Möglichkeiten den richtigen Umfang zu bestimmen.

Informieren Sie sich am besten über Erfahrungen und Best Practices zu MVP aus echten Projekten. Vorträge und Meetups bieten viele Informationen und einen einfachen Einstieg, zum Beispiel bei der Conciso-Veranstaltung am 27.06.2019 in Dortmund. 

Beitragsfoto von unsplash.com

Interaktiver Vortrag am 27.06.2019 bei Conciso

Schreibe einen Kommentar

Das könnte Dich auch noch interessieren

Agile Series: Ihr agiles Portfolio in 6 Schritten mit Portfolio for Jira

Agile Series: Ihr agiles Portfolio in 6 Schritten mit Portfolio for Ji...

Vereinfachen Sie Ihr agiles Projektmanagement. Lesen Sie, wie Sie in nur 6 Schritten zu Ihrem agilen Portfolio mit Portfolio for ...
Warum Sie beim MVP nicht an der Sicherheit sparen sollten

Warum Sie beim MVP nicht an der Sicherheit sparen sollten

Im Vortrag zu „Arbeiten mit MVPs - Erfahrungen aus der Praxis“ im Rahmen des Agile Coaching Meetups fasste Moritz Peitzsch ...
Der effiziente Product Owner - Umfrage Manage Agile 2016

Der effiziente Product Owner – Umfrage Manage Agile 2016

Unsere These: "Der Product Owner ist der Schlüssel zum Produkterfolg". Für einen effektiv und effizient arbeitenden Product Owner sind die ...