Jusletter IT

Das Konzept der «technischen Schuld» ist nicht neu. Bereits 1992 sprach der Softwareentwickler Ward Cunningham darüber, wie mit der Implementierung von «unreifem Code» Schulden aufgenommen würden. Gewisse Schulden würden zwar die Entwicklung beschleunigen, müssten aber umgehend mit einer Code-Überarbeitung «zurückgezahlt» werden.¹ Im Kern handelt es sich bei technischer Verschuldung um eine Abweichung von der optimalen Entwicklung bzw. Programmierung eines Projektes, welche zu erhöhten Wartungs- und Weiterentwicklungskosten führt. Es wird demnach umso zeitaufwändiger und teurer, je länger man auf technischen Schulden sitzen bleibt. Wie beim Herauszögern der Rückzahlung von Bankkrediten hat es schwerwiegende und kostspielige Folgen, wenn technische Schulden nicht umgehend beglichen werden.

Ein prominentes Beispiel für die Folgen technischer Verschuldung ist der sog. «Y2K Bug». Aus Platzgründen wurde bei Computersystemen bis in die 1990er Jahre die Jahreszahl mit nur zwei Ziffern erfasst (TT/MM/JJ), was beim Übergang vom Jahr 1999 zum Jahr 2000 (durch Anzeige einer Doppelnull) zu Problemen führte. Im Zuge grosser Unsicherheit über die Folgen dieser Umstellung wurden weltweit schätzungsweise 300 Milliarden Dollar für Upgrades von PC-Systemen ausgegeben.²

Technische Schulden belasten nicht nur die Gesamtkosten eines IT-Projektes mit Erstellung und Wartung des bestehenden Funktionsumfanges, sie können auch die Einführung neuer Funktionalitäten unverhältnismässig teuer machen. Steigt die technische Verschuldung eines Projektes unkontrolliert, erhöhen sich laufend die Kosten für eigentlich banale Anpassungen.

Aus juristischer Sicht ist die Regelung technischer Verschuldung auf verschiedenen Ebenen interessant. IT-Projekte setzen sich oft aus verschiedenen Dienstleistungen zusammen, rechtlich handelt es sich dabei um gemischte Verträge. Für die Beratung und Konzeption kommt in der Regel Auftragsrecht zur Anwendung, für die Erstellung eines bestimmten Programmes sind Bestimmungen des Werkvertragsrechtes anwendbar und beim Verkauf von Standardsoftware gilt in der Regel Kaufrecht.³ Der simple «Kauf» eines Webshop-Systems kann also alle Ebenen, namentlich Beratung, Kauf von Standardsoftware, Entwicklung von Individualsoftware und Wartung bzw. Hosting umfassen. Um grösstmögliche (Rechts-)Sicherheit über den Fortbestand und das reibungslose Betreiben eines IT-Projektes zu haben, lohnt es sich also, möglichst früh und klar Instrumente zu vereinbaren, mit welchen Zusatzwünsche, Support, Wartung, Updates und nicht zuletzt die Vermeidung technischer Verschuldung geregelt werden.

Ziel dieses Beitrages ist es, basierend auf einem Austausch mit Experten auf diesem Gebiet, technische Verschuldung zu definieren, ihre Treiber zu bestimmen, Möglichkeiten zu ihrer Minimierung aufzuzeigen und vertragliche Instrumente und Regelungskonzepte vorzuschlagen.

Um das Konzept der technischen Verschuldung zu verstehen, ist ein gewisses Grundverständnis von IT-Projektentwicklung und dem Lebenszyklus eines Programmes hilfreich. Bereits 1980 erkannte Lehman die Wichtigkeit, effektive, kosteneffiziente und zeitgerechte Software zu erstellen und zu unterhalten. Im Jahr 1977 wurden etwa 70% der Gesamtausgaben für IT-Projekte in den USA für die Programmpflege und -wartung und nur etwa 30% für die Programmentwicklung aufgewendet. Es ist indes klarzustellen, dass Programmpflege und -wartung alle Änderungen an einem Computerprogramm erfassen. Anders als physikalische Maschinen leiden Programme nicht unter Abnutzung, Verschleiss, Korrosion oder Verschmutzung. Sie ändern sich nicht, es sei denn, Menschen nehmen Anpassungen vor. Dies geschieht immer dann, wenn das aktuelle Verhalten eines Programms als falsch, unpassend oder zu eingeschränkt wahrgenommen wird. «Reparaturen» können also eine Veränderung weg vom Ursprungszugszustand bedeuten.⁴ Unter die Softwarepflege und -wartung fällt somit auch deren Weiterentwicklung und Anpassung an veränderte Bedürfnisse, was die eingangs erwähnte Kostenaufteilung relativiert.

Der Lebenszyklus eines Programmes (auch SDLC, Software Development Life Cycle genannt) durchläuft gemäss Lehman im Grundsatz drei Phasen: Definition, Implementierung und Wartung.⁵

Ob starre, aufeinander aufbauende Phasen auf die heutigen komplexen IT-Projekte noch ohne weiteres anwendbar sind, erscheint fraglich, zumal eine agile Entwicklung zunehmend als Standard angesehen wird. Ein fliessender Übergang und ein gewisses Vor und Zurück bzw. mehrmaliges Durchlaufen dieser Lebensphasen erscheint zeitgemässer.

Basierend auf der beschriebenen Grundstruktur haben sich verschiedene Methoden entwickelt, welche je nach den Anforderungen, Mitteln und der gewünschten Mitwirkung des Bestellers unterschiedliche Vorgehensweisen implizieren. Die wohl bekannteste und traditionellste Methode ist die Wasserfall-Methode, in welcher zu Beginn der Entwicklung alle Anforderungen festgelegt werden und die Entwicklung in vorgegebenen, sequenziellen Schritten abläuft.⁶ Dem gegenüber steht die heute zunehmend wichtige Agile-Methode, in welcher Anforderungen laufend evaluiert werden und die Entwicklung in inkrementellen Schritten erfolgt.⁷ Die Methoden unterscheiden sich also insbesondere darin, in welchem Zeitpunkt Anforderungen festgelegt werden und wie ausgeprägt die Mitwirkung des Bestellers im Entwicklungsprozess ist.

Aus alledem folgt, dass Evolution eine intrinsische, durch Feedback angetriebene Eigenschaft von Software ist.⁸ Auf Basis dieser Annahme formulierte Lehman seine «Gesetze der Software Evolution». Das erste und zweite Gesetz sind vorliegend von Bedeutung:⁹

1. Kontinuierliche Veränderung
   Ein Programm muss laufend angepasst werden, sonst verliert es zunehmend an Nützlichkeit.
2. Zunehmende Komplexität
   Mit der Entwicklung eines Systems nimmt seine Komplexität zu, wenn nicht daran gearbeitet wird, sie auf dem bisherigen Niveau zu behalten oder zu reduzieren.

Zwischen diesen beiden Gesetzen besteht ein gewisses Spannungsverhältnis: Auf der einen Seite muss ein Programm laufend angepasst und weiterentwickelt werden; auf der anderen Seite führt dies zu einer höheren Komplexität, welche es wiederum schwieriger und teurer macht, auf Veränderungen zu reagieren. Wird diese Komplexität nicht aktiv beseitigt, resultiert eine technische Verschuldung.

Dass insbesondere das erste Gesetz noch heute Bedeutung hat, bestätigt Vladimir Riecicky¹⁰ mit Hinweis auf das Prinzip der Kontinuität: Software müsse die Realität widerspiegeln. Die Realität ändere sich laufend, also habe sich auch Software laufend anzupassen. Auch dem zweiten Gesetz kommt eine nicht zu unterschätzende Bedeutung zu: Zunehmende Komplexität ist ein Symptom von zu wenig Zeit für die Entwicklung und folglich zunehmender technischer Verschuldung, welche aktiv beseitigt werden muss.

Technische Verschuldung tritt in unterschiedlichen Dimensionen in Erscheinung. Gemeinsam ist ihnen oft, dass den Entwicklern nicht dasjenige Umfeld gegeben wird, in welchem die Aufarbeitung und Beseitigung technischer Verschuldung im Rahmen des gewöhnlichen Betriebes möglich ist. Es muss die Grundüberzeugung gelten, dass Entwickler einen möglichst optimalen Code schaffen wollen und dies auch (entsprechend ihrer Fähigkeiten) können, wenn ihnen das richtige Umfeld gegeben wird. Die folgend dargelegten Erscheinungsformen von technischer Verschuldung ergeben sich aus Expertengesprächen mit Stephan Sutter¹¹ und Vladimir Riecicky. Sie sind nicht trennscharf, gehen fliessend ineinander über und hängen in gewissem Masse auch voneinander ab.

1. Kurzfristige «quick and dirty» Lösungen (Spaghetti-Code):
   Um engen Zeitplänen gerecht zu werden, sehen sich Entwickler gezwungen, rasche und unausgereifte Lösungen zu implementieren, die nicht den optimalen technischen Standards entsprechen. Dies kann zu erhöhtem Wartungsaufwand, hoher Codekomplexität, mangelnder Skalierbarkeit und einem erhöhten Risiko von Fehlfunktionen führen. Man handelt sich eine Schuld gegenüber der zukünftigen Entwicklung ein: Wird diese nicht bald «zurückbezahlt», schlägt sie sich in allen weiteren Anpassungen des Codes in Form gesteigerter Kosten nieder. Die Qualität des Codes, in welcher sich technische Verschuldung am ehesten zeigt, leidet.
2. Unzureichende Dokumentation:
   Zu enge Zeitpläne können zu einer unzureichenden Dokumentation des Codes oder des Gesamtsystems und diese wiederum zu Problemen bei künftiger Wartung oder Erweiterung führen. Entwickler, die später mit dem Code arbeiten müssen, können Schwierigkeiten haben, ihn zu verstehen und Änderungen vorzunehmen. Es kommt zu teuren Zeitverlusten. Auch führt dies zur Problematik des sog. Key-Personals, wenn das System nur noch von einigen wenigen, hochqualifizierten Entwicklern verstanden wird, deren Abgang ein Abrutschen in die digitale Sklaverei bedeutet.¹² Eine unzureichende Dokumentation ist ein klares Symptom technischer Verschuldung.
3. Mangelhafte Automatisierung von Tests:
   Wenn unzureichende, zu wenig oder gar keine automatisierten Tests implementiert werden, um die Funktionalität und Qualität der Software zu überprüfen, kann dies zu unentdeckten Fehlern führen. Besonders bei kurzfristigen Lösungen für ein spezifisches Problem kann der Mangel an automatisierten Tests dazu führen, dass Fehler (als «Spätfolge» der kurzfristigen Lösung) erst spät im Entwicklungsprozess erkannt werden, was erhebliche Kosten und Verzögerungen verursacht. Auch erschwert ein Mangel an Tests die Übersichtlichkeit über den Code und damit auch die allenfalls nötigen Arbeiten wie Refactorings.
