Ihr einziger Entwickler hat gekündigt: Die ersten 14 Tage

Ihr einziger Entwickler hat gerade gekündigt, und jetzt läuft ein Countdown von zwei Wochen, der entscheidet, ob Ihr Produkt weiterläuft oder in der Woche nach seinem Abgang leise zerfällt. Wenn Sie sich fragen, was zu tun ist, wenn ein Entwickler kündigt und niemand sonst die Codebasis kennt, lautet die ehrliche Antwort, dass der größte Teil des Schadens in der Kündigungsfrist entsteht, nicht danach. Was Sie in diesen 14 Tagen tun, entscheidet darüber, wie viel von dem, was im Kopf dieser Person steckt, nach draußen gelangt, bevor sie durch die Tür geht.

Das ist kein Dokument, das Sie ihr oder ihm an einem Freitagnachmittag abverlangen. Es ist ein kurzer, strukturierter Plan, den Sie gemeinsam durchziehen, ab dem Tag, an dem die Kündigung ausgesprochen wird.

Tag 1 bis 2: Zugänge sichern, noch bevor irgendetwas anderes passiert

Bevor Sie über Übergabedokumente oder Wissenstransfer sprechen, verschaffen Sie sich ein klares Bild davon, was eine einzige Person derzeit alles erreichen kann. Die meisten Unternehmen mit nur einem Entwickler haben nie einen zweiten Admin-Zugang für irgendetwas eingerichtet, sodass die scheidende Person oft die Einzige ist, die sich bei der Hälfte des Folgenden einloggen kann:

• der Domain-Registrar und die DNS-Einstellungen
• das Hosting-Konto oder die Cloud-Provider-Konsole (AWS, Hetzner, DigitalOcean, was auch immer es ist)
• die Produktionsdatenbank, einschließlich jeder Lesereplik oder jedes Backup-Dienstes
• die CI/CD-Pipeline und alle damit verbundenen Deployment-Keys
• der Zahlungsabwickler und dessen API-Keys
• der E-Mail-Versanddienst (transaktionale E-Mails fallen leise aus, und niemand merkt es tagelang)
• Drittanbieter-APIs, von denen das Produkt abhängt
• der Source-Control-Host, besonders wer Admin-Rechte auf dem Repository hat
• der Passwort-Manager oder Credential-Tresor, falls vorhanden
• jede Zwei-Faktor-Authentifizierung, die an ein persönliches Telefon oder eine Authenticator-App gebunden ist

Gehen Sie diese Liste gemeinsam durch und fügen Sie eine zweite Person hinzu, idealerweise Sie selbst oder jemand in einer festen Rolle, als Inhaber oder Admin bei jedem Konto. Rotieren Sie jede Zugangsdaten, die sich nicht saubertrennbar teilen lässt, etwa persönliche API-Tokens, und erzeugen Sie einen neuen Satz, der an das Konto gebunden ist, das Sie kontrollieren. Allein dieser Schritt verhindert das schlimmste Ergebnis: eine ausgesperrte Produktionsumgebung drei Wochen nach dem Abgang Ihres einzigen Entwicklers, wenn er oder sie nicht mehr erreichbar ist.

Tag 3 bis 5: Aufschreiben, wie Deployments tatsächlich ablaufen

Bitten Sie Ihren Entwickler, Ihnen schriftlich genau zu zeigen, was zwischen „Code ist fertig" und „Code ist live" passiert. Die meisten kleinen Unternehmen haben das nie aufgeschrieben, weil eine Person es immer auf dieselbe Weise gemacht hat und es nie erklären musste. Dieses Wissen muss die Übergabe überleben, selbst wenn Sie selbst nie ein Deployment anfassen. Mindestens brauchen Sie:

• was ein Deployment auslöst (ein manueller Befehl, ein Merge in einen Branch, ein geplanter Job)
• wo Umgebungsvariablen und Secrets gespeichert sind und wer sie bearbeiten kann
• wie ein normales Deployment aussieht, einschließlich wie lange es dauert und was „es hat funktioniert" bedeutet
• jeder manuelle Schritt, der nicht automatisiert ist (eine Migration, die händisch laufen muss, ein Cache, der geleert werden muss, ein Dienst, der in einer bestimmten Reihenfolge neu gestartet werden muss)
• geplante Jobs und Cronjobs, was sie tun und was kaputtgeht, wenn sie nicht mehr laufen
• Monitoring und Alerting: wo Fehler auftauchen und wer aktuell benachrichtigt wird

Das ist auch der Moment, die Frage zu stellen, die nicht-technische Gründerinnen und Gründer am häufigsten vergessen: Was geht als Erstes kaputt, wenn einen Monat lang niemand dieses System anfasst? Die Antwort ist oft eine bestimmte Abhängigkeit, die erneuert werden muss, ein Zertifikat, das abläuft, oder ein Batch-Job, der leise stoppt, sobald sich das Format einer Datenquelle ändert.

Das Übergabegespräch

