O'Reilly logo

IT-Projektverträge: Rechtliche Grundlagen by Christoph Zahrnt

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

9 Erstellung von Programmen
238
Ist die Aufgabenstellung bei Programmerstellung zum Zeitpunkt des
Abschlusses des Vertrags erst vage beschrieben, liegt deswegen noch nicht ein
Dienstvertrag vor; es besteht dann ein vager Maßstab für das geschuldete Ergeb-
nis, sodass unterschiedliche Ergebnisse vertragsgemäß sind. Die Behauptung (sei-
tens IT-Fachleuten), dass ein Werk(lieferungs)vertrag nur dann vorliege, wenn die
Leistungen »genau definiert« worden sind, ist überzogen.
Gibt der Kunde hingegen die Vorgaben Stück für Stück vor, dürfte eher gemein-
same Arbeit, also ein Dienstvertrag, vorliegen. Dienstvertr
äge kommen am ehes-
ten in Betracht, wenn die Vertragspartner das Programm in einem gemeinsamen
Team entwickeln.
Bei einem Werk(lieferungs)vertrag ist der Auftragnehmer für die Gestaltung
des Ergebnisses zuständig, z.B. entscheidet er, wenn nichts vereinbart ist, welche
Entwicklungs- und Dokumentationsrichtlinien er sachgerechterweise anwendet.
Bei einem Dienstvertrag muss er mit dem Kunden klären, welche Entwicklungs-
und Dokumentationsrichtlinie das Team anwenden soll.
Wenn man einen Vertrag in der Praxis einordnen muss, sollte man vom
Werk(lieferungs)vertrag ausgehen und fragen, ob dieser ausschei
det:
Soll der Auftragnehmer ein Ergebnis abliefern, das er (!) erstellt hat? Bei
gemeinsamer Arbeit liegt ein Dienstvertrag vor, weil der Auftragnehmer für
das Ergebnis nicht alleine verantwortlich sein kann.
Kann man ausnahmsweise dem Auftragnehmer trotzdem nicht zumuten, für
das Erreichen des Ergebnisses zu haften?
Erforderliche lieferungs-vom Anwendungsgebiet: Welche Fachkenntnisse der
Auftragnehmer haben muss, hängt vom Vertragsgegenstand ab. Wenn der Auf-
tragnehmer von einer endgültig definierten Aufgabenstellung ausgehen darf,
braucht er keine speziellen Fachkenntnisse zu haben.
9.1 Die Erstellungsphase:
Konkretisierung der Aufgabenstellung
Je gröber die Aufgabenstellung abgefasst ist, desto weiter ist der Rahmen für die
Lösung und desto größer ist die Zahl möglicher Realisierungen. Manche sind als
vertragsgemäß einzustufen, manche als mangelhaft. Dementsprechend ist zu
unterscheiden:
+/75/+1
&7D9>; 8;H`>CJ; );HI_DB?9>A;?J M7H I9>ED C?J :;C )EHJH7?J :7I I?; 8;? ;?D;C
CE:;HD;D$`DIJB;H7BI0;HAL;HJH7=?DK<JH7==;=;8;D>7JJ;I;>HKDPK<H?;:;D
239
9.1 Die Erstellungsphase: Konkretisierung der Aufgabenstellung
Die Sachmängelproblematik
Was kann der Kunde aufgrund der – grob definierten – Aufgabenstellung als
geschuldete Verwendbarkeit erwarten? Welche Realisierungen muss er als
tauglich hinnehmen, welche kann er also als mangelhaft ablehnen?
Die Festpreisproblematik
Nach welchen Grundsätzen ist di e – grob defi nierte – Aufgabenstellung in ein
Programm umzusetzen, wenn von vornherein ein Festpreis vereinbart worden
ist? Wie verläuft der Konkretisierungsprozess? Wie viel Leistung muss der
Auftragnehmer erbringen? Welche Einflussnahme des Kunden muss er sich
gefallen lassen?
Die Sachmängelproblematik: Wenn nichts Spezifisches vereinbart ist, hat der
Auftragnehmer nach der Rechtsprechung ein Programm zu liefern, das – ausge-
hend von der Darstellung der Aufgabenstellung i
m Vertrag hinsichtlich Qualität
und Quantität – einen »mittleren Ausführungsstandard« hat. Dabei gibt es in der
Praxis verschiedene Standards.
Die Festpreisproblematik: Der Kunde möchte nicht nur irgendeine taugliche Rea-
lisierung erhalten, sondern eine, die seinen spezifischen Anforderungen möglichst
nahekommt. Bei Vergütung nach Aufwand ist der Auftragnehmer bereit, das zu
liefern, was der Kunde haben will, soweit er die technische Verantwortung dafür
tragen kann. Bei Verei
nbarung eines Festpreises gibt es allerdings massive Interes-
sengegensätze zwischen den Vertragspartnern.
Konstellationen in der Praxis: Es kommen verschiedene Konstellationen vor, je
nachdem, wie grob die Aufgabenstellung im Vertrag abgefasst worden ist und wie
sie konkretisiert werden soll. In Abbildung 9–1 sind die im Folgenden behandel-
ten Konstellationen beispielhaft formuliert [zur Erstellung auf der Grundlage von
Rohlingssoftware siehe Kapitel 9.6]:
Gemeinsame Konkretisierung
Die Vertragspartner wollen die Aufgabenstellung ausdrücklich noch gemein-
sam verfeinern [Kapitel 9.1.1]. Der Kunde geht davon aus, dass die Aufga-
benstellung noch nicht programmierreif beschrieben ist.
Angeblich definierte Aufgabenstellung
Der Kunde me
int, die Aufgabenstellung bereits ausreichend definiert zu
haben, und der Auftragnehmer stimmt dem zu [Kapitel 9.1.2]. Tendenziell
denkt der Kunde, dass er nach Vertragsabschluss bei der Konkretisierung
durch den Auftragnehmer noch erheblich mitzureden habe.
Erkennbar offene Aufgabenstellung
Aus dem geringen Detaillierungsgrad der Aufgabenstellung ergi bt sich, dass
sie noch stark konkretisiert werden muss. Häufig wird ergänzt [was nach dem
Stand der Technik ohnehin gilt, Kapitel 9.1.2 und 9.1.3 (1)], dass der Auf-
tragnehmer eine Konkretisierung der Aufgabenstellung vorlegen und der

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required