Der Quellcode liegt vor, die Rechnung ist bezahlt, das Projekt scheint übergeben. Erst beim nächsten Update merkt das neue Team: Eine benötigte Komponente fehlt, der Build funktioniert nur auf einem alten Rechner oder niemand weiß, welche Datenmigration zur produktiven Version gehört. Formale Vollständigkeit und praktische Übernehmbarkeit sind unterschiedliche Dinge.
Eine gute technische Übergabe beantwortet deshalb eine konkrete Frage: Kann eine andere berechtigte Person mit den vereinbarten Unterlagen die Anwendung nachvollziehbar bereitstellen, prüfen und weiterbearbeiten? Das lässt sich erproben. Dafür muss nicht jeder interne Gedanke dokumentiert sein.
Zuerst festlegen, was übernommen werden soll
Ein Teamwechsel innerhalb desselben Dienstleisters braucht einen anderen Umfang als die Übernahme von Entwicklung und Betrieb durch einen neuen Anbieter. Vereinbaren Sie das Ziel früh: Nur Weiterentwicklung? Auch Hosting, Datensicherung und Störungsbearbeitung? Wird die bestehende Infrastruktur weitergenutzt oder eine neue aufgebaut?
Davon hängen die benötigten Unterlagen und Zugänge ab. Rechte an kundenspezifischem Code, Bibliotheken, Lizenzen, Repository-Historie und Konten müssen passend zur Vereinbarung geklärt werden. Der technische Wunsch nach einer vollständigen Übergabe ersetzt diese Klärung nicht. Ein öffentlich herunterladbares Paket ist auch kein geeigneter Ort für vertraulichen Code oder Zugangsdaten.
Was ein übernehmendes Team tatsächlich braucht
- Einen bezeichneten Stand: Welche Version läuft produktiv, welcher Repository-Stand gehört dazu und welche Änderungen sind noch nicht ausgeliefert?
- Eine ausführbare Anleitung: Benötigte Werkzeuge und Versionen, Abhängigkeiten, Build, Bereitstellung und grundlegende Funktionsprüfung.
- Konfigurationswissen: Welche Einstellungen werden benötigt, wofür dienen sie und wie werden Geheimnisse sicher bereitgestellt?
- Daten und Übergänge: Datenbankschema, erforderliche Migrationen, Import-/Exportwege und bekannte Einschränkungen.
- Betriebswissen: Protokolle, Überwachung, Sicherung, Wiederherstellung, Rücknahme einer fehlerhaften Auslieferung und zuständige Rollen.
- Offene Arbeit: Bekannte Fehler, ausstehende Entscheidungen und Abhängigkeiten zu Fremdsystemen.
Diese Informationen können in bestehenden Repositories, Tickets und Betriebsunterlagen liegen. Eine neue umfangreiche Dokumentation ist nicht automatisch besser. Entscheidend sind eindeutige Verweise, passende Zugriffsrechte und ein nachvollziehbarer Bezug zum gelieferten Stand.
Ein fiktives Beispiel: Die fehlende Datenmigration
Ein Fachportal soll an ein neues Betreuungsteam übergehen. Der Quellcode lässt sich übersetzen, die Startseite öffnet sich. Bei der ersten Anmeldung scheitert die Anwendung jedoch, weil eine Datenbankänderung bisher von Hand ausgeführt wurde. Die Anleitung enthält diesen Schritt nicht.
Eine Übernahmeprobe in einer isolierten Umgebung macht die Lücke sichtbar, bevor sie den Produktivbetrieb betrifft. Das Team ergänzt den nachvollziehbaren Migrationsweg und führt die Probe erneut aus. Erst danach kann die Übergabe diesen Teil als geprüft ausweisen. Ein kurzer gemeinsamer Bildschirmtermin hätte den Fehler womöglich verdeckt, wenn die ursprüngliche Entwicklerin den fehlenden Schritt beiläufig selbst erledigt hätte.
Die Probe gehört einer zweiten Person
Wählen Sie eine berechtigte technische Person, die die Bereitstellung nicht bereits auswendig kennt. Sie beginnt mit den vereinbarten Unterlagen und einem definierten Ausgangszustand. Rückfragen sind erlaubt und wertvoll: Jede notwendige mündliche Ergänzung zeigt, welches Wissen noch fehlt oder missverständlich beschrieben ist.
Die Probe sollte die Anwendung nicht nur starten. Prüfen Sie einen wesentlichen fachlichen Ablauf und, soweit Teil des Übernahmeumfangs, eine Wiederherstellung aus einer Sicherung. Nutzen Sie dafür eine abgesicherte Testumgebung mit geeigneten Daten. Produktionszugänge gehören in einen dafür vorgesehenen sicheren Übergabekanal, nicht in Tickets oder Anleitungen.
Halten Sie Datum, Version, Umgebung, ausgeführte Schritte, Ergebnis und offene Punkte fest. Ein abweichendes Zielsystem kann zusätzliche Prüfungen benötigen. Eine erfolgreiche lokale Probe bestätigt nicht automatisch jede spätere Kundenumgebung.
Ein konkretes Übergabepaket mit Aufbau, Wiederherstellung und Rückweg beschreibt das fiktive Entwicklungsbeispiel für ein Freigabeportal. Es zeigt auch, was die übernehmende Person selbst prüfen soll.
Die Übergabe passend dosieren
Bei einem kleinen Importwerkzeug kann eine kurze Anleitung mit Testdatei und Fehlerbeispielen ausreichen. Eine geschäftskritische Fachanwendung mit mehreren Schnittstellen benötigt mehr Betriebs- und Wiederherstellungswissen. Der Umfang sollte sich am Schaden eines Ausfalls und am vorgesehenen Empfänger orientieren.
Auch eine sehr gute Übergabe beseitigt Einarbeitung nicht. Fachliche Regeln und historische Entscheidungen brauchen weiterhin Erklärung. Das Ziel ist eine planbare Übernahme mit bekannten Grenzen. Fordern Sie daher keinen pauschalen Anspruch auf sofortige Unabhängigkeit, sondern einen vereinbarten und tatsächlich erprobten Übergabeumfang.
Vor dem Abschluss drei Entscheidungen treffen
Wer nimmt die Übergabe technisch entgegen? Welche Probe gilt als ausreichender Nachweis? Wer schließt verbleibende Lücken bis wann? Klären Sie außerdem den Zeitpunkt, ab dem die neue Stelle für Betrieb oder Weiterentwicklung verantwortlich ist. Bis dahin dürfen Zuständigkeiten nicht stillschweigend zwischen den Beteiligten verschwinden.
Die fachliche Abnahme und die technische Übernahme ergänzen sich. Für die Zeit danach braucht es eine klare Betriebsvereinbarung. Schon während der Entwicklung lässt sich die Übernehmbarkeit durch eine praktisch eingearbeitete Vertretung verbessern.
Was unsere bisherigen Nachweise zeigen
Für einen unserer Prototypen sind ein geprüftes Bereitstellungspaket und eine getrennte Wiederherstellungsprobe dokumentiert. In einem Bestandsprojekt beschreiben die Build-Unterlagen auch benötigte Nachbarsysteme und Betriebsabhängigkeiten. Diese Bausteine helfen einer Übernahme; sie ersetzen nicht die Prüfung durch das tatsächlich übernehmende Team auf dem vereinbarten Stand.
Die Reihe: Softwareprojekte verlässlich beauftragen
- Budget und Restkosten
- Vollständige Abnahme
- Technische Übergabe – dieser Artikel
- Ansprechpartner und Vertretung
- Betrieb und Verantwortung
Zur Übersicht der fünf Projektrisiken und Entscheidungshilfen