Anforderungs-Workshops

Ein Workshop ist nur dann etwas wert, wenn er die richtigen Menschen an einen Tisch bringt. Fehlt die Fachabteilung, die später damit arbeitet, oder die Person mit Entscheidungsbefugnis, produziert die Runde Wunschlisten ohne Verbindlichkeit. Die Vorbereitung, wer dabei sein muss und welche Fragen wirklich offen sind, entscheidet mehr über das Ergebnis als der Workshop-Tag selbst.

Freie Diskussion erzeugt selten handlungsfähige Anforderungen. So läuft ein Workshop bei uns konkret: Vorab führen wir kurze Einzelgespräche mit den Beteiligten und sammeln die Formulare, Listen und Ausnahmen, mit denen heute gearbeitet wird. Im Workshop selbst legen wir einen echten Vorgang, etwa eine Reklamation oder eine Auftragsänderung, beim Event-Storming Schritt für Schritt als Ereignisse an die Wand. Wo zwei Abteilungen dasselbe Wort unterschiedlich verwenden, halten wir die Begriffe in einem Glossar fest, der Ubiquitous Language des Projekts. Am Folgetag liegen die Ergebnisse als priorisierte User Stories vor und gehen zur Freigabe an alle Teilnehmer.

Der eigentliche Wert entsteht durch Priorisierung, nicht durch Vollständigkeit. Eine endlose Anforderungsliste ohne Reihenfolge hilft niemandem. Business-Value und Aufwand gemeinsam zu bewerten legt fest, wann welcher Nutzen entsteht. Und ein Konflikt, der im Workshop sichtbar wird, kostet Moderationszeit, während derselbe Konflikt nach dem Go-Live ein Vielfaches an Nacharbeit und Vertrauen kostet.

Ein Workshop ist der Auftakt, nicht das ganze Verfahren. In einem agilen Projektmanagement kommen neue Fragen in jedem Sprint auf, und dann reicht oft eine kurze Klärungsrunde statt eines weiteren Workshop-Tags. Wie Anforderungen in agiler Softwareentwicklung laufend verfeinert werden, erklärt unser Wiki. Wo dagegen ein Festpreis oder eine Ausschreibung ansteht, braucht es eine schriftliche Spezifikation; wie man sie aufbaut, zeigt unser Leitfaden zu Lastenheft und Pflichtenheft.