Kernaussage: Subcontracting funktioniert zuverlässig, wenn Kapazität, Verantwortungen und Abnahmeformalitäten vor dem Start klar geregelt sind — nicht später. Ein 48‑Stunden‑Onboarding, verbindliche DoR/DoD und dokumentierte Übergaben vermeiden Überraschungen und sichern Go‑live‑Termine.
Wann Subcontracting wirklich Sinn macht
Subcontracting ist ein operatives Hebelwerkzeug, kein Placebo für schlechte Planung. Es schafft kurzfristige Kapazität, spezielle Skills oder parallele Auslieferungspfade. Entscheidend ist, dass die Einsatzbedingungen vor Beginn deterministisch sind: Kontingent (Monatskapazität) oder Abruf (Ticket/Story‑Basis) müssen mit SLA, Eskalationswegen und Abrechnungslogik vertraglich definiert sein. Fehlt diese Klarheit, entstehen Verantwortungsblindspots zwischen Kunde, integrativem Team und Subcontractor.
Onboarding in 48 Stunden: Was wirklich passieren muss
Ein schnelles Onboarding verlangt eine Checkliste mit minimalem, aber vollständigem Inhalt:
- Ziele & Scope: Konkrete Deliverables, Akzeptanzkriterien, Nicht‑Scope.
- Rollen & Verantwortungen: Wer ist technischer Owner, wer Product Owner, wer Testverantwortlich?
- Zugänge & Tools: Dev‑Repos, CI/CD, Ticketing, Monitoring, Dokumentationsplattform.
- Prozesse: Branching‑Strategie, Release‑Window, Kommunikationskanäle, Eskalationspfad.
- Compliance & Sicherheit: Zugangskontrollen, NDA, Datensicherheitsanforderungen.
Diese Punkte sind in einem One‑Pager plus kurzen technischen Runbook zu dokumentieren. Prüfung: Subcontractor kann innerhalb der 48 Stunden einen einfachen Commit und einen erfolgreichen CI‑Build vorweisen.
Qualität: Definition of Ready / Definition of Done, Controls, Nachweise
Qualität lässt sich nur über klare, messbare Kriterien steuern:
- Definition of Ready (DoR): Welche Vorbedingungen muss eine Aufgabe erfüllen, bevor Arbeit beginnt? Beispiel: Akzeptanzkriterien, Testdaten vorhanden, Ticket verlinkt.
- Definition of Done (DoD): Was ist minimal notwendig, um ein Increment als geliefert zu betrachten? Unit‑Tests, Code‑Review, Pipeline‑Grün, Deploy‑Skript, Release‑Note.
- Controls: Gatekeeping durch automatisierte Checks (Linting, Security‑Scans), mandatory Code Reviews, Sign‑offs für Produktionsdeploys.
- Nachweise: Jeder Abschluss wird mit Artefakten belegt: Build‑Artifact, Test‑Report, Migrationsskript, Übergabeprotokoll.
Ohne diese Nachweise entstehen teure Rückfragen beim Kunden und Verzögerungen im Go‑live.
Transparentes Reporting und Kommunikationsrhythmus
Reporting muss für zwei Zielgruppen funktionieren: die Projektleitung (Steuerungsdaten) und der Kunde (Outcome).
- Tägliche/zweimal wöchentliche Kurzstände: Blocker, Fortschritt gegen Milestones, Risikobewertung.
- Wöchentliche Statusreports: offene Tickets, Durchsatz (Stories/Tasks), Defect‑Trends, Deployment‑Status.
- Quarterly/Meilenstein‑Reviews: Retrospektive, Lessons Learned, Capacity Forecast.
Reporting darf nicht in manuellen Excel‑Reports ersticken: APIs der Ticketsysteme, automatisierte Dashboards und ein klar definierter Zugriff für Stakeholder sind Pflicht.
Häufige Stolpersteine und operative Fragen vor dem Go‑live
- Unklare Ownership bei Fehlern: Wer rollt Rollbacks? Festlegen, wer Production‑Runbook und Eskalationskette betreut.
- Unterschiedliche Dev‑Standards: Inkonsistente Code‑Styles, fehlende Security‑Scans — zwingend harmonisieren vor Merge.
- Integrationstests fehlen: Subcontractor liefert Komponenten, die lokal funktionieren, aber nicht im Integrations-Environment. End‑to‑end Tests und Schnittstellentests sind Voraussetzung.
- Zugangsbeschränkungen: Verzögerte VPN/Key‑Freigaben blockieren Timelines — frühzeitig beantragen.
- Wissenstransfer lückenhaft: Kein dokumentiertes Onboarding führt zu „Bus‑Factor“. Pairing‑Sessions und Recorded Walkthroughs reduzieren Risiko.
- Betriebsschnittstelle unklar: Wer übernimmt Monitoring‑Alarme, On‑Call? SLAs für Mean Time to Acknowledge/Resolve müssen bestehen.
- Compliance & Daten: Testdaten mit Produktionsdaten vermischen ist häufig verboten — legen Sie anonymisierte Datensätze oder synthetische Generatoren fest.
Entscheidungen, die Kosten und Risiken steuern
- Kontingent vs. Abruf: Kontingente sichern planbare Kapazität und Festpreise; Abruf ist flexibler, kann aber höhere Taktkosten verursachen. Wählen, was Budget‑ und Planungsrhythmus am besten unterstützt.
- Contractualise DoR/DoD: Nehmen Sie DoR/DoD als vertragliche Anlage auf — das minimiert Diskussionen bei Abnahmen.
- Automatisierungsgrad vorgeben: CI/CD, Tests, Deploys — ein Minimum an Automatisierung reduziert Go‑live‑Risiko drastisch; fordern Sie es ein.
- Release‑Fenster und Feature‑Toggles: Für risikoreiche Features Feature‑Toggles und schmale, getestete Releases vereinbaren.
- On‑Call & Securitiy Escalation: Legen Sie zeitlich begrenzte On‑Call‑Verpflichtungen für Subcontractor fest; versehen Sie kritische Pfade mit schnellen Eskalationsregelsätzen.
Übergabe und Go‑live: konkrete Checklisten
Vor dem Go‑live bestehen drei unverrückbare Gates:
- Pre‑Integration: Komponenten erfolgreich im Integrations‑Environment, automatisierte Tests grün.
- Release Readiness: Release‑Artifact verfügbar, Rollback‑Plan dokumentiert, DBA‑/Ops‑Checks durchgeführt.
- Go‑live‑Fenster: Verantwortlicher für Deployment anwesend, Monitoring aktiviert, Kommunikationsplan zum Kunden steht.
Jedes Gate wird mit einem kurzen Übergabeprotokoll (Wer, Was, Wann, Beleg/Artefakt) abgestempelt.
14–30‑Tage‑Plan (nummerierte Schritte)
Tag 0–2: Onboarding (48 h)
- One‑Pager: Scope, Rollen, Zugangsliste, Tools.
- Technischer Runbook‑Check: Commit + erfolgreicher CI‑Build.
Tag 3–7: Einrichtung und Harmonisierung
- Zugänge, Branching‑Strategie, Linter, Security‑Scans konfigurieren.
- Erstes Pairing: Subcontractor + Integrations‑Owner, Knowledge‑Transfer aufnehmen.
Tag 8–14: Implementierungsphase & Automatisierung
- Implementieren von DoR/DoD in Ticketsystem.
- CI/CD‑Pipeline mit Unit‑ und Integrationstests lauffähig.
- Monitoringsensitivität und Alerts definieren.
Tag 15–18: Integrationstests und Stabilisierung
- End‑to‑end Tests, Schnittstellentests, Lasttests in Staging.
- Defect‑Triagen, Fixes und erneute Testläufe.
Tag 19–22: Release Readiness
- Release‑Artifact fertig, Rollback‑Plan, Runbooks final.
- Sicherheits‑ und Compliance‑Checks abgeschlossen.
- Stakeholder‑Go/No‑Go‑Meeting ansetzen.
Tag 23–25: Go‑live‑Fenster
- Deployment durchführbar, On‑Call‑Ressourcen bereit.
- Live‑Monitoring aktiviert, Kommunikationsplan an Kunde.
- Erstes 4‑stündiges Beobachtungsfenster nach Deploy.
Tag 26–30: Stabilisierung und Übergabe
- Stabilitäts‑Review, Post‑Go‑live‑Report, Lessons Learned.
- Wissensübergabe und Dokumentation abschliessen.
- Übergabe in den regulären Betrieb inkl. SLAs und Reporting‑Zyklus.
Fazit: Subcontracting liefert zuverlässig, wenn Sie vor Start klar regeln: Scope, DoR/DoD, Automatisierung und die Betriebsschnittstelle. Kurzfristige Onboardings gelingen mit einer festen Checkliste und einem messbaren Commit‑Beleg innerhalb 48 Stunden — so bleiben Termine kalkulierbar und Abnahmen reproduzierbar.
