Wissenstransfer beim Entwickler-Abgang: Die Vorlage für das Übergabe-Interview

Der Wissenstransfer beim Abgang eines Entwicklers scheitert meist aus einem banalen Grund: Niemand stellt vor dem letzten Arbeitstag die richtigen Fragen. Ein Übergabedokument wird geschrieben, es deckt die offensichtlichen Teile des Systems ab, und drei Wochen später geht etwas kaputt, weil ein geplanter Job existierte, von dem niemand wusste, oder weil ein manueller Schritt im Dokument nie erwähnt wurde. Die Lösung ist nicht ein längeres Dokument. Es ist ein strukturiertes Gespräch, geführt während der Entwickler noch da ist, um Rückfragen zu beantworten, aufgebaut aus einer konkreten Liste von Fragen statt aus der vagen Bitte, „einfach alles aufzuschreiben".

Das ist diese Liste. Nutzen Sie sie als Leitfaden für das Übergabegespräch, passen Sie die Reihenfolge an Ihre Situation an, und zeichnen Sie das Gespräch auf, wenn Ihr Entwickler damit einverstanden ist. Eine Aufzeichnung erfasst Details, die handschriftliche Notizen im Moment übersehen.

Warum ein Dokument beim Wissenstransfer beim Entwickler-Abgang nicht ausreicht

Ein Dokument erfasst nur das, worauf der Verfasser beim Schreiben denkt, und ein Entwickler, der ein System jahrelang betreut hat, lässt tendenziell genau die Dinge weg, die ihm selbstverständlich erscheinen. Das vierteljährliche Datenbank-Aufräumskript, das sonst niemand je geöffnet hat. Die Tatsache, dass die Staging-Umgebung einen anderen Zahlungsanbieter-Schlüssel verwendet und stillschweigend fehlschlägt, wenn jemand den falschen Schlüssel einträgt. Der Lieferantenkontakt, der nur auf E-Mails von einer bestimmten Adresse antwortet.

Ein Interview bringt diese Lücken zutage, weil eine gute Frage die Antwort in Worte zwingt, während ein Dokument darauf angewiesen ist, dass der Verfasser selbst zuerst an die Frage denkt. Führen Sie das Interview vor dem Dokument oder parallel dazu, statt das Dokument als fertiges Ergebnis und das Gespräch als optional zu behandeln.

Das Interview richtig vorbereiten

Planen Sie mindestens neunzig Minuten ein und teilen Sie das Gespräch in zwei Sitzungen, wenn das System groß ist. Legen Sie den Termin früh in die Kündigungsfrist, nicht in die letzte Woche, damit noch Raum für Rückfragen bleibt, sobald Sie die ersten Antworten verarbeitet haben. Bringen Sie wenn möglich eine zweite Person mit, die Notizen macht, während Sie fragen, denn wer beides gleichzeitig versucht, übersieht Details.

Sagen Sie Ihrem Entwickler offen, dass es nicht darum geht, ihn zu prüfen oder Lücken in seiner Arbeit aufzudecken. Es geht darum, das, was in seinem Kopf steckt, zu Papier zu bringen, bevor es mit ihm das Unternehmen verlässt. Menschen antworten vollständiger, wenn sie nicht befürchten, dass das Interview in Wirklichkeit eine Leistungsbeurteilung ist.

Die Fragen, die zutage fördern, was nirgendwo aufgeschrieben ist

Das sind die Fragen, die typischerweise die Antworten liefern, die ein schriftliches Übergabedokument auslässt.

Zu geplanten Jobs und Automatisierung: Welche Cron-Jobs oder geplanten Aufgaben laufen aktuell, was macht jeder davon, und was passiert, wenn einer davon stillschweigend stoppt? Gibt es einen Job, den niemand mehr kontrolliert, weil er einfach immer funktioniert hat? Welche geplanten Aufgaben hängen von Daten ab, deren Struktur sich ändern und das Ganze lautlos zum Scheitern bringen könnte?

Zu manuellen Korrekturen und Workarounds: Was erledigen Sie jeden Monat von Hand, oder immer wenn ein bestimmter Fehler auftritt, wovon sonst niemand weiß? Gibt es einen Schritt im Deployment oder in der Datenverarbeitung, der eine Ermessensentscheidung statt eines festen Verfahrens erfordert? Was würden Sie einem Nachfolger sagen, das er niemals anfassen soll, ohne vorher Sie zu fragen, wenn Sie noch erreichbar wären?

Zu dem, was aktuell kaputt ist oder nur notdürftig zusammenhält: Was ist gerade nur halb repariert oder wird umgangen statt richtig gelöst? Bei welchem Teil des Systems würde es Sie am wenigsten überraschen, wenn er in den nächsten sechs Monaten ausfällt? Gibt es ein Stück Code, für das Sie sich insgeheim schämen, das aber trotzdem einwandfrei funktioniert, sodass es nie jemand hinterfragt hat?

Zu Geschichte und Kontext: Wer außerhalb des aktuellen Teams hat diese Codebasis jemals angefasst? Ein ehemaliger Auftragnehmer, eine Agentur, ein früherer Mitarbeiter, der Code ohne Dokumentation hinterlassen hat. Gibt es eine Entscheidung in der Architektur, die heute seltsam wirkt, aber aus einem Grund sinnvoll war, der heute nicht mehr zutrifft?

