Ein Pilot ist kein kostenloser Probelauf und keine verkleinerte Version des gesamten Projekts. Er ist ein bezahlter, klar begrenzter Workstream, der die wichtigsten Annahmen über Zusammenarbeit und technische Delivery unter realen Bedingungen prüft.
Eine echte Aufgabe wählen
Reine Übungsaufgaben zeigen wenig über den späteren Alltag. Der Pilot sollte fachlich relevant sein, sich aber ohne großes Betriebsrisiko abgrenzen lassen. Geeignet sind etwa eine definierte Integration, ein vertikaler Produkt-Schnitt oder die Stabilisierung eines konkreten Release-Engpasses.
Die Aufgabe muss klein genug sein, um Ergebnis und Arbeitsweise innerhalb weniger Wochen bewerten zu können. Gleichzeitig sollte sie Schnittstellen zu realen Systemen und Ansprechpartnern enthalten.
Vorher festlegen, was geprüft wird
Abnahme umfasst mehr als funktionierenden Code. Relevant sind beispielsweise:
- Qualität technischer Rückfragen,
- Sichtbarkeit von Risiken und Fortschritt,
- Verständlichkeit von Entscheidungen,
- Qualität von Reviews und Tests,
- Umgang mit Änderungen und Blockern,
- Zustand von Dokumentation und Übergabe.
Diese Kriterien sollten vor dem Start besprochen werden. Sonst wird der Pilot im Nachhinein nach Bauchgefühl bewertet.
Nicht künstlich abschirmen
Ein Pilot liefert nur dann belastbare Erkenntnis, wenn er unter realistischen Bedingungen stattfindet. Dazu gehören vorhandene Repositories, tatsächliche Build-Checks, relevante Kommunikationswege und eine echte Abnahme auf Kundenseite. Sensible Zugriffe können trotzdem begrenzt und nach Least Privilege vergeben werden.
Eine bewusste Entscheidung treffen
Am Ende stehen drei legitime Ergebnisse: Zusammenarbeit erweitern, mit konkreten Anpassungen fortsetzen oder sauber beenden. Ein guter Partner behandelt auch das dritte Ergebnis professionell und übergibt Code, Wissen und offene Punkte geordnet.