4. Verwendung veralteter Technologien und Durchbrechung der Kontinuität:
   Der Einsatz veralteter Technologien kann angehäufte technische Verschuldung bedeuten. Veraltete Technologien können Sicherheitslücken aufweisen, die vom Anbieter nicht mehr behoben werden, und es kann schwierig sein, qualifizierte Entwickler zu finden, die diese warten oder erweitern können. Dies kann so weit gehen, dass mit der verwendeten Technologie die Realität nicht mehr abgebildet werden kann, also das Prinzip der Kontinuität durchbrochen wird. In diesem Fall muss eine Ablösung der Software in Betracht gezogen werden.
5. Teamfluktuation und Team-Mix:
   Durch zu kurze Fristen und einen zu hohen Business-Delivery-Druck steigt die technische Schuld, die Komplexität des Codes nimmt zu und die Dokumentation nimmt ab, beides entgegen den Vorstellungen des Entwicklerteams. Wird ihnen wiederholt verunmöglicht, ihre Arbeit ordnungsgemäss und nach ihren Qualitätsansprüchen durchzuführen, resignieren sie, wodurch es zu Teamfluktuationen und einem Wissensverlust durch Abnahme von Senior-Entwicklern bzw. Zunahme von Junior-Entwicklern kommt. Verändert sich der Team-Mix eines Entwicklerteams hin zu mehr Junior-Entwicklern und weniger Senior-Entwicklern, kann dies ein Ausdruck technischer Verschuldung sein.¹³

Anhand der genannten Erscheinungsformen lassen sich verschiedene Treiber technischer Schuld eruieren. In erster Linie treibt ein zu hoher Zeitdruck bzw. «Business-Delivery-Druck»¹⁴, verstärkt durch ein mangelndes Bewusstsein (aller Parteien) für die Problematik, die Zunahme von «Spaghetti-Code» an und schafft damit technische Verschuldung. Werden zu schnell zu viele Features erwartet, ohne genügend Zeit für die Optimierung des bestehenden Codes zu gewähren, leiden die Code-Qualität und Dokumentation. Dazu kommt ein Wissensverlust aufgrund von Teamfluktuationen, wenn erfahrene Entwickler das Team verlassen. Weiter kann ein Mangel automatisierter Tests bzw. grundsätzlich qualitätssichernder Prozesse zu unerkannten Problemen führen, die sich erst zu spät bemerkbar machen. Nicht zuletzt treibt auch ein basierend auf einer schlechten Architektur entwickeltes Projekt die technische Verschuldung an und kann die Einhaltung der Kontinuität erschweren.

Nach dem Gesagten lässt sich technische Verschuldung wie folgt definieren:

Technische Verschuldung ist das Ausmass an ausgelassener Arbeit, gemessen an der optimalen Entwicklung, und damit das Ergebnis (bewusster) Abkürzungen in der Entwicklung einer Software. Je länger diese Schuld nicht beseitigt wird, desto grösser sind die Auswirkungen auf Betrieb, Wartung und Weiterentwicklung.

Eine niedrige technische Verschuldung bedeutet, dass das Systemdesign sauber und leicht zu verstehen ist und die Dokumentation dazu umfassend und aktuell ist. Bei einem hohen technischen Schuldenstand ist es hingegen, ohne persönliche Anleitung durch die involvierten Systementwickler, sehr schwierig zu verstehen, wie das System funktioniert.¹⁵

Die Folgen technischer Verschuldung sind so vielfältig wie ihre Erscheinungsformen und hängen oft direkt mit selbigen zusammen. In erster Linie sind steigende Kosten eine Hauptfolge, indem Betriebs- und Wartungskosten steigen. Auch wird die Weiterentwicklung durch die Notwendigkeit, technische Schulden abzuarbeiten, erschwert bzw. unverhältnismässig hohe Weiterentwicklungskosten verursachen. Weiter besteht das Risiko von Entwicklerfrustration und dem Verlust von Fachwissen, wenn erfahrene Entwickler resignieren und das Entwicklerteam verlassen. Nicht zuletzt leidet die Kundenzufriedenheit aufgrund von Zeitverzögerungen und der mit dem Zuwachs technischer Verschuldung einhergehenden Risikoerhöhung für den Fortbestand des Projektes.

Um Regelungen zur Minimierung oder Beseitigung von technischer Verschuldung entwickeln zu können, muss diese in ihren verschiedenen Erscheinungsformen messbar gemacht werden. Dazu gibt es verschiedene Möglichkeiten, die die unterschiedlichen Facetten technischer Verschuldung abdecken können:

1. Codequalität und Architektur: Zur Messung technischer Verschuldung im Code bestehen bereits verschiedene Softwaretools, die unterschiedliche Metriken zur Berechnung einer technischen Verschuldung verwenden. Beurteilt werden unter anderem die Architektur, das Design und der eigentliche Code, jeweils in verschiedenen Kombinationen und auf verschiedene Art und Weise.¹⁶ Auf technischer Ebene lässt sich mittels dieser Tools technische Verschuldung klar definieren und berechnen. Das bekannteste Programm ist wohl SonarQube¹⁷, ein «selbstverwaltetes statisches Analysewerkzeug für die kontinuierliche Überprüfung der Codebase»¹⁸. Die Messung der technischen Schuld im Code kann durch den Anbieter selbst oder auch Dritte (bspw. im Rahmen eines Gutachtens) erfolgen.
2. Marginal Cost of Ownership: Die sog. Marginal Cost of Ownership ist eine von Vladimir Riecicky vorgeschlagene Masseinheit zur Messung technischer Verschuldung.¹⁹ Es handelt sich hierbei um eine Art der Grenzkostenbetrachtung, bei der die fachliche Komplexität einer Story mit den Kosten ihrer Umsetzung durch die Zeit verglichen wird. Die Grundüberlegung ist, dass die Implementierung einer ähnlich komplexen Funktion im Laufe des Projektes gleich viel kosten müsste. Ist dies nicht der Fall, kostet die Implementierung dieser ähnlich komplexen Funktion also mehr als zuvor, steigen die Grenzkosten, was ein Zeichen für eine potenzielle technische Verschuldung ist (mehr technische Verschuldung = mehr (Code-)Komplexität = mehr Zeit und Geld für Änderungen am Code). Gemessen an dieser Entwicklung lässt sich also eine Aussage über die technische Verschuldung eines IT-Projektes machen.
3. Team-Mix: Mitverantwortlich für den Erfolg eines IT-Projektes ist die Fähigkeitsverteilung im Team. Werden (Senior-) Entwickler nicht genügend gefördert oder zu lange einem ungünstigen Arbeitsumfeld ausgesetzt, verlassen sie das Team, woraufhin sich die verbleibenden (Junior-) Entwickler im Blindflug oder schlimmstenfalls bereits in der digitalen Sklaverei befinden. Im Blindflug schaffen die verbliebenen Entwickler unbewusst weitere technische Verschuldung.²⁰ Folglich lässt sich aus der Fähigkeitsverteilung und allenfalls Teamfluktuation ein Mass für mögliche technische Verschuldung ableiten.

Die wohl naheliegendste Lösung zur Minimierung der technischen Verschuldung ist, sie bereits auf der Ebene des Codes zu beseitigen. Dazu gibt es verschiedene Aspekte, die helfen, einen möglichst schuldarmen Code sicherzustellen.

Agile Entwicklung ist eine Entwicklungsmethode basierend auf dem sog. Agile Manifesto.²¹ Im Kern bedeutet Agilität die Fähigkeit, schnell und flexibel Veränderungen im geschäftlichen und technischen Bereich wahrzunehmen und darauf zu reagieren. Im Gegensatz dazu steht die eine lange Zeit verbreitete «Wasserfall» Entwicklungsmethode, nach welcher bereits zu Beginn der Entwicklungsarbeiten klargestellt wird, in welcher Reihenfolge welche Schritte unternommen werden müssen, um zu dem gewünschten Ergebnis zu gelangen. Vor dem Hintergrund reglementarischer Entwicklungen bspw. zur «Compliance by Design» erscheint die agile Entwicklung heute als das Mass der Dinge.²²

Eine Entwicklung anhand der im agilen Manifest darlegten Grundsätze schafft einen Mehrwert, indem in regelmässigen, kurzen Abständen (Sprints) funktionierende Softwareteile (Inkremente) erstellt werden. Dies erlaubt es, geänderten Anforderungen in jeder Phase des Entwicklungsprozesses auch kurzfristig Rechnung zu tragen und die zukünftige Arbeit (kommende Sprints) bei Bedarf anpassen zu können. Darüber hinaus wird der Besteller aktiv in den Entwicklungsprozess einbezogen, wodurch Feedback und Reflexion erleichtert werden. Die Grundsätze stellen keine formale Definition von Agilität dar, sondern sind vielmehr Leitlinien für die Bereitstellung hochwertiger Software auf agile Weise.²³

Für das Management technischer Verschuldung ausschlaggebend sind die Möglichkeit, noch während des Entwicklungsprozesses schnell auf geänderte Anforderungen zu reagieren, sowie der regelmässige Austausch zwischen Besteller und Anbieter. Auch besteht die Möglichkeit, eine Entwicklungseinheit, also einen Sprint, zugunsten der Reduktion technischer Verschuldung, anstatt zur Entwicklung einer neuen Funktion, zu verwenden. Bei der optimalen Entwicklung von Software verbindet die Produktvision den Anbieter und den Besteller. Erst im Zusammenspiel der jeweiligen Fähigkeiten und Möglichkeiten kann eine Produktvision geschaffen, verfeinert und realisiert werden. Eine agile Entwicklung stärkt diesen Gedanken und schafft eine gute Grundlage, um technischer Verschuldung bereits im Entwicklungsstadium zu begegnen.

