Sieben Tipps zur Erstellung von Lastenheften – Teil I

Wenn es um die Erstellung von Lastenheften geht, kann man gewisse Fehler vermeiden – wenn man sich von Beginn an bewusst macht, welche diese sind und wie und warum sie entstehen.

In dieser und der folgenden Ausgabe des Blogs möchte ich Euch sieben entscheidende Tipps geben, die die Erstellung von Lastenheften vereinfachen und Fehlerquellen minimieren.

Tipp 1: Realistische und strikte Zeitplanung und -einhaltung!

Ihr müsst Eure (und meine) Zeit sinnvoll einplanen – und dranbleiben. Bei meinen Erstgesprächen für die Erstellung eines Lastenheftes mit den Entwicklungsleitern kommt sehr schnell die Frage: „Wie viel Zeit werden wir brauchen?“

Zunächst sind der Footprint-Workshop und der Aufbau der Release-Strategie ganz wichtig – auf diesen beiden Grundlagen basiert schließlich der gesamte Rest. Zeitlich sind sie allerdings nicht so wahnsinnig aufwändig: Diese beiden Punkte sind relativ einfach in ein bis zwei Tagen abzuarbeiten.

Dann geht es um das Erarbeiten der Inhalte (also der Teile 0.3, 0.5, 0.7, 0.8, 0.9, 1.0) – und hier müssen wir zwischen dem Aufwand und der Dauer unterscheiden. Der Aufwand auf Seiten des Projektes entsteht, weil noch fehlende Teile beschrieben werden und viele Inhalte zum Review müssen.

Der Aufwand auf meiner Seite ist ein etwas anderer: Ich kümmere mich mit meinem Erfahrungsschatz und meinem Wissen – quasi mit der Hand auf dem Ganzen – um die Erstellung und das „Hübsch-Machen“. Beim B.-Braun-Projekt beispielsweise belief sich mein Aufwand auf 18 Tage.

Man könnte meinen, dies klinge relativ locker – doch Vorsicht: Aufwand ist nicht Dauer! Denn gleichzeitig bedeutet diese Vorgehensweise auch: Wenn irgendjemand im Projekt etwas sucht oder erarbeitet, ist das eine Phase, in der ich zunächst auf weiteren Input warte. Entscheidend für die Organisation ist hierbei, dass ich je nach Projektphase ca. zwei Tage pro Woche für solche 18-Tage-Projekte einplane.

Somit bedeutet dieser Aufwand also eine Dauer von vier Monaten – und das ist nicht unüblich. Bei der Berechnung kommt es auch auf die Größe und die Komplexität des Systems an: Bei überschaubaren Subkomponenten und einem übersichtlichen Entwicklungsteam war das schnellste Lastenheft in ca. drei Wochen erstellt, das aufwändigste dauerte hingegen acht Monate: Hier handelte es sich um ein hochkomplexes, hochintegratives System von Systemen.

Mein Fazit: Unterschätzt die Dauer nicht, auch wenn der Aufwand nicht allzu hoch sein mag.

Plant also die Zeit ein – und vor allem: Bleibt dran! Das ist ein ganz großer Punkt. Immer wieder erstelle ich für Projekte Lastenhefte und merke, dass die Aktivitäten peu à peu weniger werden oder gar im Sande verlaufen.

Hierbei ist der Projektleiter ganz entscheidend, denn ich kann die Motivation des Teams nicht steuern, das kann nur er: Wenn der Projektleiter sich dahinterklemmt, dranbleibt und das Ganze wirklich planmäßig abschließen WILL, dann schaffen wir es auch.

Tipp 2: Weniger ist mehr!

Ich bekomme bei den Vorbereitungen immer wieder zu hören, dass man am liebsten alles und jeden noch in das Lastenheft hineinschreiben möchte. Meine Antwort: „Nein.“

Der große Trick, die große Kunst ist, zu streichen. So lange zu kürzen, bis wir merken: Wenn wir diesen Teil jetzt löschen – diesen Satz, dieses Kapitel, dieses Unterkapitel –, verändern wir den Inhalt entscheidend. Für uns Ingenieure ist es ganz normal, zu viel zu dokumentieren, zu viel hineinzuschreiben – allerdings führt das nicht zu einem Mehrwert im Verständnis, ganz im Gegenteil: Meist führt es nur zu Unklarheiten.

Hier helfen mir die Inhalte der Phasen 1.5 bis 1.8, also die Peer-Reviews, die ich parallel mache und in denen ich ebenso die Frage stelle: „Muss das da rein? Kann man das nicht komprimieren, fokussieren, rausschmeißen?“.

Dieses „weniger ist mehr“ ist ganz wichtig, wenn schließlich Punkt 1.0 in der Welt ist und darauf basierend vielleicht andere, neue Kollegen mit der Umsetzung konfrontiert werden.

Tipp 3: Kein Pseudo-Code!

Pseudo-Code kommt primär im Embedded-Software-Umfeld vor – und gehört dort auch hin. Ich hingegen schreibe keinen Pseudo-Code, denn dies ist eine Lösungsbeschreibung, auf der basierend vor allem Softwareentwickler Quellcodes umsetzen sollen.

Ich mache aber in einem Lastenheft für ein komplexes technisches System auf der obersten Ebene keine Lösungsbeschreibung, die irgendwo ganz unten und viel später eine Embedded-Software im Design umzusetzen hat.

Wenn ich ein Verhalten beschreiben muss, kann ich das wunderbar mit anderen Mitteln machen, aber eben nicht mit Pseudo-Code. Das Gleiche gilt als Bild übrigens auch für die Elektronik und für die Konstruktion.

 

Hier geht es zu den nächsten vier der sieben Tipps