Ausgangslage: Der Schnitt folgt dem Aufwand

Vor einem ersten Release muss ein Team entscheiden, was hineinkommt. In den meisten Vorhaben, die wir begleitet haben, fiel diese Entscheidung nach Aufwand und Risiko: Was sich mit dem vorhandenen Team bis zum Termin bauen lässt, kommt hinein. Das Ergebnis ist ein Release, das viele Funktionen anbietet und wenige Aufgaben zu Ende bringt. Nutzende beginnen eine Aufgabe im neuen Produkt und beenden sie im alten, in einer Tabelle oder per Mail.

ISO 9241-11 definiert Gebrauchstauglichkeit über Effektivität, Effizienz und Zufriedenstellung bei der Erreichung festgelegter Ziele. Effektivität heißt: Nutzende erreichen ihr Ziel vollständig und genau. Ein Release, das eine Aufgabe zur Hälfte unterstützt, hat für diese Aufgabe keine Effektivität, unabhängig davon, wie gut die vorhandene Hälfte gestaltet ist. Diese Definition liefert die Schnittkante: Ein Release wird entlang vollständiger Aufgaben geschnitten.

Schritt 1: Aufgaben aus dem Nutzungskontext ableiten

Die Grundlage ist das Aufgabenmodell aus der Erhebung. Aus Kontextinterviews und Hospitationen liegt vor, welche Aufgaben Nutzende erledigen, in welchen Schritten und woran sie erkennen, dass die Aufgabe abgeschlossen ist. Der Abschluss ist entscheidend. Bei einer Aufgabe wie „Monatsauswertung an eine andere Abteilung weitergeben" ist der Abschluss die Weitergabe. Ein Produkt, das die Auswertung anzeigt, aber die Weitergabe nicht ermöglicht, unterstützt die Aufgabe nicht vollständig.

Für jede Aufgabe wird der Endzustand aus der Beobachtung notiert. Er ist das Prüfkriterium für den Schnitt.

Schritt 2: Nutzungsanforderungen je Aufgabe bündeln

Nutzungsanforderungen nach ISO 9241-210 beschreiben, was Nutzende mit dem System erreichen müssen. In der Dokumentation liegen sie meist als Liste vor, sortiert nach Thema oder Quelle. Für den Schnitt werden sie neu sortiert: je Aufgabe alle Anforderungen, die zwischen Auslöser und Abschluss liegen. Eine Anforderung kann in mehreren Aufgaben vorkommen; dann steht sie in mehreren Bündeln.

Das Bündel je Aufgabe ist die kleinste Einheit, die ein Release enthalten muss, damit die Aufgabe vollständig wird. Anforderungen, die zu keiner Aufgabe gehören, werden gesondert behandelt; oft handelt es sich um Vorgaben aus Fachbereichen, deren Nutzungsziel noch nicht erhoben ist.

Schritt 3: Aufgaben für das erste Release auswählen

Jetzt entscheidet das Team, welche Aufgaben das erste Release vollständig unterstützt. Kriterien sind die Häufigkeit der Aufgabe, die Folgen eines Fehlers und der heutige Erfüllungsgrad, jeweils aus der Erhebung. Dazu kommt die Geschäftssicht: Welche Aufgabe hat für die Organisation Vorrang. Der Unterschied zum Vorgehen nach Aufwand liegt darin, dass Aufgaben ausgewählt werden und nicht Funktionen. Der Aufwand wird je Bündel geschätzt.

Wenn das Budget für ein vollständiges Bündel nicht reicht, gibt es zwei Wege: eine kleinere Aufgabe wählen, oder die Aufgabe bewusst unvollständig lassen und dokumentieren, wie Nutzende den fehlenden Schritt bis zum Folgerelease erledigen. Der zweite Weg ist zulässig. Er wird zur Entscheidung mit bekannten Folgen, statt zum Zufallsprodukt.

Schritt 4: Den Schnitt mit der Prüffrage testen

Bevor der Schnitt festgeschrieben wird, prüft das Team ihn mit einer Frage je Aufgabe im Release: Kann eine Person aus der Zielgruppe diese Aufgabe vom Auslöser bis zum dokumentierten Abschluss im Produkt erledigen, ohne ein anderes Werkzeug zu öffnen?

Die Frage lässt sich am Aufgabenmodell durchspielen und, besser, mit einem Prototyp im Usability-Test prüfen. Im Test bekommen Teilnehmende die Aufgabe als Szenario und arbeiten sie durch. Jede Stelle, an der sie das Produkt verlassen müssten, ist ein Befund gegen den Schnitt. Ein Release, das die Frage für mindestens eine Aufgabe mit Ja beantwortet, ist aus Sicht der Nutzenden ein Produkt. Eines, das sie für keine Aufgabe mit Ja beantwortet, ist eine Sammlung von Funktionen.

Grenzen

Das Vorgehen setzt ein Aufgabenmodell aus Beobachtung voraus. Aus Annahmen abgeleitete Aufgaben führen zu einem Schnitt, dessen Vollständigkeit niemand geprüft hat. Es sagt außerdem nichts darüber, welche Aufgabe wirtschaftlich den höchsten Wert hat; diese Entscheidung bleibt beim Produktmanagement. Und es gilt für Produkte, in denen Nutzende abgrenzbare Aufgaben erledigen. Für Angebote ohne klaren Aufgabenabschluss, etwa Informationsportale, ist die Schnittkante anders zu bestimmen.

Wirkungszahlen zu diesem Vorgehen, etwa eingesparte Nacharbeit in Folgereleases, liegen bei uns nicht erhoben vor. Was wir dokumentiert haben, sind Beobachtungen aus Projekten, in denen halbe Aufgaben zu Zweitsystemen geführt haben.

Was danach vorliegt

Nach den vier Schritten liegen vor: ein Aufgabenmodell mit dokumentiertem Abschluss je Aufgabe, Anforderungsbündel je Aufgabe, eine Auswahl der Aufgaben für das erste Release mit Begründung, und ein Testprotokoll, das für jede ausgewählte Aufgabe zeigt, ob sie im Prototyp vollständig abschließbar ist. Mit diesen Artefakten lässt sich der Schnitt gegenüber Fachbereichen und Geschäftsführung begründen, und er lässt sich nach dem Release mit denselben Aufgaben messen.