Ein bekannter, agiler Entwicklungsansatz stellt die DevOps-Methode dar. Diese setzt sich aus den Wörtern «Development» für Entwicklung sowie «Operations» für den Betrieb ab.²⁵ Die normalerweise getrennt agierenden IT-Bereiche Entwicklung und Betrieb werden durch die DevOps-Methode zusammengeführt mit dem Ziel, effizientere Softwareprodukte zu realisieren.²⁶ DevOps verfolgt bei der Softwareentwicklung und -bereitstellung einen iterativen Ansatz. Bei der DevOps-Methode werden Prozesse in regelmässigen Abständen wiederholt, um neue Anforderungen, Funktionen und Verhaltensweisen, welche sich aus dem Betrieb ergeben, aufzufangen. Diese werden als DevOps-Prozesse bezeichnet.²⁷ Grundsätzlich umfasst der DevOps Prozess folgende Phasen: Planung, Entwicklung, Test, Bereitstellung, Inbetriebnahme, fortlaufende Überwachung, Feedback-Einholung und damit die Rückkehr zur Planung. Diese Prozesse sind jedoch nicht in Stein gemeisselt. Bei Bedarf können Sie angepasst werden, denn das Ziel von DevOps ist die ständige Optimierung und Verbesserung von Prozessen, damit die Softwareentwicklung und -bereitstellung noch effizienter erfolgt.²⁸ Der Leistungsumfang eines Produkts (Scope) wird, wie bei allen agilen Entwicklungsmethoden, nicht bereits von Beginn weg festgelegt, sondern es entstehen im Rahmen mehrerer, kurzer Entwicklungsphasen (Sprints) neue Prototypen. Dadurch erhält der Entwickler die Möglichkeit, rasch auf sich ändernde Erfordernisse eines Bestellers oder des Markts zu reagieren, oder sich an neue Technologien sowie Tools anzupassen.²⁹

Die DevOps-Methode bietet somit die Möglichkeit, technischer Verschuldung bereits während einzelner Sprints zu begegnen. Ein Vorteil von DevOps im Vergleich zu anderen agilen Entwicklungsmethoden besteht darin, dass DevOps auch die Betriebsphase miteinschliesst. Dadurch erhält der Besteller bereits im Anfangsstudium ein Feedback darüber, wie die einzelnen Softwareteile im operativen Alltag entsprechend ihres Nutzens abschneiden und welche Problemfelder noch bestehen. Der Besteller kann dadurch das Risiko einer technischen Verschuldung bereits im Vorfeld minimieren.

In der Praxis besteht bei DevOps jedoch die Problematik, dass Entwicklungskosten (CapEx) und Betriebskosten (OpEx) separat betrachtet werden. CapEx bezeichnet Investitionen, die einmalig anfallen, während OpEx die wiederkehrenden, laufenden Betriebskosten umfasst. Wenn ein Teil des Softwaresystems gewartet wird, werden diese Kosten den Betriebskosten zugeordnet. Werden Softwareteile entwickelt, gehören die entstehenden Kosten zu den Entwicklungskosten. Das bedeutet im Umkehrschluss, dass sich Unternehmen entweder für CapEx oder OpEx entscheiden müssen. Dadurch werden die tatsächlichen Kosten verschleiert, da sich die Kosten eines Softwaresystems während seiner Lebensdauer zwischen diesen beiden Bereichen hin und her bewegen.³⁰ Für das Management technischer Verschuldung ist es daher unumgänglich, sich diesem Problem anzunehmen, bevor DevOps als Lösungsansatz in Betracht gezogen wird.

Ein Audit ist «eine unabhängige Prüfung eines Softwareprodukts, eines Softwareprozesses oder einer Reihe von Software-Prozessen durch einen Dritten, um die Einhaltung von Spezifikationen, Standards, vertraglichen Vereinbarungen oder anderen Kriterien zu beurteilen»³¹. Codequalität und sogar technische Verschuldung selbst lassen sich wie beschrieben mittels Analysesoftware beurteilen. Ein vollständiger Code-Audit kann zudem massgeschneidert erfolgen und über die reine Verwendung eines Analysetools hinaus Änderungsempfehlungen umfassen. Ein solcher Code-Audit kann in erster Linie durch einen unabhängigen Dritten, aber auch durch den Anbieter selbst im Sinne einer Selbstkontrolle durchgeführt werden.

Durch Festlegung eines Standards sowie bestimmter Kennzahlen und Messmethoden, bspw. durch Bestimmung eines reputablen Analysetools, kann eine Code-Qualität (und eine Qualität der Dokumentation) vereinbart werden, die sowohl der Anbieter als auch der Besteller nachvollziehen und messen kann.³² Über eine allfällige technische Verschuldung im Code kann der Anbieter selbst, unter Bezugnahme auf die vereinbarten Kennzahlen, eine Aussage machen. Es können ihm auch entsprechende Sorgfaltspflichten überbunden werden, die vereinbarten Kennzahlen einhalten zu müssen. Im Zweifelsfall können die Kennzahlen durch einen unabhängigen Dritten überprüft werden.

Damit der Code bereits von Beginn weg möglichst unverschuldet ist, bietet es sich an, automatisierte Testverfahren anzuwenden. Dieses Vorgehen hängt auch mit dem oben beschriebenen Code-Audit zusammen: Ziel ist es, eine hohe Code-Qualität zu gewährleisten und zu verhindern, dass Fehler und folglich technische Verschuldung erst bei einem externen Audit sichtbar werden. Es bedarf deshalb einer Übersicht durch den Softwareentwickler selbst und automatisierte Testverfahren sollten von Beginn weg vorgesehen sein.

Sich selbst testender Code erlaubt es zudem, Bugs bereits bei ihrer Entstehung zu erkennen. Damit erhöht sich die Fehlerlosigkeit des Codes sowie auch die Produktivität der Entwickler, da weniger Zeit mit Debugging verbraucht werden muss. Bugs lassen sich somit von selbst identifizieren und effizient beseitigen.³³ Des Weiteren reduziert sich die Anfälligkeit für technische Verschuldung in Form von kurzfristig funktionierendem, aber langfristig problematischem Code, da die Tests fast alle potenziell betroffenen Bereiche abdecken können. Ein möglicher Blindpunkt besteht allerdingt im Auffinden von Architektur- und Designfehlern.

Um den Code aufzuräumen und allenfalls nötige Anpassungen vorzunehmen (bspw. aufgrund geänderter Anforderungen, damit das Prinzip der Kontinuität nicht missachtet wird), bietet sich ein sog. Refactoring an. Refactoring ist ein Prozess, bei dem ein Softwaresystem so verändert wird, dass sich das äussere Verhalten des Codes nicht verändert, sich aber seine interne Struktur verbessert.³⁴ Voraussetzung sind unter anderem solide (Selbst-)Tests im Code, was die Wichtigkeit soeben erwähnter automatisierter Tests noch erhöht.³⁵ Ein Refactoring ist indes nicht ganz ungefährlich: Es erfordert Änderungen an funktionierendem Code, welche subtile Bugs einführen können.³⁶ Es gibt eine grosse Zahl verschiedener Refactoring-Szenarien, welche unterschiedliche und teils widersprüchliche Einflüsse auf die Codequalität haben können. Mit der richtigen Wahl lässt sich jedoch eine klare Verbesserung der Codequalität erzielen.³⁷ Ein Refactoring lohnt sich also nach grösseren Änderungen, sollte aber nicht ohne Not erzwungen werden.

Neben der Code-Ebene kann technische Verschuldung auch auf Ebene der Entwicklungspartner angegangen und reduziert werden. Ein sowohl von Sutter als auch Riecicky hervorgehobener Aspekt ist das grundsätzliche Bewusstsein aller beteiligten Parteien über die Problematik der technischen Verschuldung und den Lebenszyklus des in Frage stehenden Produktes. Wie oben dargelegt ist ein zu hoher «Business-Delivery-Druck» einer der Haupttreiber technischer Verschuldung. Wird in zu kurzer Zeit zu viel von den Entwicklern verlangt, sowohl seitens des Managements des Anbieters als auch seitens des Kunden, müssen die Entwickler Abkürzungen nehmen, woraus suboptimaler Code und eine mangelhafte Dokumentation resultieren. Ein diesbezügliches gegenseitiges Bewusstsein kann einen Haupttreiber also dämpfen.

Wie in Kapitel 2.2 anhand des von Riecicky entwickelten K@R Navigators³⁸ dargelegt, besteht eine direkte Verbindung zwischen technischer Verschuldung und dem Team-Mix in einem Entwicklungsteam. Wird dem Team ein suboptimales Umfeld gegeben, verlassen in letzter Konsequenz essenzielle Entwickler das Team und hinterlassen ein Projekt mit hoher technischer Verschuldung und ein Team mit geringer Berufserfahrung, welche wiederum unbewusst technische Verschuldung schaffen. Es bietet sich folglich an, ein Auge auf die Zusammensetzung des Entwicklerteams zu haben und allenfalls mittels Vereinbarung sicherzustellen, dass immer eine genügende Anzahl erfahrener Entwickler involviert ist. Auch ist darauf zu achten, dass Junior-Entwickler im Team «nachgezogen» und weitergebildet werden und mit der Applikation vertraut gemacht werden.

Anknüpfend an die oben erklärte Masseinheit der Marginal Cost of Ownership lässt sich mit ihr eine weitere Metrik für die technische Verschuldung eines Projektes festlegen, auf welche sich die Parteien stützen können. So kann vereinbart werden, dass der Anbieter neben der Kostenschätzung eine Beurteilung der Komplexität der in Frage stehenden Änderung oder Weiterentwicklung vornimmt, und diese kategorisiert – bspw. mit Buchstaben. Zusätzlich können als weitere Grundlage bereits im Voraus die Bedingungen bestimmter Standardänderungen festgelegt werden, konkret innert welcher Zeit (und mit welchem Aufwand) eine Standardänderung realisiert werden muss.

Es kann vereinbart werden, welches Verhältnis zwischen Komplexität und Kosten eingehalten werden soll, über welchen Zeitraum die Beurteilung erfolgt und wie bei unterschiedlichen Verhältnissen reagiert wird (bspw. in Form von Eskalationsstufen beginnend mit einer Informationspflicht über kostenfreie Wartungssprints bis hin zu einer Vertragsauflösung). Dies schafft einerseits Raum für eine gewisse Flexibilität: Es bleibt also möglich, dass Änderungen etwas mehr oder weniger Kosten verursachen als «sie sollten». Andererseits wird eine Kennzahl geschaffen, aufgrund welcher Massnahmen ergriffen werden können, sollte sie zu lange einen bestimmten Wert unter- oder überschreiten.

Nicht zuletzt kann technischer Verschuldung begegnet werden, indem man sie als Funktionsbestandteil betrachtet. Als Resultat des gegenseitigen Bewusstseins der Parteien für die Problematik kann technische Verschuldung als normaler Bestandteil eines Entwicklungsprozesses betrachtet werden. Dadurch lässt sich der Behebung allfällig angehäufter technischer Verschuldung wie der Entwicklung einer neuen Funktion begegnen. Das bedeutet, dass insbesondere diese zeitlichen und finanziellen Ressourcen für die «Aufräumarbeiten» zur Verfügung gestellt werden. Die Parteien gestehen sich damit ein, dass eine gewisse technische Verschuldung in der Entwicklung «zu erwarten» ist. Die technische Verschuldung ist jedoch kaum zu jedem Zeitpunkt vollständig fassbar. Dem könnte mit periodischen Standortgesprächen begegnet werden.

