Pflichtenhefte

"Was soll denn nun an Pflichtenheften schon wieder falsch sein?" (höre ich gedanklich die genervte Frage)

Gegenfrage: Wieviel Spaß macht es Ihnen, ein Pflichtenheft zu schreiben?

Und allein der Name: PFLICHTEN HEFT ! Pflichten mag ja wohl keiner wirklich gern – ich auf jeden Fall nicht und Hefte sind mir aus der Schule in eher unangenehmer Erinnerung.

Gut, aber Streitereien dieser Art bringen uns nun wirklich nicht weiter und Argumente auf dem Niveau der Namenskritik auch nicht.

Pflichtenhefte stellen eine möglichst vollständige Auflistung der Anforderungen an ein System dar. Und sie bilden die Grundlage für eine Art Vertrag mit der Entwicklung oder dem Entwickler.

Nun hat es mit Anforderungen eine etwas eigenartige Bewandtnis:

Je nachdem wie rum man draufschaut, sind sie Anforderung oder Lösung, sind sie WIE oder WAS:

Man nehme sich eine beliebige Anforderung her und stelle dann die nicht immer gern gehörte Frage: Ja aber warum soll ich das machen? Warum brauchen wir dieses Leistungsmerkmal? etc.

Möglicherweise hat die Anforderung an dieser Stelle schon abgedankt. Falls aber nicht, taucht irgendein Grund auf. Dieser Grund nun wiederum ist eine höhere Anforderung und aus ihrer Sicht ist unsere "niedrigere" Anforderung vom Anfang eine Lösung. Denn wenn man von dieser höheren Anforderung aus herunterschaut sind sehr wahrscheinlich auch andere Lösungen denkbar.

Dieses Spiel kann man immer weiter treiben und schließlich gelangt man – wer hätte das gedacht – zur Vision, zum eigentlichen Zweck, zur zentralen Hauptfunktion. (Falls das Projekt im Verlaufe dieses Spiels nicht eingestellt wurde.)

Und genau dieses Spiel möchte ich hier auch empfehlen und zwar anstelle eines Pflichtenheftes.

Denn schreibt man ein Pflichtenheft, dann

• ist die Blickrichtung auf den Details, wo sich die Energie verabschiedet
• verliert man den Blick fürs Wesentliche
• schreibt man lauter Sachen auf, die sich im Verlauf der Entwicklung sowieso noch x-mal ändern. Sie sollen es zwar nicht, tun es aber trotzdem.
• weiß man nicht, wo man aufhören soll, denn was in Richtung Vision funktioniert, geht auch umgekehrt und aus einem Leistungsmerkmal ergibt sich ein Leistungsmerkmal, ergibt sich ein Leistungsmerkmal, (Endlosschleife erkannt und gestoppt)

"Aber ohne Pflichtenheft wissen wir doch gar nicht, was wir entwickeln sollen."

Doch! Nämlich die Hauptfunktion als Basisapplikation. Und die haben wir ja gefunden, indem wir den Leistungsmerkmalen mal ordentlich auf den Zahn gefühlt haben.

Existiert die Basisapplikation erst einmal, ergibt sich das weitere aus dem Dialog mit der Praxis. Und ein Leistungsmerkmal, das im praktischen Gebrauch nicht kräftig wieder anklopft, braucht auch kein Mensch. Es gibt schließlich schon genug überflüssige Software und auch Entwickler, die schon lange keinen Urlaub mehr hatten und es abends nie ins Fitnessstudio schaffen, weil sie immer so lange arbeiten müssen.

Da wäre noch die Angst, Leistungsmerkmale könnten ohne Pflichtenheft verloren gehen ... Gut so! Weg damit!

Ein Wort zur Praxis: Natürlich schreibt man sich im Gespräch mit Kunden oder zukünftigen Anwendern deren Wünsche auf und natürlich gibt es gerade bei Projekten wie der 101-sten Entwicklung eines Warenwirtschaftssystems eine Menge Leistungsmerkmale, über die man sich schon im Vorhinein sicher ist. Aber das ist etwas ganz anderes, als diese akribische Sammelei von Features, wie sie mit Pflichtenheften getrieben wird.

Bleibt das Thema: Das Pflichtenheft als Vertrag zwischen Auftraggeber und Entwickler:

In dieser Eigenschaft stehen Pflichtenhefte im krassen Widerspruch zur Eigendynamik schöpferischer Prozesse. Es wird versucht, einen Prozess zu kontrollieren, der nicht kontrollierbar ist und die Unwägbarkeiten werden in äußerst unfairer Weise auf den Entwickler abgeschoben. Der ist dann auch regelmäßig der Sündenbock, wenn es – wie nicht anders zu erwarten – anders kommt als vorausgeplant.