Das Repository eines Projekts zu erhalten, bedeutet noch nicht, dass man bereit ist, die Verantwortung zu übernehmen. Das neue Team muss auch verstehen, welche Dienste zum vereinbarten Umfang gehören, wie sie bereitgestellt werden, wer die Zugänge verwaltet und welche Entscheidungen die Lösung prägen. Fehlen diese Informationen, kann eine Routineaufgabe von einer Person abhängen, die nicht mehr verfügbar ist. Ein Vorfall kann dann zur Fehlersuche von Grund auf werden.
Wer ein digitales Projekt verlässlich übergeben möchte, sollte die Übergabe als überprüfbaren Prozess behandeln – nicht als Abschlusssitzung oder als Versand eines Ordners. Ziel ist, dass die neue Partei das Produkt mit dem vereinbarten Maß an Selbstständigkeit betreiben, diagnostizieren und weiterentwickeln kann. Dieser Leitfaden beschreibt Schritte, Prüfungen und Anzeichen, anhand derer sich beurteilen lässt, ob die Übergabe tatsächlich vollständig ist.
Den Umfang festlegen, bevor Dateien ausgetauscht werden
Zunächst muss vereinbart werden, was übergeben wird und was nicht. „Das Projekt“ kann eine Anwendung, mehrere Dienste, Cloud-Infrastruktur, Integrationen, Administrationsoberflächen, manuelle Abläufe und Supportaufgaben umfassen. Bleibt der Umfang unausgesprochen, betrachtet der Anbieter möglicherweise den Code als übergeben, während das übernehmende Team auch Verfahren, Konfigurationen oder betriebliche Zuständigkeiten erwartet.
Erstellen Sie gemeinsam ein Inventar, das für jede Komponente ihre Funktion, ihre Umgebung sowie die bisherige und künftige verantwortliche Person aufführt. Berücksichtigen Sie die Produktionsumgebung und gegebenenfalls auch Test- und Entwicklungsumgebungen. Halten Sie außerdem zugehörige Drittanbieterdienste, Domains, Zertifikate, Warteschlangen, geplante Aufgaben, Speicher, Analysen und Supportkanäle fest. In dieser ersten Liste muss nicht jedes Detail dokumentiert werden. Klar sein muss aber, was vorhanden ist und wer den jeweiligen Bereich erklären soll.
Grenzen Sie auch die Aufgaben ab, für die sich die Zuständigkeit ändert: Bereitstellungen, Prüfung von Warnmeldungen, Störungsbearbeitung, Erneuerung von Zugangsdaten oder Freigabe von Änderungen. Halten Sie fest, welche Dienste weiterhin von einer anderen Partei betreut werden und wie Unterstützung angefordert wird. Eine einfache Zuständigkeitsmatrix mit Haupt- und Vertretungsverantwortlichen verhindert, dass eine kritische Aufgabe „dem ganzen Team“ zugewiesen wird und in der Praxis niemandem.
Dokumentation für den Arbeitsalltag erstellen
Die Dokumentation sollte Fragen beantworten, die das übernehmende Team tatsächlich klären muss, und sich nicht darauf beschränken, das Produkt zu beschreiben. Beginnen Sie mit einer Architekturübersicht, die Komponenten, Datenflüsse und Integrationen zeigt. Ergänzen Sie eine Anleitung zur lokalen Installation und nennen Sie wichtige Abhängigkeiten, erforderliche Versionen und Konfigurationsvoraussetzungen. Wenn eine technische Entscheidung erhebliche Folgen hat, dokumentieren Sie sowohl die Entscheidung als auch ihre Begründung – insbesondere, wenn sie künftige Alternativen einschränkt.
Betriebsverfahren sind ebenso wichtig. Dokumentieren Sie, wie eine Bereitstellung vorbereitet und ausgeführt, das Ergebnis überprüft und eine Änderung zurückgenommen wird. Beschreiben Sie Schritte zur Untersuchung häufiger Fehler, zur Einsicht in verfügbare Protokolle oder Messwerte und zur Eskalation eines Vorfalls. Gibt es manuelle Aufgaben, erklären Sie, wer sie wann ausführt und woran sich erkennen lässt, dass sie erfolgreich abgeschlossen wurden. Passwörter und Geheimnisse gehören nicht in Textdokumente.
Die Dokumentation kann auf ein Repository, ein Wiki oder ein Ticketsystem verteilt sein. Entscheidend ist, dass eine aktuelle, maßgebliche Quelle existiert und allen bekannt ist. Bitten Sie die übergebende Partei, veraltete Seiten und bekannte Lücken zu benennen. Eine Anleitung ist nicht schon deshalb für den Betrieb geeignet, weil sie vorhanden ist: Sie muss es ermöglichen, eine Aufgabe ohne mündliche Erklärung abzuschließen.
Zugänge kontrolliert und nachvollziehbar übergeben
Erstellen Sie vor dem Wechsel der Zuständigkeiten eine Liste der Konten und Systeme: Repositories, Cloud-Umgebungen, Domains, Bereitstellungswerkzeuge, Monitoring, Datenbanken, Anbieter und Integrationen. Ermitteln Sie für jedes System, wer administrativ verantwortlich ist, wie der Zugang wiederhergestellt werden kann und wer Zugriff benötigt. Vermeiden Sie, dass die Kontinuität von einem persönlichen Konto oder einer einzigen Person mit exklusiven Berechtigungen abhängt.
Vergeben Sie individuelle Konten und wenden Sie das Prinzip der geringsten Berechtigung an: Jede Person sollte nur die Rechte erhalten, die sie für ihre Aufgabe benötigt. Nutzen Sie die sicheren Verfahren zur Verwaltung von Geheimnissen, über die die Organisation bereits verfügt, statt Zugangsdaten per E-Mail zu versenden oder in Tickets einzutragen. Vereinbaren Sie, wann die Zugänge der ausscheidenden Partei entzogen werden und wie die Administrationsfähigkeit erhalten bleibt. Lassen sich gemeinsam genutzte Schlüssel nicht sofort ersetzen, dokumentieren Sie das Risiko und legen Sie einen Rotationsplan fest.
Überprüfen Sie die Zugänge praktisch. Es reicht nicht, wenn jemand bestätigt, das neue Team „eingeladen“ zu haben: Stellen Sie sicher, dass es sich anmelden, die vorgesehenen Aktionen ausführen und den Zugang über das festgelegte Verfahren wiederherstellen kann. Die Prüfung sollte auch Notfallberechtigungen umfassen, ohne daraus dauerhafte Privilegien für alle zu machen.
Die Übergabe anhand echter Aufgaben überprüfen
Am aussagekräftigsten ist es, wenn das neue Team typische Aufgaben selbst erledigt. Richten Sie, sofern verfügbar, eine Umgebung außerhalb der Produktion ein und bitten Sie das Team, das Projekt zu konfigurieren, vorhandene Prüfungen auszuführen und der Anleitung folgend eine Bereitstellung vorzunehmen. Achten Sie darauf, wo Fragen entstehen, und aktualisieren Sie die Dokumentation direkt im Anschluss. Eine Präsentation kann den Überblick vermitteln; erst die Übung zeigt, ob dieser Überblick bei der Orientierung hilft.
Führen Sie außerdem eine Diagnosesimulation durch: Stellen Sie einen bekannten Vorfall vor oder betrachten Sie einen früheren Fall. Bitten Sie das Team, Hinweise zu finden, die Auswirkungen zu bestimmen und zu erklären, wen es benachrichtigen würde. Wenn es der Dienst zulässt und ein sicheres Verfahren vorhanden ist, prüfen Sie, wie eine Änderung zurückgenommen oder der Betrieb wiederhergestellt wird. Führen Sie in der Produktionsumgebung keine Wiederherstellungsversuche ohne Genehmigung, Vorbereitung und angemessene Kontrollen durch.
Legen Sie im Voraus fest, was als erfolgreiche Prüfung gilt. Das Team könnte beispielsweise eine Bereitstellung ohne direkte Unterstützung durchführen, die relevante Konfiguration finden, eine Anwendungsstörung von einem Problem mit einer Abhängigkeit unterscheiden und den Eskalationskanal benennen. Ist eine Aufgabe nur mit Eingreifen des Anbieters möglich, halten Sie fest, was fehlt, wer sich darum kümmert und bis wann. Erklären Sie die Übergabe nicht vorschnell für abgeschlossen, wenn die Abnahmebedingungen unklar sind.
Implizites Wissen durch strukturierte Begleitung vermitteln
Organisieren Sie kurze Sitzungen zu konkreten Aufgaben: eine Benutzeranfrage nachverfolgen, eine Änderung prüfen, auf eine Warnmeldung reagieren oder eine Veröffentlichung vorbereiten. Die Person mit Systemkenntnis sollte ihre Überlegungen und Ausnahmen erläutern. Das neue Team führt die Schritte aus und stellt Fragen. Aufzeichnungen können hilfreich sein, ersetzen aber weder aktuelle Verfahren noch praktische Übungen.
Vereinbaren Sie eine Begleitphase mit festgelegten Kanälen, Zeiten oder Eskalationskriterien, ohne unbegrenzte Verfügbarkeit vorauszusetzen. Erfassen Sie offene Punkte und ordnen Sie sie nach ihrer Auswirkung: Blockaden für den Betrieb, erhebliche Risiken und Verbesserungen, die später eingeplant werden können. Weisen Sie jedem Punkt eine verantwortliche Person, einen nächsten Schritt und einen Prüfungstermin zu. So lässt sich eine unvollständige Übergabe von der normalen Weiterentwicklung des Produkts unterscheiden.
Abnahme-Checkliste und Warnsignale
Prüfen Sie vor Abschluss der Übergabe gemeinsam mit Vertretungen aus Produkt, Technik und Betrieb – soweit zutreffend – die folgenden Punkte:
- Das Inventar benennt Komponenten, Umgebungen, Integrationen und die Grenzen des vereinbarten Umfangs.
- Für Bereitstellungen, Vorfälle und kritische Zugänge sind Haupt- und Vertretungsverantwortliche festgelegt.
- Die Dokumentation ermöglicht Installation, Bereitstellung, Überprüfung und Rücknahme von Änderungen.
- Das neue Team hat seine Zugänge getestet und weiß, wie Geheimnisse sicher verwaltet werden.
- Betriebs- und Diagnoseübungen wurden durchgeführt; für erkannte Lücken gibt es Verantwortliche und einen Plan.
- Bekannte Risiken, externe Abhängigkeiten und offene Aufgaben sind dokumentiert und von den zuständigen Parteien akzeptiert.
Die Übergabe ist wahrscheinlich noch nicht vollständig, wenn nur eine Person das Veröffentlichungsverfahren kennt, niemand sagen kann, wer einen Dienst administriert, die Dokumentation dem tatsächlichen System widerspricht oder unklar ist, wie bei einem Vorfall vorzugehen ist. Auch fehlende, unverzichtbare Administratorrechte sind ein Grund, die Abnahme auszusetzen. Dasselbe gilt, wenn das übernehmende Team Aufgaben übernehmen soll, die nicht Teil der Vereinbarung sind.
Für die Abnahme muss das neue Team weder jedes Detail kennen noch muss jede künftige Arbeit erledigt sein. Es muss innerhalb des vereinbarten Umfangs arbeitsfähig sein, Risiken müssen sichtbar sein und für offene Punkte muss es einen Lösungsweg geben. So hängt die Übergabe nicht mehr von einem einmaligen Termin ab, sondern wird zu einem überprüfbaren Wechsel mit klaren Zuständigkeiten und der tatsächlichen Fähigkeit, das Projekt fortzuführen.