Ratgeber · · 2 Min. Lesezeit
Bus-Faktor im Softwareteam: Wissen bei einer Person finden
Welche Themen hängen in eurem Team an einer Person? Was der Bus-Faktor misst, was Git übersieht und wie ihr Wissen festhaltet, bevor jemand geht.
Felix KünneckeMitgründer von Scibly
Das Wichtigste auf einen Blick
- Der Bus-Faktor ist die kleinste Zahl von Personen, die ein Team verlieren kann, bevor ein Projekt ins Stocken gerät. Bei 1 hängt ein Thema an einer einzigen Person.
- In einer Studie von 133 beliebten GitHub-Projekten hatten 65 % einen Bus-Faktor von 2 oder weniger.
- Die Git-Historie zeigt nur, wer Code geändert hat. Absprachen mit Kunden, Gründe und Workarounds stecken in Meetings und Gesprächen.
- Scibly sieht in Meetings und Aufgeschriebenem, wer sich mit einem Thema auskennt, und zeigt Themen, die an einer Person hängen.
- Hängt ein Thema an einer Person, fragt das Interview von Scibly sie danach. Was sie freigibt, finden Kollegen und ihre Agenten mit Quelle.
- Aufschreiben macht Wissen erreichbar. Der Bus-Faktor steigt erst, wenn eine zweite Person mit dem Thema arbeitet.
Was ist der Bus-Faktor?
Der Bus-Faktor, auch Truck-Faktor, ist die kleinste Zahl von Personen, die ein Team verlieren kann, bevor ein Projekt ins Stocken gerät. Der Name kommt von der düsteren Frage, was passiert, wenn jemand morgen vom Bus erfasst wird. Gemeint ist meist Harmloseres: Elternzeit, ein Teamwechsel, eine Kündigung. Liegt der Bus-Faktor eines Themas bei 1, hängt es an einer einzigen Person.
Das ist häufig. Avelino und Kollegen haben die Git-Historie von 133 beliebten Open-Source-Projekten auf GitHub ausgewertet: Bei 65 % reichte es, dass höchstens zwei Personen gehen, und mehr als die Hälfte der Dateien hatte niemanden mehr, der sie pflegen kann (Avelino et al., 2016).
Probiert es aus: Wer darf ausfallen?
Ein kleines Team, acht Themen. Jeder Punkt zeigt, wie viel eine Person in Meetings und Aufgeschriebenem zu einem Thema beigetragen hat. Klickt auf eine Person, um sie aus dem Team zu nehmen:
Wissensverteilung im Team5 Personen · 8 Themen- Themen, die niemand mehr kennt
- 0
- Themen, die nur eine Person kennt
- 3
- Personen fehlen
- 0
Achtet auf den Payment-Service. Markus hat dort einen kleinen Punkt, er war einmal dabei. Trotzdem steht dort „Nur Daniel“, denn fast alles, was das Team darüber weiß, kommt von Daniel. Wer einmal im Meeting saß, ist noch keine Vertretung.
Warum reicht die Git-Historie nicht?
Git zeigt, wer welche Datei geändert hat. Warum der Export für einen Kunden montags läuft, was im Call mit dem Zahlungsanbieter vereinbart wurde und welcher Workaround nur bei einem Kunden nötig ist, steht dort nicht. Solches Wissen entsteht in Meetings und Gesprächen. Ein Verfahren, das auch Code-Reviews und Meetings liest, traf den Bus-Faktor deshalb besser als eines, das nur Git liest (Jabrayilzade et al., 2022).
Wie findet Scibly solches Wissen?
Scibly sieht in Meetings und in dem, was Personen aufschreiben und freigeben, wer sich mit welchem Projekt, System oder Kunden auskennt. Hängt ein Thema an einer Person, steht es im Dashboard unter Wissen bei einer Person, und eure KI-Agenten, etwa in Claude Code oder ChatGPT, sehen es auch. Wie Scibly mit diesen Daten umgeht, steht unter Sicherheit.
Was tut ihr, wenn ein Thema an einer Person hängt?
- Lasst Scibly fragen. In einem kurzen Interview, gesprochen oder getippt, fragt Scibly die Person nach dem, was zu ihren Themen noch fehlt.
- Prüfen und freigeben. Aus den Antworten entstehen Entwürfe. Was die Person freigibt, finden Kollegen und ihre Agenten, mit ihr als Quelle.
- Holt eine zweite Person dazu. Aufgeschrieben ist das Wissen erreichbar, gekannt wird es dadurch noch nicht. Gebt das nächste Ticket zum Payment-Service an Markus, mit Daniel im Review.
Wie schätzt ihr den Bus-Faktor selbst?
Ohne Code reicht eine Frage an jede Teamleitung: Welche drei Themen könnte bei euch nur eine Person erklären? Für das Repository gebt eurem Agenten diesen Auftrag:
Werte die Git-Historie dieses Repositorys der letzten 12 Monate aus. Nenn mir für jedes Verzeichnis der obersten Ebene, welchen Anteil der Änderungen jede Person hat, und markiere jedes, bei dem eine Person fast alle Änderungen gemacht hat. Liste danach Themen auf, die im Code nicht stehen, etwa Absprachen mit Kunden, Abläufe beim Release oder die Rufbereitschaft, und frag mich zu jedem, wer es außer der zuständigen Person erklären könnte.
Wie eine Teamleitung vor einer längeren Abwesenheit sieht, wo Wissen fehlt, zeigt die Seite für Führungskräfte.
