Was passiert mit Ihrer Software, wenn die Entwicklerin ausfällt?

Es gibt eine Frage, die mir in Erstgesprächen fast nie gestellt wird, obwohl sie die wichtigste ist: Was passiert mit unserer Software, wenn Sie ausfallen? Nicht „wenn Sie im Urlaub sind", das ist die harmlose Variante. Sondern: Krankheit, Unfall, Berufsaufgabe, oder einfach ein Zerwürfnis, nach dem keiner mehr mit dem anderen reden will. Ich bin eine Person. Wer mich beauftragt, baut sein Geschäft ein Stück weit auf eine Person. Das ist der Bus-Faktor, und bei mir steht er auf eins.

Dieser Beitrag ist der Versuch, diese Frage ehrlich zu beantworten. Nicht mit „keine Sorge", sondern mit einer Liste von Dingen, die Sie als Auftraggeber kontrollieren müssen, damit mein Ausfall ein Ärgernis ist und keine Katastrophe. Die Liste gilt genauso für Agenturen. Dort heißt der Bus-Faktor nur anders: Er ist die eine Person im Team, die das Projekt wirklich versteht, und von außen sehen Sie nicht, wer das ist.

Ein Hinweis vorab: Ich bin Entwicklerin, keine Juristin. Was hier zu Verträgen steht, beschreibt, wie ich es handhabe und warum. Die konkrete Vertragsgestaltung gehört zur Prüfung in eine Kanzlei.

TL;DR - Die Kurzfassung

• Der Bus-Faktor ist die Zahl der Personen, die ausfallen müssen, bis ein Projekt stillsteht. Bei einer freien Entwicklerin ist er eins. Bei kleinen Agenturteams ist er nach meiner Erfahrung oft ebenfalls eins, nur unsichtbar.
• Das Risiko liegt nicht im Ausfall, sondern darin, ob danach jemand anderes weiterarbeiten kann. Das entscheidet sich an fünf Dingen: Quellcode, Zugänge, Dokumentation, Deployment und Daten.
• Das Kriterium für alle fünf ist dasselbe: Nichts davon existiert ausschließlich bei mir. Für Zugänge heißt das, Sie kontrollieren Vertrag, Wiederherstellung und Adminzugang unabhängig von mir.
• Was ich für mich Zweitentwickler-Klausel nenne, regelt vor dem Ernstfall, was bei Ausfall gilt: Nutzungsrechte, Reaktionsfristen, Gewährleistung und Haftung, wenn Dritte am Code arbeiten.

Was der Bus-Faktor misst und was nicht

Der Begriff kommt aus der Softwareentwicklung und ist bewusst drastisch: Wie viele Leute müssen vom Bus überfahren werden, bis niemand mehr das Projekt weiterführen kann? Ein Bus-Faktor von eins heißt: eine Person. Das klingt nach einem Argument gegen freie Entwicklerinnen, und so wird es im Vertrieb von Agenturen auch gern benutzt.

Nur misst der Bus-Faktor nicht die Zahl der Leute, die an einem Projekt arbeiten, sondern die Zahl der Leute, die es verstehen. In mehreren Agenturprojekten, die ich im zweiten Anlauf übernommen habe, gab es ein Team von fünf, aber einen Entwickler, der die Architektur im Kopf hatte. Als er ging, blieben vier Leute, die Tickets abarbeiten konnten, und ein System, das niemand mehr erklären konnte. Der Bus-Faktor war eins. Es stand nur nirgends.

Der Unterschied zwischen mir und dieser Agentur ist also nicht der Bus-Faktor. Der Unterschied ist, dass Sie ihn bei mir sehen und deshalb etwas dagegen tun können. Das ist ein echter Vorteil, aber nur, wenn Sie ihn nutzen.

Das Risiko ist nicht, dass eine Person ausfällt. Das Risiko ist, dass nach dem Ausfall niemand weiterarbeiten kann. Das sind zwei verschiedene Probleme, und nur das zweite lässt sich lösen.

Die fünf Dinge, die Sie kontrollieren müssen

