Die Lücke bis zum Start des neuen Entwicklers überbrücken: Ein Übergabeplan in beide Richtungen

Ihr Entwickler hat vor sechs Wochen gekündigt. Die neue Person startet in drei Wochen. Irgendjemand muss die Entwicklerlücke dazwischen überbrücken, denn Releases müssen weiter raus, mittendrin läuft ein Serverzertifikat ab, und ein Kundenfehler, den nur die ausscheidende Person versteht, ist noch offen.

Die meisten Unternehmen behandeln das als Terminierungsproblem. Das Übergabemeeting in den Kalender setzen, um ein Dokument bitten, der ausscheidenden Person alles Gute wünschen. Dann kommt die neue Person zu einem Dokument, das an einem Freitagnachmittag in Eile entstanden ist, und zu einem System, das niemand mehr vollständig erklären kann. Die Entwicklerlücke zu überbrücken sind eigentlich zwei separate Übergaben, und sie als eine zu behandeln ist genau der Grund, warum in diesem Zwischenraum so viel Wissen verschwindet.

Warum das Überbrücken der Entwicklerlücke zwei Übergaben bedeutet, nicht eine

Die erste Übergabe findet statt, wenn Ihre aktuelle Entwicklerin oder Ihr aktueller Entwickler geht. Was diese Person weiß und nirgendwo aufgeschrieben ist, geht am letzten Tag mit ihr, unabhängig davon, ob Sie schon eine Nachfolge eingestellt haben. Die zweite Übergabe findet später statt, wenn die neue Person tatsächlich anfängt und das Festgehaltene in arbeitsfähiges Wissen über ein laufendes System verwandeln muss.

Sitzt in dieser Lücke niemand auf dem Platz, landen beide Übergaben gleichzeitig bei der neuen Person: Sie liest die Notizen einer anderen Person über ein System, das seitdem weiterlief und sich möglicherweise verändert hat, und niemand ist mehr da, den sie fragen kann, wenn etwas nicht passt. Das ist genau die Situation, die unser Leitfaden für geerbte Codebasen für Menschen beschreibt, die bei null anfangen. Als Ausgangspunkt ist das deutlich schwerer, als es sein müsste.

Die Lösung ist, jemanden auf diesen Platz zu setzen: eine Interimsentwicklerin oder ein Interimsentwickler, der die Übergabe von der ausscheidenden Person übernimmt, solange das Wissen noch frisch ist, das System während der Lücke am Laufen hält und dokumentiert, und der neuen festen Person danach ein saubereres Paket übergibt. Das macht aus einer schwierigen, verzögerten Übergabe zwei handhabbare.

Was Sie festhalten müssen, bevor die aktuelle Entwicklerin oder der aktuelle Entwickler geht

Egal ob Sie eine Interimsperson einsetzen oder nicht, diese Liste muss vor dem letzten Arbeitstag abgearbeitet sein, nicht danach. Sobald jemand gegangen ist, werden Fragen, die früher fünf Minuten gekostet haben, unbeantwortbar.

Beginnen Sie mit Zugängen und Zugangsdaten: Hosting-Konten, Domain-Registrar, Dashboards der Zahlungsabwickler, API-Keys von Drittanbietern, die CI/CD-Pipeline, DNS und jedes Admin-Panel, in das sich jemals nur eine einzige Person eingeloggt hat. Erstellen Sie eine vollständige Liste mit Verantwortlichen und Verlängerungsdaten und rotieren Sie alles Sensible, sobald der Übergang abgeschlossen ist.

Als Nächstes der Deployment-Prozess. Wie kommt Code tatsächlich in Produktion? Ist es ein Skript, das jemand von Hand ausführt, eine Pipeline, die beim Merge auslöst, oder etwas dazwischen mit manuellen Schritten, die nie jemand aufgeschrieben hat? Halten Sie die genaue Reihenfolge fest, einschließlich allem, was in einer bestimmten Reihenfolge passieren muss oder „nur dieses eine Mal“ übersprungen wird.

Dann die betrieblichen Eigenheiten: der Cronjob, der um 3 Uhr morgens läuft und den Cache anfasst, der Workaround für eine Drittanbieter-API, die montags fehlerhafte Daten liefert, die Datenbankspalte, die ungenutzt aussieht, aber einen Report zerschießt, wenn man sie entfernt. Nichts davon taucht in Code-Kommentaren auf. Es existiert, weil einmal etwas kaputtgegangen ist und jemand drumherum geflickt hat.

Halten Sie schließlich eine Architektur-Walkthrough fest, solange die ausscheidende Person sie noch erzählen kann. Eine 45-minütige Bildschirmaufnahme, in der sie die wichtigsten Services, den Datenfluss und die Teile des Systems durchgeht, bei denen sie selbst nervös würden, etwas anzufassen, ist mehr wert als ein geschriebenes Architekturdokument, weil sie das Zögern und die Vorbehalte zusammen mit den Fakten einfängt.

Was die Interimsentwicklerin oder der Interimsentwickler während der Lücke tatsächlich tut

Die Aufgabe einer Interimsperson in dieser Phase geht über das bloße Am-Laufen-Halten hinaus. Sie muss das, was sie von der ausscheidenden Person gelernt hat, in etwas verwandeln, das eine fremde Person kalt übernehmen könnte.

