Zusammenfassung
- Der Erfolg einer Übernahme eines Softwareunternehmens hängt im hohem Maße vom Verbleib der wichtigsten Entwickler ab.
- Die DETANGLE® Software Analyse Suite identifiziert dabei unterschiedliche Gruppen an Schlüsselentwicklern.
- Das Akquisitionsrisiko sinkt, wenn der Investor frühzeitig Maßnahmen konzipieren kann, um diese Mitarbeiter zu binden.
- Das Tool analysiert auch die gesamte Aufwands- und Wissensverteilung im Entwicklungsteam. Die Optimierung der Wissensverteilung ermöglicht Qualitäts- und Effizienzverbesserungen.
- Eine optimierte Wissenverteilung vermindert auch die Abhängigkeit von einzelne Personen.
Einführung
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.
Warum ist es wichtig Entwickler und Entwicklungsmethoden zu analysieren?
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:
- Wer sind die wichtigsten Entwickler und warum?
- Entspricht die Skill-/Wissensverteilung zwischen den Projektmitgliedern den Anforderungen des Projekts/Produkts?
- Ist die Entwicklungslast gleichmäßig verteilt?
Eine automatisierte Analyse der Wissens- und Kooperationsmuster durch DETANGLE® liefert daten-basierte Antworten auf solchen Fragen.
Kann der Verlust eines Top Entwicklers ein Projekt zu Fall bringen?
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!
Wie kann ich die relevanten Entwickler identifizieren?
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.
- Solisten: Das sind Entwickler, die Wissensinseln darstellen und am liebsten allein arbeiten. Sie weisen oft eine hohe Arbeitsleistung aus. Diese Wissensinseln dürfen aber nicht überhand nehmen und sollten nicht zu lange als solche bestehen bleiben.
- Teamstars: Sie teilen ihr Wissen mit anderen Entwicklern zusätzlich zu Ihrer “Einzelarbeit”. Diese sind ebenfalls sehr produktiv, bringen aber insgesamt die Teamleistung nach vorne und reduzieren das Risiko von einzelnen Solisten abhängig zu werden.
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.
Wie kann die Wissensverteilung im Team gemessen werden?
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.
Bild 1: Verteilung von Wissen und Entwicklungsaufwand
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.
Fazit
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.
Frequently Asked Questions (FAQs)
- Wie können Sie sicher sein, dass bei der Untersuchung des Codes nicht unkontrolliert Daten und IP abfließen?
Die DETANGLE® Analyse Software wird auf einem Rechner des Unternehmens/Kunden installiert, konfiguriert und ausgeführt. Dabei bleiben alle Analyseergebnisse auf einem Rechner. Ein Remote-Zugang zu diesem Rechner kann über eine VPN Verbindung verschlüsselt und gesichert stattfinden.
- Wie aufwändig ist eine Software Due Diligence?
Wir unterscheiden zwischen eine Red Flag Due Diligence, die wenige Tage Aufwand benötigt 3-7 Tage (je nach Systemgröße, -Komplexität und Report-Umfang ) und der Deep Dive Analyse, die mindestens 10 Tage in Anspruch nimmt.Die Red Flag Due Diligence fokussiert auf wenige vorher festgelegte Themen und untersucht diese Themen auf kritische Risiken (Red Flags). Sie wird meistens durchgeführt, wenn noch viele Investoren im Rennen sind und nicht sicher ist, ob man zu finalen Kaufverhandlungen eingeladen wird. Die Deep Dive Analyse geht wesentlich tiefer und liefert auch Hinweise zu den Prioritäten nach Übernahme und ggfs auch erste Aufwandsabschätzungen um Probleme zu korrigieren. Diese Detailtiefe ist sinnvoll, wenn die Software einen sehr wesentlichen Wert für das Unternehmen darstellt und man schon exklusiv mit dem Verkäufer verhandelt.
- Welche Programmiersprachen können mit der DETANGLE® Analyse Suite untersucht werden?
Mit DETANGLE® können alle gängigen Programmiersprachen uneingeschränkt untersucht werden.
Links
[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/