Konkret sollte der Anbieter einen Überblick über die angesammelte technische Verschuldung im Projekt haben, bspw. durch Messungen wie oben beschrieben. Für diese Schuld vereinbaren die Parteien eine Informationspflicht. Sobald die Schuld einen gewissen Stand, gemessen bspw. an einer Kennzahl, erreicht hat und bereinigt werden muss, wird diese Bereinigung behandelt wie jede andere Entwicklung. Das heisst, dass auch der gleiche finanzielle Aufwand wie bei der Entwicklung einer neuen Funktion in Rechnung gestellt wird. Dieses Vorgehen funktioniert indes nur in Kombination mit den anderen Regelungsmöglichkeiten zur Minimierung der technischen Verschuldung.³⁹ In erster Linie soll diese also minimiert werden. Für denjenigen Teil, der auch bei treuer und redlicher Entwicklungsarbeit entsteht, kommt dann die beschriebene Vorgehensweise zum Zug.

Ebenfalls als wichtiger Funktionsbestandteil sollte die Sicherstellung der Kontinuität betrachtet werden. Vladimir Riecicky betont, dass eine Software immer die Realität abzubilden hat. Wird eine essenzielle Anpassung an geänderte Umstände in der Realität, bspw. eine bevorstehende reglementarische Änderung, nicht genügend im Code abgebildet, verschlimmern sich die Konsequenzen bei einem allfälligen Eintritt der entsprechenden Veränderung in der Realität. Das gilt im Übrigen auch für die mittels Software unterstützten Unternehmensprozesse. Neben dem Abarbeiten technischer Schuld sollte also die nötige Zeit aufgewendet werden, um einen Abgleich mit der Realität zu ermöglichen, damit die zukünftige Entwicklung nicht eine unverhältnismässig grosse Abweichung des verlangten Funktionsumfanges auszugleichen hat.

Nur am Rande mit dem Management technischer Verschuldung verknüpft, aber dennoch zu beachten, ist das Vereinbaren von Konfliktlösungsmechanismen und das Bereithalten einer Exit-Strategie. Sollte es bspw. im Zusammenhang mit steigender technischer Verschuldung zu Meinungsverschiedenheiten kommen, kann mit einem vorbestimmten Eskalationsverfahren bestenfalls ein langwieriges Gerichtsverfahren vermieden werden.⁴⁰

Als möglicher erster Eskalationsschritt bietet sich die gemeinsame Lösungsfindung zwischen den Parteien, wenn nötig auf der jeweils nächst höheren Ebene in der Organisationshierarchie (bspw. Projektteam, Leitungsausschuss, Geschäftsleitungsmitglieder) an, jeweils mit verbindlichen Fristvorgaben. Schliesslich kann die Einsetzung eines Mediators und/oder die Aufnahme einer Schiedsklausel eine Beschleunigung ermöglichen.⁴¹

Zusätzlich kann es sich anbieten, klare Prozesse zu vereinbaren, die im Falle eines vorzeitigen Ausstieges aus dem Projekt einen möglichst sauberen Übergang der Entwicklungsgrundlagen (Codebase, Dokumentation etc.) gewährleisten. Dadurch kann die Arbeit am Projekt mit einem anderen Partner möglichst bald weitergeführt werden, während allfällige Ansprüche gegen den ursprünglichen Partner geprüft und gegebenenfalls (gerichtlich) durchgesetzt werden können. Eine Möglichkeit hierzu ist das Hinzuziehen eines «Escrow-Agenten». Bei diesem hinterlegt der Softwareersteller regelmässig den aktuellen Sourcecode und weitere Entwicklungsdokumente des Projektes. Unter gewissen, zuvor bestimmten Bedingungen kann der Besteller die entsprechenden Daten von dem Escrow-Agenten beziehen und erlangt so eine gewisse Unabhängigkeit vom Softwarehersteller.⁴²

Als Herausgabefälle werden meist nur Insolvenz und manchmal auch rechtskräftige Urteile vereinbart. Möglich – und in diesem Zusammenhang sinnvoll – kann die Möglichkeit sein, eine Herausgabe nur gegen Leistung eines bestimmten Geldbetrages zu erlauben. Solche Beträge sind aber in der Regel hoch, um den Anbieter zur schützen.

Ziel dieses Beitrages ist es, vertragliche Instrumente für den Umgang mit technischer Verschuldung aufzuzeigen. Um eine Einbettung in das bestehende Regelungssystem sicherzustellen, ist es unumgänglich, zunächst eine kurze Analyse des bestehenden gesetzlichen Rahmens durchzuführen. Diese soll den Grundstein für die anschliessenden vertraglichen Lösungsansätze legen. Die Analyse beschränkt sich auf das Schweizer Recht.

Zur Analyse der auf ein IT-Projekt anwendbaren gesetzlichen Bestimmungen ist zunächst eine Vertragsqualifikation vorzunehmen. Aus Platzgründen wird hierbei nur der für IT-Projekte relevante Teil genannt und auf die Arbeit von Straub⁴³ verwiesen.

1. Auftrag: Im Zusammenhang mit IT-Projekten fallen insbesondere Beratung, Planung und Projektmanagement unter die Bestimmungen des Auftragsrechtes.⁴⁴ Abzugrenzen sind bspw. ausgearbeitete Konzepte als Projektgrundlage, für welche das Werkvertragsrecht anwendbar sein kann.
2. Werkvertrag: In den Anwendungsbereich des Werkvertragsrechts fallen im Rahmen von IT-Projekten die Erstellung individueller Produkte und Informationssysteme.⁴⁵
3. Kaufvertrag: Im IT-Bereich kommt Kaufvertragsrecht insbesondere für den Verkauf von Standardsoftware zur Anwendung. Dies gilt auch für noch zu erstellende Software, wenn es sich dabei um ein Serienprodukt handelt.⁴⁶ Allenfalls ist eine Abgrenzung zum Lizenzvertrag vorzunehmen.
4. Gemischte Verträge: Bei IT-Projekten handelt es sich oft um eine Kombination aus verschiedenen Leistungen und damit verschiedenen Vertragsarten. In solchen Situationen spricht man von einem gemischten Vertrag.⁴⁷ Bei gemischten Verträgen werden die Leistungen verschiedener Vertragstypen kombiniert. In der Rechtsanwendung kommt es dadurch jedoch nicht zu einer Absorption in einen einzigen Vertragstypen, sondern es werden jeweils die Regeln derjenigen Vertragsart herbeigezogen, die am besten auf die in Frage stehende Leistung passt.⁴⁸ Für ein IT-Projekt bedeutet dies, dass insbesondere Fragen der Mängelgewährleistung immer unter Zuhilfenahme des auf die in Frage stehende (mangelhafte) Leistung anwendbaren Rechtes zu beantworten sind.

Zum Management der technischen Verschuldung stellt sich somit die Frage, wie diese in den verschiedenen gesetzlichen Vertragsarten zutage tritt.

1. Auftrag: Im Rahmen eines Projektmanagements im Sinne eines Auftrages kann das Management technischer Verschuldung einen wichtigen Bestandteil darstellen. Als Ausfluss seiner Treuepflicht hat der Beauftragte auch eine Aufklärungspflicht, unter anderem über die technische Verschuldung des Projektes. Auch kann von einem treu und redlich handelnden Experten erwartet werden, die nötigen Massnahmen zur Minimierung technischer Verschuldung von sich aus zu treffen.
2. Werkvertrag: Bei der Erstellung von Individualsoftware spielt technische Verschuldung eine sehr grosse Rolle. Der Unternehmer erstellt für den Besteller (von Grund auf) eine Software und hat damit massgeblichen und direkten Einfluss auf die Faktoren, die zu technischer Verschuldung führen. Bei der Erstellung von Individualsoftware ist aktives Management technischer Verschuldung wohl am wichtigsten, zumal hier Ereignisse, die ausserhalb des eigentlichen Codes liegen, wie Teamfluktuation und Zeitpläne des Bestellers, hauptsächlich von Relevanz sind.
3. Kaufvertrag: Auch in Zusammenhang mit einem Kaufvertrag über Standardsoftware kann technische Schuld auftreten. Anders als bei einem Werkvertrag treffen die Parteien erst nach Entwicklung der Software aufeinander. In der Standardsoftware bestehende und nicht beseitigte technische Schuld kann dennoch im weiteren Betrieb des Käufers ins Gewicht fallen. Da hier kein gemeinsamer Entwicklungsprozess mit der entsprechenden Möglichkeit zur Intervention besteht, wird die Beurteilung einer technischen Schuld wohl oft vor dem Hintergrund zugesicherter oder für den Gebrauch vorausgesetzter Merkmale geschehen müssen.

Ausgehend von der oben dargelegten Klassifizierung der verschiedenen vertraglichen Leistungen in die gesetzlichen Vertragskategorien lässt sich nun darlegen, in welchem Rahmen für die Akkumulation von technischer Verschuldung bereits kraft geltenden Rechts gehaftet werden könnte. Auf detaillierte Ausführungen zu gesetzlichen Haftungsnormen wird indessen bewusst verzichtet.

Der Beauftragte hat seinen Auftrag sorgfältig auszuführen. Sorgfaltsmassstab ist nach Art. 398 OR die gleiche Sorgfalt, welche von einem Arbeitnehmer im Arbeitsverhältnis erwartet wird. Verlangt wird die Sorgfalt, «welche ein gewissenhafter Beauftragter (mit der vertraglich verlangten Qualifikation) in der gleichen Lage unter Berücksichtigung des spezifischen Vertragsinhalts bei der Besorgung der ihm übertragenen Geschäfte anwendet.»⁴⁹ Fehlendes Fachwissen oder fehlende Erfahrung (sog. Übernahmeverschulden) kann der Beauftragte nicht haftungsmildernd einwenden.⁵⁰

