Das hier ist eine Fortsetzung zu den beiden Blogs über die Abnahme und die Gewährleistungsansprüche im Werkvertragsrecht. Das Problem ist ganz einfach zu benennen und sehr schwer zu lösen. Das Werkvertragsrecht passt nicht zum Projektgeschäft.
Das liegt an vielen Faktoren: Das Werkvertragsrecht als Arbeitsgrundlage funktioniert, wenn beide Seiten Einigkeit über den vereinbarten Sollzustand haben. Diese Einigkeit muß in den Details bestehen. Das Werkvertragsrecht als Arbeitsgrundlage funktioniert, wenn der vereinbarte Sollzustand bis zur Abnahme nicht geändert wird. Damit sind für den Kenner die Tatsachen genannt, warum das Werkvertragsrecht nicht funktionieren kann.
Software ist kein Produkt wie ein Schrank oder ein Schuh. Schränke oder Schuhe können auf der Basis des Werkvertragsrechts erstellt werden, weil das Produkt in sich komplex sein mag, aber die Vorstellungen der Parteien über Aussehen und Funktion doch in einem einfachen Prozeß schnell überprüft und notfalls abgeglichen werden können. Das funktioniert mit Software nicht. Software ist ein hochkomplexes Produkt. Alleine die Funktionen von Microsoft Word zu verstehen und anzuwenden, wird viele Menschen überfordern. Möchte man aber ein Produkt wie Word herstellen lassen, wird man sich vorstellen wie komplex die Aufgabe sein wird, einem anderen Menschen zu erklären, welche Funktionen und Eigenschaften das gewünschte Programm hat.
Im Prinzip geht bei dem Prozeß der Erstellung oder Änderung von Software immer darum, das Know How aus dem Kopf des Anwenders auf den Bildschirm des Programmierers zu transportieren. Da der Anwender aber schon intellektuell oft nicht in der Lage ist, die Prozesse, die er täglich vollzieht auf abstrakter Ebene so schriftlich zu dokumentieren, daß der Programmierer auch eindeutig versteht, was gemeint ist. Hinzukommt, daß viele Anwender diese Beschreibungen neben der täglichen Arbeit machen sollen.
Und so ergibt es sich dann aus der Praxis, daß ungefähre Angaben des Anwenders reichen müssen, damitmit dem Projekt begonnen werden kann. Das Ungefähre aber ist Gift für das Werkvertragsrecht. Während des Projekts kommt es dann zu einem hermeneutischen Zirkel, in dem sich der Anwender und der Programmierer wie zwei Zwangsverheiratete auf einer Reise immer besser kennenlernen. Neben den eigentlichen Schwierigkeiten der Umsetzung, der Sprache an sich und der interdisziplinären Kommunikation zwischen Techniker und Anwender im Besonderen drängt immer die Zeit, es drängt immer das Budget. Gelangt der Anwender nach dem Vertragsabschluß zu einer neuen Erkenntnis – entweder, weil er jetzt auf einmal doch gut formulieren kann, was er vorher nicht gut in Worte fassen konnte – oder weil er nun angesichts eines Probelaufs der Software am Objekt erkennen kann, daß etwas noch nicht stimmt, spricht der ITler von Changes und meint mehr und höhere Vergütungen. Viele Changes werden verlangt und zugesagt, ohne daß die Planung noch einmal grundsätzlich überarbeitet wird. In den Verträgen stehen häufig ellenlange Regelungen über die Change Verfahren. In der Praxis erweisen sie sich als zu aufwändig.
Und das schönste an allem ist dann immer die Abnahmeprüfung. In vielen Fällen beginnen die Parteien mit viel Fleiß eine Dokumentation zu erstellen, die dann im weiteren Verlauf des Projekts immer mehr an Bedeutung verliert. Und bei der Abnahme gehen viele Kunden produktiv, ohne eine Prüfung gegen die mit viel Mühsal erstelle Dokumentation vorzunehmen.
Was soll man jetzt machen? Die Kunden wollen gerne Werkvertragsrecht vereinbaren, als ITler weiß man um seine Tücken (und versierte Kunden kennen diese auch).
Im Grunde genommen zielt das Werkvertragsrecht auf eine Planungssicherheit und Budgetsicherheit, die es in einem Projekt ab einer Stufe mittlerer Komplexität einfach nicht geben kann. Wenn man wirklich im Werkvertragsrecht arbeiten will, wird man nicht umhin können, viel Zeit, Manpower und Geld dafür einzusetzen, daß die Vorstellung des Kunden und Vorstellung des Technikers wirklich zusammenwachsen dafür eine Dokumentation erstellt wird, die die Prüfung ermöglicht ob dieses Zusammenwachsen stattfindet oder noch wesentliche Lücken bestehen.
Den einzigen (und nicht immer praxisgerechten Rat), den man geben kann, ist in möglichst kleinen Portionen zu arbeiten. Das aber auch nur dann, wenn die einzelnen Portionen für sich genommen arbeitsfähige Ergebnisse zeitigen. Sind die Portionen nur Schritte auf dem Weg zu einem Großen und Ganzen, ist auch dieser Rat sinnlos.
In einem neuen Aufsatz von Herrn Prof. Schneider – einer der Autoritäten des IT Rechts – wird wieder beschrieben, warum auch neuere Lösungsansätze zur Lösung dieses Problems nicht funktionieren. Teilabnahmen können funktionieren, wenn man das Projekt in Milestones zerlegt, aber eben nur dann, wenn diese Teilabnahmen auch verbindlich sind. Sonst bleiben die beschriebenen Unsicherheiten bestehen. Der zweite Ansatz, die Fragestellung zwischen echten/ und unechten Changes hintenanzustellen und beide immer als Changes zu behandeln, überzeugt mich dagegen nicht. Es geht bei der Frage ums Geld. Der Vorschlag, den ich immer wieder mache und den auch viele meiner Kollegen unterbreiten lautet, die Frage nicht zu diskutieren sondern zu sagen, daß der ITler eine bestimmte Anzahl an Manntagen verschenkt, um die Changes zu realisieren, ab dieser Stufe arbeitet er auf der Hälfte der normalen Tagessätze für eine bestimmte Anzahl von Tagessätzen und ab dieser Anzahl werden die Changes nach Beauftragung zu normalen Sätzen realisiert.