Die mit Abstand nützlichste Frage zum Abschluss: Wenn Sie in einem Jahr einen Anruf zu diesem System bekämen und gefragt würden, was kaputt ist, was wäre Ihre erste Vermutung? Diese Frage benennt den fragilen Teil des Systems meist schneller als alles andere auf dieser Liste, weil sie den ausscheidenden Entwickler bittet, ein letztes Mal sein eigenes Urteil einzusetzen, statt nur Fakten aufzuzählen.

Lieferanten- und Dienstleisterkontakte

Ein eigener Abschnitt des Interviews sollte jede externe Partei abdecken, von der das System abhängt, denn diese Liste existiert fast nie irgendwo schriftlich. Gehen Sie jede Lieferantenbeziehung durch, die der Entwickler pflegt: den Hosting-Anbieter, die Domain-Registrierungsstelle, den Zahlungsdienstleister, den Dienst für transaktionale E-Mails, jede Drittanbieter-API, auf die das Produkt angewiesen ist, sowie jeden Auftragnehmer oder jede Agentur, die gelegentlich für bestimmte Arbeiten hinzugezogen wird.

Erfassen Sie für jeden einzelnen die Zugangsdaten oder bestätigen Sie, wer bereits Zugriff hat, den Support-Kontakt oder Ansprechpartner, sofern vorhanden, relevante Vertragsbedingungen wie Verlängerungstermine oder Nutzungsgrenzen, sowie alles Ungewöhnliche daran, wie dieser Anbieter kontaktiert werden muss, etwa einen Support-Kanal, der nur über eine bestimmte registrierte E-Mail-Adresse funktioniert.

Genau hier verstecken sich auch oft Abrechnungsüberraschungen. Fragen Sie gezielt, ob einer dieser Dienste auf einem kostenlosen Tarif läuft, der ab einer bestimmten Nutzungsgrenze aufhört zu funktionieren, oder ob eine Testphase bald abläuft. Ein Entwickler, der etwas vor zwei Jahren eingerichtet hat, erinnert sich vielleicht nicht spontan an das Verlängerungsdatum, aber die Frage zu stellen, solange er noch nachsehen kann, ist weit besser, als es zu erfahren, wenn der Dienst plötzlich ausfällt.

Die Checkliste zum Zugriffsentzug

Sobald das Interview abgeschlossen ist, müssen Sie das System noch absichern, was eine separate Aufgabe von der Dokumentation ist. Arbeiten Sie diese Liste durch und bestätigen Sie bei jedem Punkt, dass jemand anderes als der ausscheidende Entwickler Eigentümer- oder Admin-Zugriff hat und dass alle persönlich mit ihm verknüpften Zugangsdaten erneuert wurden:

die Domain-Registrierungsstelle und die DNS-Verwaltungskonsole, das Hosting-Konto bzw. der Cloud-Anbieter, die Produktionsdatenbank sowie jeder Backup- oder Replik-Dienst, die CI/CD-Pipeline und ihre Deployment-Schlüssel, der Zahlungsdienstleister und seine API-Schlüssel, der Dienst für transaktionale E-Mails, jede Drittanbieter-API, von der das Produkt abhängt, der Quellcode-Hoster und wer Admin-Rechte am Repository hat, der Passwort-Manager bzw. Credential-Tresor, falls vorhanden, sowie jede Zwei-Faktor-Authentifizierung, die an ein persönliches Gerät oder eine Authenticator-App gebunden ist.

Diese Checkliste und das Übergabeinterview beantworten zwei unterschiedliche Fragen. Das Interview zeigt Ihnen, wie das System funktioniert. Die Checkliste zeigt Ihnen, wer noch hineinkommt. Beides muss vor dem letzten Arbeitstag abgeschlossen sein, nicht danach. Für die vollständige Abfolge der ersten zwei Wochen, die beides zusammen mit allem anderen Notwendigen abdeckt, führt unser Leitfaden zu den ersten 14 Tagen, nachdem Ihr einziger Entwickler gekündigt hat durch die richtige Reihenfolge.

Was Sie mit den Antworten tun sollten

Schreiben Sie die Interviewnotizen innerhalb eines Tages aus, solange das Gespräch noch frisch ist, und ordnen Sie sie nach Systemkomponenten statt nach der Reihenfolge der gestellten Fragen. Wer das später liest, sucht nach Antworten auf „Wie funktioniert das Deployment" oder „Was macht der nächtliche Job", nicht danach, das Interview selbst zu rekonstruieren.

Ordnen Sie alles, was als kaputt oder fragil zur Sprache kam, danach, wie viel Schaden ein Ausfall anrichten würde, und halten Sie diese Liste sichtbar für denjenigen, der übernimmt, egal ob das eine Neueinstellung, ein Entwickler in Teilzeit oder ein externes Team ist, das die Lücke überbrückt. Wenn Sie schon vorher wissen möchten, wie exponiert das Unternehmen bereits ist, liefert unser Leitfaden zum Bus-Factor-Risiko einen kurzen Fragenkatalog, der das zeigt.

Liegt zwischen dem Abgang Ihres Entwicklers und dem Start eines festen Nachfolgers mehr als ein paar Wochen, brauchen Sie jemanden, der mit diesen Notizen arbeiten und Releases in der Zwischenzeit am Laufen halten kann. Unser Team für Webanwendungsentwicklung hat schon Systeme übernommen, die es nicht selbst gebaut hat, direkt auf Basis solcher Übergabenotizen. Schreiben Sie an hello@wolf-tech.io, oder finden Sie mehr Details unter wolf-tech.io, und bringen Sie mit, was Sie aus dem Interview haben. Das erste Gespräch kostet nichts.