Weniger Features sind oft mehr

In einem typischen Softwareprodukt werden viele Funktionen kaum benutzt. Ein Produkt mit weniger Features zu haben, wäre hier von Vorteil, sowohl was die Komplexität betrifft, als auch die Wartung der Software, und die Kosten.

Heute geht’s um des „minimal viable scope“ eines Produktes, als eine Möglichkeit, genau das zu entwickeln, was für den Markterfolg notwendig ist (und nicht mehr).

Minimum Viable Scope

Oft ist das Problem, daß eine Software mehr kann, als sie eigentlich müßte, um die Anforderungen eines normalen Nutzers abzudecken. Viele Produkte (gerade die „gewachsenen“ großen Softwarepakete) bilden ein Sammelsurium von Features, die oft nicht einmal konsistent zusammenpassen.

Sehr viele Features werden nicht von jedem Nutzer gebraucht, und kosten demnach überflüssiges Geld, oder bedingen unnötige Komplexitäten. In Ihrem Artikel →Cut Features; Add-Value sagt Joy Beatty hierzu:

„Yet 65 percent of features in software aren’t used (according to a Standish Group survey), and those unused and rarely used features are everywhere you look. Product managers and business analysts are in the unique position of being able to drastically cut scope to deliver more usable products faster and for less cost.”

Bedeutung des Features

Man soll nach Beatty ein Produkt so zusammenbauen, daß es die Bedeutung der Features für die Nutzer in Betracht zieht.

Die Bedeutung, die ein einzelnes Features für das Produkt hat, ergibt sich aus dem Wert den das Feature für die einzelnen User in den unterschiedlichen Nutzergruppen hat. Beatty meint, um diesen Wert zu bestimmen, solle man für jedes Produktmerkmal ermitteln, wieviele Nutzer das Gerät unter der Annahme kaufen würden, daß es das eine betrachtete Feature gibt.

Der Artikel macht diesen Entscheidungsprozess an einem Musikspieler für Sportler fest, der bestimmte Anforderungen erfüllen soll, wie zum Beispiel:

  • Playlisten anlegen – must have Anforderung
  • Bilder auf dem Screen anzeigen – nice to have Anforderung

Sie nutzt diese Angaben zu den Anforderungen, um nun festzustellen, wie kaufentscheidend die einzelnen Features sind.

Den Ansatz halte ich für gut. Meiner Erfahrung nach sind jedoch die Zahlen, die hierfür notwendig sind, nicht immer einfach zu erheben. Auch sollte man die einzelnen Nutzer besser in Zielgruppen einteilen. Ein Ausweg aus diesem Datenproblem bieten meiner Meinung nach die folgenden Ansätze:

  • Mockups anlegen und mit Nutzern testen, so wie dies Das Design Thinking zum Beispiel vormacht
  • Sehr viel Aufwand in die Beantwortung der Frage legen „Vor Entwicklungsbeginn sehr genau verstehen, welches Problem der zukünftige Nutzer eigentlich hat“ (wofür er eine Lösung sucht)

Requirements Matrix

Beatty schlägt weiterhin vor, darüber nachzudenken, wie der Nutzer Schritt für Schritt die Funktionalität erschliesst („Process Flow“). Der Process Flow kann für die einzelnen Nutzer unterschiedlich sein, und zeigt die zentralsten Aspekte auf, die ein Produkt für diese Nutzer abdecken sollte.

Sie schlägt hierfür eine relativ komplexe „Requirements Mapping Matrix“ vor, die dafür sorgen soll, ein komplettes Bild zu erhalten, und, um die einzelnen Anforderungen nachzuvollziehen.

Der Artikel zeigt hierfür eine sehr detaillierte Tabelle mit den Spaltenüberschriften die sich aus ihrem Beispiel ergeben, und Zeilen, die den einzelnen Nutzungsszenarien entsprechen (hier nur ein Szenario wiedergegeben):

  • L1 Process Step: Create Music Library
  • L2 Proces Step: Create Playlist
  • L3 Process Step: User Names Playlist
  • REQID: Requirement ID
  • Requirement: Create Playlist Name
  • Business Rule 1: Playlist cannot be longer than 24 chars
  • Business Rule 2: Default playlist name…is Playlist #

Gerade auf dem gezeigten Level der Information, und bei komplexeren Produkten ist die vorgeschlagene Matrix meiner Meinung nach viel zu detailliert, und auch erst einmal garnicht notwendig, solange man nicht das Gesamtprodukt strukturiert hat.

Insbesondere ist es sehr aufwendig, bis dahin zu kommen, daß man genaue Anforderungen aufschreiben kann. Ich würde stattdessen eher eine Matrix verwenden, die sich auf die folgenden Informationen konzentriert:

  • Welche Szenarien
  • Welche Personas
  • Welche Nutzungswünsche
  • Welche Rahmenbedingungen

Mit diesen Daten kann man viel einfacher Anforderungen angleichen, und Nutzergruppen identifizieren, die zu viel Komplexität erfordern.

Die Grafik ganz oben zeigt eine Tabelle, die genau diese Daten zusammenfasst (Clicken zum Öffnen). Dort sieht man, daß es drei Personas gibt, wovon eine Persona (Zielgruppe) sehr viel Komplexität ergänzt. Man kann das Produkt sehr viel einfacher machen, indem man sich zunächst auf die einfachen Anwendungsfälle konzentriert.

Um dort hinzukommen beschreibt man die neben den Szenarien, die Anforderungen der Nutzer. Hierfür hat es sich bewährt, die einzelnen Gruppen (in dieser Phase) an einen Tisch zu holen, um so dafür zu sorgen, daß sich die die Anforderungen angleichen.

Weiterführende Informationen

… im Internet

Im Internet finden Sie weiterführende Artikel, in denen Sie mehr Informationen über die vorgestellten Konzepte:

… auf www.Produkt-Manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema Innovationsmanagement generell:

Kontakt

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:

Comments are closed.