Wer bezahlt die Bugs?

Diese Gedanken sind noch ein bischen unsortiert, ein Update des Artikels ist daher denkbar und wahrscheinlich. Work in Progress.

Zusammenarbeit mit Dienstleistern in der Software-Erstellung

Die Zusammenarbeit mit Software-Dienstleistern in der Individualsoftwareentwicklung hat natürlich verschiedene (mindestens zwei) Perspektiven: der Dienstleister und der Kunde, als Vertragspartner. Je nach Kontext ist es durchaus relevant, noch genauer hinzuschauen, da z.B. in größeren Unternehmen die Einkaufsabteilung erheblichen Einfluß auf die Vertragsgestaltung nimmt.

Grundsätzlich ist es möglich, mit modernen Arbeitsmethoden und Werkzeugen „NULL BUGS“ anzustreben und umzusetzen.

Perspektive des Kunden

Als Kunde erwarte ich eine fehlerfreie Lieferung, und eine technische Entwicklung auf dem Stand der Technik. Dafür gebe ich ja eine Menge Geld aus. Aber es gibt einige Fallstricke, bei denen der Kunde Einfluß hat auf das Ergebnis seines Auftrags:

• Preisdruck: wenn ich als Kunde den Preis versuche beliebig zu drücken, kann ein Dienstleister dafür in der Regel keine hochwertige Arbeit mehr abliefern.
• Termindruck: wenn ich als Kunde den Zeitdruck im Auftag zu hoch treibe, kann der Dienstleister keine hochwertige Arbeit mehr abliefern
• wenn ich den Aussagen des Dienstleisters zu Zeit und Kosten nicht traue, sollte ich einen anderen Dienstleister wählen
• Festpreisprojekte in der klassischen „Gewerk“-Vertragsgestaltung machen mich unflexibel, Nachbesserungs-Aufträge machen es im Nachgang häufig teurer. Durchaus auch ein Geschäftsmodell einer Unternehmensberatungen.
• Ist die Auswahl unserer Dienstleister nach dem günstigsten Preis nicht dafür anfällig, Dienstleister zu engagieren die NICHT nach dem Stand der Technik arbeiten?

Das sind ein paar potentiell toxische Haltungen, die eine fruchtbare Zusammenarbeit torpedieren können. Es gibt noch zahlreiche mehr, wer eine Weile in der Branche unterwegs ist kennt die Beispiele. Obwohl es wohlbekannten Schwierigkeiten sind, werden die Fehler immer wieder gemacht.

Perspektive des Dienstleisters

Als Dienstleister versuche ich, dem Kunden ein hochwertiges Produkt zu liefern. Aber es gibt da einige Fallstricke:

• Bin ich/meine Teams wirklich in der Lage, Nach dem Stand der Technik zu entwickeln und zu liefern? (TDD, 100% Test Coverage, Static Code Analysis, …)
• Haben wir feste Teams mit einer stabile Lieferfähigkeit?
• Beruht unser Geschäfts- und Aquisemodell nicht darauf, dem Kunden die Fehlerbereinigung extra zu verkaufen, und uns billig in die Verträge reinzudumpen?

Der Dienstleister fühlt sich häufig in einer schwächeren Position gegenüber großen Kunden. Haltung zu bewahren und sich treu zu bleiben, ist langfristig häufig die bessere Strategie, als um jeden Preis mit einem renommierten Kunden ins Geschäft kommen zu wollen.

Auswege aus dem Dilemma

Es fängt mit der Haltung an: Beide Seiten sollten sich auf Augenhöhe und mit Respekt begegnen. Ein befreundeter Handwerker formulierte das mal so: Freunde von mir vertrauen darauf, das ich ihnen ein faires Angebot mache, und ich vertraue darauf, das sie nicht anfangen zu feilschen. Ich finde, das beschreibt es ganz gut. Als Kunde beauftrage ich einen Dienstleister, weil er Experte für etwas ist das ich selber nicht beherrsche, mit welcher Expertise sollte ich also seine Aussagen bzgl. Kosten und Zeitpunkt der Lieferung anzweifeln? Als Dienstleister habe ich kein Interesse, ein überhöhtes Angebot abzugeben, weil ich dann entweder den Auftrag nicht bekomme oder eine längerfristige Zusammenarbeit davon potentiell Schaden nimmt.

Wenn ich als Kunde feststelle, das etwas so teuer ist, das die Umsetzung nicht lohnt, dann sollte ich es vielleicht auch einfach sein lassen, anstatt in ein Vorhaben zu starten bei dem bei allen Beteiligten nur Frust rauskommen kann!

Der Kunde testet.

Eine Variante könnte so aussehen: der Kunde stellt zum Entwicklungsstart eine automatisierte Testsuite bereit, gegen die der Dienstleister jederzeit das Produkt testen kann. Laufen die Tests sauber durch, ist die Software abgenommen. Für Fehler die außerhalb der Testsuite gefunden werden, bezahlt der Kunde die Bereinigung. Der Kunde übernimmt also die Verantwortung dafür, mit der Testsuite eine präzise und vollständige „Spezifikation“ bereitzustellen. Nachteil: der Kunde braucht die Fähigkeiten und Kapazitäten dazu.

Time and Material

Der Kunde vertraut darauf, das der Dienstleister für ein tolles Produkt entwicklen möchte und mehr Spaß daran hat, tolle Features umzusetzen anstatt Fehlerbereinigung zu betreiben. Die Vertragsart „Time and Material“ ist aber z.B. in Einkaufsabteilungen eher unbeliebt, da es aus der Perspektive eines Controllers zu einfach auszubeuten ist. Dennoch sollte man hier klar die Mitwirkungsverpflichtung des Kunden nicht aus den Augen verlieren, da KEINE mehr oder weniger präzise definierte Produktbeschreibung existiert, braucht es kontinuierlichen Austausch mit dem Kunden. Bei der Nutzung von Scrum könnte es sich z.B. anbieten, die Rolle des PO Kundenseitig zu besetzen.

Eine schöne Ergänzung für agile Verträge finde ich daher z.B. eine Konstruktion, die Verträge einfach kündbar zu machen: Von beiden Seiten kann der Vertrag mit einer Frist von zwei Iterationen ohne Begründung gekündigt werden. Wenn der Kunde der Ansicht ist, der Dienstleister liefert zu wenig, kann er ohne große Bindung raus. Für die Gegenseite genau so, wenn die Zusammenarbeit nicht konstruktiv ist oder der Aufwand zum vereinbarten Preis nicht dauerhaft leistbar ist. Die Kündigungsoption soll dabei  beide Seiten in erster Linie ermuntern, in einer frustrierenden Situation das Gespräch zu suchen, und nicht in Duldungsstarre auf das Vertragsende zu warten.