Softwareprojekt übernehmen: So lösen Sie sich von einem Dienstleister, der nicht liefert
Mit KI zusammenfassen
Zusammenfassung lesen
- Die Übernahme eines Softwareprojekts ist in erster Linie keine technische Aufgabe. Sie ist eine Operation zur Wissenssicherung, und ob der scheidende Dienstleister ein Interesse an voller Kooperation hat, ist nicht garantiert, selbst wenn man sich halbwegs im Guten trennt.
- Die Arbeit gliedert sich in drei Phasen: Sichern (das Wissen des scheidenden Dienstleisters), Stabilisieren (die Delivery während der Überlappung) und Übergeben (die volle Verantwortung an das neue Team).
- Die Bestandsaufnahme von Zugängen und geistigem Eigentum muss abgeschlossen sein, bevor die Zusammenarbeit offiziell endet. Sie ist der einzige Arbeitsstrang, der sich nicht aufschieben lässt.
- Die Abnahme ist ein klar definiertes Ereignis, nicht das Gefühl, „größtenteils fertig“ zu sein. Ohne ausdrückliche Abnahmekriterien zieht sich eine Übernahme unbemerkt über Monate hin, und keines der beiden Teams trägt die volle Verantwortung.
Die Entscheidung, sich von einem Dienstleister zu trennen, fällt meist in einem einzigen Meeting, nachdem monatelang aufgestauter Frust endgültig eine Schwelle überschritten hat: eine verpasste Deadline, die einen Kunden gekostet hat, eine Sicherheitsfrage, die niemand beantworten konnte, eine Rechnung für Arbeit, an deren Freigabe sich niemand erinnert. Was in diesem Meeting fast nie entschieden wird: was in den Wochen direkt danach passiert.
Die Übernahme eines Softwareprojekts ist eine Operation zur Wissenssicherung, über der gleichzeitig ein Vertragsverhältnis und eine Lieferverpflichtung laufen. Das größte Risiko ist selten technisch. Es liegt im Verhalten: Ein Dienstleister, der spürt, dass seine Tage gezählt sind, bleibt nicht immer voll kooperativ.
Die drei Phasen einer kontrollierten Übernahme
Eine gut geführte Übernahme durchläuft drei klar getrennte Phasen: Sichern, Stabilisieren, Übergeben. Jede Phase hat eine andere verantwortliche Person und ein anderes Tempo, und jede scheitert auf ihre eigene Weise, wenn sie übersprungen oder überhastet wird.
Phase 1 (Sichern): Wissen und Assets herausholen, bevor die Zusammenarbeit endet
Das Sichern umfasst vier Arbeitsstränge: Zugänge, Code, Infrastruktur und Dokumentation. Alle vier müssen im selben Zeitfenster laufen, weil sie von derselben Voraussetzung abhängen: einem Dienstleister, der vertraglich noch zur Mitwirkung verpflichtet ist.
Zugänge heißt: eine vollständige, geprüfte Bestandsaufnahme aller Zugangsdaten, Repositories, Drittanbieter-Konten, Domain-Registrierungen und Signaturschlüssel, die mit dem System verbunden sind. Code heißt: Quellcode, abgeglichen mit dem, was tatsächlich in der Produktion läuft, nicht mit dem, was laut Repository des Dienstleisters aktuell ist. Infrastruktur heißt: die Deployment-Pipeline, die Hosting-Konfiguration und das eingeübte Betriebswissen darüber, wie Releases wirklich ablaufen. Dokumentation heißt: alles, was existieren sollte, aber oft fehlt, einschließlich eines Registers der technischen Schulden, das jede Abkürzung benennt, von der das aktuelle Team weiß.
Phase 2 (Stabilisieren): Shadowing und gesteuerte Überlappung statt eines glatten Übergabetermins
Eine gesteuerte Überlappung, in der das neue Team neben dem scheidenden arbeitet, statt nur zu lesen, was dieses hinterlassen hat, gibt es aus einem Grund: Dokumentation hält Entscheidungen fest, aber kein Urteilsvermögen. Wie lang diese Phase dauert, sollte sich nach der Komplexität des Systems richten, nicht danach, wie schnell die Führungsebene den alten Dienstleister loswerden will.
Phase 3 (Übergeben): Die Abnahme ist ein Ereignis, kein Gefühl
Für die Abnahme braucht es ausdrückliche, schriftliche Kriterien, die vor Beginn des Übergangs vereinbart werden. Sinnvolle Kriterien sind zum Beispiel: Das neue Team hat selbstständig ein Release ausgerollt, mindestens einen Incident in der Produktion gelöst, ohne an das scheidende Team zu eskalieren, und jeder Posten in der Bestandsaufnahme von Zugängen und geistigem Eigentum ist nachweislich rotiert oder übertragen.
Was, wenn der scheidende Dienstleister nicht kooperiert?
Die Bestandsaufnahme von Zugängen und geistigem Eigentum ist der einzige Arbeitsstrang, der überhaupt nicht von Kooperation abhängt. Sie sollte abgeschlossen sein, bevor der Dienstleister erfährt, dass die Zusammenarbeit endet. Code und Infrastruktur zu sichern ist ohne Kooperation schwieriger, aber nicht unmöglich: Eine Codebasis lässt sich per Reverse Engineering aus dem Code selbst und aus dem Verhalten in der Produktion erschließen.
| Arbeitsstrang | Phase | Wenn der Dienstleister kooperiert | Wenn der Dienstleister nicht kooperiert |
|---|---|---|---|
| Bestandsaufnahme von Zugängen und geistigem Eigentum | Sichern | Der Dienstleister bestätigt die Zugangsdaten und übergibt sie direkt | Rekonstruiert aus Abrechnungsunterlagen, DNS und Kontoinhaberschaft |
| Code (abgeglichen mit der Produktion) | Sichern | Der Dienstleister gewährt Zugriff auf das Repository und bestätigt, dass es der Produktion entspricht | Aus der laufenden Produktion gezogen und per Reverse Engineering erschlossen |
| Infrastruktur und Deployment | Sichern | Walkthrough durch Pipeline, Umgebungen und Release-Prozess | Rekonstruiert aus der Konfiguration beim Hosting-Anbieter |
| Dokumentation und Register der technischen Schulden | Sichern | Der Dienstleister dokumentiert bekannte Probleme und Architekturentscheidungen | Unabhängig erstellt durch Code-Review und Analyse des Systemverhaltens |
| Shadowing und gesteuerte Überlappung | Stabilisieren | Zwei bis sechs Wochen gemeinsamer Betrieb | Nicht möglich; ersetzt durch eine längere, vorsichtigere Stabilisierung im Alleingang |
| Abnahme und Freigabe | Übergeben | Formelle Freigabe, bei der der scheidende Dienstleister den Abschluss bestätigt | Freigabe allein auf Basis der unabhängigen Prüfung durch das neue Team |
Wie lange dauert die Übernahme eines Softwareprojekts wirklich?
Der gesamte Ablauf dauert in der Regel fünf bis zwölf Wochen: fünf bis zehn Werktage für den Readiness-Check vor dem Wechsel, zwei bis sechs Wochen für Wissenssicherung und Shadowing und zwei bis vier Wochen für die Einarbeitung des neuen Teams. Ein einfaches System mit einem kooperativen scheidenden Dienstleister kommt mit dem unteren Ende aus. Bei einem großen, schlecht dokumentierten System und einem unkooperativen Dienstleister kann es realistischerweise deutlich länger als zwölf Wochen dauern.
Sie lesen Intelvision öfter? Fügen Sie uns in der Google-Suche als bevorzugte Quelle hinzu.
Zu bevorzugten Quellen hinzufügen