Überzeugenden Business Case für Softwareprojekte erstellen

Der Bedarf an starken Proof of Concepts

Ein Proof of Concept (PoC) für Softwareprojekte zielt in der Regel darauf ab, Mittel für Initiativen zu akquirieren, die aus technischer Sicht als wichtig erachtet werden, aber oberflächlich betrachtet vielleicht keinen offensichtlichen geschäftlichen Bedarf darstellen. Stellen Sie sich beispielsweise vor, ein Team möchte eine Legacy-Architektur ersetzen, die zwar technisch noch funktionstüchtig ist, aber die Möglichkeit einschränkt, neue Ansätze für das Anwendungsdesign zu verfolgen oder moderne Entwicklungs-Tools einzusetzen.

Während die Programmierer die technischen Vorteile einer solchen Initiative erkennen können, sind ihre Argumente für einen Produktmanager oder andere leitende Manager auf der Geschäftsseite möglicherweise nicht von Bedeutung. Im Rahmen des POC müssen die Softwareteams einen überzeugenden finanziellen Nachweis für das Projekt erbringen und zeigen, dass sich die Arbeit für das Unternehmen ausreichend auszahlen wird, um die Investition zu rechtfertigen.

Aussagekräftige Metriken finden

Um einen überzeugenden Business Case für Softwareprojekte zu erstellen, muss ein POC Metriken enthalten, die die überprüfenden Manager auf der Geschäftsseite sinnvoll in greifbare, realistische und nachweisbare ROI-Zahlen übersetzen können. Es ist nicht immer leicht zu wissen, welche Metriken für die Geschäftsseite von Bedeutung sind. Im Folgenden finden Sie einige Beispiele für typische POC-Kennzahlen, die Softwareteams versuchen sollten, in finanzielle Größen zu übersetzen, auch wenn die Liste nicht vollständig ist.

Reduzierte technische Schulden

Technische Schulden gibt es in vielen Formen, aber der Pionier der agilen Entwicklung, Ward Cunningham, hat eine der ersten Definitionen geliefert. Er beschrieb technische Schulden als ein operatives Nebenprodukt, das entsteht, wenn Teams Funktionen ohne Rücksicht auf die eigentliche Domäne des Themas implementieren und es versäumen, die Software mit den Informationen, die die Programmierer gelernt haben, zu überarbeiten. Mit zunehmender technischer Verschuldung verschlimmern sich diese bestehenden Diskrepanzen und verlängern schließlich die Zeit, die für die Entwicklung von Anwendungskomponenten und Funktionen benötigt wird.

Softwareexperten sind sich in der Regel darüber im Klaren, wie wichtig es ist, technische Schulden abzubauen, aber es kann schwierig sein, Projekte zum Abbau technischer Schulden von der Geschäftsseite genehmigen zu lassen. Für nicht-technische Mitarbeiter kann ein solches Projekt einfach wie eine Neufassung einer bereits funktionierenden Software aussehen – etwas, das die Zeit des Entwicklungsteams in Anspruch nimmt, ohne einen neuen Wert für das Unternehmen zu liefern. Daher sollte jeder POC, der darauf abzielt, technische Schulden zu reduzieren, harte Zahlen liefern, die die spezifischen finanziellen oder produktiven Vorteile eines solchen Projekts aufzeigen.

Verbesserte Widerstandsfähigkeit

Die Leiter von Softwareteams können auch ein überzeugendes Geschäftsargument für Softwareprojekte vorbringen, die auf die Verbesserung der Widerstandsfähigkeit (Resilienz) der Software oder ihrer unterstützenden Architektur abzielen. Anstatt zu versuchen, das Auftreten von Fehlern in der Software zu verhindern, zwingt das Konzept des belastbaren Softwaredesigns die Entwickler dazu, das Auftreten von Fehlern in laufender Software zu antizipieren und im Voraus Vorkehrungen zu treffen, um diese Fehler zu beheben. Stellen Sie sich zum Beispiel vor, dass Sie sich auf einer Website anmelden müssen, um bestimmte Seiten zu sehen, aber ein Benutzer versucht, die Seite anzusehen, bevor er sich anmeldet. Anstatt einfach eine 404-Fehlermeldung anzuzeigen, wäre es sinnvoller, den Benutzer mit einer speziellen Meldung darauf hinzuweisen, dass er sich anmelden muss.

Aus geschäftlicher Sicht kann ein belastbares Softwaredesign die Wiederherstellungszeiten bei Fehlern verkürzen und das Benutzererlebnis verbessern. So kann ein Architekt einen Business Case für Projekte zur Verbesserung der Ausfallsicherheit erstellen, indem er aufzeigt, wie sich dies auf Dinge wie geringere Ausfallzeiten, höhere Kundenbindung oder höhere Verkaufszahlen auswirkt.

Kosten für Regressionstests

Regressionstests können Entwicklungsteams dabei unterstützen, zu verhindern, dass Funktionserweiterungen oder andere Aktualisierungen die Codebasis zerstören, aber diese Tests können viel Zeit und Mühe kosten. Entwicklungsteams, die Regressionstests verzögern oder auslassen, schaffen jedoch Unsicherheiten hinsichtlich der Fähigkeit der Codebasis, Aktualisierungen zu verarbeiten. Wenn Regressionstests schließlich durchgeführt werden müssen, werden diese Testzyklen länger und mühsamer. Dies wiederum führt dazu, dass das Team immer weniger Regressionstests durchführen will, und das Problem nimmt exponentiell zu. Auch das Hinzufügen von Automatisierungen löst das Problem nicht, da es Zeit kostet, umfangreiche, durchgängig automatisierte Testsuiten zu schreiben und zu pflegen.