Wenn ich morgen ausfalle, braucht die Person, die übernimmt, genau fünf Dinge. Fehlt eines, wird aus einer Übergabe eine Rekonstruktion, und die kostet ein Vielfaches. Für alle fünf gilt dasselbe Kriterium, und ich schreibe es gleich an den Anfang, weil es den Rest des Beitrags trägt: Nichts davon existiert ausschließlich bei mir. Kein Schlüssel, kein Konto, kein Dokument und kein Wissen, das nur ich habe. Für Zugänge heißt das konkret: Sie kontrollieren Vertrag, Wiederherstellung und Eigentümer- oder Adminzugang unabhängig von mir. Für Dokumentation heißt es: Sie liegt dort, wo Sie sie lesen können, nicht in meinem Kopf. Wie das im Einzelnen aussieht, hängt vom Punkt ab. Das Kriterium nicht.

1. Der Quellcode, lebend und vollständig

Der Code liegt in einem Git-Repository, auf das Sie zugreifen können, ohne mich zu fragen. Bei meinen Projekten ist das ein Repository, in dem der Kunde ein eigenes Konto mit Administratorrechten hat, oder eines, das auf den Namen des Kunden läuft und in das ich eingeladen bin. Das Entscheidende ist die Richtung: Sie können mich ausladen. Nicht umgekehrt.

„Vollständig" heißt mehr als die PHP-Dateien. Dazu gehören die Datenbank-Migrationen, die Konfigurationsvorlagen (ohne Geheimnisse, dazu gleich), die Build-Skripte, die Abhängigkeitslisten mit festen Versionen und die Tests. Ein Repository, aus dem sich die Anwendung nicht ohne mein Wissen bauen lässt, ist keine Übergabe, sondern ein Souvenir.

Und „lebend" heißt: Was auf dem Produktivserver läuft, ist exakt ein Stand im Repository. Keine Korrekturen, die nur auf dem Server existieren. Das ist eine Disziplinfrage, und sie lässt sich prüfen: Deployment nur aus dem Repository, nie per Hand auf dem Server, und ein regelmäßiger Abgleich, ob der Server noch dem letzten ausgerollten Stand entspricht. Wenn der Abgleich eine Abweichung zeigt, hat jemand am Server geschraubt, und das muss zurück ins Repository, bevor es jemand vergisst.

2. Die Zugänge, unter Ihrer Kontrolle

Das ist der Punkt, an dem die meisten Übergaben scheitern, die ich von außen gesehen habe. Die Domain läuft auf den Namen des Entwicklers. Der Server ist unter seinem Konto gemietet. Der Mailversand, der Zahlungsanbieter, die Karten-API: alles auf seine Adresse registriert. Wenn er nicht mehr antwortet, haben Sie eine Anwendung, die Sie nicht einmal abschalten können.

Die Regel lautet nicht „jedes Konto läuft auf Ihr Unternehmen". Das wäre schön, aber manche Dienste haben keine brauchbare Organisationsverwaltung, und manche funktionieren schlicht anders. Die Regel lautet: Für jeden Dienst, von dem Ihre Anwendung abhängt, liegen Vertrag, Eigentümer- oder Adminzugang und der Weg zur Wiederherstellung bei Ihnen. Ich arbeite darin mit einem eigenen Benutzerkonto und den Rechten, die ich brauche. Falle ich aus, entziehen Sie mir die Rechte und geben sie jemand anderem.

Drei Stellen, an denen das in der Praxis still schiefgeht, obwohl auf dem Papier alles stimmt:

• Der zweite Faktor. Ein Konto auf Ihren Namen nützt nichts, wenn die Zwei-Faktor-App auf meinem Handy läuft und die Wiederherstellungscodes in meinem Passwortmanager liegen. Das ist der häufigste stille Lock-in, den ich kenne. Der zweite Faktor für Eigentümer- und Adminkonten gehört auf ein Gerät bei Ihnen, die Wiederherstellungscodes in Ihren Tresor.
• Die Domain. Es reicht nicht, als Ansprechpartner eingetragen zu sein. Domaininhaber ist Ihr Unternehmen, der Vertrag mit dem Registrar läuft auf Sie, und Sie können den Auth-Code für einen Wechsel selbst anfordern.
• Die Zertifikatsverwaltung. Bei automatisch erneuerten Zertifikaten gibt es kein Konto, das man überschreibt. Was es gibt, ist ein Prozess auf dem Server, der dokumentiert sein muss, und ein Monitoring auf das Ablaufdatum, dessen Alarm nicht nur bei mir ankommt.

Bei den Geheimnissen selbst unterscheide ich zwei Sorten. Zugänge für Menschen, also Passwörter für Verwaltungsoberflächen, Registrar, Hosting, liegen in einem Passwortmanager, dessen Tresor Ihnen gehört und zu dem Sie ohne mich Zugang haben. Zugänge für Maschinen, also API-Schlüssel, Datenbankpasswörter, Signaturschlüssel, gehören nicht in einen Passwortmanager, sondern dorthin, wo sie gebraucht werden: in eine geschützte Serverkonfiguration, ein Deployment-System oder einen Secret Store, mit dokumentiertem Weg, wie man sie dort einsieht und erneuert. In beiden Fällen gilt derselbe Satz: Kein Geheimnis existiert ausschließlich bei mir. Ein Tresor, den nur die Entwicklerin öffnen kann, ist kein Tresor für Sie. Er ist einer gegen Sie.

3. Die Dokumentation, die jemand Fremdes liest

Eine fremde, kompetente Entwicklerin braucht am ersten Tag zwei Arten von Dokumentation, und beide fehlen in den meisten Projekten, die ich übernommen habe.

Die erste ist die Betriebsdokumentation: Welche Komponenten gibt es, wo laufen sie, wie hängen sie zusammen? Was ist fachlich das Herz der Anwendung, welche drei Abläufe müssen funktionieren, damit der Betrieb nicht steht? Wo liegen die Daten, wie werden sie gesichert, wie wird ein Backup zurückgespielt? Welche wiederkehrenden Aufgaben gibt es, und was passiert, wenn eine davon nicht läuft? Welche Stellen sind heikel und warum? Jede Anwendung hat drei oder vier Ecken, an denen man sich schneidet, wenn man es nicht weiß.

Die zweite ist die Architekturdokumentation, und die wird gern als Entwickler-Eitelkeit abgetan. Zu Unrecht. Ein Systembild auf einer Seite, das zeigt, welche Teile es gibt und wer mit wem spricht, und dazu eine Handvoll festgehaltener Entscheidungen mit Begründung: Warum keine Warteschlange, warum diese Datenbankstruktur, warum dieser Umweg beim Import. Solche Entscheidungsnotizen verhindern das Teuerste, was einer Nachfolgerin passieren kann: dass sie eine absichtliche Entscheidung für einen Fehler hält und sie zurückbaut. Nicht zwanzig Seiten Diagramme. Ein Bild und fünf bis zehn kurze Notizen.

Beides lebt im Repository, neben dem Code, als einfache Textdateien. Nicht in einem Wiki, dessen Zugang wieder an einer Person hängt. Und es wird bei jeder Änderung an Infrastruktur oder Architektur nachgezogen, nicht einmal im Jahr.

4. Das Deployment-Handbuch, von jemand anderem erprobt

Ein Deployment-Handbuch beantwortet eine Frage: Wie kommt die Anwendung aus dem Repository auf einen frischen Server? Schritt für Schritt, mit Befehlen, ohne stilles Wissen. Welche Pakete, welche PHP-Version, welche Konfiguration, welche Datenbank, wie Migrationen laufen, wie der Webserver eingerichtet wird, wie Zertifikate ausgestellt werden, wie die Cronjobs aussehen.