Irgendwo zwischen Tag 3 und Tag 10 setzen Sie sich zu einem strukturierten Gespräch zusammen, statt zu hoffen, dass ein Dokument alles abdeckt. Eine schriftliche Übergabe übersieht die Dinge, die jemand nicht aufgeschrieben hat, weil sie ihm oder ihr offensichtlich erschienen, und genau das sind meist die Dinge, die den nächsten Ausfall verursachen. Unser Leitfaden zum Übernehmen einer undokumentierten Codebasis behandelt das von der anderen Seite, für diejenigen, die das Dokument später lesen, aber das Gespräch selbst ist es, das die Lücken schließt, die eine schriftliche Übergabe offenlässt.

Fragen Sie direkt:

• Welchen Teil dieses Systems würden Sie niemanden ohne Sie im Raum anfassen lassen?
• Welcher Workaround oder Trick existiert, von dem niemand außerhalb dieser Codebasis weiß?
• Was ist aktuell kaputt, halb repariert oder wird nur mit Mühe zusammengehalten?
• Wer außerhalb des Unternehmens hat diesen Code jemals angefasst (ein ehemaliger Auftragnehmer, eine Agentur, ein früherer Mitarbeiter)?
• Wenn Sie in einem Jahr einen Anruf wegen dieses Systems bekämen, was würden Sie als Problem vermuten?

Die letzte Frage bringt die fragilen Stellen meist schneller zutage als jede Dokumentationsprüfung. Nehmen Sie das Gespräch auf, wenn Ihr Entwickler damit einverstanden ist, denn ein Transkript fängt Details ein, die im Moment mitgeschriebene Notizen nicht erfassen.

Die Liste offener Punkte aufbauen

Erstellen Sie vor dem letzten Arbeitstag eine einzige, priorisierte Liste mit allem, was derzeit offen ist: bekannte Bugs, halbfertige Features, technische Schulden, die der Entwickler schon länger angehen wollte, und alles, was Kunden gemeldet haben, aber nie in ein formales Bug-Tracking-System aufgenommen wurde. Sortieren Sie danach, wie sehr es schadet, einen Monat lang unbearbeitet zu bleiben, nicht danach, wie interessant die Arbeit daran wäre. Diese Liste wird zum Ausgangspunkt für alle, die die Lücke als Nächstes füllen, egal ob das eine Neueinstellung, eine fraktionelle Entwicklerin oder Sie selbst mit externer Hilfe sind.

Tag 6 bis 14: Einfrieren, was geht, und festlegen, wer Änderungen freigibt, solange der Platz leer ist

Sobald die Zugänge gesichert und das Übergabegespräch geführt sind, geht es in der letzten Woche darum, Risiko zu senken, statt Features hinzuzufügen. Zwei Entscheidungen zählen hier.

Erstens, vereinbaren Sie einen Änderungsstopp für alles Nicht-Essenzielle. Neue Features können warten. Bugfixes, die aktiv Kunden schaden, können das nicht, legen Sie also jetzt fest, wer berechtigt ist, einen Notfall-Fix freizugeben und auszuliefern, sobald Ihr Entwickler weg ist, und wie dieser Prozess ohne ihn oder sie abläuft.

Zweitens, entscheiden Sie, wer das System Tag für Tag im Blick hat. Jemand muss das Fehler-Monitoring prüfen, bestätigen, dass geplante Jobs gelaufen sind, und merken, wenn ein Zertifikat bald abläuft. Das muss keine Entwicklerin oder kein Entwickler sein, aber es braucht eine konkrete Person mit einer konkreten täglichen Gewohnheit, nicht die vage Hoffnung, dass „schon jemand" etwas bemerkt, wenn etwas kaputtgeht.

Was nach der Kündigung Ihres Entwicklers und den 14 Tagen zu tun ist

Vierzehn Tage verschaffen Ihnen ein dokumentiertes, zugangsgesichertes System und eine priorisierte Liste dessen, was Aufmerksamkeit braucht. Sie verschaffen Ihnen keinen Entwickler. Irgendwann in den folgenden Wochen brauchen Sie jemanden, der den Code tatsächlich lesen, die Fixes von dieser Liste offener Punkte ausliefern und Releases am Laufen halten kann, während Sie eine feste Nachbesetzung einstellen.

Genau für diese Lücke ist interimistische Entwicklungsunterstützung gedacht: jemand, der in ein System einsteigen kann, das er nicht selbst gebaut hat, mit der Übergabe arbeitet, die Sie gerade erstellt haben, und es am Laufen hält, ohne auf das Ende eines sechswöchigen Einstellungsprozesses zu warten. Wenn das Ihre Situation beschreibt, hat unser Team für Webanwendungsentwicklung diese Art von Übernahme schon gemacht und kann Ihnen ehrlich, ohne jede Verpflichtung, sagen, ob interimistische Unterstützung oder eine schnellere feste Einstellung für Ihre Situation mehr Sinn ergibt.

Schreiben Sie uns an hello@wolf-tech.io oder erfahren Sie mehr auf wolf-tech.io. Das erste Gespräch kostet nichts, und es ist deutlich günstiger, als herauszufinden, was kaputtgeht, wenn niemand hinschaut.