Der Bus-Faktor: Wie ein 82-jähriger Entwickler zum Unternehmensrisiko werden kann

Und wieso Software-Projekte mehr brauchen als nur guten Code

Bus-Faktor? Was soll das denn sein? Plakativ formuliert, ermittelt der Bus-Faktor, oder auch Truck-Faktor, wie viele Menschen von einem Bus überfahren werden müssen, damit ein Unternehmen in bestimmten Bereichen handlungsunfähig wird.

Was makaber klingt, stellt eine reale Gefahr für Unternehmen dar: ruhen das Wissen über bestimmte Projekte, Systeme, Abläufe oder zentrale Berechtigungen bei nur einer einzigen Person, stehen im schlimmsten Fall die Maschinen still. Daher gehört zur Neuentwicklung oder Anpassung unternehmenskritischer Software auch eine genaue Analyse der Verantwortlichkeiten.

‍

Bus-Faktor: Definition

Der Begriff Bus-Faktor kommt aus dem Risikomanagement und schätzt Projektrisiken ein. Es geht darum, aufzuzeigen, wie viele Personen maximal ausfallen dürfen, um ein Unternehmen in einem bestimmten Bereich handlungsunfähig zu machen.

Je niedriger die Nummer, desto höher das Risiko im Projekt. Ein Bus-Faktor von 1 ist somit die denkbar schlechteste Zahl. Denn sie besagt, dass ein einzelnes Team-Mitglied entscheidend für den Erfolg eines Projektes, die Steuerung eines Systems oder die Bedingung einer unternehmenskritischen Software ist. Fällt diese eine Person aus, hat das Unternehmen ein echtes Problem. Produktionsstopps, Verzögerungen, Systemausfälle etc. sind die Folge und teure Ersatzlösungen müssen her.

„Könnte ein 82-jähriger Entwickler ein Risiko darstellen?“

Was makaber oder auch sehr pessimistisch klingt, ist nicht selten der Fall, weiß Marcel Dambach, Team Lead Software Engineering bei generic.de. Er ist in seiner Funktion oftmals bei Kunden und analysiert unter anderem Verantwortlichkeiten und Projektrisiken.

Er sagt: „Grundsätzlich ist es den meisten Kunden bewusst, dass einzelne Wissensträger, die zum Beispiel für eine wettbewerbsentscheidende Software zuständig sind, ein potenzielles Risiko darstellen. Sie müssen nicht gleich vom Bus überfahren werden. Es reicht schon, wenn sie das Unternehmen verlassen, etwa weil sie kündigen oder in Rente gehen.

Aber obwohl gerade der letztere Fall ein planbares Risiko darstellt, wird er im Berufsalltag gerne übersehen oder beiseitegeschoben. Mir ist das im Projekt schon begegnet: es ging darum, eine sehr alte, aber fürs Unternehmen kritische Software zu überarbeiten. Auf die Frage, wo denn der Quellcode liegt, kam dann: ‚Ja, das ist ein Grund, wieso ihr da seid. Der Einzige, der sich mit der Software auskennt, ist unser ehemaliger Kollege. Der macht das noch so nebenbei, obwohl er schon 82 Jahre alt und seit 15 Jahren in Rente ist‘.  Da sind wir fast vom Stuhl gefallen.“

‍

Risikoanalyse mit RACI-Diagramm: Wer bin ich und wie viele?

In besagtem Fall war das Risiko offensichtlich und bekannt. Das ist aber nicht immer der Fall. Um aufzuzeigen, wo es potenzielle Schwachstellen geben könnte, arbeitet generic.de mit der Verantwortungszuweisungs-Matrix, oder auch RACI-Diagramm.

Ein RACI-Diagramm beschreibt die Verantwortlichkeiten der Teammitglieder in einem bestimmten Projekt in vier unterschiedlichen Kategorien:

• Responsible | Task ausführen: Diese Person verantwortet, dass ein bestimmter Task innerhalb der vereinbarten Parameter und einer vereinbarten Frist erledigt wird. Ein Task kann mehrere verantwortliche Personen haben.
• Accountable | Projektaufsicht: Accountable ist die Person, die dafür sorgt, dass der Task von allen verantwortlichen Mitgliedern erledigt wird. Diese Verantwortung sollte nur einer verantwortlichen Person zugewiesen sein, die während des gesamten Projekts als Entscheidungsträger und Betreuer fungiert und sicherstellt, dass der Task nach einem akzeptablen Standard erledigt wird. Um hier nicht selbst einen Busfaktor=1 zu erzeugen, sollte hier direkt eine Vertretungsregelung eingerichtet werden.
• Consulted | Informationsbereitstellung: Die "konsultierte" Person ist ein Wissensträger im Team. Diese Person bietet Hilfe, zusätzlichen Kontext und Ratschläge zum Task, stellt alle benötigten Informationen zur Verfügung und gewährt Zugriffe.
• Informed | Erhält Status-Updates: Dies ist ein Stakeholder, der Informationen über das Projekt erhält oder diese benötigt. Das "I" können viele Personen sein, wie ein Führungsteam oder der Abteilungsleiter, der das Projekt nach oben berichten muss.

Im RACI-Modell bei Software-Projekten zählen auch Punkte wie: Wer hat welchen Zugang? Welche Berechtigungsstufen gibt es und wer hat sie? Wer kann etwas freigeben oder erteilen?

Ist diese Matrix erstellt, ist auf einen Blick ersichtlich, welche Person zu oft bei R steht oder wo Vertretungsregelungen hermüssen. Marcel Dambach weiß: „Manchmal wollen die Personen, die sehr viel Verantwortung tragen diese überhaupt nicht abgeben. Da muss dann, am besten von außen, Überzeugungsarbeit geleistet werden. Das Argument des Bus-Faktors kann manchmal ein Weckruf sein.“

‍

Wissensaustausch aktiv vorantreiben, um Nachvollziehbarkeit zu gewährleisten

Was bei der RACI-Matrix gilt, gilt auch im gesamten Projekt: Es muss eine stetige Kommunikation zwischen allen Projektbeteiligten stattfinden. Denn ohne regelmäßige Kommunikation oder Dokumentation kann dasselbe Problem wie zu Beginn auftreten. Die Folge: Niemand weiß mehr, was wieso wie entwickelt wurde. Das wird vor allem bei der Evolvierbarkeit und der Nachvollziehbarkeit des Codes, zum Problem.

Marcel Dambach zufolge ist dieser Punkt für viele Kunden entscheidend bei der Auswahl eines Entwicklungspartner: „Die Kunden möchten heute nicht mehr von einem bestimmten Produkt oder einer Firma abhängig sein. Der sogenannte Vendor Lock-In, der Kunden daran hindert, den Anbieter zu wechseln, muss vermieden werden.

Das gewährleisten wir durch die absolut transparente Zusammenarbeit mit dem Kunden, der zu jeder Zeit vollen Zugriff auf den Quellcode hat. Durch die Verwendung der Clean Code Development Prinzipien stellen wir sicher, dass technische Schulden minimiert werden. Das bedeutet, dass wir selbst und auch andere Entwickler, die ggf. später das Projekt übernehmen, nachvollziehen können, wieso welche Entscheidungen getroffen wurden.“

‍

Fazit: Risiken immer wieder prüfen und vorbeugend vermeiden

Zusammenfassend lässt sich festhalten, dass der Bus-Faktor nicht erst dann geprüft werden sollte, wenn der Betroffene schon im Krankenhaus liegt. Vielmehr sollten gerade bei unternehmenskritischen Prozessen oder Software immer wieder überprüft werden, ob die zugewiesenen Rollen noch schlüssig sind und das Unternehmen jederzeit handlungsfähig bleibt. Gleiches gilt für Software: auch hier sollte, z.B. mittels RACI-Modell sichergestellt sein, dass keine kritischen Abhängigkeiten entstehen um einen Vendor Lock-in zu vermeiden.

‍