Das Pflichtenheft - ein früher Stolperstein fürs Management

Als Manager oder Berater hat man gelernt in Prozessen zu denken. Da ist es nicht verwunderlich, dass auch das Managen von IT-Projekten als ein Prozess gesehen wird. Nach allgemeinem Verständnis umfasst dieser (grob vereinfacht) folgende Teilprozesse:

• Initiierung
• Planung
• Ausführung
• Überwachung und Steuerung
• Abschluss

Bei den Phasen Initiierung und Abschluss herrscht wenig Uneinigkeit. Anders sieht es da bei den übrigen drei Punkten aus.

In diesem Beitrag möchte ich mich der Planung etwas annehmen – genaugenommen dem Pflichtenheft.

Nachdem flächendeckend das Lastenheft mehr oder weniger ausgerottet und durch Meetings, Beratungs- und Anbahnungsgespräche abgelöst zu sein scheint, liegt der ganze Augenmerk eines Entwicklungsteams auf dem Pflichtenheft.
Das Pflichtenheft ist sozusagen die „Schnittstelle“ bzw. das, was von der Planung in die Ausführung übernommen wird. Es ist für die Entwickler das wichtigste Produkt der Planungsphase.

Planung

Die Planung, die nach obiger Sichtweise eigentlich eine Managementaufgabe ist, kann bei IT-Projekten kaum ohne die Entwickler geschehen. Meist unterstützt einer der Entwickler dabei den Projektmanager mit technischen Empfehlungen bei Erstellung des Pflichtenheftes.

Dabei wird der Entwickler mit der größten Erfahrung aus dem noch recht kleinen Entwicklerteam gewählt, da er die meiste Erfahrung hat. Man benötigt seine Empfehlungen zur Machbarkeit, Aufwandsabschätzung und Wahl einer geeigneten Technologie.

Kommt Ihnen das bekannt vor?
Wenn sie jetzt „Ja“ antworten wollten, dann sollten Sie jetzt dringend weiter lesen.
Denn hier läuft bereits in dieser frühen Phase eines Projektes einiges falsch.

Fehlende Softwarearchitekten

Aus Kostengründen können es sich nur große IT-Firmen leisten, Softwarearchitekten als Vollzeitkräfte einzustellen. Da wird dann, wie oben beschreiben, kurzerhand einfach ein Entwickler zum Architekten umgemünzt. Tragischer noch – meist ist es einer aus einer winzigen Gruppe von zwei bis drei. Größer sind Entwicklerteams zu diesem frühen Zeitpunkt selten. Das bedeutet man bekommt nicht den besten Entwickler aus hundert, sondern den besten aus eventuell drei.
Es sind auch mitnichten die besten Entwickler die so früh zur Verfügung stehen, sondern in der Regel einfach nur jene, die gerade frei geworden sind. (In diesem Zusammenhang sollte ich vielleicht eine persönliche Beobachtung hinzufügen: Die besten Entwickler scheinen am meisten belastet und am wenigsten verfügbar zu sein.)

Auf diese Weise werden architektonische Aufgaben der zahlreichen Projekte auf ebenso zahlreiche Entwickler verteilt. Jeder Entwickler bekommt einen Hauch davon mit, aber die gesamte Erfahrung wird letztendlich so breit verteilt, dass sich keine richtigen Expertisen bilden können.

Man verpasst die Chance einen Softwarearchitekten selbst auszubilden.

Pflichtenheft mit Mängeln

Durch die mangelnde Erfahrung des Entwicklers, was Softwarearchitektur angeht, werden nur bestimmte Informationen festgehalten. Was der Entwickler als selbstverständlich hält, wird nicht notiert. Dass anderen Entwicklern im Team das nicht so selbstverständlich sein muss, wird dabei meist nicht beachtet.

Dafür strotzt solch ein Pflichtenheft dann nur so vor Selbstverständlichkeiten. Hier werden akribisch Zusammenhänge erfasst, die für den Entwickler neu waren und lassen ein trügerisches Bild entstehen, man habe sich ausreichend mit der technischen Seite des Projektes beschäftigt.