Eine Möglichkeit, das Problem der Regressionstests zu lösen, besteht darin, eine Architektur zu implementieren, die eine komponenten- oder funktionsbasierte Codebasis fördert. So können Sie sicherstellen, dass Aktualisierungen in einem Bereich einer Anwendung keine Auswirkungen auf die anderen Bereiche haben. Das bedeutet auch, dass die Teams Komponenten und Funktionen unabhängig voneinander testen können, was den Zeit- und Arbeitsaufwand für die Durchführung von Aktualisierungen und die Bereitstellung von Fehlerkorrekturen verringert. Um den ROI für ein solches Architekturprojekt zu quantifizieren, schätzen Sie ab, wie viel Zeit das Team bei der Durchführung von Regressionstests einsparen kann, wie viel schneller Softwareänderungen ausgerollt werden und wie sich diese Verbesserungen in finanzielle Vorteile für das Unternehmen umsetzen lassen.

Neue Entwicklungsmöglichkeiten

Manchmal liegt der Geschäftsnutzen eines Softwareprojekts darin, dass es einem Team völlig neue Möglichkeiten zur Entwicklung und Bereitstellung wichtiger benutzerorientierter Anwendungen bietet. Ein Softwareteam könnte beispielsweise auf ein Low-Code-Tool drängen, das es Entwicklern ermöglicht, bestehende Webanwendungen mit wiederverwendbaren APIs für Mobilgeräte umzugestalten. Dies wird nicht nur dazu beitragen, einen neuen Vektor für das Engagement der Benutzer zu erschließen, sondern bedeutet auch, dass das Unternehmen möglicherweise Geld sparen kann, da es keine spezialisierten Programmierer für mobile Anwendungen einstellen muss. Vermeiden Sie die Versuchung, Projekte wie dieses ausschließlich aufgrund der technischen Vorteile von Dingen wie der Wiederverwendbarkeit von APIs zu befürworten; bemühen Sie sich stattdessen, sich auf diese zentralen geschäftlichen Wertüberlegungen zu konzentrieren.

Tipps für die Erstellung von Business Cases und POCs

Die geschäftliche Seite der Dinge in einem Projektvorschlag anzusprechen, erfordert ein wenig Fingerspitzengefühl. Zum Glück gibt es bestimmte Techniken und Strategien, die Mitarbeiter auf der technischen Seite anwenden können, um ihre Fähigkeit zu verbessern, überzeugende Geschäftsszenarien für Softwareprojekte zu erstellen. Hier sind einige Tipps für Architekten, Entwicklungsleiter und andere leitende technische Mitarbeiter, die Sie beachten sollten:

• Je spezifischer die Metriken in einem POC sind, desto besser. Wenn eine bestimmte Initiative einem agilen Team helfen kann, mehr User Stories pro Woche zu erstellen, ohne dass zusätzliche Teammitglieder eingestellt werden müssen, bedeutet dies einen greifbaren Produktivitätsvorteil. Die Fluktuationsrate und die Einarbeitungszeit sind weitere Kennzahlen, mit denen die Leiter von Softwareteams die Produktivitätsvorteile einer neuen Initiative oder eines neuen Entwicklungsansatzes messen können.
• Es gibt eine unendliche Anzahl von Kennzahlen, die Softwarearchitekten versuchen können, zu quantifizieren, um den Business Case für ein bestimmtes Projekt zu erstellen. Drei besonders nützliche Kennzahlen sind jedoch der ROI im Verhältnis zur Entwicklungsproduktivität, die Kosten einer Initiative im Vergleich zu den Kosten des Nichtstuns und ein All-Inclusive-ROI, der die Kosten einer Software-Initiative im Verhältnis zu ihrem voraussichtlichen finanziellen Nutzen berechnet.
• Wenn es darum geht, Beziehungen zur Geschäftsseite aufzubauen, sollten die Leiter der Softwareteams als Influencer und Berater auftreten. Eine Möglichkeit, dies zu tun, besteht darin, zunächst einen allgemeinen Projekt-POC zu erstellen und dann den unteren technischen Mitarbeitern die Möglichkeit zu geben, spezifische Ideen einzubringen und im Idealfall die Verantwortung für Teile einer Implementierung zu übernehmen.
• Wenn möglich, bauen Sie den POC als verbesserte Implementierung einer bestehenden Anwendung auf, anstatt eine neue, eigenständige Anwendung zu entwickeln. Wenn der POC für eine Demo bereit ist, hat das Team bereits eine Reihe von Funktionen entwickelt, die es implementieren und vorführen kann. Dies ist ein Bereich, in dem die Implementierung eines Strangler Pattern nützlich sein kann.

Soft Skills sind wichtig. Treffen Sie sich schon vor den offiziellen Meetings mit wichtigen Mitarbeitern und Geschäftspartnern, um ihre Ideen und ihr Feedback einzuholen. Fragen Sie potenzielle Stakeholder, welche Bedenken sie in Bezug auf ein Projekt oder eine Initiative haben, damit Sie einen Weg finden können, wie der PoC diesen Bedürfnissen gerecht werden kann.