Cost of Delay (2): Verzögerungskosten durch Perfektion

Wenn man einmal anfängt, sich mit Verzögerungskosten in der Softwareentwicklung auseinanderzusetzen, hat man den Eindruck, es sei ein Fass ohne Boden. Ich bin selbst gespannt, ob sich das Thema hier noch zu einer langen Serie entwickelt. Auf alle Fälle wirft die Betrachtung, inwiefern das Bestreben nach hoher Qualität und Perfektion Verzögerungskosten generiert, interessante Fragen auf.

Viele Entwickler sind stolz auf ihre Arbeit. Sie wollen eine positive Reputation aufbauen – persönlich, als Team, als Firma und als Profession. Aus diesem Grund versuchen sie, ihre Arbeit immer gut zu machen. Dafür gibt es in der Softwareentwicklung verschiedene Arten:

• sicherstellen, dass keine technische Schuld aufgeladen wird.
• die Prinzipien von Clean Code beachten.
• eine Story absolut fehlertolerant implementieren.
• alle fachlichen Eventualitäten berücksichtigen.

Das ist alles wirklich gut, vernünftig und auch wichtig. Dennoch sind diese Dinge nicht immer gefordert. Vielleicht, weil der Kunde kein zu 100 Prozent fehlertolerantes System benötigt oder er nicht das Budget für ein System hat, das Clean Code (zum jetzigen Zeitpunkt) vollumfänglich berücksichtigt. Vielleicht ist es wichtig Funktionalität zu liefern, sodass der Kunde diese direkt verwenden kann und alles andere ist zweitrangig. Vielleicht ist die Geschäftsstrategie die, dass zunächst Funktionalität und Qualität erst später verkauft wird.

Nur um sicherzugehen: Ich sage nicht, dass das meine präferierte Strategie ist, aber dass es Firmen gibt, die genau so eine Strategie zum Geschäftskonzept erhoben haben. Das heißt, sie verkaufen zunächst die Funktionalität günstig (und gewinnen dadurch beispielsweise eine Ausschreibung) und verkaufen dann zu einem späteren Zeitpunkt die Wartung zu einem wesentlich höheren Preis.

Wenn so eine Strategie den Entwicklern nicht bekannt ist, kann es passieren, dass sie nicht nur die Lieferung der Funktionalität verzögern, weil die Implementierung nicht ihrem Anspruch genügt, sondern dass sie mit diesem Verhalten darüber hinaus sicherstellen, dass das Unternehmen am Markt nicht bestehen kann. Denn, wenn keiner die teure Wartung später kauft, wird das Unternehmen nicht auf Basis des günstigen Angebots für die Lieferung der Funktionalitäten überleben können. Dieses Szenario habe ich mir übrigens nicht ausgedacht. Tatsächlich kenne ich mehr als ein Unternehmen, das vom Markt verdrängt wurde, weil die Entwickler Produkte geliefert hatten, die besser waren, als es die Geschäftsstrategie vorsah.

Wenn Sie sich in einem Markt bewegen, der hoch innovativ ist, haben Sie ein verwandtes Problem. In solch einem Markt kommt es darauf an, schnell Funktionalitäten bereitzustellen, um an der Spitze der Innovation zu bleiben. Später kann man immer noch in Qualität investieren. Aber am wichtigsten ist es, den Kunden Funktionalitäten anzubieten, sodass sie diese sehen und erfahren können, in welche Richtung das Ganze gehen wird. Auch diesbezüglich habe ich Firmen gesehen, die vom Markt verschwanden, weil die Entwicklungsabteilung sich geweigert hatte auszuliefern, da das Produkt noch nicht "gut genug" war. Das Produkt des Wettbewerbers war qualitätsmäßig zwar viel schlechter, aber es war verfügbar. Deshalb blieb der Wettbewerber im Markt.

Das heißt, Verzögerungskosten durch Perfektion – oder dadurch, dass man noch den Goldrahmen um die Features bastelt – können nicht nur dazu führen, dass ein Produkt, sondern sogar ein ganzes Unternehmen vernichtet wird. Deshalb muss das Maximum an Investition (bezogen auf den Return on Investment), die man bereit ist, für eine nachgefragte Funktionalität in die Hand zu nehmen, der Entwicklung offengelegt werden. Nur so lässt sich bei der Entwicklung die Investitionsobergrenze berücksichtigen. Und ja, leider kann das zur Folge haben, dass man Funktionalitäten liefert, obwohl man sie eigentlich noch verbessern will – aber wenn man nicht aufhört, die Funktionalitäten zu verbessern, kann es sein, dass man sie nie liefern wird.

Folglich ist es manchmal weniger wichtig, die Entwickler nach einer Schätzung zu fragen, um herauszufinden, wie komplex die Funktionalität ist (oder wie lange es dauern wird, bis sie implementiert ist), sondern es ist wichtiger, von der Geschäftsseite zu erfahren, wie viel sie bereit ist, in die Funktionalität (oder das Produkt) zu investieren. Andernfalls wird die Lieferung des Produkts unnötigerweise verzögert. ()