Eine Projektübernahme ist gelungen, wenn das neue Team bauen, veröffentlichen und betreiben kann, ohne auf undokumentierten Zugang des bisherigen Lieferanten angewiesen zu sein.
Eine Projektübernahme ist gelungen, wenn das neue Team bauen, veröffentlichen und betreiben kann, ohne auf undokumentierten Zugang des bisherigen Lieferanten angewiesen zu sein. Das Repository ist nur ein Teil der Übergabe. Beweisen Sie Fähigkeiten schrittweise und erhalten Sie währenddessen den laufenden Betrieb.
Eigentum und Zugänge klären
Inventarisieren Sie Repositories, Domains, Cloud-Konten, Zahlungsanbieter, App-Stores und Monitoring. Prüfen Sie Organisationszugehörigkeit und Wiederherstellungszugang sowie relevante Lizenzen und Verträge. Verwenden Sie persönliche Berechtigungen und geregelte Übertragung. Gemeinsame Passwörter oder Produktionsgeheimnisse gehören nicht in ein allgemein zugängliches Übergabedokument.
Lieferung und Betrieb reproduzieren
Das neue Team soll aus der Anleitung bauen, zentrale Prüfungen ausführen und in eine sichere Umgebung veröffentlichen. Erfassen Sie fehlende Schritte, Migrationen, Hintergrundjobs und Rückfallverfahren, solange das alte Team erreichbar ist. Gehen Sie eine wichtige Nutzerreise, bekannte Vorfälle und wiederkehrende manuelle Aufgaben gemeinsam durch. Ein lokaler Build beweist keine Betriebsfähigkeit.
Stufenweise abnehmen
Nutzen Sie Zugangsprüfung, reproduzierbares Deployment, Wiederherstellungsübung und Fehlerregister als Nachweise. Entfernen oder rotieren Sie alte Zugänge erst nach verifiziertem Ersatz gemäß Übergangsplan. Halten Sie Stabilisierung und neue Funktionszusagen getrennt, bis das System verstanden ist. Ein begrenzter Überlappungszeitraum mit klaren Zuständigkeiten ist belastbarer als das offene Versprechen, später Fragen zu beantworten.
Ein konkreter Abnahmetest
Lassen Sie eine Person des neuen Teams eine harmlose Änderung vom frischen Checkout bis zur Testumgebung bringen, ohne mündliche Zusatzanweisungen. Jede fehlende Variable, nicht dokumentierte Freigabe oder unbekannte Aufgabe wird zum Übergabepunkt. Danach soll eine zweite Person anhand der Anleitung den vorherigen Stand wiederherstellen. Halten Sie Ergebnisse und benötigte Rechte fest. Damit prüfen Sie sowohl technische Reproduzierbarkeit als auch Wissensverteilung. Eine erfolgreiche Demonstration durch den bisherigen Hauptentwickler allein genügt dafür nicht, weil sie dessen stillschweigendes Wissen und persönliche Zugänge verdecken kann.
- Passende Leistung
- Warum das MVP langsam ist: eine Diagnosefolge
- Softwareprojekt retten: ein Plan für die ersten zwei Wochen
Häufige Fragen
Genügt Repositoryzugriff?
Für eine erste Untersuchung, nicht für vollständigen Betrieb.
Sofort alle Geheimnisse rotieren?
Geplant und nach Prüfung des Ersatzes, damit abhängige Dienste nicht ausfallen.
Was ohne bisherige Agentur?
Lieferungs- und Betriebswege aus Belegen rekonstruieren und Unsicherheiten offen halten.
Beweist Zugriff das Eigentum?
Nein. Vertragliche und organisatorische Eigentumsfragen müssen gesondert geklärt werden.
Wann ist die Übergabe fertig?
Wenn vereinbarte Fähigkeiten demonstriert und Restpunkte verantwortet sind.
Vom Vorhaben zu einem umsetzbaren Umfang
Teilen Sie Nutzerablauf, Schnittstellen und Rahmenbedingungen. Gemeinsam klären wir den Umfang und erstellen eine Schätzung mit Annahmen und Ausschlüssen.
Weiterführend
Warum das MVP langsam ist: eine Diagnosefolge
Ein langsames MVP braucht zuerst eine messbare Diagnose.
Softwareprojekt retten: ein Plan für die ersten zwei Wochen
Die ersten zwei Wochen einer Projektrettung sollen ein glaubwürdiges Lagebild und eine tragfähige nächste Entscheidung liefern.
MVP refaktorieren oder neu schreiben?
Refactoring und Neuentwicklung unterscheiden sich vor allem in Übergangs- und Lieferungsrisiken.