Schaffen Sie Ihr eigenes Vorgehen für die vertragliche Zusammenarbeit in Entwicklungsprojekten – das RCDA-Verfahren zeigt Ihnen den Weg.

Das RCDA-Verfahren liefert Ihnen ein Korsett für die vertragliche Zusammenarbeit in Entwicklungsprojekten. Völlig unabhängig von Ihrem konkreten Vertrags- oder Vorgehensmodell und ohne auf jedes am Markt gespielte Vertragsgebaren im Einzelnen einzugehen zeigen wir Ihnen hier ein Prinzip auf, nach dem Sie die Verbindlichkeiten von Artefakten seitens des Auftraggebers und seitens des Auftragsnehmers festlegen können.

Man nennt dieses Verfahren RCDA-Verfahren, da es das Zusammenspiel von Require, Commit, Deliver und Accept regelt.
Die oben gezeigte Grafik verdeutlicht das Prinzip.

Vom Grundsatz her gibt es ein „Require“ (die Forderung) des Auftraggebers, auf das der Auftragnehmer mit einem „Commit“ (einer Verpflichtung, Zustimmung) antwortet. Nach einer definierten Zeit (z. B. der Entwicklungsphase) stellt der Auftragnehmer ein „Deliver“ (die Lieferung) zur Verfügung, und der Auftraggeber spricht daraufhin hoffentlich ein „Accept“ (Abnahme) aus.

Durch welche Artefakte die vertraglich relevanten Schritte Require, Commit, Deliver und Accept genau repräsentiert werden, hängt von Ihrem Vertrags- und Vorgehensmodell ab. Wie die Artefakte erstellt werden, regelt das Vorgehensmodell. Natürlich kann der Prozess gerade bei iterativen Vorgehensmodellen auch mehrfach durchlaufen werden oder ohne Accept mit einem Reject (Ablehnung der Lieferung) enden.

Grundsätzlich muss an der Schnittstelle zwischen den beiden Vertragspartnern immer ein Artefakt definiert sein, dessen Inhalt, Qualität, Beschreibungsstil und Detaillierungsniveau vertraglich festgelegt ist. Generell sollten alle Ihre Verträge Aufschluss über die folgenden Punkte geben:
* Welche Artefakte des Auftraggebers (z. B. ein Lastenheft) werden als Vertragsbestandteil geliefert?
* Welche Artefakte des Auftragnehmers (z. B. Pflichtenheft) werden als Vertragsbestandteil geliefert, oder wird nur das Dokument des Auftraggebers „abgenickt“?
* Welche weiteren vertraglich vereinbarten Dokumente werden ausgetauscht?
* Welche Artefakte des Auftragnehmers (z. B. Code, ausführbare Dateien, Dokumentation, Testberichte) werden als Vertragsbestandteil bei der Lieferung übergeben?
* Wodurch drückt der Auftraggeber sein „Accept“ aus und wie seine Ablehnung?

Ein klassisches Beispiel entstammt dem Maschinenbau. Dort wird mit Lasten- und Pflichtenheften gearbeitet. Auch die IT stützt sich in vielen Projekten auf die althergebrachte und erprobte Abgrenzung beider Dokumente:
* Das Lastenheft umfasst die vom Auftraggeber notierten Forderungen, was das System leisten soll. Beispiel: „Das System soll 10 Getränke gleichzeitig befüllen.“ (Nach RCDA: „Require“ des Auftraggebers.)
* Das Pflichtenheft ist die vom Auftragnehmer verfasste Beschreibung, wie das System die Lastenheftanforderung realisieren wird. Beispiel: „Das System stellt 10 Auslasshähne. Das System hat x bar Druck auf den Füllstutzen, sodass innerhalb von 3s bis zu 10 Getränke gefüllt werden können. Das System ist mit Überdruckventilen (siehe Plan YZ), … ausgestattet.“ (Nach RCDA: Das „Commit“ des Auftragnehmers).

Bei der Vertragsgestaltung und dem Austausch von Dokumenten sind natürlich unterschiedliche Spielarten möglich, die vor allem vom Vertragsmodell und dem Vorgehensmodell, aber auch von den Fähigkeiten und der Motivation der Vertragspartner abhängen. Im Kapitel „Vertragspoker und Requirements-Engineering“ unseres Buches „Requirements-Engineering und -Management“ beschreiben wir Ihnen sehr ausführlich unterschiedliche Spielarten des Vertragsmanagements auf der Basis von Spezifikationen.
Generell gilt: Der Auftraggeber sollte sich darauf beschränken, das „Was“ (Was soll mein System können? Z. B. Löschen, Suchen, Anlegen, …) und die relevanten Schnittstellen zu beschreiben. Er ist normalerweise für eine lösungsneutrale Problembeschreibung zuständig. In Fällen, in denen er ein berechtigtes Interesse hat, den Lösungsspielraum einzuschränken, darf er natürlich auch eine Lösung vorgeben. Der Auftragnehmer muss sich auf das „Wie“ (Wie wird das System – die Umsetzung der „Was“-Forderung) konzentrieren. Seine Aufgabe ist es, eine Lösung für die Problemschilderung des Auftraggebers zu liefern.