In Bezug auf die Haftung für technische Verschuldung in einem IT-Projekt, mit welchem ein IT-Projektmanager beauftragt wurde, ergibt sich, dass Abweichungen von den Regeln der Kunst eine Haftung zur Folge haben können. Ausgehend von obengenannter Definition technischer Verschuldung kann dafür auch eine Haftung konstruiert werden. Unterschieden werden muss hier indes zwischen bewusst, bspw. aufgrund eines engen Zeitplanes des Bestellers, aufgenommener Verschuldung und solcher, welche auf mangelnde Sorgfalt in der Projektführung zurückzuführen ist. Nur für Letztere ist eine Haftung aus unsorgfältiger Auftragsausführung denkbar, sofern die Aufklärungs- und Treuepflichten in ersterem Fall eingehalten wurden.

Damit ein Werkvertrag korrekt erfüllt ist, muss das Werk den vertraglichen Vorgaben entsprechen und die vorausgesetzten und vertraglich vereinbarten Eigenschaften aufweisen.⁵¹ Ein Mangel am Werk ist folglich ein vertragswidriger Zustand des Werkes. Neben dem Fehlen einer hinsichtlich der Gebrauchstauglichkeit des Werkes vorausgesetzten Eigenschaft gilt auch das Fehlen einer vereinbarten Eigenschaft als Mangel.⁵²

Dem Besteller stehen nach Ablieferung des Werkes, abhängig von der Schwere des Mangels, gemäss Art. 368 OR vier Mängelrechte zur Verfügung: Die Wandelung, die Minderung, die Nachbesserung und ergänzend der Schadenersatz. Die Mängelrechte sind dispositiv, bei einer Freizeichnung gilt jedoch die Schranke von Art. 100 OR.⁵³

Betreffend die Haftung für technische Verschuldung in IT-Projekten stellt sich also wieder die Frage, in welchem Rahmen (und welcher Schwere) technische Verschuldung einen Mangel darstellt. Nicht jeder Fehler in der Informatik ist ein Mangel im Sinne des Werkvertragsrechtes⁵⁴, so ist bei komplizierten Leistungsprogrammen eine gewisse Menge an «Störungen» noch vertragsgemäss.⁵⁵ Ausschlaggebend ist, «ob die hergestellte Software die nach dem konkreten Vertrag (z.B. in einem integrierten ‹Pflichtenheft›) vereinbarten und die ohne Vereinbarung vorausgesetzten Eigenschaften aufweist […], oder ob sie von der vertraglichen Sollbeschaffenheit […] abweicht»⁵⁶.

Vereinbaren die Parteien explizit die (technische) Schuldenfreiheit des Werkes bzw. die Einhaltung gewisser Qualitäts-Kennzahlen, so stellt das Vorhandensein technischer Verschuldung das Fehlen einer vereinbarten Eigenschaft und damit einen Mangel dar. Je nach vereinbartem und vorausgesetztem Gebrauch stellt eine technische Verschuldung einen schweren oder nur minder schweren Mangel dar. Zu unterscheiden ist hierbei zwischen Systemen, die als Basis für eine Weiterentwicklung dienen sollen und solchen, welche durch den Besteller nicht weiterentwickelt werden.⁵⁷ In ersterem Fall kann eine technische Verschuldung schwer ins Gewicht fallen, in letzterem Fall kann sie hingegen von geringerer Relevanz sein.⁵⁸ Abhängig davon stehen dem Besteller dann unterschiedliche Mängelrechte zu. Fälle, in denen «nur» die Beseitigung technischer Verschuldung anfällt, sofern diese noch nicht überhandgenommen hat⁵⁹, werden wohl am einfachsten mit einer unentgeltlichen Nachbesserung erledigt. Sollte der Anbieter nicht in der Lage sein, diesem Ersuchen nachzukommen, wird der Abzug am Werklohne die sinnvollste Lösung sein.

Im Rahmen eines Kaufvertrages haftet der Verkäufer dem Käufer gemäss Art. 197 OR für alle zugesicherten Eigenschaften sowie dafür, dass die Sache nicht körperliche oder rechtliche Mängel hat, welche ihren Wert oder ihre Tauglichkeit zum vorausgesetzten Gebrauch aufheben oder mindern. Das Kaufvertragsrecht kommt in erster Linie bei Standardprodukten zum Einsatz. Folglich stellt sich einerseits die Frage, in welchem Rahmen technische Verschuldung als Sachmangel gilt und andererseits, ob die Schuldenfreiheit allenfalls als zugesicherte Eigenschaft gilt.

Ein Sachmangel ist die «ungünstige Abweichung der Ist-Beschaffenheit von der Soll-Beschaffenheit»⁶⁰, welche den Wert oder die Tauglichkeit zum vorausgesetzten Gebrauch aufhebt oder erheblich mindert. Auch eine unzureichende Dokumentation kann ein Mangel sein.⁶¹ Ausschlaggebend ist, wie sich der «vorausgesetzte Gebrauch» definiert sowie die Erheblichkeit der Minderung des Wertes oder der Tauglichkeit. Hier gilt es zu differenzieren: Handelt es sich bei der eingekauften Software um ein Standardprodukt, welches erwartungsgemäss vom Käufer nicht selbst weiterentwickelt oder angepasst werden kann, so kann eine technische Verschuldung nicht stark ins Gewicht fallen, da nicht davon ausgegangen werden muss, dass der Käufer Handlungen vornimmt, bei welchen technische Verschuldung von Relevanz ist. Hingegen bei einer Software, die als Grundlage zur Weiterentwicklung dienen soll, fällt eine bestehende technische Verschuldung im Weiterentwicklungsprozess klar ins Gewicht, weshalb der vorausgesetzte Gebrauch wohl auch eine Schuldenfreiheit oder zumindest eine tiefe technische Verschuldung umfasst. Wenn Software wie «Baumaterial» eingekauft wird, kann nach der Meinung des Autors eine (hohe) technische Verschuldung als Mangel qualifiziert werden.

Wird im Rahmen der Vertragsverhandlungen zugesichert, dass die gekaufte Software frei von technischer Verschuldung ist bzw. ein bestimmter Qualitäts-Score eingehalten wurde, ist das Vorhandensein technischer Verschuldung ein Mangel im Sinne der Sachmängelgewährleistung und der Käufer kann entsprechend seine Mängelrechte geltend machen.

Steht ein Mangel an der Kaufsache fest, so kann der Käufer gemäss Art. 205 OR mittels Wandelung den Kauf rückgängig machen oder durch Minderung Ersatz des Minderwerts der Sache fordern. Handelt es sich bei der Kaufsache um eine Gattungsschuld, besteht überdies die Möglichkeit einer Ersatzlieferung einer fehlerfreien Sache i.S.v. Art. 206 OR.

Beim Kauf von Software handelt es sich in der Regel um ein Standard- und Serienprodukt. Damit handelt es sich grundsätzlich um eine Gattungsschuld, da es «auf die Individualität der ausgewählten Sache nicht ankommt»⁶² und die Software ohne weitere Anpassungen verkauft wird. Weist die gekaufte Software also wider Erwarten eine (hohe) technische Verschuldung auf, besteht grundsätzlich neben Wandelung und Minderung auch die Möglichkeit einer Ersatzlieferung. Dies wird indes in den wenigsten Fällen erfolgversprechend sein, denn die Mangelhaftigkeit liegt nicht in dem spezifischen, dem Käufer gelieferten Exemplar der Software (ausser der physikalisch gelieferte Datenträger ist defekt), sondern der gesamten Software, deren Kopien verkauft werden. So wird dem Vorliegen technischer Verschuldung wohl mit einer Minderung oder in schweren Fällen einer Wandelung begegnet werden müssen.

Im Schweizerischen Recht gilt der Grundsatz der Vertragsfreiheit. Die Vertragsfreiheit ist Ausfluss der Privatautonomie und umfasst unter anderem die Freiheit zu bestimmen, ob, mit wem und mit welchem Inhalt ein Vertrag geschlossen werden soll.⁶³ Art. 19 OR hält fest, dass der Inhalt eines Vertrages innerhalb der Schranken des Gesetzes frei festgelegt werden kann. Die oben ausgeführte Klassifikation in verschiedene Vertragstypen bleibt indes als Grundlage relevant und dient der Lückenfüllung bei offenen Fragen. Da es sich bei der Entwicklung von Individualsoftware oft um einen Werkvertrag, allenfalls mit auftragsrechtlichen Komponenten, handelt, wird sich betreffend Haftung im Folgenden daran orientiert.

Ausgehend von den beschriebenen Lösungsmöglichkeiten lassen sich vertragliche Regelungen für das Management technischer Verschuldung entwickeln. Als Ausgangspunkt wird vorliegend von einer agilen Entwicklung ausgegangen, die vertraglichen Lösungen lassen sich aber, teilweise etwas angepasst, auch auf andere Entwicklungsmethoden anwenden.

Eine wichtige Grundlage für das Management technischer Verschuldung ist, wie mehrfach betont, das Bewusstsein für die Problematik. Auch für vertragliche Lösungsansätze zur Vermeidung technischer Verschuldung sind ein gegenseitiges Verständnis und eine einheitliche Definition die Grundlage. Folglich sollten sich die Parteien in einem ersten Schritt auf eine einheitliche Definition einigen. Durch die Auseinandersetzung mit den für die jeweilige Partei wichtigen Punkte bzw. Problematik kann zugleich das gegenseitige Bewusstsein gestärkt werden. In gewissem Umfang sollte der Anbieter der IT-Dienstleistung den Besteller (häufig ein IT-Laie) an die Hand nehmen und auf die Problematik der technischen Verschuldung aufmerksam machen.

Wenn die Problematik der technischen Verschuldung beiden Parteien bekannt und bewusst ist, kann sie behandelt werden, als wäre sie Teil des gewöhnlichen Funktionsumfanges. Eine saubere, vollständige und schuldenfreie Entwicklung dauert unter Umständen länger und kostet mehr, als wenn Abkürzungen genommen werden (und dadurch technische Verschuldung aufgenommen wird). Genau wie es zur gewöhnlichen Entwicklung gehört, Zeit und Ressourcen für die Entwicklung einer neuen Funktion aufzuwenden, so sollte als ebenso normal die Aufarbeitung von technischer Verschuldung betrachtet werden. Die Parteien müssen sich einigen, wie viel technische Verschuldung in welchem Zeitraum als «zu erwarten» anzusehen ist. Einer darüber hinausgehenden technischen Verschuldung ist mit geeigneten Instrumenten zu begegnen und das Risiko zwischen den Parteien aufzuteilen.⁶⁴ Ziel ist es, den Entwicklern ein Umfeld zu bieten, in dem technische Verschuldung möglichst vermieden und nötigenfalls aufgearbeitet werden kann, sowie dem Besteller die Sicherheit zu geben, dass sein IT-Projekt so schuldfrei wie möglich entwickelt wird.

