Entwurfsmethodiken – Minimum Viable Scope

Die Akzeptanz einer Software lebt unter anderem davon, daß sie sich agil weiterentwickelt, und, daß sie die Aufgaben erledigt, die sie erledigen soll.

Konzepte wie der „Minimum Viable Scope“ helfen dem Entwicklungsteam dabei, genau die Anforderungen zu finden, die dem späteren Anwender der Software wichtig sind.

Insbesondere lohnen sich die zeitlichen Investitionen in die Methode auch deshalb, weil man mit den Ergebnissen auch entscheiden kann, welches Feature man nicht entwickelt – um so ggfs schneller am Markt sein zu können.

Heute liefere ich einen Überblick über solche und ähnliche Methoden.

Der Entwurfszyklus im Überblick

Der Startup Blender schreibt in seinem Artikel „Minimum Viable Product vs. Minimum Delightful Product“ (siehe Links am Artikelende) über die beiden im Titel erwähnten Begriffe “Minimum Viable Product“ und ”Minimum Delightful Product“.

Ähnlich wie beim Konzept des „Minimum Viable Scope“ geht es bei diesen Ansätzen darum, Softwareprodukte agil so zu entwickeln, daß sie aus Kundensicht genau die richtigen Anforderungen abbilden. Die Ansätze unterscheiden sich hierbei lediglich im Hinblick auf die Definition von „richtig“.

Wie das folgende Zitat aus dem Artikel zeigt, bieten solche Ansätze eine wichtige Unterstützung gegen de Tendenz, zu viele und die falschen Features zu entwickeln. Dabei heißt das Schlüsselwort „vereinfachen“, und „agil weiterentwickeln“:

At face value MVP is a great idea because the concept addresses a major anti-pattern in product development: building too many features and the wrong features as a result of spending too much time in development without shipping or getting real feedback from customers and users.

Focusing on “minimum” is generally simple. It helps to correct against the tendency to build features because they are “cool” even if it’s unclear whether or not people want them.

Ausgangsdaten

In der Anlage finden Sie einige Literaturempfehlungen zum Thema. Demnach dienen die „Minimum Viable-Methoden“ dazu, die Entwicklungszeit zu verkürzen, ohne an notwendigen Features zu sparen. Dies geschieht auf dem folgenden Weg und zu den aufgeführten Gelegenheiten:

  • Fokussieren des Projekts auf die essentiellen Features, die unbedingt aus Sicht der Zielkunden notwendig sind, und die mindestens drei bis vier der wichtigsten Anwendungsprobleme lösen.
  • Identifizieren eines sinnvollen Scopes, der so ausgestaltet ist, daß Kunden willens sind, hierfür zu zahlen, bzw Zeit, oder Ähnliches zu investieren.
  • Durchführen eines nicht technischen Prove of Concept (Prototype), bzw Erstellen einer Alpha Version eines Produktes oder eines Services.
  • Insbesondere sind die „Minimum-Viable-Methoden“ sinnvoll, um zu entscheiden, welches Feature man nicht entwickeln sollte. So helfen die Methoden dem Team dabei, sich auf die Teile zu fokussieren, die die Kunden wertschätzen. Sie erinnern das Entwicklungsteam auch daran, daß es nicht unbedingt notwendig ist, ein komplettes Produkt zu entwickeln, nur um Annahmen zu prüfen.

Probleminterviews

Ein wichtiger Input sind Probleminterviews mit späteren Nutzern, die folgende Ziele verfolgen:

  • 15-20 Minuten Interviews mit wichtigen Vertretern des Zielmarktsegments
  • Fragen, die dazu dienen, die Grundannahmen über die wichtigsten Features zu prüfen
  • Feststellen ob eine Lösung die Bedürfnisse der Kunden adressiert

Solche Interviews sollten gut vorbereitet sein. Hier einige Tipps:

  • Erstellen und testen Sie ein Skript, das die Vorbedingungen für die Befragung aufzeigt, und die wesentlichsten Schritte.
  • Bauen Sie das Skript so, daß mit den Antworten die wesentlichsten Annahmen geprüft werden können.
  • Ermitteln Sie die zentralsten Fragen, und orientieren Sie die Fragen an den jeweiligen Produktnutzen
  • In der Befragung sollten Sie ein echtes Interesse an den Angaben des Kunden entwickeln
  • Wählen Sie die Kunden des Zielsegmentes sorgsam aus, um nicht Anforderungen zu erhalten, die nicht zu dem Kernprodukt gehören sollten
  • Mindestens zwei Personen sollten das Interview durchführen – der Interviewer, und der Protokollant. Bei Bedarf können Sie auch eine Person mitbringen, die die Aufgaben hat, die Befragung selbst zu beobachten, um ggfs methodische Verbesserungen zu formulieren
  • Dokumentieren Sie die Ergebnisse sofort nach dem Interview, und nutzen Sie Methoden, wie das Story-Telling um dem (nicht anwesenden) Team die Erkenntnisse zu vermitteln.
  • Sorgen Sie für die Vergleichbarkeit der Ergebnisse, und ggfs für quantifizierbare Ergebnisse
  • Um das Problem aus der Kundensicht zu beurteilen, sollten Sie in Erfahrung bringen, ob Kunden etwas versucht haben, um ihr Anwendungsproblem zu lösen, und was.
  • Erlauben Sie offene Elemente in der Befragung, die dem Interviewer gestatten situativ vorzugehen, achten Sie aber auch auf Elemente für die Vergleichbarkeit
  • Das wichtigste Ziel ist es, daß Sie lernen, wie der Kunde zu denken, bzw das Problem mit seinen Augen zu sehen, sodaß Sie später in der Lage sind, die Anforderungen auch zu bewerten.

Weiterführende Informationen

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen.

In der Online Version finden Sie hier die versprochenen weiterführenden Links:

I

This entry was posted on Montag, August 19th, 2013 at 7:40 pm. It is filed under Agile&Scrum, Thema des Tages and tagged with , , , , , . You can follow any responses to this entry through the RSS 2.0 feed.

Andreas Rudolph - Fotoshop Andreas Rudolph - AS-Photo-Project.de

Comments are closed.