Und dann kommt der Teil, der wehtut: Jemand anderes muss es ausprobieren. Nicht ich, denn ich weiß zu viel und überlese die Lücken. Ich biete das als Übergabe-Test an, alle ein bis zwei Jahre: Eine Entwicklerin, die die Anwendung nicht kennt, setzt sie nur mit Repository und Handbuch auf einem Testserver auf. Jede Stelle, an der sie mich fragen muss, ist eine Lücke im Handbuch und wird geschlossen. Wie lange das dauert, hängt von der Anwendung ab. Der Punkt ist nicht die Zeit, sondern dass es ohne mich geht.

Wer das noch nie gemacht hat, wird überrascht sein, wie viel in den Köpfen steckt. Der eine Pfad, der in der Konfiguration anders heißt. Die Umgebungsvariable, die nur auf dem Produktivserver gesetzt ist. Das Paket, das vor zwei Jahren von Hand installiert wurde. Genau diese Dinge bringen einen Ersatz zum Stehen, und genau sie stehen in keiner Dokumentation, bis jemand gestolpert ist.

5. Die Daten, in zwei Formen

Der letzte Punkt wird gern vergessen, weil er so selbstverständlich scheint. Ihre Daten müssen in zwei Formen verfügbar sein, und die werden oft verwechselt. Die erste ist die Sicherung: ein Datenbank-Dump, mit dem sich die Anwendung auf einem neuen Server wiederherstellen lässt. Der ist für die Weiterführung der Anwendung gedacht und setzt voraus, dass die Anwendung weiterläuft. Die zweite ist der Export: Ihre Daten in einem lesbaren, dokumentierten Format wie CSV oder JSON, mit einer Beschreibung, was in welcher Spalte steht. Der ist für den Fall gedacht, dass die Anwendung nicht weiterläuft und ein anderes System die Daten übernehmen muss. Ein Datenbank-Dump ist kein Export. Er ist für Fachleute lesbar und für alle anderen eine Blackbox.

Beides gehört getestet. Der Dump über den Restore-Test, denn ein Backup, das nur ich zurückspielen kann, hat denselben Bus-Faktor wie ich. Der Export, indem jemand aus Ihrem Haus ihn einmal öffnet und prüft, ob er versteht, was darin steht.

Die Zweitentwickler-Klausel: regeln, bevor es passiert

Alles bisher Gesagte ist Technik und Disziplin. Es gibt aber auch einen vertraglichen Teil, und der ist bei kleinen Projekten fast nie vorhanden. Ich nenne das für mich Zweitentwickler-Klausel. Sie beantwortet drei Fragen:

1. Welche Rechte haben Sie am Code? Der Quellcode bleibt mein Werk, aber Sie erhalten die Nutzungsrechte, die Sie für Betrieb, Änderung und Weiterentwicklung brauchen, ausdrücklich auch durch Dritte, zeitlich unbegrenzt. Und Sie haben jederzeit Zugriff auf den vollständigen Quellcode, nicht erst im Ernstfall. Ob diese Rechte ausschließlich oder einfach sind, gehört in die Vertragsprüfung; in der Praxis bleibt mir die Wiederverwendung eigener, allgemeiner Bausteine wie Login, Rechteverwaltung oder PDF-Erzeugung in anderen Projekten, Ihre fachliche Logik bleibt bei Ihnen. Das ist der Unterschied zu vielen Agenturverträgen, in denen eine eingeschränkte Lizenz steht und die Weitergabe an Dritte ausgeschlossen ist. Bibliotheken von Dritten gehören weder mir noch Ihnen, ihre Lizenzen liegen im Repository.
2. Was heißt Ausfall, und was ändert er? Hier wird es oft unsauber. Wenn Sie ohnehin alle nötigen Rechte haben, dürfen Sie jederzeit jemand anderen beauftragen, dafür braucht es keinen Ausfall. Was der Ausfall tatsächlich ändert, sind andere Dinge: Er kann einen Wartungsvertrag beenden, ein Sonderkündigungsrecht auslösen, und er regelt, was mit Gewährleistung und Haftung passiert, wenn ab jetzt Dritte am Code arbeiten. Dafür braucht es eine Definition, und die hängt von der Anwendung ab. Bei einer Produktionsstörung sind fünf Werktage ohne Reaktion absurd lang. Bei einer unbeantworteten Änderungsanfrage sind sie viel zu kurz, um einen juristischen Ausfall auszulösen. Deshalb gebe ich hier keine Frist vor: Der Vertrag definiert Ausfall und Reaktionsfristen passend zum Wartungsvertrag und zu den vereinbarten Service-Levels.
3. Wer könnte übernehmen? Wo es eine Kollegin gibt, die das Projekt in Grundzügen kennt, etwa weil sie den Übergabe-Test gemacht hat, kann sie im Vertrag als Ansprechperson benannt werden. Das ist keine Garantie, dass sie Zeit hat. Aber es ist ein Anruf, den Sie führen können, statt im Branchenverzeichnis zu suchen.

