Am Ende eines Auftrags steht ein Termin im Kalender, und er heißt Übergabe. Es gibt eine Präsentation, ein Dokument, vielleicht eine Aufzeichnung, und danach gilt die Sache als übergeben. Sechs Wochen später ruft jemand an, weil ein nächtlicher Lauf hängt und niemand weiß, wo er startet.
Der Fehler steckt in der Form. Übergabe ist kein Termin, sondern ein Zustand, und dieser Zustand lässt sich prüfen. Wer ihn nicht prüft, weiß erst dann, ob die Übergabe funktioniert hat, wenn es zu spät ist, sie zu wiederholen.
Dieser Artikel beschreibt den Test, der zählt, die Reihenfolge davor und die Stelle, an der es fast immer klemmt, und die hat nichts mit Wissen zu tun.
Der einzige Test, der zählt
Es gibt genau eine Prüfung, die etwas aussagt, und sie ist unbequem, weil sie nicht bestanden werden kann, indem man gut vorbereitet ist.
Das Team bringt eine echte, kleine Änderung in Produktion, ohne dass der Externe im Raum ist. Nicht in einer Testumgebung, nicht mit jemandem am Telefon, nicht mit einem Skript, das vorher gemeinsam geschrieben wurde. Vom Ticket bis zur laufenden Produktion, allein.
Alles andere ist Vorbereitung auf diese Prüfung. Ein Dokument mit hundert Seiten sagt nichts darüber, ob sie bestanden wird, und eine Präsentation sagt nur, dass jemand zugehört hat.
Der Zeitpunkt ist ebenso wichtig wie die Prüfung selbst: nicht am letzten Tag. Der Test gehört vier bis sechs Wochen vor das Ende, weil sein eigentlicher Zweck ist, die Lücken zu zeigen, solange noch Zeit ist, sie zu schließen. Eine Übergabe, die am letzten Tag geprüft wird, wird nicht geprüft, sondern bestätigt.
Die Stelle, an der es klemmt, ist nicht das Wissen
Bei Übergaben wird über Dokumentation gesprochen, und das Problem liegt woanders. In den meisten Fällen hängt irgendwo ein persönliches Konto im Weg, und es fällt erst auf, wenn es gebraucht wird.
Die Liste ist immer ähnlich und länger als erwartet: Die Domain steht auf dem Namen des Externen. Das Zertifikat verlängert sich über sein Konto. Die Zwei-Faktor-Anmeldung des Zahlungsanbieters liegt auf seinem Telefon. Der Zugang zum Paketverzeichnis, unter dem die internen Bibliotheken veröffentlicht werden, gehört ihm. Die Warnmeldungen der Überwachung gehen an seine Adresse. Der Schlüssel für den Auslieferungsserver liegt in seinem Passwortspeicher, und das Konto beim Anbieter der Fehlerberichte läuft auf seine private Adresse, weil das vor drei Jahren schneller ging.
Jeder einzelne Punkt ist an einem Nachmittag zu lösen und nach dem Ende des Auftrags eine Woche Arbeit mit Support-Kontakt. Deshalb steht diese Inventur nicht am Ende der Übergabe, sondern am Anfang: Zugänge zuerst, Wissen danach.
Die Probe darauf ist einfach und wird selten gemacht: Der Externe schaltet seine eigenen Zugänge für einen Tag ab. Was dann klemmt, ist die Liste, und sie ist ehrlicher als jede Aufzählung aus dem Gedächtnis.
Warum das Wissen überhaupt in einer Person liegt und was das kostet, steht in Wissen in einer Person ist ein Architekturproblem.
Was in welcher Reihenfolge übergeben wird
Nach den Zugängen kommt der Rest, und die Reihenfolge folgt der Frage, was zuerst gebraucht wird, wenn etwas passiert.
Der Weg von der Änderung in die Produktion. Wie kommt eine Zeile Code auf den Server, wie sieht man, ob es geklappt hat, und wie nimmt man es zurück? Das ist das Erste, weil es das Einzige ist, was in den ersten Tagen tatsächlich gebraucht wird.
Die drei Dinge, die nachts passieren. In jedem System gibt es zwei bis vier wiederkehrende Störungen. Der Import bleibt hängen, die Warteschlange läuft voll, der Partner antwortet nicht. Für jede davon ein Runbook von einer Seite: Woran erkennt man es, was tut man, wann eskaliert man. Das ist die wertvollste Seite Dokumentation im ganzen Vorhaben.
Die Entscheidungen. Nicht die Architektur, die steht im Code. Sondern warum etwas so ist: warum es zwei Tabellen für fast dasselbe gibt, warum die Abrechnung montags anders läuft, warum diese Bibliothek nicht aktualisiert wurde. Das ist das Wissen, das nirgends sonst steht, und es gehört in kurze Notizen mit Datum, nicht in ein Handbuch.
Der Rest. Alles, was sich aus dem Code lesen lässt, wird nicht abgeschrieben. Ein Diagramm der Klassenstruktur ist am Tag nach seiner Erstellung veraltet und ersetzt keine halbe Stunde gemeinsames Lesen.
Die Wochen davor: Rollen tauschen
Der Übergang gelingt nicht dadurch, dass am Ende mehr erklärt wird, sondern dadurch, dass vorher weniger gemacht wird.
Die letzten vier bis sechs Wochen gehören deshalb einem vertauschten Verhältnis: Das Team schreibt den Code, der Externe liest ihn. Jede Änderung, die noch ansteht, wird von jemandem umgesetzt, der bleibt, und der Externe steht daneben und beantwortet Fragen, die dabei entstehen.
Das ist unbequem, weil es langsamer ist, und es ist der einzige Weg, der zuverlässig wirkt. Fragen, die beim Lesen von Dokumentation entstehen, sind harmlos. Fragen, die beim Ändern von echtem Code entstehen, sind die richtigen, und sie kommen nur, wenn jemand echten Code ändert.
Ein Nebeneffekt dieser Wochen ist der ehrlichste Fortschrittsbericht, den es gibt: Wenn die Fragen nach der dritten Woche nicht weniger werden, ist die Übergabe nicht auf Kurs, und das weiß man dann noch rechtzeitig.
Der Tag selbst
Wenn das Vorherige stimmt, ist der Übergabetag unspektakulär, und das ist das Ziel. Er besteht aus drei Dingen.
Eine Liste, die abgehakt wird. Zugänge übertragen, persönliche Konten entfernt, Warnmeldungen umgeleitet, Schlüssel getauscht, Rechnungen auf das Unternehmen umgestellt. Punkt für Punkt, gemeinsam, nicht per Mail.
Eine benannte Zuständigkeit. Ab heute ist eine Person im Team für dieses System verantwortlich, mit Namen. Ohne das verteilt sich die Zuständigkeit auf alle, und das heißt auf niemanden.
Eine Frist statt einer offenen Tür. „Melde dich, wenn was ist" klingt großzügig und ist der schlechteste Teil vieler Übergaben: Es hält die Abhängigkeit am Leben, ohne sie zu regeln. Besser ist eine klare Abmachung: vier Wochen erreichbar für Fragen, danach auf Anfrage und nach Aufwand. Das ist kein Rückzug, sondern der Unterschied zwischen einem Nachlauf und einem Dauerzustand.
Zu den Dingen, die nachts passieren, gehört fast immer der Wiederanlauf: Backups, die niemand je wiederhergestellt hat.
Wenn es nicht reicht
Zum Schluss der Fall, der selten ausgesprochen wird: Manchmal ist die Übergabe zum vereinbarten Termin nicht zu schaffen. Das Team ist zu klein, das Wissen zu konzentriert, oder es kam etwas dazwischen.
Dann ist die einzige brauchbare Reaktion, es früh zu sagen, mit einem konkreten Vorschlag: was bis zum Termin erreichbar ist, was danach offen bleibt, und welche zwei oder drei Dinge zuerst geschlossen werden müssten. Eine Übergabe, die auf dem Papier stattgefunden hat, ist teurer als eine, die um sechs Wochen verschoben wurde, und der Unterschied zeigt sich beim ersten Vorfall.
Der Maßstab dafür ist am Ende derselbe wie bei jeder anderen Arbeit an einem gewachsenen System: Nicht, wie viel erklärt wurde, sondern was das Team danach allein kann. Wie ich an solchen Systemen arbeite, steht auf einer eigenen Seite.
Dieser Artikel gehört zu einer Reihe über Systeme, die es schon gibt. Der Rückblick ordnet alle Artikel der Reihe nach Anlass.
