Bus-Faktor: Was passiert, wenn Ihr einziger Entwickler ausfällt?
Unabhängig von einer einzelnen Person wird Ihr Softwareprojekt, wenn Zugänge Ihrem Unternehmen gehören, das Wissen aufgeschrieben ist und eine zweite Person die Anwendung schon einmal selbst ausgeliefert hat. Das lässt sich herstellen, ohne dauerhaft doppelt zu bezahlen.
Die Frage stellt sich meist zur Urlaubszeit oder bei einer Krankheit, also dann, wenn es zu spät ist. Vorher lässt sich die Abhängigkeit mit drei Fragen messen: Auf wen laufen Server, Domain und Code-Repository? Wo steht, wie die Anwendung gestartet und ausgeliefert wird? Und wer außer dem Hauptentwickler hat schon einmal selbst eine Version live gestellt? Lautet die Antwort dreimal auf denselben Namen, liegt Ihr Bus-Faktor bei 1.
Wie eine geregelte Vertretung im laufenden Betrieb aussieht, zeigt unsere Seite zum technischen Support. Hier geht es um neutrale Prüfpunkte, die unabhängig davon gelten, wer Ihre Software entwickelt.
Der Begriff
Was der Bus-Faktor beschreibt
Der Bus-Faktor ist die kleinste Zahl von Personen, die ausfallen müssten, damit ein Projekt nicht mehr weitergeführt werden kann. Der etwas drastische Name stammt aus der Softwareentwicklung: Wie viele Leute dürften vom Bus angefahren werden? Gemeint ist jeder Ausfall, auch Kündigung, Elternzeit oder ein Wechsel des Dienstleisters.
Ein Bus-Faktor von 1 bedeutet: Eine einzige Person weiß, wie die Anwendung gebaut, ausgeliefert und betrieben wird. Das kommt bei kleinen Projekten vor und ist kein Vorwurf an diese Person. Es ist ein Organisationsrisiko, das Sie als Auftraggeber steuern.
Auch das BSI behandelt das Thema im IT-Grundschutz-Kompendium, Baustein ORP.2 Personal. Die Anforderung ORP.2.A3 verlangt praktikable Vertretungsregelungen für alle wesentlichen Aufgaben und eine ausführliche Dokumentation, wenn eine direkte Übergabe nicht möglich ist. ORP.2.A4 „Festlegung von Regelungen für den Einsatz von Fremdpersonal“ geht weiter: Auch für längerfristig beschäftigtes Fremdpersonal muss eine Vertretungsregelung eingeführt werden. Das ist genau der Fall des einzigen externen Entwicklers.
Selbsttest
Warnzeichen in Ihrem Projekt
Die folgenden Punkte deuten auf einen niedrigen Bus-Faktor hin. Je mehr davon zutreffen, desto dringender ist eine Bestandsaufnahme.
Server, Domain oder Code-Repository laufen auf das private Konto des Entwicklers.
Niemand außer einer Person kann eine neue Version live stellen.
Passwörter werden per E-Mail oder Chat weitergegeben, nicht über einen gemeinsamen Passwortmanager.
Es gibt keine schriftliche Beschreibung, wie die Anwendung lokal gestartet und ausgeliefert wird.
Fragen zum Projekt beantwortet immer dieselbe Person, auch nach Jahren.
Ein Urlaub des Entwicklers bedeutet faktisch einen Änderungsstopp.
Sie wissen nicht genau, welche externen Dienste und Verträge an der Anwendung hängen.
Den Bus-Faktor in einer Stunde schätzen
Listen Sie die Aufgaben auf, die für den Betrieb nötig sind: Anwendung lokal starten, Änderung ausliefern, Backup zurückspielen, Domain und Zertifikat verlängern, auf eine Störung reagieren, eine Sicherheitslücke in einem Paket schließen. Schreiben Sie zu jeder Aufgabe die Namen der Personen, die sie ohne Hilfe erledigen könnten. Die Aufgabe mit den wenigsten Namen bestimmt Ihren Bus-Faktor. Steht dort nur ein Name, wissen Sie, wo Sie anfangen.
Grundlagen
Zugänge, Dokumentation und Übergaben
Die wirksamsten Maßnahmen kosten wenig Entwicklungszeit, verlangen aber Klarheit über Eigentum und Ablage.
Zugänge
Domain, DNS, Hosting, Code-Repository, App-Stores und Zahlungsdienste auf Ihr Unternehmen registrieren, mit einer funktionalen E-Mail-Adresse statt einer persönlichen.
Dienstleister erhalten eigene Benutzer mit passenden Rechten, nie das Hauptkonto.
Alle Zugänge mit MFA absichern und die Wiederherstellungscodes sicher in Ihrem Unternehmen hinterlegen.
Einen gemeinsamen Passwortmanager nutzen, auf den mindestens zwei Personen Zugriff haben.
Beim Abschied eines Mitarbeiters oder Dienstleisters Zugänge entziehen und Passwörter ändern. Das BSI verlangt dafür in ORP.2 ein geregeltes Verfahren, einschließlich der Einweisung des Nachfolgers.
Dokumentation
Gute Dokumentation für den Notfall ist kurz und liegt im Code-Repository, nicht in einem Ordner auf einem einzelnen Laptop. Sie beantwortet vier Fragen: Wie starte ich die Anwendung lokal? Wie liefere ich eine neue Version aus? Wo laufen Server, Datenbank und Backups? Welche externen Dienste sind angebunden, und wer ist dort Ansprechpartner?
Übergaben
Eine Übergabe ist erst abgeschlossen, wenn die übernehmende Person eine Änderung selbst ausgeliefert hat. Ein Gespräch oder ein Dokument allein reicht nicht. Planen Sie dafür eine kleine, echte Aufgabe ein.
Vertretung
Vertretung organisieren, ohne doppelt zu bezahlen
Eine Vertretung muss nicht bedeuten, zwei Entwickler dauerhaft voll zu beschäftigen. Es reicht, wenn eine zweite Person das Projekt kennt und im Ernstfall handlungsfähig ist. Dafür gibt es mehrere Wege:
Code-Reviews: Eine zweite Person liest regelmäßig Änderungen mit. Das kostet wenig Zeit und verteilt Wissen nebenbei.
Rotation bei Auslieferungen: Abwechselnd liefert jemand anderes eine Version aus. So bleibt der Ablauf geübt.
Vertretung beim Dienstleister: Ein Team mit mehreren Entwicklern kann Vertretung als Teil des Vertrags anbieten. Fragen Sie konkret, wer vertritt und ob diese Person das Projekt kennt.
Bereitschaftsvertrag: Ein zweiter Dienstleister wird mit einem kleinen Stundenkontingent eingearbeitet und hält sich über wenige Termine im Jahr auf dem Laufenden.
Urlaubsvertretung planen
Die Urlaubsvertretung eines Entwicklers ist der beste Probelauf für den Ernstfall. Legen Sie vorab fest, welche Änderungen in der Abwesenheit erlaubt sind, wer im Störungsfall entscheidet und wie die Vertretung erreichbar ist. Lassen Sie die Vertretung in der Woche vor dem Urlaub eine kleine Änderung selbst ausliefern. Was dabei fehlt, gehört in die Dokumentation.
Welches Modell passt, hängt davon ab, wie geschäftskritisch die Anwendung ist und wie viele Änderungen pro Jahr anfallen. Wenn Sie zwischen einem einzelnen Freelancer und einem Team abwägen, finden Sie in unserem Vergleich zwischen MARCODES und einem Solo-Freelancer die Unterschiede bei Vertretung und Verträgen. Wie man Werkzeuge und Dienstleister so auswählt, dass kein einzelner Anbieter unersetzlich wird, beschreibt unser Beitrag Best of Breed: Was hinter dem Schlagwort steckt.
Kurz beantwortet
Häufige Fragen
-
So viel, dass eine fachkundige Person ohne Rückfrage die Anwendung starten, eine Änderung ausliefern und ein Backup zurückspielen kann. Das sind oft nur wenige Seiten. Ein guter Test: Lassen Sie eine zweite Person diese drei Schritte nach Anleitung durchführen und ergänzen Sie alles, woran sie hängen bleibt.
-
Die Konten für Domain, Hosting, Code-Repository und Dienste sollten auf Ihr Unternehmen laufen, Dienstleister erhalten eigene Benutzer. Davon getrennt ist die Frage der Nutzungsrechte am Quellcode, die im Vertrag geregelt sein sollte. Prüfen Sie beides, bevor ein Ausfall eintritt.
Vertretung für Ihre Anwendung regeln
Wir prüfen Zugänge und Dokumentation Ihres Projekts, schließen Lücken und übernehmen auf Wunsch die Vertretung im laufenden Betrieb.
Nachweise
Quellen und Stand
Geprüft am 02.11.2026: Aktuelle Fassung des IT-Grundschutz-Kompendiums ist die Edition 2023. Das BSI löst das Kompendium schrittweise durch Grundschutz++ ab, Zertifizierungen nach Grundschutz++ sind ab dem 01.01.2027 vorgesehen.
Artikel teilen