Was ich bewusst nicht anbiete, ist ein klassischer Software-Escrow, also die Hinterlegung des Codes bei einem Treuhänder, der ihn im Ernstfall herausgibt. Für Standardsoftware, deren Hersteller den Code nicht herausgibt, ist das sinnvoll. Für Individualsoftware, bei der Sie ohnehin jederzeit Zugriff auf das Repository haben, ist es die teure Lösung für ein Problem, das gar nicht da sein sollte. Was Sie an Escrow-Gebühren sparen, stecken Sie in den Übergabe-Test. Der prüft nicht nur, ob der Code da ist, sondern ob er jemandem nützt.

Meine Seite der Vorsorge

Alles bisher beschreibt, was Sie kontrollieren müssen. Es gibt aber eine Frage, die kein Kunde für mich beantworten kann: Wer sagt Ihnen überhaupt, dass ich ausgefallen bin? Bei Krankheit oder Unfall meldet sich niemand von selbst. Deshalb gibt es auf meiner Seite eine zur Verschwiegenheit verpflichtete Vertrauensperson mit einer Liste der laufenden Kundenprojekte, den Ansprechpartnern und einer Anweisung, wer wann zu informieren ist. Dazu einen Notfallordner für meinen eigenen Betrieb: wo meine Verträge liegen, welche Dienste ich selbst betreibe, also meine eigenen, keine Kundenanwendungen, wie meine Infrastruktur heruntergefahren oder übergeben werden kann. Das ist nichts, worüber man gern nachdenkt. Aber eine Entwicklerin, die von ihren Kunden Vorsorge verlangt und selbst keine hat, ist nicht glaubwürdig.

Und bei der Agentur?

Ich habe oben gesagt, dass der Bus-Faktor einer Agentur nach meiner Erfahrung oft auch eins ist. Das ist kein Agentur-Bashing, sondern eine Beobachtung aus Projekten, die ich übernommen habe: Ein Projekt für einen Mittelständler ist in vielen Agenturen ein Team von zwei bis vier Leuten, und die Architektur hat davon eine Person im Kopf. Menschen wechseln den Arbeitgeber, in dieser Branche erfahrungsgemäß nicht selten. Die Chance, dass die eine Person Ihr Projekt über seine gesamte Lebensdauer begleitet, ist nicht hoch.

Die fünf Dinge oben gelten also auch dort, und Sie sollten sie genauso einfordern. Mit einem Unterschied: Bei einer Agentur müssen Sie zusätzlich fragen, wer intern die Architektur verantwortet, und was passiert, wenn genau diese Person geht. Die Antwort „wir haben ein Team" ist keine Antwort. Die Antwort „hier ist das Deployment-Handbuch, und wir haben es letztes Jahr von jemandem außerhalb des Teams testen lassen" wäre eine. Wer zwischen Agentur und Freelancerin abwägt, sollte diese Frage in beide Richtungen stellen.

Der Selbsttest für Ihre bestehende Software

Wenn Sie bereits eine Anwendung im Betrieb haben, egal von wem, können Sie den Bus-Faktor-Test in einer Stunde selbst machen. Beantworten Sie diese Fragen, ohne jemanden anzurufen:

