Die Ausgangslage ist häufig dieselbe. Ein Altsystem soll modernisiert werden, das eigene Team kennt das System, hat aber weder Erfahrung mit dem Umbau noch Zeit dafür, und jemand von außen soll helfen. Die Zusammenarbeit läuft ein halbes Jahr, danach ist die Modernisierung fertig.
Und ein Jahr später ist der Zustand wieder derselbe wie vorher, nur mit neuerer Technik. Das Team ändert nichts an den neuen Teilen, weil es sie nicht kennt, und die Person, die sie gebaut hat, ist nicht mehr da.
Dieser Artikel beschreibt, woran das liegt und was dagegen hilft. Ich schreibe ihn als jemand, der die externe Rolle einnimmt; dass ich mir damit Folgeaufträge erschwere, ist mir bewusst und aus meiner Sicht richtig so.
Das Muster, das schiefgeht
Der Ablauf, der zu dem beschriebenen Ergebnis führt, sieht von innen vernünftig aus, und genau das ist das Problem.
Der Externe ist schneller, weil er den Umbau schon oft gemacht hat. Das Team ist mit dem Tagesgeschäft ausgelastet. Also übernimmt der Externe die neuen Teile vollständig, und das Team arbeitet weiter am alten System. Beide Seiten sind zufrieden, weil es vorangeht.
Was dabei entsteht, ist eine zweite Grenze mitten durch das System. Nicht zwischen alt und neu, sondern zwischen „unser Code" und „sein Code". Diese Grenze steht nirgends und ist trotzdem wirksam: Bei einem Fehler im neuen Teil fragt das Team, statt nachzusehen.
Der Test dafür ist einfach und lohnt in jedem laufenden Vorhaben: Wer hat in den letzten vier Wochen etwas an den neuen Teilen geändert? Steht dort nur ein Name, und es ist der externe, dann entsteht gerade ein zweites Wissensmonopol. Es ist nur noch nicht sichtbar, weil die Person ja da ist.
Was Übergabefähigkeit konkret heißt
„Das Team soll es danach können" ist als Ziel zu weich, um danach zu handeln. Vier Kriterien machen es prüfbar, und alle vier lassen sich an einem Nachmittag messen.
Erstens: Jemand aus dem Team kann eine kleine Änderung an einem neuen Teil allein ausrollen. Nicht theoretisch, sondern hat es getan, in den letzten vier Wochen.
Zweitens: Jemand aus dem Team kann die Umgebung von null aufbauen. Ohne Rückfragen, mit der Beschreibung, die im Repository liegt.
Drittens: Für jede größere Entscheidung gibt es eine Begründung, die jemand findet, ohne zu fragen. Warum diese Bibliothek, warum diese Aufteilung, warum nicht der naheliegende Weg.
Viertens: Es gibt niemanden, dessen Abwesenheit das Vorhaben anhält. Auch nicht den Externen. Vor allem nicht den Externen.
Diese vier gehören an den Anfang des Vorhabens, nicht ans Ende. Als Ziel am Ende sind sie eine Absichtserklärung; als Prüfpunkt alle vier Wochen sind sie ein Steuerungsinstrument.
Die Arbeitsteilung, die funktioniert
Die Aufteilung, die in meinen Projekten getragen hat, ist nicht „wir machen es zusammen", weil das zu unbestimmt ist. Sie ist eine Rollenverteilung, die sich im Lauf des Vorhabens verschiebt.
Am Anfang: Der Externe baut, das Team prüft. Die ersten Schritte macht die Person, die sie kennt. Aber jede Änderung wird von jemandem aus dem Team gelesen und freigegeben, und zwar mit dem ausdrücklichen Auftrag, alles zu fragen, was unklar ist. Eine Freigabe ohne Fragen ist an dieser Stelle ein Warnzeichen, kein gutes Zeichen.
In der Mitte: Umgekehrt. Das Team baut, der Externe prüft. Das ist der eigentliche Übergang, und er passiert nicht von selbst; er wird terminiert. In der Praxis ist das der Punkt, an dem das Vorhaben kurz langsamer wird, und diese Verlangsamung ist der Preis für alles danach.
Am Ende: Das Team baut, der Externe ist erreichbar. Die letzten Wochen arbeitet der Externe an etwas anderem und beantwortet Fragen. Wenn in dieser Phase viele Fragen kommen, war der Übergang zu spät. Wenn keine kommen, ist es geschafft.
Die Verschiebung braucht einen Termin im Kalender, sonst findet sie nicht statt. Der Grund ist derselbe wie bei jeder Maßnahme, die kurzfristig Tempo kostet: Sie wird verschoben, solange es gut läuft.
Der Anlass für eine solche Zusammenarbeit ist oft derselbe: Wissen in einer Person ist ein Architekturproblem.
Was bleiben muss, und was nicht
Am Ende eines Vorhabens bleibt etwas zurück, und die Liste ist kürzer, als viele erwarten. Vier Dinge, mehr nicht.
Der Code, im Repository des Kunden. Das klingt selbstverständlich und ist es nicht immer: Ein Skript auf dem Rechner des Externen, das den Bau vorbereitet, gehört genauso dazu wie die Anwendung.
Ein Weg, die Umgebung aufzubauen. Geprüft dadurch, dass jemand aus dem Team es einmal getan hat.
Die Entscheidungen, mit Begründung. Dazu unten mehr, weil das der Teil ist, der am häufigsten fehlt.
Die Zugänge, auf Namen des Kunden. Konten bei Diensten, Schlüssel, Verwaltungszugänge. Ein Konto, das auf die Mailadresse des Externen läuft, ist ein Vorfall, der auf sein Datum wartet.
Was ausdrücklich nicht dazugehört, ist eine Abschlussdokumentation. Ein Dokument, das am Ende eines Vorhabens geschrieben wird, beschreibt einen Zustand, der sich ab der nächsten Woche ändert, und es wird nicht gepflegt. Der Aufwand ist dieselbe Zeit besser in den dritten Punkt gesteckt.
Entscheidungen protokollieren, nicht dokumentieren
Der Unterschied ist der wichtigste Einzelpunkt dieses Artikels. Dokumentation beschreibt, wie etwas funktioniert; das sagt der Code auch. Ein Entscheidungsprotokoll beschreibt, warum es so ist und was verworfen wurde, und das sagt der Code nie.
Praktisch ist das eine Datei je Entscheidung, im Repository, in einer halben Stunde geschrieben, zu dem Zeitpunkt, an dem die Entscheidung fällt.
docs/entscheidungen/2026-10-28-auftragstabelle-statt-sqs.md
# Auftragstabelle statt SQS
Stand: entschieden, 28.10.2026
Beteiligt: Team Plattform, extern
## Situation
Der Export an das Warenwirtschaftssystem laeuft als Cronjob ohne
Wiederholung. Etwa 4.000 Vorgaenge am Tag, Spitzen um 11 Uhr.
## Entscheidung
Auftragstabelle in der bestehenden Datenbank, Arbeiter als Konsolen-
befehl, SKIP LOCKED fuer die Parallelitaet.
## Warum nicht SQS
Wuerde eine zweite Infrastruktur einfuehren, die das Team noch nicht
betreibt. Bei 4.000 Vorgaengen taeglich traegt die Tabelle deutlich.
Der Wechsel bleibt moeglich: die Schnittstelle im Code ist dieselbe.
## Wann wir das revidieren
Wenn die Zahl ueber 100.000 am Tag steigt oder ein zweites System
dieselben Auftraege erzeugt.Der letzte Abschnitt ist der, der den Unterschied macht. Er beantwortet die Frage, die in zwei Jahren gestellt wird, und er nimmt der Entscheidung die Endgültigkeit: Wer die Bedingung kennt, unter der eine Wahl nicht mehr gilt, kann sie später ohne Streit ändern.
Fünf bis fünfzehn solcher Dateien sind für ein Vorhaben dieser Größe normal. Sie ersetzen die Abschlussdokumentation vollständig, und sie werden gelesen, weil sie kurz sind und eine konkrete Frage beantworten.
Wie das Ende eines solchen Auftrags aussieht, wenn keine Abhängigkeit zurückbleibt, steht in Der Übergabetag.
Der Test vor dem Ende
Zwei bis drei Wochen vor dem geplanten Ende lohnt eine Probe, die unangenehm ist und die einzige verlässliche Antwort gibt: Der Externe ist eine Woche nicht erreichbar. Nicht als Test angekündigt, sondern als Abwesenheit eingeplant.
Was in dieser Woche passiert, ist das Ergebnis des Vorhabens. Arbeitet das Team normal weiter, ist die Übergabe erfolgt. Bleibt etwas liegen, gibt es eine Liste von Dingen, die noch zu tun sind, und zwar genau die richtigen.
Diese Woche früh genug zu legen ist der Punkt. Eine Abwesenheit in der letzten Woche liefert dieselbe Erkenntnis und keine Zeit mehr, etwas damit zu machen.
Was in dieser Woche regelmäßig auffällt, sind nicht die großen Dinge. Es ist der Zugang zu einem Dienst, den nur einer hat. Ein Bauschritt, der auf einem bestimmten Rechner läuft. Eine Einstellung, die niemand kennt, weil sie einmal von Hand gesetzt wurde. Alles kleine Dinge, und alle zusammen sind sie der Unterschied zwischen handlungsfähig und blockiert.
Was ein Externer nicht tun sollte
Zum Schluss vier Dinge, die ich in dieser Rolle vermeide, weil sie kurzfristig helfen und langfristig schaden.
Die Betriebsverantwortung übernehmen. Wer die Bereitschaft für ein System übernimmt, das der Kunde betreiben soll, verhindert genau das Lernen, um das es geht. Mitlesen ja, in Vorfällen unterstützen ja, die Verantwortung tragen nein.
Werkzeuge einführen, die nur der Externe kennt. Eine Sprache, ein Framework, eine Infrastruktur, für die es im Team keinen zweiten Kopf gibt. Das ist manchmal trotzdem richtig, und dann gehört es zur Entscheidung, wer im Team es lernt, mit Namen und Termin.
Allein auf einem Zweig arbeiten. Zwei Wochen ohne Zusammenführung heißt zwei Wochen ohne Prüfung durch das Team. Am Ende steht ein Änderungssatz, den niemand liest, und die Freigabe ist eine Formsache.
Die unangenehme Frage vermeiden. Wenn nach drei Monaten niemand aus dem Team etwas an den neuen Teilen geändert hat, gehört das angesprochen, auch wenn das Vorhaben gut läuft. Es ist der Befund, der am Ende darüber entscheidet, ob das Ergebnis dem Kunden gehört.
Wie ich Modernisierungsvorhaben schneide, damit diese Rollenverteilung überhaupt möglich ist, steht auf der Seite zur Legacy-Modernisierung. Und wenn die Frage eher lautet, wer ein bestehendes PHP-System überhaupt übernimmt: dazu gibt es eine eigene Seite.
Dieser Artikel gehört zu einer Reihe über Systeme, die es schon gibt. Der Rückblick ordnet alle Artikel der Reihe nach Anlass.