Damit die technische Verschuldung in einem Projekt bestimmt werden kann, muss sie messbar sein. Dazu können sich die Parteien auf Kennzahlen und Messmethoden einigen, um eine Überprüfung durch die Parteien selbst und allenfalls sachverständige Dritte zu ermöglichen. Wenngleich damit nicht alle der vielen Facetten technischer Verschuldung abgedeckt werden können, wird eine gewisse Sicherheit und nicht zuletzt ein Beweismittel in einem allfälligen Prozess geschaffen. Insbesondere die Qualität des Codes und der Dokumentation können so im Rahmen eines Audits beurteilt werden.

Eine erste Möglichkeit besteht in der Vereinbarung der Nutzung eines bestimmten Tools zur Messung technischer Verschuldung wie bspw. dem meistverbreiteten Tool SonarQube⁶⁵. Dieses misst und beurteilt eine Vielzahl von Aspekten wie die Codekomplexität, die Zuverlässigkeit und insbesondere die Wartbarkeit⁶⁶, zu welcher die technische Verschuldung gehört.⁶⁷ SonarQube vergibt dann unter anderem für die «Technical Debt ratio» einen Score von A bis E. Die Parteien können somit vereinbaren, welche Scores für eine Abnahme des Projektes verlangt werden. So kann bei jeder Änderung des Codes eine Beurteilung der Komplexitätserhöhung erfolgen und diese, wenn nötig, aktiv behandelt werden. Zeigt die Entwicklung der Kennzahlen ein negatives Bild, kann die Ergreifung technischer Massnahmen, wie bspw. ein Refactoring, vereinbart werden.

Es handelt sich bei den vereinbarten Kennzahlen um ein Qualitätsmerkmal, welches die Parteien vertraglich als vorausgesetzte Eigenschaft der geschuldeten Sache vereinbaren können. Eine Abweichung davon würde einen Mangel darstellen und dem Besteller die entsprechenden Mängelrechte zur Verfügung stehen. Um die Feststellung solcher Mängel noch vor einer allfälligen Klage zu erleichtern, können die Parteien vereinbaren, einen externen Code-Audit durchführen zu lassen. Dessen Kosten können, bei entsprechender Vereinbarung, der «unterliegenden» Partei überbunden werden. Sollte noch ein stärkeres Mittel gewünscht sein, bietet es sich an, die Beurteilung der technischen Schuld im Rahmen eines Schiedsgutachtens i.S.v. Art. 189 ZPO durchführen zu lassen, wobei den Parteien bewusst sein sollte, dass hierfür beträchtliche Kosten entstehen können.

Eine weitere Möglichkeit besteht in der Vereinbarung einer Grenzkostenbetrachtung im Sinne der MCO. Die Parteien vereinbaren in diesem Fall, neben der Kostenschätzung für eine Story auch eine (technische) Komplexitätsschätzung vorzunehmen. Für diese beiden Werte wird dann ein Verhältnis vereinbart, welches in einem bestimmten Zeitraum gewahrt werden muss. Entwickelt sich das Verhältnis dahin, dass für gleich komplexe Inkremente höhere Kosten anfallen, und dies nicht innert einer festgelegten Frist behoben wird, fällt bspw. ein Wartungssprint auf Kosten des Anbieters an.

Die Zusammensetzung insbesondere des Entwicklerteams kann entscheidend für den Erfolg eines IT-Projektes sein. Wie dargelegt kann sowohl die Seniorität der Entwickler sowie das Ausscheiden eines (für die Entwicklung massgebenden) Entwicklers während des laufenden Entwicklungsprozesses zu einer grossen technischen Verschuldung führen.

Da sich die Geschäftsleitung des Entwicklerteams wohl kaum Vorgaben zur internen Personalpolitik vom Besteller machen lässt, können die Parteien bspw. eine gewisse Anzahl an Senior-Entwicklern⁶⁸, die an dem Projekt arbeiten, bestimmen. So können bspw. in einem Rahmenvertrag die Rollen im Projektteam definiert werden. Im Falle des Ausstieges eines Senior-Entwicklers aus dem Projekt müsste dann innert einer bestimmten Frist ein Ersatz für die Arbeit an dem Projekt bereitgestellt werden, wobei es sich anbietet, bereits auf dem Projekt arbeitende Junior-Entwickler entsprechend weiterzubilden. Gleichzeitig lässt sich in diesem Rahmen die minimale nötige und die maximal zulässige Teamgrösse festlegen.

Der Rahmenvertrag eines Projektes entspricht oft einem Auftragsverhältnis, allenfalls mit Elementen anderer Vertragstypen. Der Beauftragte hat den Auftrag gemäss Art. 298 OR persönlich auszuführen, grundsätzlich jedoch mit der Möglichkeit, Hilfspersonen beizuziehen. Da der Beizug von Hilfspersonen vertraglich ausgeschlossen werden kann,⁶⁹ muss es nach der Meinung des Autors auch möglich sein, die Zulässigkeit von Hilfspersonen auf bestimmte Personen oder Rollen zu beschränken. Zudem sollte sich der Anbieter (und Beauftragte) auch verpflichten können, eine bestimmte Zusammensetzung von Hilfspersonen verschiedener Qualifikationen im Entwicklerteam sicherzustellen. Eine Abweichung einer solchen Regelung wäre eine Nicht- oder Schlechterfüllung des Vertrages, welcher über Art. 97 OR abgewickelt werden könnte.

Für die Vergütung eines agil entwickelten Projektes gibt es verschiedene Vergütungsmodelle mit unterschiedlicher Risikoverteilung.⁷⁰ Neben einer Vergütung nach Aufwand haben sich Modelle wie der agile Festpreis, Stückpreise, Change for Free und weitere⁷¹ entwickelt, welche der agilen Entwicklung besser gerecht werden. Den Parteien stehen dementsprechend viele Möglichkeiten offen, um eine Vergütung zu vereinbaren, die ihren Vorstellungen einer optimalen Entwicklung am besten gerecht werden. Über die Vergütung kann viel gesteuert werden, wenn bspw. erst nach mangelloser Abnahme der volle Betrag ausbezahlt wird, wodurch die Risikoverteilung zwischen den Parteien etwas ausgeglichen werden kann. Auch kommt hier zum Ausdruck, wie viel technische Verschuldung die Parteien noch als «im Rahmen der zu erwartenden Entwicklung abzuarbeiten» betrachten.

Vor dem Hintergrund technischer Verschuldung sollte darauf geachtet werden, dass das Risiko für die Entstehung technischer Verschuldung fair verteilt wird. Eine reine Vergütung nach Aufwand bspw. kann zu einer Verzerrung der Projektkosten führen, da der Besteller das gesamte Risiko trägt, auch wenn ein gewisser Aufwand für die Beseitigung technischer Verschuldung anfällt, die eigentlich der Anbieter zu tragen hätte. Nach der Meinung des Autors bieten sich insbesondere der agile Festpreis⁷² und/oder eine Vergütung von Stückpreisen⁷³ an. Letztere funktioniert gut mit der Behandlung von technischer Verschuldung als Funktionsumfang: Durch festgelegte Stückpreise pro Story kann eine Bereinigung technischer Verschuldung als gewöhnliche Story abgearbeitet und die geleistete Arbeit entsprechend in Rechnung gestellt werden.⁷⁴

Eine weitere Möglichkeit, die zuvor beschriebenen Lösungsansätze in der Praxis umzusetzen, ist eine Incentivierung, also das Schaffen von Anreizen. Wie besprochen, kann technische Verschuldung mit entsprechendem Bewusstsein und achtsamer Entwicklung tief gehalten werden. Um technische Verschuldung zu minimieren, lassen sich Anreize vereinbaren, die eine schuldenfreie Entwicklung belohnen (bspw. mit Criteria of Satifaction in der Definiton of Done).

Anknüpfend an die obengenannten Kennzahlen und als Gegenstück zur Vereinbarung von Eskalationsstufen bei negativer Entwicklung kann also vereinbart werden, dass bei konstant guter Entwicklung (die entsprechenden Scores bleiben in einem bestimmten Zeitraum konstant gut) eine Belohnung fällig wird.

In einem lange dauernden Entwicklungsprozess gewinnen insbesondere die Dokumentation und das Know-how des Teams an Bedeutung. Die Aufrechterhaltung dieses Know-hows kann für den Anbieter eine kostspielige Angelegenheit werden, da sie Zeit und Ressourcen bindet, ohne dass ein neues Produkt oder Feature geliefert werden kann. Um dem entgegenzuwirken, kann auch hier mit Anreizen gearbeitet werden, so könnte bspw. eine Pauschale zur Aufrechterhaltung des Know-hows vom Besteller an den Softwareentwickler entrichtet werden. So kann sich der Besteller darauf verlassen, dass das geschaffene Wissen erhalten bleibt und der Anbieter kommt nicht in Versuchung, aus Kostengründen die Wissenserhaltung zu vernachlässigen. Eine Überprüfung ist für den Besteller hingegen anspruchsvoll.

Schliesslich lassen sich die oben betreffend Team-Mix gemachten Lösungsvorschläge mit Anreizen begünstigen. Besonders die laufende Weiterbildung bereits auf dem Projekt arbeitender Junior-Entwickler kann für den Besteller von Vorteil sein, da viel Know-how behalten werden kann und bei einem allfälligen Ausscheiden eines Senior-Entwicklers keine neue, externe Person in das Projekt eingearbeitet werden muss.

Generell, aber auch in Bezug auf das Management technischer Verschuldung ist es wichtig, Konfliktlösungsmechanismen zu vereinbaren. Dies nicht aus Misstrauen den Entwicklungspartnern gegenüber, sondern zur Schaffung von geregelten Vorgehensweisen und um möglicherweise auftretende Meinungsverschiedenheiten möglichst einvernehmlich zu lösen. Dies auch vor dem Hintergrund, dass Probleme in IT-Projekten durch gerichtliche Schritte nur schwer zu lösen sind,⁷⁵ das Projekt während der Dauer eines Prozesses «brach» liegt⁷⁶ und die «Behandlung» technischer Verschuldung mit ihrer Zunahme zunehmend teurer wird («Zinsen und Zinseszinsen»). Eine schnelle Streitbeilegung dürfte im Interesse beider Parteien liegen.

In erster Linie kommt hierzu eine Parteiverhandlung in Frage, also das Führen von Verhandlungen. Vertraglich ist zu vereinbaren, wer mit wem zu welchem Zeitpunkt und wie lange zu verhandeln hat (zuerst im Projektteam, dann im Führungsausschuss etc.). Den Parteien soll damit ermöglicht werden, stets zu wissen, wer erste Ansprechperson für Konflikte ist (bspw. mit einem Single Point of Contact) und Meinungsverschiedenheiten möglichst schlank zu bereinigen.⁷⁷ Auch kann vereinbart werden, in welchem Zeitpunkt ein Audit durch einen Dritten erfolgen soll.

