heft

Warum wir das Lastenheft verabschiedet haben …

… (und es nie wieder zurücknehmen).

„Ich schreibe ganz genau auf, was ich brauche. Nur so können sich potentielle Dienstleister ein präzises Bild meiner Anforderungen machen und verlässliche Angebote erstellen, die ich dann vergleichen kann.“

Klingt plausibel, oder? Ist es auch, allerdings leider nur bei simplen Anforderungen.

Der Unterschied zwischen simplen, komplizierten, und komplexen Projekten: Nur die simplen lassen sich vollumfänglich beschreiben.

Stellen Sie sich vor, Sie möchten eine Gartenhütte bauen. Sie wissen genau, wie viel Platz in Ihrem Garten dafür zur Verfügung steht und welche sonstigen Anforderungen Sie haben (Material, Farbe, Schiebetür). Sie schauen sich passende Modelle online an und bestellen schließlich eines. Wie hoch ist die Chance, dass alles reibungslos läuft und die Gartenhütte am Ende ganz genau Ihren zuvor definierten Vorstellungen entspricht?

Stellen Sie sich nun vor, Sie möchten ein Einfamilienhaus bauen. Sie besprechen mit dem Architekten Ihre Wünsche und dieser macht daraus ein präzises Leistungsverzeichnis, mit dem er verschiedene Gewerke ausschreibt. Wie hoch bewerten Sie nun die Chance, dass alles reibungslos läuft?

Jetzt stellen Sie sich vor, Sie bauen etwas tolles Neues, das noch nie jemand so gebaut hat, z. B. die Elbphilharmonie (Sie können hier den Namen praktisch jedes individuellen Bauprojektes eintragen, das Ihnen in den Sinn kommt). Sie machen einen ganz präzisen Plan, glauben alles bedacht zu haben… Aber naja, dem ist leider nicht so . Den Ausgang der Geschichte zum Bau der Elbphilharmonie kennen Sie vermutlich.

requirement

Warum ist das so? Unsicherheit im „Wie?“ und „Was?“ steigert die Komplexität exponentiell.

Der Akademiker Ralph Stacey hat dies wissenschaftlich untersucht. Je höher die Unsicherheit in den beiden Dimensionen „Anforderungen“ (Was soll gebaut werden?) und „Umsetzung“ (Wie kann man das genau erreichen?) werden, desto schwieriger lässt sich nach einem genauen Plan arbeiten.

Sind die Anforderungen einfach zu überblicken (bei einer Gartenhütte gibt es wenig Optionen) und die Details der Umsetzung bekannt (das Unternehmen hat schon hunderte gleiche Gartenhütten gebaut), befindet sich das Projekt in der „simplen“ Domäne. Hier kann man gut eine vollständige Liste der Anforderungen nach einem präzisen Plan abarbeiten.

Bei einem Einfamilienhaus wird es schon etwas komplizierter. Wünschen Sie ein recht übliches Haus, welches das Unternehmen bereits mehrfach analog gebaut hat (z. B. ein Fertighaus), kann das reibungslos klappen. Wünschen Sie etwas individuelleres oder hat eines der beteiligten Unternehmen wenig Erfahrung gesammelt, wird es voraussichtlich Schwierigkeiten geben. Sehr individuelle Projekte liegen schon in der „komplexen Domäne“.

Die „chaotische“ Domäne tritt beispielsweise in der Grundlagenforschung auf.

RalphStacyyMatrix.original.png

"Statt einem umfangreichen Lastenheft sollte man eine starke Produktvision und einen groben Plan in Form einer User Story Map erarbeiten."

Was hat die Baubranche mit meiner Software zu tun? Es ist selten so simpel, wie es scheint.

Wenn Sie eine Standardsoftware benötigen, z. B. einen Online-Shop oder eine repräsentative Webseite, sind Sie vermutlich in der simplen der komplizierten Domäne unterwegs. Wenn Sie eine Individualsoftware bauen, dann sind Sie ziemlich sicher in der komplexen Domäne.

Wie man seine Zeit besser investiert? In eine starke Produktvision und einen groben Plan.

Wenn man nun versucht, seine noch nicht vollständig bekannten Anforderungen in einem Lastenheft niederzuschreiben, muss man viele Annahmen treffen, was die Benutzer später wirklich wollen. Man investiert viel Zeit in die Planung von Eventualitäten, die ziemlich sicher nicht genauso kommen werden. Zwar schadet das nicht unbedingt dem Projekt, es ist aber auch keine sinnvoll investierte Zeit.

Natürlich muss man sich trotzdem Gedanken machen, was man genau erreichen möchte. Das Ziel muss also klar sein, der genaue Weg aber nicht unbedingt. Aus diesem Grunde investiert man seine Zeit besser in eine starke Produktvision. Wie dies gelingen kann, habe ich in einem Blogartikel "How to create a meaningful agile Product Vision" beschrieben.

Wie kann man seine Anforderungen grob erfassen, ohne viel Zeit in hypothetische Pläne zu investieren? Mit einer User Story Map.

Hat man eine genau durchdachte und abgestimmte Produktvision, sollte man die Anforderungen grob erfassen. Hierzu empfehlen wir die Technik „User Story Mapping“, bei der die Anforderungen in Form von User Stories entlang der Wertschöpfungskette für die wichtigsten Benutzer (User Journey) ermittelt werden. Danach hat man eine „Landkarte“ des Projektes, auf der die Anforderungen entlang der User Journey und in aufsteigender Priorität dargestellt werden. Hier kann man ablesen, welche Anforderungen zuerst erfüllt werden sollen, um dem Kunden möglichst früh ein funktionierendes Produkt zu liefern.

Achtung: Ganz genau ausdefinieren, in dem Detailgrad, in dem man auch ein Lastenheft schreiben würde, sollte man dann nur die User Stories, die man in etwa in den nächsten vier Wochen bearbeiten kann.

Fazit: Adieu Lastenheft, Hallo User Story Mapping

Nur bei sehr simplen Projekten lassen sich alle Anforderungen verlässlich planen. Statt einem umfangreichen Lastenheft sollte man eine starke Produktvision und einen groben Plan in Form einer User Story Map erarbeiten. Im weiteren Verlauf des Projektes plant man dann immer die Anforderungen im Detail, die man in den nächsten vier Wochen umsetzt.

Unser Video zur Erstellung einer User Story Map, inklusive Erklärung am Beispiel finden Sie hier:

cookie button png