Software ist ein Produkt, das sich mit geringem Aufwand schnell an die sich rasch ändernden Markt-/Benutzeranforderungen anpassen können muss. Damit ist klar, dass sowohl qualifizierte Entwickler, als auch hoch entwickelte Arbeitsmethoden einen beträchtlichen Teil des Unternehmenswertes darstellen. Entwickler sind aber auch “walking assets”. Sie können jederzeit entscheiden, dem Projekt kurzfristig nicht mehr zur Verfügung zu stehen. Solche Abhängigkeiten oder in diesem Zusammenhang auch Knowhow-Defizite in einzelnen Teams sollten als erhebliche Risiken für einen Investor vor der Investitionsentscheidung festgestellt und beurteilt werden.
Das Thema der Software-Qualität in einer Due Diligence haben wir bereits im letzten Artikel beleuchtet: Meiden Sie Fallstricke in einer Software Due Diligence.
Die Identifikation von Schlüsselentwicklern und auch der Codebereiche, die ausschließlich von einem Entwickler bearbeitet wurden, sind Voraussetzungen, um das Risiko für eine erfolgreiche Weiterentwicklung der Software einschätzen zu können.
Fragen wie die folgenden sollten gestellt werden und können auch im engen Zeitrahmen einer Due Diligence mit der nötigen Tiefe beantwortet werden:
Eine automatisierte Analyse der Wissens- und Kooperationsmuster durch DETANGLE® liefert daten-basierte Antworten auf solchen Fragen.
Auf den ersten Blick scheint es nur vorteilhaft zu sein einige Star-Entwickler im Team zu haben. Retrospektiv mag das stimmen, aber ein Investor kauft und zahlt für die Zukunft. Softwareentwicklung ist nunmal Teamwork. Wenn diese Stars Wissensinseln darstellen und alleine wichtige Code-Anteile entwickeln und warten, dann stellen diese Mitarbeiter auch ein Risiko dar, weil von deren Verbleib die Weiterentwicklung der Software abhängig ist.
mehr als 70% der Projekte leiden unter einem Bus Factor von 1.
— THE BUS FACTOR – WHY YOUR ‘BEST’ DEVELOPER IS YOUR BIGGEST PROBLEM [1]
Das heißt, dass nur ein Schlüsselentwickler das Projekt verlassen muss, um die Weiterentwicklung der Software ernsthaft zu gefährden!
Wer sind also die wirklichen Schlüsselentwickler und wie kann man sie objektiv identifizieren? Das Bauchgefühl ist ein schlechter Ratgeber. Zum Beispiel können stille Teammitglieder übersehen werden, die unaufgeregt eine Top-Arbeit leisten, dazu noch ihr Wissen teilen und auch nur sehr wenige Fehler machen.
Grundsätzlich gibt es zwei Grundtypen von relevanten Entwicklern.
Mit DETANGLE® ist es einfach beide Gruppen von Schlüsselentwicklern als auch deren Bus Factor zu identifizieren. Wir bei Cape of Good Code haben dafür Metriken und KPIs entwickelt, die bei der Analyse direkt aus der Historie des Codes im Code-Repository abgeleitet werden und damit objektive und nachvollziehbare Ergebnissen ermöglichen. Ergänzt werden diese Analysen nur noch mit einigen kurzen Interviews, um das Bild abzurunden. Das Risiko von Abhängigkeiten wird damit transparent. Damit ergeben sich Chancen, rechtzeitig Konzepte auszuarbeiten, um diese Leistungsträger nach dem Eigentümerwechsel im Unternehmen zu halten. Erscheint dies unmöglich, wäre zu prüfen, ob das Risiko nicht ein Redflag für die Transaktion darstellt.
Ein weiterer wichtiger Aspekt bei der Risikobeurteilung im Bereich Software-Engineering ist die Verteilung des Wissens und der Arbeitslast in den aktuellen Projekten. Um mehr Einblick zu bekommen, ist es Teil unserer Software Due Diligence Untersuchung, zu messen und zu visualisieren, ob diese Wissensinseln durch Wissensaustausch kompensiert und damit mittelfristig aufgelöst werden.
Das Bild zeigt als Beispiel eine Visualisierung der Messergebnisse nach einer DETANGLE® Analyse aus einem Open-Source-Projekt. Es ist deutlich zu erkennen, dass ein signifikanter Code-Abschnitt existiert, bei dem nur ein Schlüsselentwickler beteiligt war (“Wissensinsel”). Fällt dieser Mitarbeiter aus und hat seine Arbeit ggfs. auch noch schlecht dokumentiert, läßt sich der entsprechende Code nicht mehr mit normalem Aufwand weiterentwickeln. Es ist auch ein Bereich (“Wissensknäuel”) erkennbar, wo viele Teammitglieder Code erstellen, aber keiner offensichtlich die Verantwortung hat (s. auch unseren Blog zu “Kooperation und Knowledge Sharing für Agile Remote Entwicklung [2]” ). Hier ist mit vielen Bugs zu rechnen. Schließlich zeigt sich aber auch ein gutes Beispiel (“Wissensausgleich”), in dem zwar ein Entwickler dominiert, dieser sich aber einen bedeutenden Teil der Arbeit mit zwei anderen Entwicklern teilt.
Ein Softwareunternehmen ist eine Wissens-Organisation. Insbesondere in kleineren Softwareunternehmen sind die Mitarbeiter somit die wertvollsten aber auch die riskantesten Assets. Wir empfehlen dringend, dieses Risiko in der Due Diligence professionell zu analysieren.
Cape of Good Code hat einen analytischen, softwaregestützten Ansatz entwickelt, um Schlüsselmitarbeiter sowie Skill- und Knowhow-Risiken differenziert und umfassend zu identifizieren. Damit kann ein Investor die Führungs- und Handlungsprioritäten ab Day 1 (Tag der Übernahme) zeitig planen und unmittelbar umsetzen.
[1] Why5, “THE BUS FACTOR – WHY YOUR ‘BEST’ DEVELOPER IS YOUR BIGGEST PROBLEM”, https://www.5whys.com/articles/the-bus-factor-why-your-best-developer-is-your-biggest-probl.html
[2] Cape of Good Code, “Kooperation und Knowledge Sharing für Agile Remote Entwicklung”, https://capeofgoodcode.com/de/wissen/kooperation-und-knowledge-sharing-fuer-agile-remote-entwicklung/