Wenn Software scheitert, liegt die Ursache oft weniger im Code als im Vertrag. Entscheidend ist, ob Erfolg oder Aufwand geschuldet wird: Werden agile Vorhaben faktisch als Werkvertrag gestaltet, kann plötzlich das gesamte Backlog als geschuldet gelten. Klare Leistungsbeschreibungen, nachvollziehbare Qualitätskriterien und eine gemeinsam gelebte Definition des Stands der Technik reduzieren Haftung, Gewährleistung und Streit. Sinnvoll ist, auf relevante Metriken wie die erwartete Restfehlerrate zu schauen statt auf bloße Coverage.
In dieser Episode spreche ich mit Sebastian Dietrich über rechtliche Fallstricke in Softwareprojekten. Er ist Gerichtssachverständiger und zeigt, warum Freelancer nicht nur Einsatz, sondern Erfolg schulden. Bugs, Gewährleistung, Haftung, Warnpflicht. Alles hat Gewicht. Für Unternehmen wird es heikel, wenn agile Verträge als Werkverträge gelten und plötzlich das ganze Backlog geschuldet ist. Wir diskutieren, wie man Dienstleistung sauber beschreibt, technische Qualität definiert und den Stand der Technik als gemeinsamen Prozess festhält. Statt Coverage-Fetisch schauen wir auf Restfehlerrate.
"Im Gegensatz zu einem Angestellten schuldet ein Selbstständiger einen Erfolg und nicht nur ein Bemühen." - Sebastian Dietrich
Seit 2003 ist Sebastian Dietrich neben seinen Tätigkeiten als Trainer, Berater und Softwarearchitekt als Sachverständiger für Softwarequalität und Softwarewartung tätig. Seit 2015 als allgemein beeideter und gerichtlich zertifizierter Sachverständiger. In dieser Rolle stellt er im Rahmen von Ausschreibung, Umsetzung, Test, Abnahme und Wartung von Software sicher, dass diese dem Stand der Technik entspricht und weder veraltet noch unwartbar wird. Wenn nötig auch als Gerichtssachverständiger im Streitfall.
Verträge in der Softwareentwicklung nerven viele. Die meisten Entwickler und Tester wollen programmieren oder testen, nicht Paragraphen lesen und Textpassagen formulieren. Doch Verträge sind nicht nur Papierkram. Sie entscheiden im Streitfall, ob ein Unternehmen pleitegeht oder ein Freelancer auf Schadenersatz verklagt wird. Im Podcast Software Testing sprechen Richie und Sebastian Dietrich ganz offen über rechtliche Stolperfallen und führen durch die wichtigsten Punkte für sichere Verträge.
Freelancer in der IT sind oft stolz auf ihre Arbeit und zeigen ihren Einsatz über viele Stunden im Projekt. Aber: Wer selbstständig arbeitet, schuldet dem Kunden nicht nur Fleiß, sondern einen echten Projekterfolg. Das heißt: Die Arbeit muss ein bestimmtes Ziel erfüllen, zum Beispiel eine funktionsfähige Software liefern. Wenn dabei Fehler passieren, haften die Entwickler und Tester dafür.
Wie kann man sich davor schützen, für jeden kleinen Bug haftbar gemacht zu werden? Das Wichtigste: In den Vertrag aufnehmen, dass Fehler technisch normal sind und dass die Behebung kleiner Fehler nach Aufwand bezahlt wird, nicht als Gewährleistung. Sebastian Dietrich erklärt klar, dass man grobe Fahrlässigkeit nicht ausschließen kann, aber für leichte Fahrlässigkeit nicht haftet, wenn man das vertraglich klärt.
Viele glauben, ein Vertrag ist sofort ein Werkvertrag oder ein Dienstleistungsvertrag, je nach Überschrift oder Zahlungsweise. Das ist ein Irrtum. Entscheidend ist, was im Vertrag wirklich steht und wie es beide Parteien verstehen. Besonders bei agilen Projekten, bei denen das Ergebnis zu Beginn oft unklar ist, kann aus einem scheinbaren Dienstleistungsvertrag schnell ein Werkvertrag werden, der den vollen Projekterfolg fordert.
Im Podcast schildert Sebastian Dietrich Fälle, wo Kunden das Backlog immer weiter auffüllten, die Software nie "fertig" wurde, Zahlungen ausblieben und Unternehmen klagten. Die Lösung: Den Vertrag so formulieren, dass der Auftraggeber aktiv am Prozess beteiligt ist, dass die Dienstleistung im Vordergrund steht und nicht das perfekte Endprodukt. Einfache Sätze können hier Millionen schützen.
Was ist "Stand der Technik"? Viele schreiben das in Verträge, ohne zu wissen, wie schwammig der Begriff ist. "Stand der Technik" meint nicht immer das Neueste vom Neuen, sondern das, was sich bewährt hat und als sicher gilt. Im Streitfall wird oft ein Sachverständiger geholt, der prüft, ob die angewandten Methoden mit dem üblichen Standard vergleichbar sind.
Zum Beispiel: Ist Mob Programming wirklich besser als Peer Programming? Gibt es Wissenschaft dazu? Nein, sagt Sebastian Dietrich. Ohne Studien zählt das, was sich als effizient und sicher bewährt hat. Darum ist es klug, im Vertrag einen gemeinsamen Entscheidungsprozess mit dem Kunden zu vereinbaren, wie die eingesetzten Techniken und Tools ausgewählt werden.
Viele reden über Testabdeckung ("Coverage"), doch die Zahl der verbleibenden Fehler (“Restfehlerrate”) kann wichtiger sein. Sebastian Dietrich sagt: Bei zu hoher Fehlerrate ist ein Produkt nicht abnahmebereit. Neue Methoden wie Tests mit KI sind spannend, aber noch nicht Stand der Technik, weil es dazu kaum Forschung gibt. Wer nur damit arbeitet, geht ein rechtliches Risiko ein. Der Stand der Technik ist immer das, was zum Zeitpunkt der Übergabe als sicher gilt – nicht beim Projektstart.
Der Vertrag ist nicht für den Freund gedacht, sondern für den Feind, sagt Sebastian Dietrich offen. Im Streitfall zählen die kleinen, klaren Sätze, die vor Haftung und finanziellen Schäden schützen. Wer sich unsicher ist, sollte Verträge prüfen lassen, bevor das böse Erwachen kommt. Das kostet wenig Zeit, kann aber die Existenz retten.
Softwareprojekte sind mehr als Technik. Sie sind rechtlich verminte Felder. Wer sich absichert, spart nicht nur Nerven, sondern rettet im Ernstfall die eigene Existenz. Mehr Klarheit, weniger Risiko – und manchmal reicht schon ein einziger, gut formulierter Satz im Vertrag.