Das hat dann nicht selten zur Folge, dass wesentliche Teile der Anforderungen gar nicht angefragt werden und im Pflichtenheft keiner Erwähnung gewürdigt werden.

Das solche Missstände nicht gleich sichtbar werden und ihnen auch später nicht viel Beachtung geschenkt wird liegt an dem Adjektiv „agil“ dass sich mittlerweile selbst ins Management rumgesprochen hat. Es muss als universelle Absolution für alle Sünden der Planungsphase herhalten. So werden Planungsfehler später aufwendig ausgebügelt und erzeugen einen nicht zurückverfolgbaren Aufwandsaufschlag bei der Umsetzung. Dass die Ursache möglicherweise bereits in den Planungsphase liegt, wird in der Regel vernachlässigt.

Es scheint das Motto zu gelten: Ein schlechter Plan ist besser als kein Plan.

Dies ist eine teure Einstellung, wenn man die Ausführungsphase betrachtet:

Ausführungsphase

Entwickler mögen klare Ziele und Aufgaben. Unklare Anforderungen haben einen viel zu großen Handlungsspielraum. Es mag zwar nett gemeint sein, dass man seinen Entwicklern alle Möglichkeiten offen halten will. Jedoch wollen Entwickler nicht alle möglichen Wege umsetzen. Einer genügt da schon. Welcher aber passend ist wird in so einem Fall erst durch unzählige Rückfragen geklärt. (Unter anderem auch Fragen zu Möglichkeiten, die der Kunde so nie angedacht hat. Entwickler sind meist kreativ, wenn es um Lösungsmöglichkeiten geht. – Und das ist positiv gemeint.)
Es ist wichtig darzulegen in welcher Weise die Software verwendet werden soll.

Man sollte dabei aber nach Möglichkeit nicht ohne triftigen Grund die zu verwendende Technik unnötig detailiert festlegen. (Dies ist ein häufiger Fehler unerfahrener Softwarearchitekten.) Ein Entwicklerteam strukturiert sich meist selbst und erarbeitet die beste Lösung. Ernennt man einen Entwickler des Teams zum Architekten, fehlt dieser Konsens. Abgesehen davon, dass die Lösung meist suboptimal ausfällt, ist die Unterstützung des Teams von vorne hinein beeinträchtigt.

Man signalisiert damit, nicht an die Kompetenz des Teams zu glauben. Sowas hat Auswirkungen auf die Moral. Selbst wenn der beste Entwickler die Architektur alleine genau so entwirft, wie es das Team gemacht hätte, ist die Unterstützung dann nicht immer gegeben.

Entscheidet das Team hingegen über die einzusetzende Technologie, ist es viel eher bereit diese zu tragen und zu verwenden. Natürlich kann es hier zu Bevorzugungen von „Lieblingstechnologien“ des Teams führen. Meist ist aber nicht die eingesetzte Technologie das Problem bei Projekten, sondern die Zeit und die Motivation der Beteiligten. Persönliche Präferenzen lassen sich ohnehin bei keinem Vorgehen vollständig ausschließen.

Fazit

Ein Pflichtenheft sollte nach Möglichkeit die Wünsche der Kunden erfassen und mögliche Rückfragen des Entwicklerteams antizipieren. Dafür wäre es ideal, unternehmensinterne oder externe Architekten zu beauftragen, welche Kenntnis über die Variationsbandbreite der umgebenden Infrastruktur kennen. Diese Kenntnis soll vorrangig dem Kunden dienen neue Möglichkeiten zu entdecken und Kosten abzuschätzen. Es sollte jedoch so weit wie möglich darauf verzichtet werden, die konkrete Umsetzung vorzugeben zu wollen, da dies eher Aufgabe des Entwicklerteams ist, dass sich andernfalls eher ablehnend dem Entwurf des Architekten entgegenstellen kann.

Der Erfolg eines Projektes hängt viel weniger von der konkreten Technologie als vom Engagement und Zusammenhalt der beteiligten Personen ab.