Das heißt: zu reparieren, was sich in der verfügbaren Zeit reparieren lässt, die drei Versionen veralteten Abhängigkeiten zu patchen, den Deployment-Prozess zu dokumentieren, indem man ihn tatsächlich durchführt und aufschreibt, was passiert, und die kleinen Bugs abzuschließen, die sonst im Backlog liegen würden und wie unbeliebte Aufgaben für die neue Person aussehen. Es bedeutet auch, Entscheidungen darüber zu treffen, was man besser in Ruhe lässt. Eine Interimsperson, die in sechs Wochen die halbe Codebasis umschreibt, macht die spätere Übergabe schwerer statt leichter, weil es dann zwei Sätze undokumentierter Entscheidungen gibt statt einem.

In der Praxis braucht es genau das, um die Entwicklerlücke zu überbrücken, ohne den Schmerz nur zu verschieben: ein funktionierendes System, ein echtes Deployment-Runbook und Dokumentation dessen, was sonst mit der letzten Person stillschweigend verschwunden wäre, kein polierter Statusbericht. Hat die Interimsperson zusätzlich Sicherheits- oder Performance-Erkenntnisse aus der Arbeit im Code, ist jetzt der Moment, sie zu melden, bevor eine feste Neueinstellung ihren ersten Monat damit verbringt, dieselben Probleme neu zu entdecken. Unsere Arbeit im Bereich Code-Qualitäts-Beratung fördert während eines Übergangs oft genau solche Dinge zutage, Probleme, die informell bekannt waren, aber nirgendwo aufgeschrieben, wo eine neue Person sie hätte finden können.

Das System an die feste Neueinstellung übergeben

Wenn die neue Entwicklerin oder der neue Entwickler anfängt, sollte sie oder er nicht dieselben Rohmaterialien bekommen, mit denen die Interimsperson gestartet ist. Sie oder er sollte ein System bekommen, in dem bereits sechs Wochen lang eine Fachperson gearbeitet hat, plus Dokumentation, die speziell für jemanden geschrieben wurde, der bei nichts davon dabei war.

Strukturieren Sie die zweite Übergabe um eine kurze Überlappung, wenn irgend möglich, und sei es nur wenige Tage, in denen die Interimsperson und die neue Person beide verfügbar sind, idealerweise im selben Raum oder in einem gemeinsamen Call statt nur mit einem weitergereichten Dokument und der Hoffnung, dass es reicht. Gehen Sie das Deployment-Runbook durch, indem die neue Person es tatsächlich ausführt, nicht nur liest. Gehen Sie die Liste der Eigenheiten und Workarounds gemeinsam mit der neuen Person durch, damit sie die Rückfragen stellen kann, die einem beim bloßen Lesen fremder Notizen nie einfallen.

Geben Sie der neuen Person eine kurze Liste dessen, was sie im ersten Monat besser in Ruhe lässt: welche Teile des Systems stabil und risikoarm zu ändern sind und welche Vorsicht erfordern, weil die Interimsperson oder die ursprüngliche Entwicklerin bzw. der ursprüngliche Entwickler sie als fragil markiert hat. Das allein verhindert viele der „warum hat die neue Person das kaputt gemacht“-Vorfälle, die entstehen, wenn jemand ankommt, ohne zu wissen, wo die Minen liegen.

Die Überlappung planen, damit nichts zweimal verloren geht

Der Fehler, den die meisten Unternehmen machen, ist, nur einen dieser beiden Übergänge zu planen und zu hoffen, dass sich der andere von selbst regelt. Planen Sie beide, noch vor der letzten Woche der ausscheidenden Person:

Stellen Sie sicher, dass der Starttermin der Interimsperson sich mit der letzten Woche der ausscheidenden Person überschneidet, und sei es nur um ein, zwei Tage. Ein einziger gemeinsamer Nachmittag der beiden beantwortet mehr Fragen als eine Woche schriftlicher Notizen.

Legen Sie einen festen Übergabetermin zwischen der Interimsperson und der festen Neueinstellung fest, und behandeln Sie ihn genauso: Lassen Sie ihn nicht zu einem „wann auch immer sich die neue Person eingelebt hat“ verschwimmen. Wissen verfällt schnell, selbst bei jemandem, der nur befristet eingestellt wurde, um es zu halten; nach sechs Wochen vergisst die Interimsperson schon, welche Entscheidungen bewusst getroffen wurden und welche unter Zeitdruck entstanden.

Schreiben Sie offene Fragen auf, sobald sie während der Interimsphase auftauchen, statt zu versuchen, sie im Übergabemeeting aus dem Gedächtnis zu rekonstruieren. Eine laufend geführte Liste schlägt jede nachträgliche Rekonstruktion.

Verschiebt sich der Starttermin einer festen Neueinstellung immer wieder, was häufiger vorkommt, als Unternehmen zugeben möchten, behandeln Sie die Interimslösung als fortlaufend, statt bei jeder Verschiebung nach einer neuen Brücke zu suchen. Es ist einfacher, einen bereits funktionierenden Einsatz zu verlängern, als später jemandem die Lücke zu erklären, der oder die irgendwann doch in die Rolle einsteigt.

Eine Kündigung und ein Starttermin werden immer wieder Wochen auseinanderfallen. Was darüber entscheidet, ob diese Lücke Sie etwas kostet, ist, ob jemand beide Enden der Übergabe als echte Arbeit behandelt, statt sie in die letzte Woche von irgendjemandem hineinzuquetschen.

Stehen Sie gerade vor einer Entwicklerlücke und brauchen jemanden, der die Mitte hält, melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io, um zu besprechen, wie der Übergang für Ihr Team aussehen kann.