Komm, wir spielen Lastenheft - Pflichtenheft: Ein Spiel, bei dem es nur Verlierer gibt - das Spiel für alle diejenigen, die eigentlich Romanautoren werden wollten, bei denen es aber doch nur zum Projektmanager gereicht hat. Hier kann sich der klassische Projektmanager noch voll austoben, seine Gedanken in Prosaform darlegen und das tolle ist ja: Je mehr wir als Auftraggeber schreiben, desto besser denken wir sind unsere Anforderungen dargelegt und desto mehr können wir auch in Form eines Pflichtenheftes vom Auftragnehmer erwarten. Trotzdem bemerken wir oft im laufenden Projekt, dass Auftraggeber und Auftragnehmer sich in wesentlichen Punkten nicht verstanden haben - das Projekt wird teurer oder verzögert sich.
Ein Lastenheft enthält die Anforderungen des Auftraggebers. Das ist per se eine gute Sache: Wenn ich etwas tolles zu Weihnachten bekommen möchte, sollte ich eine Wunschliste schreiben, andernfalls kann ich mich nicht beschweren, wenn wieder nur Socken unter dem Christbaum liegen. Wenn ich als Stichwort "Auto" auf meinen Wunschzettel schreibe, kann dies von den geneigten Empfängern sowohl als Spielzeugauto als auch als Kleinwagen aufgefasst werden - da ist es also hilfreich wenn ich spezifiziere, dass ich schon gerne den neuen Porsche Taycan GTS in der Farbe Schwarz mit 598 PS und sämtlicher Sonderausstattung hätte. Dafür zeigt mir dann jeder in meiner Verwandtschaft einen Vogel und zur Strafe werde ich abermals mit Socken beschenkt - die Anforderung wurde zwar klar definiert, aber leider nicht auf Machbarkeit hin überprüft.
Im agilen Projektmanagement sagen wir uns von den Lastenheftromanen los und arbeiten stattdessen mit kurzen Userstories als Anforderungsbasis - eine Wunschliste aus Sicht des Kunden oder zumindest davon, was wir meinen, was der Kunde sich wünscht. Somit schreibe also ich als Product Owner eine Wunschliste für jemand anderen, also etwa so: Ich habe vor kurzem mal mit meiner Frau gesprochen, sie hat im Winter oft kalte Füße und findet Socken generell ganz praktisch - also denke ich, dass meine Frau sich Socken zu Weihnachten wünscht. Schon ist die Userstory komplett.
Die Userstory wird in Tasks aufgeteilt, also in Aufgaben umgewandelte Anforderungen - aber wie können wir die sinnvoll und objektiv priorisieren? In der Praxis kann nicht nach jedem Sprint ein lauffähiges Produkt entstehen und beim fortlaufenden Entwickeln von Verbesserungen entsteht regelmäßig ein höherer Testaufwand dieser Verbesserungen, als wenn Verbesserungen systematisch implementiert werden würden.
Am Anfang eines Projektes stehen immer Anforderungen - darum geht es im Kern. Bleiben wir beim Bild der weihnachtlichen Wunschliste, die die meisten von uns aus Kindertagen kennen dürften. Wie bauen wir unsere Wunschliste am besten auf?
Als Kinder haben wir die Wunschliste auf einen Zettel geschrieben, in Stichpunkten und evtl. mit Erläuterungen. Jetzt sind wir erwachsen, im Büro und können Excel bedienen. Zusätzlich wirkt es irgendwie klarer strukturiert, wenn wir in der ersten Spalte eine fortlaufende Nummer hinzufügen, das mag der Chef halt und wir können in nachfolgenden Dokumenten einfach auf die Anforderungsnummer verweisen, damit der Leser dann halt noch ein weiteres Dokument suchen muss und so die Gefahr verringert ist, dass er am Arbeitsplatz einschläft.
Die aussagekräftige Gestaltung der Erläuterungsspalte ist gar nicht so leicht - überhaupt kann ich die ja eigentlich leer lassen, ich weiß ja, was gemeint ist, oder? Das Bild der Wunschliste zeigt sehr gut, dass nicht der Absender wissen muss, was gemeint ist, sondern dass die Empfänger es verstehen müssen - und das ist erfahrungsgemäß wesentlich schwieriger. Machen wir es uns an dieser Stelle leicht und verwenden wir ein Konzept zur Zieldefinition -SMART. Ziele müssen
- Spezifisch
- Messbar
- Erreichbar
- Realistisch und
- Terminiert
sein, dann funktionieren sie als Leitplanken. Ziele sind nun nicht gleich Anforderungen, aber aus Anforderungen resultieren Ziele. Daher schadet es nicht, bereits die Anforderungen zum Verständnis in einem breiteren Empfängerkreis SMART zu definieren. AROMA ginge natürlich ebenfalls.
So, an dieser Stelle haben wir eine tolle Liste mit Anforderungen, bestehend aus 3 Spalten. Welche Anforderung realisieren wir nun zuerst? Das wissen wir noch nicht. Wir finden im Excel allerdings noch eine Menge leerer Spalten vor, also: Füllen wir eine davon. Nennen wir diese Spalte "Priorität" und legen wir eine Skala fest. 1 bis 5, Schulnoten, 1 bis 10. Gehen wir unsere Anforderungen durch um sie derart zu priorisieren, so stellen wir fest, dass natürlich alle Anforderungen wichtig sind- andernfalls hätten wir uns ja auch nicht die Mühe gemacht, sie nieder zu schreiben. Wir machen ja schließlich nichts unwichtiges. Schlimmer wird das Problem noch, wenn wir die Anforderungsliste sinnvollerweise in einem bereichsübergreifenden Team durchgehen - da findet jeder etwas anderes wichtig und keiner will seine Anforderungen hinter denjenigen der Anderen zurückstellen. Die Lösung: Wir benennen die Spalte "Priorität" um in "Rangfolge" - eine Rangfolge ist eindeutig, Prioritäten sind das nicht - mit anderen Worten: Ich kann eine unendliche Anzahl von Aufgaben auf der maximalen Priorität haben, nur eine Rangfolge gibt eine eindeutige Abarbeitungsreihenfolge wieder. Unsere Anforderungsliste sieht nun so aus:
Wir bekommen das Projektteam dann irgendwie dazu, sich auf eine gemeinsame Rangfolge zu einigen und können glücklich sein?
Nein, leider noch nicht. Wer bis hierhin durchgehalten hat, kann nun schonmal eine tolle Anforderungsliste mit nur 4 Spalten erstellen, und die hilft wirklich enorm - der Clou kommt jedoch der Spannungskurve wegen natürlich am Ende: Die Rangfolge der Anforderungen stellt leider nur in den seltensten Fällen eine sinnvolle Abarbeitungsreihenfolge dar, insbesondere in komplexen Systemen. Auf die Abarbeitungsreihenfolge sollten wir jedoch bestenfalls bei der Anforderungsdefinition bereits achten, um dem nachfolgenden Realisierungsprojekt einen geschmeidigen Verlauf zu ermöglichen.
Nehmen wir ein Beispiel aus der Automobilindustrie: Das Team hat per Kundenbefragung herausgefunden, dass Reifen das wichtigste am Auto sind, die haben ja den Kontakt zur Straße - also Rang 1. Dicht gefolgt vom Motor, der muss kraftvoll sein und einen ordentlichen Sound haben - Rang 2. Also legen wir besonderes Augenmerk auf den Motor und lassen uns gute Reifen zuliefern - das können wir so nur leider nicht zusammen testen, dafür bräuchten wir mindestens noch die Karosserie - die ist allerdings aus Kundensicht Standard und vollkommen unsexy, also hat sie den letzten Platz bei der Rangfolge erhalten. Im schlimmsten Fall merken wir einen Konstruktionsfehler im Zusammenspiel der Komponenten unseres Autos dadurch erst kurz vor Fertigstellung. Das Beispiel mit dem Auto soll anschaulich sein - bei IT- Projekten ist es wesentlich schwieriger, eine sinnvolle Reihenfolge für Realisierungsschritte zu finden.
Die absolut beste Lösung, welche ich für dieses Problem gefunden habe ist, anstatt eines langatmig ausformulierten Lastenheftes, einer vermeintlich kundenfreundlichen Userstory oder einer langweiligen Excel- Liste einen anschaulichen Sollprozess zu malen. In den meisten IT- Projekten kann der Sollprozess alle davor genannten Schritte ersetzen, auch wenn die beschriebene Anforderungsliste ein tolles Dokument zur zusätzlichen Spezifizierung der Anforderungen darstellt. Bei der Erstellung physischer Projektergebnisse wäre der Sollprozess nachgelagert der Anforderungsliste zu erstellen.
Der Sollprozess gibt anschaulich eine praktikable Realisierungsreihenfolge vor: Als erstes werden diejenigen (System) Aufgaben realisiert, welche vorne im Sollprozess liegen - die können bereits getestet werden und liefern somit früh diejenigen Testgegenstände, welche auch nach Realisierung weiterer Prozessschritte benötigt werden. Testfälle müssen somit nicht für jeden Schritt neu erstellt werden, stattdessen werden sie zum Test nach Realisierung weiterer (System) Komponenten weiterverwendet. Anhand des Sollprozesses kann somit früh und mit möglichst wenig Aufwand mit zielführenden Tests begonnen werden.
Beherzigen Sie diese Hinweise, so haben Sie als Projektmanager mehr Zeit für die wesentlichen Dinge, die unsere Berufung erlebnisreich machen, z.B. das Schreiben von meterlangen Romanen per E-Mail oder dem Erstellen von umfangreichen Excel- Tabellen, die niemand außer Ihnen selbst versteht.
Welche Erfahrung haben Sie mit der Anforderungsdefinition und deren Abarbeitung in Projekten sammeln können? Werden Ihre Lastenhefte vom Empfänger verstanden und verstehen Sie die Pflichtenhefte Ihrer Auftragnehmer? Wünschen Sie sich Socken zu Weihnachten?
Lassen Sie es mich in Ihrem Kommentar wissen.
