Werkvertrag: Ergebnis, Abnahme und Vergütung im Softwareprojekt

Ein Werkvertrag verpflichtet den Auftragnehmer, ein genau beschriebenes Ergebnis herzustellen: ein lauffähiges Modul, eine fertige Anwendung, eine abgenommene Schnittstelle. Vergütet wird nach der Abnahme und nicht nach aufgewendeter Zeit. Womit und mit wem das Ergebnis entsteht, entscheidet der Auftragnehmer. Geregelt ist diese Vertragsform in den §§ 631 ff. BGB.

Der Werkvertrag im BGB: Definition nach § 631

Das Bürgerliche Gesetzbuch formuliert die beiden Pflichten knapp: Der Unternehmer schuldet die Herstellung des versprochenen Werkes, der Besteller die Zahlung der vereinbarten Vergütung. Das Gesetz spricht vom Werk, nicht von Arbeitsstunden. Übertragen auf ein Webprojekt heißt das: Vertragsgegenstand ist ein Liefergegenstand, den beide Seiten vor dem Start beschreiben können – ein Kundenportal, ein Bestellmodul, eine Datenmigration, ein Release.

Ein Werk muss dabei nichts Körperliches sein. Eine Anwendung, die Anbindung an ein Fremdsystem oder ein überarbeitetes Datenmodell sind Werke wie ein gebautes Treppenhaus. Entscheidend ist, dass ein Zustand beschrieben ist, der am Ende überprüft werden kann. Fehlt diese Beschreibung, bleibt vom Vertrag nur eine Absichtserklärung, und der Streit beginnt bei der Rechnung.

Erfolg statt Tätigkeit: die Abgrenzung

Die Gegenform ist der Dienstvertrag nach § 611 BGB. Dort schuldet der Auftragnehmer eine Tätigkeit – Beratung, Betreuung, Entwicklung nach fachlichem Standard –, aber kein bestimmtes Resultat. Wer laufende Wartung einkauft, kauft eine Tätigkeit. Wer ein Portal bis zum Livegang einkauft, kauft ein Ergebnis.

Welche Form tatsächlich vorliegt, entscheidet nicht die Überschrift des Dokuments, sondern die gelebte Praxis: Wer verteilt die Aufgaben, wer prüft die Arbeit, wessen Prozesse und Werkzeuge werden benutzt. Aus demselben Grund gehört zu einem ergebnisbezogenen Vertrag eine Beschreibung, die ohne mündliche Ergänzung auskommt. Wo diese Grenze rechtlich verläuft, behandelt der Artikel wo die rechtliche Grenze der Vertragsform verläuft.

Die Abnahme: wann das Werk als geliefert gilt

Die Abnahme ist der zentrale Moment jedes Werkvertrags, weil an ihr vier Rechtsfolgen hängen:

• Fälligkeit. Die Vergütung wird mit der Abnahme fällig, nicht mit dem Ende der Arbeit.
• Gefahrübergang. Ab diesem Zeitpunkt trägt der Besteller das Risiko für den weiteren Betrieb.
• Beweislast. Vor der Abnahme muss der Auftragnehmer die Mangelfreiheit belegen, danach der Besteller den Mangel.
• Verjährung. Die Frist für Mängelansprüche beginnt zu laufen.

In Softwareprojekten funktioniert dieser Moment nur, wenn die Kriterien vorher feststehen. Brauchbare Kriterien sind beobachtbar: definierte Testfälle laufen durch, ein Import verarbeitet einen festgelegten Datenbestand vollständig, eine Anbindung liefert dieselben Werte wie das Quellsystem. Unbrauchbar sind Formeln wie „die Anwendung läuft stabil“ oder „das Design gefällt“, weil sie erst nach der Lieferung ausgelegt werden.

Teilabnahmen statt einer einzigen großen Abnahme

Bewährt haben sich Teilabnahmen: Jede Etappe hat einen eigenen Liefergegenstand und eigene Kriterien. Der Besteller sieht früh, was er bekommt, und beide Seiten korrigieren, solange eine Korrektur billig ist.

Leistungsbeschreibung im Werkvertrag: Lastenheft und Pflichtenheft

Die Leistungsbeschreibung ist der Teil, der über Erfolg oder Streit entscheidet. Sie entsteht in zwei Schritten: Der Auftraggeber beschreibt, was er braucht und wofür, der Auftragnehmer beschreibt, wie er es umsetzt – die klassische Aufgabenteilung von Lastenheft und Pflichtenheft.

Für Web- und Softwareprojekte gehören mindestens hinein: Rollen und Rechte, die Liste der Seiten oder Bildschirmmasken, das Datenmodell in Grundzügen, jede Schnittstelle zu einem Fremdsystem mit Richtung und Auslöser, das Verhalten bei Fehlern, die unterstützten Browser oder Endgeräte sowie die Frage, wer Inhalte und Testdaten liefert. Aus diesen Punkten werden die Abnahmekriterien abgeleitet, nicht umgekehrt.

Ein Beispiel aus unserer Arbeit, anonymisiert: Bei der Übernahme von 19 686 Bestellungen aus fünf Jahren in ein neues CRM lautete das Kriterium nicht „Daten sind migriert“, sondern „jede Bestellung ist genau einmal vorhanden, keine einzige Dublette, Summen je Kunde stimmen mit dem Altsystem überein“. Ein solcher Satz ist prüfbar, und genau das macht ihn vertragstauglich.

Mängelrechte, Nachträge und Vergütung

Zeigt sich nach der Lieferung ein Mangel, greift § 634 BGB: zuerst Nacherfüllung, danach je nach Lage Selbstvornahme, Minderung oder Rücktritt und Schadensersatz. Für den Auftraggeber ist der wichtigste Punkt, dass die Nacherfüllung nicht gesondert vergütet wird – sie gehört zum ursprünglichen Preis.

Davon zu trennen sind Änderungswünsche. Wer während der Umsetzung eine zusätzliche Funktion möchte, ändert das Werk, nicht dessen Qualität. Solche Wünsche werden als Nachtrag beschrieben, bewertet und getrennt beauftragt. Wird diese Grenze nicht gezogen, wächst der Umfang still weiter, und am Ende diskutieren beide Seiten über eine Rechnung statt über die Software. Wie sich das mit einem festen Preis oder einer Abrechnung nach Aufwand verträgt, behandelt der Artikel Festpreis oder Tagessatz.

Wie wir den Zuschnitt in Webprojekten machen

Wir schneiden Projekte in Etappen mit je einem eigenen Liefergegenstand: ein Datenmodell samt Migrationsskript, ein Modul mit Oberfläche, eine Anbindung an ein Fremdsystem. Zu jeder Etappe stehen die Abnahmekriterien im Angebot, bevor die Arbeit beginnt; fachliche Weisungen an unsere Entwickler laufen über unsere Projektleitung, Code und Zugänge stehen dem Auftraggeber vom ersten Tag an offen. Wie daraus ein Projektablauf wird, steht auf der Seite Softwareentwicklung.