Mehr als zwei rote Felder heißt: Sie sind derzeit erheblich von Ihrem Anbieter abhängig, unabhängig davon, was im Vertrag über Rechte steht. Das ist kein Vorwurf an Ihren Entwickler, es ist in kleinen Projekten der Normalzustand, weil niemand danach fragt. Manches davon ist schnell behoben: Repository-Zugang, Adminrechte oder Recovery-Codes sind oft eine Sache von Stunden. Anderes braucht Zeit, etwa ein Deployment-Handbuch, ein lesbarer Datenexport, die Vertragsklärung, eine saubere Secret-Struktur oder der Umzug von Domain und Hosting auf Ihren Namen. Ein guter Entwickler wird trotzdem froh sein, dass Sie fragen. Wer sich sperrt, hat Ihnen damit auch etwas gesagt.

Was ich nicht versprechen kann

Zum Schluss der ehrliche Teil, den ein Verkaufstext weglassen würde. Auch mit allen fünf Dingen und einer sauberen Klausel ist mein Ausfall für Sie ein Schaden. Eine neue Entwicklerin braucht Zeit, um die Anwendung zu verstehen, auch mit gutem Handbuch. Sie trifft andere Entscheidungen. Manches, was ich im Kopf hatte, ist weg. Das lässt sich mildern, nicht beseitigen, und das gilt für jede Form von Zusammenarbeit, in der jemand wirklich tief in Ihrer Sache steckt.

Was sich beseitigen lässt, ist der Totalausfall: die Software, die niemand mehr anfassen kann, die Domain, die niemand verlängern kann, die Daten, an die niemand herankommt. Das ist der Unterschied zwischen „wir brauchen ein paar Wochen und eine neue Entwicklerin" und „wir fangen von vorne an". Und dieser Unterschied ist nicht Glück. Er ist das Ergebnis von ein paar Entscheidungen am Anfang und einem Übergabe-Test alle ein bis zwei Jahre.

Häufige Fragen

Checkliste für das nächste Gespräch mit Ihrem Entwickler

• Repository: eigenes Admin-Konto, Produktivstand entspricht dem Repository, Abgleich vereinbart.
• Zugänge: Domaininhaber, Hosting-Vertrag, Admin-Konten, zweiter Faktor und Wiederherstellungscodes bei Ihnen.
• Geheimnisse: menschliche Zugänge in Ihrem Tresor, Maschinen-Schlüssel dokumentiert am Einsatzort, nichts nur beim Entwickler.
• Dokumentation im Repository: Betrieb und Architektur mit Entscheidungsnotizen.
• Deployment-Handbuch, von einer dritten Person erprobt, Wiederholung alle ein bis zwei Jahre.
• Daten: Dump mit Restore-Test und lesbarer Export mit Schemabeschreibung, beides einmal ausprobiert.
• Vertrag: Nutzungsrechte, Definition von Ausfall und Reaktionsfristen, Gewährleistung und Haftung bei Fremdbearbeitung, juristisch geprüft.

Fazit

Der Bus-Faktor eins ist kein Grund gegen eine freie Entwicklerin, und er ist auch kein Grund für eine Agentur. Er ist eine Tatsache, mit der man umgehen muss, bei jedem Partner. Der Umgang ist nicht kompliziert: fünf Dinge unter Ihrer Kontrolle, eine Klausel im Vertrag, ein Übergabe-Test alle ein bis zwei Jahre. Wer mich beauftragt, bekommt das nicht als Zugeständnis, sondern weil ich die Frage lieber selbst beantworte, bevor sie jemand im Ernstfall stellen muss. Und wer schon eine Anwendung hat: Machen Sie den Selbsttest. Eine Stunde heute ist billiger als jede Antwort, die Sie sonst später bekommen.

Verwandt auf eigene-anwendung.de: Wenn die eine Person fehlt, die alles weiß: Der Busfaktor, derselbe Busfaktor im Betrieb: wenn die eine Person fehlt, die alles weiß.

Verwandt auf app-entwicklerin.de: App-Übergabe: Quellcode, Signing-Keys, Store-Konten, die Übergabe einer App: Signing-Keys und Store-Konten als die Punkte, die bei Apps dazukommen.