Pflichtenheft, Pflichtenheft, Pflichtenheft
Ich habe in letzter Zeit immer wieder mit Software-Entwicklern zu tun. Als juristisch-technisches Amphibium bekomme ich früher oder später Geschichten über schiefgelaufene Projekte zu hören. Der Ablauf ist meist der selbe: Ein Kunde hat einen Auftrag erteilt und will nach Fertigstellung der Arbeit nicht bezahlen, weil einzelne Features fehlen, Fristen nicht eingehalten wurden oder anderweitig die Erwartungen nicht erfüllt werden.
All diesen Entwicklern gebe ich einen Appell mit auf den Weg: Pflichtenheft, Pflichtenheft, Pflichtenheft.
Was ist ein Pflichtenheft?
In einem Pflichtenheft sind alle wesentlichen Bestandteile eines Auftrages festgehalten. Im Unterschied zu Allgemeinen Geschäftsbedingungen geht es beim Pflichtenheft um die konkreten Anforderungen eines jeden Projekts. Der Name sagt es schon: Die AGB sind allgemein, das Pflichtenheft ist konkret. Während man also in den AGB generelle Regeln wie Zahlungsfristen, Abläufe bei der Abnahme und Ähnliches regelt, definiert das Pflichtenheft, was genau auf welche Art und Weise für einen bestimmten Kunden gemacht werden soll. Sinnvollerweise ist das Pflichtenheft in der Regel Anlage und damit Bestandteil des Vertrages, den Kunde und Dienstleister schließen.
Zu unterscheiden ist das Pflichtenheft vom sog. Lastenheft. Vor allem bei größeren Projekten werden bereits vom Kunden im Lastenheft die genauen Anforderungen an das Produkt definiert. Es hält also die Erwartungen des Kunden an das Endprodukt fest – das Pflichtenheft regelt dagegen die genauen Modalitäten wie diese Anforderungen erfüllt werden sollen.
Warum ist das Pflichtenheft so wichtig?
Wie eigentlich überall in der Dienstleistungsbranche treffen auch bei der Software-Entwicklung meist zwei Erwartungen aufeinander: Der Kunde möchte ein möglichst qualitativ hochwertiges Produkt für möglichst wenig Geld, der Designer oder Software-Entwickler muss seinen Aufwand in Grenzen halten, seine Kosten decken und einen Gewinn einfahren. Ziel eines vernünftigen Vertrages zwischen Kunde und Entwickler ist es deshalb, diese beiden Interessen unter einen Hut zu bringen.
Hier hilft ein Pflichtenheft: Dort ist festgehalten, was genau eigentlich entwickelt werden soll, welcher Zeitplan gilt und für was genau welche Kosten anfallen. Das bringt Klarheit für beide Seiten: Der Kunde weiß, was für ein Produkt er erwarten kann, der Entwickler weiß, mit welchem Aufwand er kalkulieren muss. Sehr viele Streitigkeiten lassen sich so im Vorfeld vermeiden.
Was sollte ein Pflichtenheft enthalten?
Der Umfang eines Pflichtenheftes hängt vom jeweiligen Projekt ab. Für ein kleines Projekt lohnt es sich meist nicht, auf vielen Seiten Papier festzuhalten, in welchen genauen Abschnitten die Entwicklung zu erfolgen hat – das Erstellen das Pflichtenhefts wäre möglicherweise aufwändiger als das eigentliche Projekt. Dennoch gibt es einige Punkte, die ein Pflichtenheft in jedem Fall enthalten sollte.
1. Zweckbeschreibung
Mit einer kurzen Beschreibung wozu ein Produkt überhaupt benötigt wird, lässt es sich meist ganz gut in die Definition der Erwartungen einsteigen. Soll zum Beispiel eine Anwendung erstellt werden, um sie anschließend bei Facebook einzubinden, ist klar, welches Ergebnis am Ende der Entwicklung stehen soll: Nicht irgendeine lauffähige Software, sondern eine, die auch die Spezifikationen von Facebook einhält.
2. Features
Was genau soll die Software können, was genau der Style-Guide enthalten? Kurz: Was genau soll eigentlich gemacht werden? Liegt ein Lastenheft des Kunden vor, kann man darauf Bezug nehmen. Andernfalls sollte mit dem Kunden genau abgeklärt werden, was genau geschuldet sein soll und – fast noch wichtiger – was nicht. Soll zum Beispiel eine App für das iPhone entwickelt werden, ist es sinnvoll auch klarzustellen, dass es keine Android-Version geben soll. Soll die App nur Fotos speichern können oder sollen diese Fotos auch per Mail verschickt werden können? Je genauer man an dieser Stelle definiert, was genau gemacht werden soll, desto besser vermeidet man potentielle Angriffsflächen für späteren Streit. Beide Parteien des Vertrages wissen, auf was sie sich einstellen können.
3. Technische Rahmenbedingungen
Welche technischen Rahmenbedingungen müssen erfüllt sein? Wird eine bestimmte Software benötigt, um die geplante Software benutzen zu können? Gibt es spezielle Systemanforderungen? In welchem Format sollen Daten ausgeliefert werden? An dieser Stelle ist vor allem die Beratung und Aufklärung des Designers oder Software-Entwicklers nötig, um den Kunden nicht am Ende zu enttäuschen oder ein Produkt zu erstellen, das der Kunde nicht benutzen kann.
4. Urheberrecht
Welche Rechte soll der Kunde am Produkt enthalten? Soll er das Recht haben, Sublizenzen zu erhalten, soll ein ausschließliches Nutzungsrecht eingeräumt werden oder sollen andere Lizenzmodelle zur Anwendung kommen? Sofern die Allgemeinen Geschäftsbedingungen zu diesem Punkt keine Regelung enthalten oder von diesen AGB-Klauseln abgewichen werden soll, ist es sinnvoll, dies im Pflichtenheft deutlich zu machen.
5. Mitwirkungspflichten des Kunden
Bei vielen Projekten ist die Mitarbeit des Kunden gefragt: Texte müssen angeliefert, interne Abläufe abgestimmt und Daten beschafft werden. Was genau der Part des Kunden beim Ablauf des Projektes ist, sollte – sofern nötig – ebenfalls zumindest kurz skizziert werden. Vor allem im Hinblick auf den nächsten Punkt im Pflichtenheft.
6. Zeitplan
Oft hilft das beste Produkt nichts, wenn es zu spät kommt. Werden die Banner für den Messestand erst nach der Messe ausgeliefert, ist Streit vorprogrammiert. Umgekehrt ist es auch für den Dienstleister ärgerlich und unter Umständen durchaus kostenintensiv, wenn sich ein Projekt unnötig in die Länge zieht. Bis wann soll das konkrete Projekt also abgeschlossen sein? Ist das Projekt in mehrere Phasen aufgeteilt und wann sollen diese abgeschlossen sein? Muss der Kunde bis zu einem bestimmten Zeitpunkt Daten angeliefert haben? Sind Abschlagszahlungen zu bestimmten Terminen vereinbart? Eine vernünftige Zeitplanung kann viel Ärger vermeiden.
Fazit
Über den genauen Umfang von Pflichtenheften sind schon viele dicke Bücher geschrieben worden. Diese Übersicht ist also bei Weitem nicht vollständig und für Großprojekte sicher auch viel zu oberflächlich. Oft sind es jedoch die kleinen Aufträge, die im Agenturalltag Ärger machen. Mit einem kurzen, aber aussagekräftigen Pflichtenheft können diese Streitigkeiten in sehr vielen Fällen vermieden werden, ohne dass sie großen Aufwand produzieren. Für standardisierte Produkte genügen möglicherweise sogar einfache Checklisten, die einfach an den jeweiligen Vertrag angehängt werden. Entscheidend ist, dass die Erwartungen beider Seiten – von Kunde und Dienstleister – klar und verständlich festgehalten sind.
