30 June 20267 Min. Lesezeit
Jede Zusammenarbeit endet. Manche enden, weil die Arbeit fertig ist, manche, weil die Fähigkeit ins Haus geholt wird, manche, weil es nicht mehr funktioniert hat, und einige, weil die Person, die Sie mochten, einen anderen Job angenommen hat. Der Grund wechselt. Das Ende nicht.
Trotzdem wird die Übergabe fast immer in den letzten zwei Wochen improvisiert, von Menschen, die gedanklich schon weg sind, unter Termindruck und ohne zugewiesenes Budget. Das Ergebnis ist ein Ordner voller Dokumente, die Fragen beantworten, die niemand gestellt hätte, und die drei Dinge auslassen, auf die es wirklich ankam.
Die Übergabe beginnt am ersten Tag
Teams, die gut übergeben, haben keine bessere Schlusswoche. Sie haben einen anderen ersten Monat. Sie haben die Zusammenarbeit so aufgesetzt, dass das Wissen nie allein in einem Kopf war, weshalb die Übergabe im Wesentlichen darin besteht, auf Dinge zu zeigen, die bereits existieren.
Die praktische Fassung: Entscheidungen werden dort festgehalten, wo die Arbeit stattfindet, Architekturnotizen liegen neben dem Code, den sie beschreiben, und kein Dienst, kein Konto und kein Deployment-Weg hat genau eine Person, die ihn versteht. Nichts davon ist Übergabearbeit. Es ist normale Praxis, die eine Übergabe nebenbei fast kostenlos macht.
Das ist auch das Argument dafür, von Anfang an darauf zu bestehen, dass Repository, Cloud-Konten, Domain und CI-Konfiguration Ihnen gehören und der Partner darin arbeitet. Es klingt nach einer Vertrauensfrage. Ist es nicht. Es ist der Unterschied zwischen einer Übergabe und einer Migration.
Was tatsächlich übergehen muss
Nicht der Code. Der Code überträgt sich selbst; er liegt im Repository und sagt, was er tut. Was sich nicht überträgt, ist alles, was ihn erklärt.
- Warum das System so geformt ist, wie es ist, samt der Randbedingungen, die es nicht mehr gibt und die den Entwurf trotzdem erklären.
- Die Fehlermodi: was kaputtgeht, woran Sie es erkennen und worin die Abhilfe meist besteht.
- Das Betriebswissen: wie deployt wird, wie man zurückrollt, was zu tun ist, wenn der Nachtlauf scheitert, welcher Alarm ignoriert werden darf und welcher nicht.
- Die Beziehungen und Abhängigkeiten außerhalb des Codes: welcher Drittanbieter unzuverlässig ist, wessen Freigabe eine Schemaänderung braucht, welcher Kunde montags keine Ausfallzeit verträgt.
- Das Unerledigte: was bewusst liegen blieb, was aus Zeitgründen liegen blieb und was bekanntermaßen falsch ist, sich aber noch nicht zu beheben lohnt.
Diese letzte Kategorie wird ausgelassen, weil es sich wie ein Eingeständnis anfühlt, sie aufzuschreiben. Sie ist die wertvollste Seite der ganzen Übergabe.
Von der falschen Person geschriebene Dokumentation ist nutzlos
Wer ein System gebaut hat, kann nicht sehen, was daran verwirrend ist. Bitten Sie diese Person, es zu dokumentieren, und Sie bekommen eine korrekte Beschreibung, die keine der Fragen beantwortet, die ein Neuling hat, weil ihr diese Fragen nie in den Sinn gekommen sind.
Ein besserer Mechanismus: Die übernehmende Person schreibt die Dokumentation, indem sie sich durch das System arbeitet und fragt, während die scheidende Person korrigiert statt verfasst. Das ist langsamer, es fühlt sich ineffizient an, und es entsteht eine Dokumentation, die auf den richtigen Leser zugeschnitten ist, dazu ein Empfänger, der sich wirklich damit befasst hat, statt ein Dokument abzulegen.
Die Überschneidungsphase ist das Entscheidende
Eine Übergabe per Dokument funktioniert für sich allein nicht. Was funktioniert, ist ein Zeitraum, zwei bis vier Wochen für ein System üblicher Größe, in dem beide Personen bezahlt werden und die übernehmende Person die Arbeit macht, während die scheidende für Antworten verfügbar ist.
Die Reihenfolge, die funktioniert: Die übernehmende Person bearbeitet echte Tickets, keine Übungen, beginnend mit etwas Kleinem und endend mit etwas, das den beängstigenden Teil des Systems berührt. Die ausscheidende Person steht für Fragen bereit und prüft die Arbeit, macht sie aber nicht. Kommt es in dieser Zeit zu einer Produktionsstörung, bearbeitet die übernehmende Person sie, während die andere zusieht. Nichts sonst erzeugt dieselbe Sicherheit.
Diese Phase kostet echtes Geld, denn Sie zahlen zweimal für dieselbe Abdeckung. Sie ist mit weitem Abstand billiger als die Alternative, und sie ist die Position, die am häufigsten von jemandem aus dem Übergangsbudget gestrichen wird, der noch nie eine schlechte Übergabe erlebt hat.
Die langweiligen Teile, früh erledigt
Zugänge, Eigentum und Papierkram sind nicht spannend, und genau dort bleiben Übergaben tatsächlich hängen. Bestätigen Sie, dass die IP-Übertragung alles Gelieferte umfasst, einschließlich der Arbeit jedes Unterauftragnehmers, dass der AV-Vertrag ordentlich abgeschlossen wird und personenbezogene Daten dort gelöscht werden, wo sie gelöscht gehören, und dass kein Produktivkonto, Zertifikat, keine Domain und keine Drittanbieter-Integration auf eine Person läuft, die geht.
Der Klassiker ist das Konto, das auf die private E-Mail-Adresse einer Person registriert ist. Entdeckt wird es elf Monate später, wenn an einem Sonntag das Zertifikat abläuft und die einzige Person, die es erneuern kann, seit dem Frühjahr nicht mehr für Sie arbeitet.
Übergabe als Gewohnheit, nicht als Ereignis
Der verlässlichste Schutz ist, kleine Übergaben zur Routine zu machen, solange nichts endet. Rotieren Sie alle paar Monate, wer welchen Bereich verantwortet. Lassen Sie gelegentlich jemand anderen als die Autorin ein System in einer Teamsitzung durchgehen. Behandeln Sie jede Komponente, die genau eine Person versteht, als Risiko auf einer Liste und nicht als Naturgesetz.
Ein Team, das so arbeitet, hat den Transfer schon ein Dutzend Mal geübt, bevor er zählt. Ein Team, das es nicht tut, verlässt sich auf zwei Wochen am Ende, organisiert von Menschen, die längst an etwas anderes denken; genau diese Konstellation ist einen Absatz im Leistungsverzeichnis wert, um sie zu vermeiden.