Sollten die Parteien nicht zu einer Einigung gelangen, gibt es weitere ADR-Verfahren, die einem (langwierigen) Gerichtsverfahren vorausgehen oder dieses ersetzen können:

Bei einer Mediation versuchen die Parteien unter Beizug einer unabhängigen Drittperson ohne Entscheidbefugnis, ihre Streitigkeit unter Berücksichtigung aller Interessen einvernehmlich zu lösen. Sie ist auch in Art. 213 ff. ZPO festgehalten. Ziel ist «das Schaffen von Rahmenbedingungen, innerhalb derer die Konfliktparteien durch wechselseitiges Ausloten von Verhandlungsspielräumen eine Lösung suchen und dabei von einer Mediatorin oder einem Mediator unterstützt werden»⁷⁸. Da der Mediator über keine Entscheidbefugnis verfügt, liegt der Fokus nicht auf dem Analysieren oder Aufrechnen vergangener Fehler, sondern die Parteien entscheiden selbst als Experten für ihre Auseinandersetzung über eine geeignete Lösung. Unter anderem sollen die Bedürfnisse der Parteien in der Gegenwart und Zukunft berücksichtigt werden und eine beidseitige Gewinnmaximierung angestrebt werden.⁷⁹ Die Vorteile der Mediation liegen insbesondere in der hohen Kontrolle und Gestaltungsmöglichkeit der Parteien, der Schnelligkeit und der Vertraulichkeit.⁸⁰ Da die Mediation von der Privatautonomie geprägt ist, ist es wichtig, dass die Parteien die Grundzüge der Mediation zuvor festlegen. Insbesondere, ob sie zwingend vor einer Klage durchgeführt werden muss, wie sie eingeleitet und abgeschlossen wird und wann sie allenfalls als gescheitert zu betrachten ist. Ob eine Mediationsabrede gerichtlich durchsetzbar ist, ist hingegen aufgrund der Freiwilligkeit des Verfahrens in der Lehre und Rechtsprechung umstritten.⁸¹

Steht eine tatsächliche Fragestellung zur Diskussion, können die Parteien über die streitige Tatsache ein Schiedsgutachten i.S.v. Art. 189 ZPO einholen. Der Schiedsgutachter entscheidet dann verbindlich über die streitige Tatsache. Anders als bei einem Parteigutachten ist sodann auch der staatliche Richter gemäss Art. 189 Abs. 3 ZPO an das Schiedsgutachten gebunden. Für die Parteien ist dies in erster Linie ein Mittel zur Prozessvermeidung.⁸² Der Schiedsgutachter kann überdies von den Parteien selbst bestimmt werden, wobei auch juristische Personen in Frage kommen, was es den Parteien erlaubt, eine Fachstelle oder einen Sachverständigen mit der nötigen fachlichen Expertise für die Beurteilung ihrer Streitigkeit zu bestimmen.⁸³

Schliesslich kann die Beurteilung der gesamten Streitigkeit den staatlichen Gerichten entzogen und mittels Schiedsklausel einem Schiedsgericht i.S.v. Art. 353 ff. ZPO zugewiesen werden. Die Parteien ermächtigen damit ein von ihnen bestimmtes Schiedsgericht, über ihre Streitigkeit eine verbindliche und vollstreckbare Entscheidung zu treffen.⁸⁴ Dies hat wiederum den Vorteil, dass die Parteien hohe Kontrolle über das Verfahren haben und die Schiedsrichter oder Schiedsinstitution selbst bestimmen können, und so die nötige fachliche Expertise der beurteilenden Personen sicherstellen können.⁸⁵ Eine gültig vereinbarte Schiedsklausel ist verbindlich, ein dennoch angerufenes staatliches Gericht müsste seine Zuständigkeit nach Art. 61 ZPO ablehnen.

Im Rahmen eines Escrow-Agreements hinterlegt der Softwareentwickler den Sourcecode und weitere Entwicklungsunterlagen bei einem Dritten «Escrow-Agenten». Rechtlich kann dies als Zwei- oder Dreiparteienverhältnis ausgestaltet werden, wobei für die vorliegende Arbeit nur das Dreiparteienverhältnis mit Softwareentwickler, Escrow-Agent und Besteller von Relevanz ist.

Im Rahmen eines solchen Dreiparteienvertrages vereinbaren die Parteien die Hinterlegung der Entwicklungsunterlagen bei einer bestimmten Stelle und legen die Bedingungen fest, unter denen die Unterlagen dem Besteller herausgegeben werden sollen. Dies erlaubt dem Besteller, eigenständig an die Daten zu gelangen, wenn bestimmte Bedingungen erfüllt sind.⁸⁶ Für zusätzlichen Schutz gegen einen Konkurs des Anbieters muss der Anbieter dem Escrow-Agenten das fiduziarische Eigentum an den Entwicklungsunterlagen übertragen.⁸⁷ Als hauptsächliche Herausgabegründe nennt Fröhlich-Bleuler bspw. den Gesellschafterwechsel, den Konkurs des Anbieters oder die Unfähigkeit des Anbieters, das Projekt fertigzustellen oder Mängel zu beheben, wobei in diesen Fällen wohl ein rechtskräftiges Urteils notwendig ist.⁸⁸

Es ist zu beachten, dass auch hier Meinungsverschiedenheiten auftreten können, für welche auf die soeben beschriebenen Instrumente, insbesondere die Mediation, zurückgegriffen werden sollte, damit nicht auch hierüber Prozess geführt werden muss.⁸⁹

Der Hauptzweck der Hinterlegung des Sourcecodes besteht darin, eine gewisse Unabhängigkeit des Bestellers vom Softwareentwickler sicherzustellen und eine zügige Herausgabe zu ermöglichen. Dies auch, damit der Zugriff auf die Daten für den Besteller nicht während eines allfälligen Gerichtsprozesses blockiert ist.

Den folgenden Musterklauseln liegt jeweils die Annahme zugrunde, dass die Parteien einen sonst vollständigen Vertrag mit Präambel, Zielsetzung etc. vereinbaren. Die Klauseln verstehen sich als beispielhafte Darstellung der oben beschriebenen Konzepte und müssten jeweils auf den Einzelfall angepasst werden. Platzhalter sind in kursiver, blauer Schrift gehalten.

Die Parteien sind sich der Problematik der technischen Verschuldung bewusst. Sie anerkennen, dass es sich bei technischer Verschuldung um eine Abweichung von der optimalen Codeentwicklung, entstanden durch (bewusste) Abkürzungen in der Entwicklung, handelt, und dass sie in erster Linie im Rahmen von mangelhaftem Code und unzureichender Dokumentation zutage tritt. Die Parteien bemühen sich gemeinsam, ein Umfeld zu schaffen, in welchem eine technische Verschulung minimiert wird.

Die Parteien anerkennen insbesondere, dass die Haupttreiber technischer Verschuldung ein zu hoher Zeitdruck und unrealistische Terminpläne sind. Jede Partei hat die Obliegenheit, die jeweils andere Partei auf ein Verhalten hinzuweisen, das zu einer höheren technischen Verschuldung führt. Die bewusste Inkaufnahme technischer Verschuldung durch den Besteller führt nicht zu einer Haftung des Anbieters.

Die Parteien anerkennen, dass es im Rahmen des Entwicklungsprozesses zu technischer Verschuldung kommen kann. Um diese möglichst tief zu halten, vereinbaren die Parteien, jeden 5. Sprint⁹⁰ oder spätestens vor jedem Release, einen Sprint zur Beseitigung technischer Verschuldung, insbesondere zur Bereinigung des Programmcodes und der Dokumentation, aufzuwenden. Sollte ein Bereinigungssprint nach der Beurteilung der Anbieterin nicht nötig sein, da der Code keine technische Verschuldung aufweist, verpflichtet sich die Bestellerin zur Leistung einer Prämie gemäss Klausel Y⁹¹. Die Anbieterin haftet in diesem Fall für die Folgen einer wider Erwarten vorhandenen technischen Verschuldung. Der Besteller hat das Recht, auf die Durchführung eines Bereinigungssprints zu bestehen, wenn die vereinbarten Scores in Klausel X nicht eingehalten werden.⁹²

Der Anbieter verpflichtet sich, die Entwicklung nach den höchsten Branchenstandards⁹³ durchzuführen. Insbesondere verpflichtet er sich dem bewussten und aktiven Management von technischer Verschuldung. Er sorgt insbesondere für eine genügende Testautomatisierung und ergreift alle nötigen Massnahmen zur Minimierung technischer Verschuldung. Die Beurteilung der Einhaltung geltender Branchenstandards erfolgt auf Verlangen einer Partei mittels Code-Audits durch einen Dritten gemäss Klausel X. Im Streitfall wird die Beurteilung durch ein Schiedsgutachten vorgenommen, wobei die das Gutachten verlangende Partei dessen Kosten zu tragen hat.⁹⁴ Die Bestimmung des Schiedsgutachters erfolgt, wenn sich die Parteien nicht innert 10 Tagen einigen können, durch den Obergerichtspräsidenten des Kantons X.⁹⁵

Die Parteien vereinbaren eine Vergütung nach Story Punkten. Der Stückpreis pro Story Punkt wird auf CHF xx.xx festgelegt. Für die regelmässige Bereinigung technischer Verschuldung gemäss Klausel X wird ein Aufwand von 1 Story Punkt(en) festgelegt.⁹⁷

alternativ

Die Parteien vereinbaren eine Vergütung mittels agilen Festpreises. [Ausführungen zum Ablauf].⁹⁸ Für die regelmässige Bereinigung technischer Verschuldung gemäss Klausel X wird ein eine Vergütung von CHF xx.xx vereinbart.

Die Bestellerin verpflichtet sich zur Entrichtung der folgenden Prämien:

0.5 Story Punkte/CHF x.xx, wenn aufgrund fehlender technischer Verschuldung kein Bereinigungssprint gemäss Klausel X nötig ist.¹⁰⁰

Die Parteien kommen überein, dass das Softwareanalysetool X (bspw. SonarQube) als massgebende Metrik für die technische Verschuldung des Projektes verwendet wird. Der Anbieter orientiert den Besteller am Ende jedes Sprints schriftlich über die aktuellen Scores und welche Handlungen er, wenn nötig, zu deren Verbesserung vorsieht. Die Parteien vereinbaren die folgenden Scores in den folgenden Kategorien als Zielwerte:

Kategorie 1: A/Kategorie 2: B/Kategorie 3: B/Kategorie 4: A.¹⁰¹

Eine Abweichung von diesen Scores nach unten wird im Rahmen des nächsten Bereinigungssprints korrigiert. Sollten die Scores nach der Bereinigung noch immer eine Abweichung nach unten aufweisen, so ist der Anbieter verpflichtet, auf eigene Kosten nachzubessern.

Als weitere Metrik zu Messung technischer Verschuldung vereinbaren die Parteien die Betrachtung der Grenzkosten im Sinne der sog. Marginal Cost of Ownership. Dazu vereinbaren sie den folgenden Mechanismus:

Unabhängig von der Kostenschätzung für jede Story (Anzahl an Story Punkten) führt der Anbieter eine Beurteilung der technischen Komplexität jeder Story durch. Die Beurteilung erfolgt durch eine technisch qualifizierte Fachperson des Anbieters und wird getrennt von der Kostenschätzung auf einer Skala von A (wenig komplex) bis E (sehr komplex) beurteilt. Diese Beurteilung wird dem Besteller schriftlich kommuniziert. Der Anbieter legt dem Besteller Rechenschaft darüber ab, wie sich die Beurteilung der technischen Komplexität im Verhältnis zum Kostenaufwand im Laufe des Projektes entwickelt.

Sollten die Kosten für eine Story der gleichen Komplexitätsklasse seit Beginn des Projektes¹⁰³, um mehr als X%¹⁰⁴, (heruntergerechnet auf den Umfang der Story¹⁰⁵ bspw. pro Story Punkt, nach Bereinigung der Teuerung) gestiegen sein, anerkennen die Parteien dies als Symptom technischer Verschuldung und der Anbieter verpflichtet sich, auf seine Kosten die nötigen Handlungen vorzunehmen, um die technische Verschuldung zu reduzieren.

Die Parteien vereinbaren, den Softwarecode regelmässig einer Überprüfung auf Qualitätsmerkmale und insbesondere technische Verschuldung zu unterziehen (sog. Audits). Die Parteien bringen der jeweils anderen Partei die Ergebnisse des von ihnen in Auftrag gegebenen Audits zur Kenntnis. Der Anbieter verpflichtet sich, auf Verlangen des Bestellers einem sachverständigen Dritten zur Durchführung eines Audits Zugang zum Sourcecode und allen weiteren notwendigen Unterlagen zu geben. Die Kosten für den Audit eines Dritten trägt diejenige Partei, die diesen verlangt. Zeigt der Audit Mängel an der Qualität oder technische Verschuldung auf, so trägt der Anbieter die Kosten für deren Beseitigung sowie den Audit, es sei denn, es handelt sich um durch den Besteller bewusst aufgenommene technische Verschuldung.¹⁰⁶

Die Parteien vereinbaren, die Grösse des Entwicklerteams auf X (bspw. 10) Personen zu beschränken. Als Ansprechperson wird dem Besteller eine Person als Single Point of Contact, sowie eine Stellvertretung, genannt.

Das Entwicklerteam hat, neben dem Projektleiter des Anbieters, aus mindestens X (bspw. 4) Senior-Entwicklern zu bestehen. Als Senior-Entwickler gilt vorliegend ein Mitarbeiter, welcher X Qualifikation aufweist und mindestens Y Jahre Berufserfahrung aufweist. Der Anbieter legt dem Besteller regelmässig Rechenschaft über Veränderungen in der Personalzusammensetzung des eingesetzten Teams ab. Er ist verpflichtet, eine Unterschreitung der vereinbarten Anzahl von Senior-Entwicklern innert Frist zu berichtigen.

Der Anbieter ist für die interne Weiterbildung des Entwicklerteams besorgt. Er stellt die Weiterbildung der Junior-Entwickler, die zum Erhalt der vereinbarten Teambesetzung notwendig ist, sicher.

Für den Erhalt des Know-hows des Entwicklerteams und die interne Weiterbildung entrichtet der Besteller eine Pauschale von CHF X pro Betriebsjahr der Software, zahlbar im Voraus. Der Anbieter verpflichtet sich, eine aktuelle und vollständige Dokumentation aller entwicklungsrelevanten Dokumente zu führen.

Die Parteien verpflichten sich, im Falle von Meinungsverschiedenheiten oder Streitigkeiten, innert 10 Tagen Verhandlungen zur gemeinsamen Lösungsfindung in den folgenden Instanzen aufzunehmen, bevor rechtliche Schritte (insbesondere die Mediation gemäss Mediationsklausel) ergriffen werden:

Verhandlungsinstanzen:

1. Der zuständige Teamleiter des Entwicklerteams mit dem zuständigen Projektleiter des Bestellers. Bei Scheitern der Verhandlung oder fehlender Entscheidungskompetenz
2. Der Account Manager des Softwareherstellers mit dem Account Manager des Bestellers. Bei erneutem Scheitern der Verhandlungen oder fehlender Entscheidungskompetenz
3. Der CEO der Softwareherstellerin mit dem CEO des Bestellers. Die genaue Benennung der zuständigen Personen erfolgt in Anhang 1.

Die Parteien vereinbaren die Hinterlegung des Quellcodes und aller weiteren Herstellungsunterlagen bei Escrow-Anbieter mit separater Vereinbarung. Der Anbieter verpflichtet sich, dem Escrow-Anbieter das fiduziarische Eigentum an den hinterlegten Sachen und Daten zu übertragen. Die Hinterlegung dauert ab Beginn der Entwicklung bis zur erfolgreichen Abnahme der letzten Arbeiten.

Die Herausgabe der hinterlegten Dokumente erfolgt ausschliesslich in den folgenden Fällen:¹⁰⁷

1. Gesellschafterwechsel von Person X beim Anbieter;
2. Konkurs oder Insolvenzverfahren des Anbieters;
3. Einleitung eines Gerichts- oder Schiedsverfahrens nach gescheiterter Mediation, wobei die die Herausgabe verlangende Partei bei Unterliegen Ersatz für den durch die Herausgabe entstandenen Schaden, insbesondere den entgangenen Gewinn, zu leisten hat.¹⁰⁸ Der Besteller darf ausserdem die Herausgabe der Daten an einen von ihm bestimmten Dritten zwecks Durchführung eines Audits verlangen, sollt der Anbieter seiner Herausgabepflicht in Klausel X nicht nachkommen.

Streitigkeiten betreffend die Herausgabe unterliegen den gleichen Eskalationsmechanismen wie die restlichen Streitigkeiten und Meinungsverschiedenheiten.

Siehe bspw. Musterklauseln der ITDR, https://www.itdr.ch/en/downloads/.

Technische Verschuldung ist kein neues Phänomen und doch hat es nicht an Relevanz verloren. Oft durch Zeitmangel entstanden, bedarf es einer bewussten Beseitigung technischer Verschuldung, um die nachhaltige und schuldenfreie Entwicklung eines IT-Projektes sicherzustellen. Während ein gemeinsames Bewusstsein und ein entsprechendes Entwicklungsumfeld eine wichtige Grundlage bilden, darf nicht unterschätzt werden, in welcher Beziehung und Abhängigkeit die Parteien eines IT-Projektes stehen. Während grundsätzlich angenommen werden darf, dass die Parteien redlich und in Harmonie auf eine erfolgreiche Entwicklung hinarbeiten, lohnt es sich doch, Kontrollmechanismen zu vereinbaren.

Abschliessend lässt sich folgendes festhalten:

Die Zunahme einer gewissen technischen Verschuldung ist in einem langjährigen IT-Projekt zu erwarten. Deren Beseitigung hat genauso zum Entwicklungsprozess zu gehören wie die Entwicklung neuer Funktionen, was beiden Parteien bewusst sein muss. Steigende Kosten für die Entwicklung neuer Funktionen sind nicht nur Symptom, sondern auch Indikator technischer Verschuldung.

Damit ein Überblick über die technische Verschuldung im Projekt möglich ist, muss diese laufend anhand verschiedener Metriken gemessen werden. Auf der technischen Ebene bestehen Analysetools, welche diese Beurteilung laufend vornehmen können. Aber auch den Risiken mangelhafter Projektführung sollte die nötige Aufmerksamkeit geschenkt werden.

Entwickelt sich die technische Verschuldung in eine Richtung, welche die zu erwartende technische Verschuldung übersteigt, sind entsprechende Massnahmen anhand des vereinbarten Risk-Shares nötig. Oft wird der Softwareentwickler wohl auf eigene Kosten «aufräumen» müssen, wobei die Ermittlung der Quelle der technischen Verschuldung (bspw. zu enge Zeitpläne) nicht unbeachtet bleiben sollte.

Die vertragliche Regelung von IT-Projekten muss den verschiedenen Bestandteilen eines IT-Projektes und den unterschiedlichen Vertragsarten Rechnung tragen. Es bietet sich an, der Entwicklung mittels Rahmenvertrag einen Mantel zu geben. Regelmässige Abnahmen durch den Besteller schaffen für beide Parteien (Rechts-)Sicherheit.

Während eine Eskalation bei Meinungsverschiedenheiten möglichst vermieden werden sollte, ist eine vorgängige Regelung von (zeit-)effizienten Mechanismen von Vorteil, um den Fortbestand und die Weiterentwicklung eines IT-Projektes sicherzustellen, bspw. durch vertragliches Accountmanagement und Konflikteskalationsverfahren.

Schliesslich lässt sich feststellen, dass sich technische Verschuldung vermeiden lässt. Wird sauber und qualitativ hochwertig programmiert, die Dokumentation laufend nachgeführt, das Entwicklerteam mit dem richtigen Personal besetzt und ein vernünftiger Zeitplan vorgegeben, so lässt sich die technische Verschuldung auf ein Minimum reduzieren. Softwareentwickler und -abnehmer gehen oft ein langjähriges Verhältnis ein und sind voneinander abhängig. Ein Bewusstsein für diese Situation und eine solide vertragliche Grundlage, die gute Arbeit belohnt, sind der Grundstein für eine schuldenfreie Entwicklung.

MLaw Nils Fuchs schloss mit seiner Masterarbeit zum Thema «Vertragliche Instrumente zum Management technischer Verschuldung» sein Masterstudium an der Universität Bern ab. Der vorliegende Beitrag stellt einen Zusammenzug seiner Erkenntnisse dar.

Der Autor dankt insbesondere Dr. Wolfgang Straub für die wohlwollende Betreuung seiner Masterarbeit und den zahlreichen hilfreichen Inputs, sowie MLaw Vaishnavan Subramaniam für seinen Beitrag zu DevOps-Verträgen.