Orchestrator/bahn/project-audit/analysis/team-reorganisation.md

Team-Reorganisation pathOS — Optionen und Bewertung

Stand: 2026-04-30 | Status: Entwurf zur Diskussion

---

1. Ausgangslage

Aktuelle Struktur (seit PI 39)

Team	Personen	Verantwortung	Services
Team 404	~10	Portal UI + Middleware	2 Services (68K LoC)
Team CIB	~13	Prozesse, Backend	~15 Services (122K LoC), Camunda
Team Zero	~9	TAF/TAP Schnittstellen	~9 Services (38K LoC)
OPs Squad	2 fest + rotierend	Infrastruktur, Betrieb	Infra-Repos, Deployment
DevOps	~7	CI/CD, Tooling	Pipelines, Helm, Monitoring
BSSUPPORT	?	2nd Level Support	—

Probleme der aktuellen Struktur

1. SPOF: Jan Lubenow (39% DevOps), Steven Meixner (Zero + OPs)
2. Ungleiche Last: CIB hat 15 Services + Camunda + Abrechnung, Zero hat 9 Services aber rotiert staendig in OPs
3. Bug-Qualitaet: 404 hat 33% Bug-Rate — systematisches Problem, nicht personenbezogen
4. OPs-Rotation belastet Zero: 3 von 5 Rotatoren kommen aus Zero
5. Abhaengigkeiten: CIB braucht 404 fuer Portal-Features, Zero braucht CIB fuer Prozess-Aenderungen
6. Kein klarer Feature-Owner: Wer ist verantwortlich fuer ein Feature das Portal + Backend + Schnittstelle braucht?

---

2. Ziele der Reorganisation

Primaere Ziele

• Schnelle Umsetzungsgeschwindigkeit
• Weniger Komplexitaet
• Weniger Abhaengigkeiten zwischen Teams
• Bessere Qualitaet
• Bessere Verantwortlichkeit (Ownership)

Nachrangige Ziele

• Entwickler, BAs, POs, Scrummaster/TeamCoaches staerkenorientiert einsetzen
• Wissen breiter verteilen (SPOF abbauen)
• Flexibilitaet bei wechselnden Prioritaeten

---

3. Option A: OpsDev + Feature-Pool

Modell

┌─────────────────────────────────────────────────────────┐
│  OpsDev Team (permanent, ~8-10 Personen)                │
│  Lead: OpsDev-Lead (kein PO)                            │
│  Aufgaben: Betrieb, Bugs, kleine Features, Monitoring   │
│  Besetzung: 2 feste Ops + rotierende Devs aus Pool      │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│  Feature-Pool (~20-25 Personen)                         │
│  Entwickler + BAs + Feature-POs                         │
│                                                         │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐              │
│  │Feature A │  │Feature B │  │Feature C │  ...          │
│  │3-5 Pers. │  │3-5 Pers. │  │3-5 Pers. │              │
│  │PO + Devs │  │PO + Devs │  │PO + Devs │              │
│  └──────────┘  └──────────┘  └──────────┘              │
│                                                         │
│  Nach Feature-Abschluss: 1 Dev → OpsDev (Hypercare)     │
└─────────────────────────────────────────────────────────┘

Vorteile

• Klare Verantwortung: Feature-Team ownt das Feature end-to-end (Portal + Backend + Schnittstelle)
• Keine Cross-Team-Abhaengigkeiten fuer Features: Ein Team macht alles
• Flexibilitaet: Pool kann nach Prioritaet umgeschichtet werden
• Wissenstransfer: Hypercare-Phase zwingt Feature-Devs in den Betrieb
• Qualitaet: Wer baut, betreibt (You build it, you run it — zeitversetzt)

Nachteile

• Kontextwechsel: Entwickler muessen mehrere Services kennen (Portal + Backend + CI)
• Onboarding-Aufwand: Jedes Feature-Team braucht Einarbeitung in fremde Codebasis
• Kein stabiles Team: Teambildung leidet wenn Teams staendig neu zusammengesetzt werden
• OpsDev wird Muellhalde: Alle Bugs landen dort, kein Ownership fuer Ursachenbekaempfung
• PO-Overhead: Jedes Feature braucht einen PO — bei 3-4 parallelen Features braucht man 3-4 POs
• Risiko: Wenn Feature-Teams aufgeloest werden, geht Wissen verloren

Bewertung gegenueber Zielen

Ziel	Bewertung	Begruendung
Geschwindigkeit	⭐⭐⭐⭐	Feature-Teams koennen autonom liefern
Weniger Komplexitaet	⭐⭐	Pool-Management ist selbst komplex
Weniger Abhaengigkeiten	⭐⭐⭐⭐⭐	Feature-Team hat alles was es braucht
Bessere Qualitaet	⭐⭐⭐	Hypercare hilft, aber kein langfristiger Code-Owner
Bessere Verantwortlichkeit	⭐⭐⭐	Gut fuer Features, schlecht fuer langfristige Service-Pflege

---

4. Option B: Fachlicher Schnitt in 2 Teams

Moegliche Schnitte

B1: Bestellung vs. Abwicklung

Team "Bestellen"                    Team "Abwickeln"
─────────────────                   ─────────────────
Portal UI + MW                      Steuerung Vertrieb (Camunda)
Common Interface (Eingang)          Auftrags-Verwaltung
Stammdaten-Bereitstellung           IFP-Connector
Kundendaten-Bereitstellung          Vertragsdaten-Verteiler
TAF/TAP-TDM-Konverter              Archivierungsservice
                                    Abrechnung/AC-Anbindung

Fokus: Alles was der Kunde          Fokus: Alles was nach der
sieht und eingibt                   Bestellung passiert

Vorteile B1:

• Klarer Kundenfokus im Team "Bestellen" (Portal + Schnittstelle = Kundenkontakt)
• Team "Abwickeln" kann sich auf Prozess-Korrektheit konzentrieren (Camunda, Abrechnung)
• Natuerliche Grenze: Bestellung ist abgeschickt → Uebergabe an Abwicklung

Nachteile B1:

• SV (93K LoC, 2214 Smells) ist ein Monolith — schwer zu teilen
• Aenderungswesen (NAÄ) betrifft BEIDE Teams (Kunde bekommt Aenderung UND Prozess muss reagieren)
• Team "Bestellen" hat Portal + CI + Stammdaten — sehr heterogener Tech-Stack (Angular + Java + SOAP)

B2: Netzfahrplan vs. Gelegenheitsverkehr

Team "Netzfahrplan"                 Team "GelV + ujBau"
─────────────────                   ─────────────────
NEP1/NEP2 Prozesse                  Gelegenheitsverkehr
Langfristige Bestellungen           Click&Ride
Koordinierungsverfahren             ujBau (Baufahrplan)
Kapazitaetsmanagement               Ad-hoc Verkehre
                                    Kurzfristige Aenderungen

Vorteile B2:

• Fachlich sauberer Schnitt (unterschiedliche Fristen, Prozesse, Kunden)
• GelV hat andere Anforderungen (Geschwindigkeit) als Netzfahrplan (Korrektheit)
• Passt zu den TTT-Meilensteinen (NEP2 vs. GelV sind separate Streams)

Nachteile B2:

• Technisch teilen sich beide denselben Code (SV, Portal, CI) — kein sauberer Service-Schnitt
• Kleine Features betreffen oft beide Bereiche
• GelV-Team waere deutlich kleiner (weniger Volumen)
• NAÄ und Abrechnung betreffen beide

B3: Extern (Kundenschnittstelle) vs. Intern (Prozesse)

Team "Aussen" (Kundenkontakt)      Team "Innen" (Prozesse)
─────────────────                   ─────────────────
Portal UI + MW                      Steuerung Vertrieb
Common Interface                    Auftrags-Verwaltung
Click&Ride                          IFP-Connector
Stammdaten (fuer Kunden)            Vertragsdaten-Verteiler
BSSUPPORT (2nd Level)               Archivierungsservice
                                    Monitoring/Alerting

Fokus: Alles was Kunden             Fokus: Alles was intern
sehen und nutzen                    verarbeitet wird

Vorteile B3:

• Aehnlich wie B1, aber mit Support integriert → schnellere Bug-Behebung
• Team "Aussen" kann Kundenfeedback direkt umsetzen
• Team "Innen" kann sich auf Korrektheit und Performance konzentrieren

Nachteile B3:

• Gleiche Probleme wie B1 (NAÄ betrifft beide, SV ist Monolith)
• Support im Team "Aussen" bindet Kapazitaet

B4: Domäne "Trasse" vs. Domäne "Vertrag"

Team "Trasse"                       Team "Vertrag"
─────────────────                   ─────────────────
Trassenanmeldung (Portal+CI)        Angebot + Vertrag (SV)
Trassenkonstruktion (IFP)           Abrechnung
Stammdaten                          Stornierung
TAF/TAP Konvertierung               Rahmenvertraege
                                    Vertragsdaten-Verteiler

Fokus: Vom Kundenwunsch             Fokus: Vom Angebot bis
bis zum Konstruktionsauftrag        zur Rechnung

Vorteile B4:

• Sauberster fachlicher Schnitt entlang des Geschaeftsprozesses
• Klare Uebergabe: Trasse ist konstruiert → Vertrag wird erstellt
• Abrechnung (das groesste Risiko) hat ein dediziertes Team
• Passt zur INB-Struktur (Bestellung vs. Entgelt)

Nachteile B4:

• SV muesste aufgeteilt werden (Bestelleingang vs. Vertragsabschluss) — technisch schwierig
• Portal zeigt sowohl Bestellungen als auch Vertraege — wo gehoert es hin?
• Aenderungswesen (NAÄ) ist ein Querschnittsthema

---

5. Option C: Hybridmodell (OpsDev + 2 fachliche Teams)

Modell

┌─────────────────────────────────────────────────────────┐
│  OpsDev Team (~6 Personen, permanent)                   │
│  Lead: OpsDev-Lead                                      │
│  Betrieb, Deployment, Monitoring, Infrastruktur         │
│  Bug-Triage (weist Bugs an fachliche Teams zu)          │
└─────────────────────────────────────────────────────────┘

┌──────────────────────────┐  ┌──────────────────────────┐
│  Team "Bestellen"        │  │  Team "Verarbeiten"      │
│  ~12 Personen            │  │  ~12 Personen            │
│  PO + BA + Devs          │  │  PO + BA + Devs          │
│                          │  │                          │
│  Portal UI + MW          │  │  Steuerung Vertrieb      │
│  Common Interface        │  │  Auftrags-Verwaltung     │
│  Stammdaten              │  │  IFP-Connector           │
│  Kundendaten             │  │  Archivierung            │
│  TAF/TAP Konverter       │  │  Vertragsdaten           │
│  Click&Ride              │  │  Abrechnung              │
│                          │  │  Rabattnummern           │
│  Bugs: Portal, CI, STB   │  │  Bugs: SV, AV, IFP      │
└──────────────────────────┘  └──────────────────────────┘

Vorteile

• Klare Ownership: Jedes Team ownt seine Services dauerhaft (kein Wissensverlust)
• OpsDev entlastet: Fachliche Teams fixen ihre eigenen Bugs, OpsDev nur Infrastruktur
• Fachlicher Schnitt: "Bestellen" = Kundenkontakt, "Verarbeiten" = Backend-Prozesse
• Stabile Teams: Teambildung moeglich, Wissen bleibt
• Skalierbar: Bei Bedarf kann ein drittes Team abgespalten werden

Nachteile

• NAÄ/Aenderungswesen: Betrifft beide Teams — braucht Abstimmung
• Portal zeigt Vertragsdaten: Team "Bestellen" muss fuer Anzeige auf Team "Verarbeiten" warten
• SV bleibt Monolith: Gehoert komplett zu "Verarbeiten" — dort konzentriert sich die Komplexitaet

Bewertung gegenueber Zielen

Ziel	Bewertung	Begruendung
Geschwindigkeit	⭐⭐⭐⭐	Zwei autonome Teams + OpsDev
Weniger Komplexitaet	⭐⭐⭐⭐	Klare Zustaendigkeiten, weniger Koordination
Weniger Abhaengigkeiten	⭐⭐⭐	Besser als heute, aber NAÄ bleibt Querschnitt
Bessere Qualitaet	⭐⭐⭐⭐	Ownership = Verantwortung fuer Qualitaet
Bessere Verantwortlichkeit	⭐⭐⭐⭐⭐	Jeder Service hat genau ein Team

---

6. Option D: Spotify-Modell (Squads + Chapters + Guild)

Modell

• Squads (3-4): Feature-orientiert, temporaer zusammengesetzt
• Chapters: Fachliche Heimat (Frontend, Backend, QA, Ops)
• Guild: Uebergreifende Themen (Security, Performance, Architektur)

Bewertung

Fuer pathOS mit ~35 Personen ist das Spotify-Modell zu komplex. Es lohnt sich erst ab 50+ Personen. Die Overhead-Kosten (Chapter Leads, Guild Meetings) ueberwiegen den Nutzen.

Nicht empfohlen.

---

7. Gesamtbewertung

Option	Geschwindigkeit	Komplexitaet	Abhaengigkeiten	Qualitaet	Ownership	Empfehlung
A: OpsDev + Pool	⭐⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	Gut fuer Feature-Sprints, schlecht fuer Langfrist
B1: Bestellen/Abwickeln	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	Solide, aber NAÄ-Problem
B4: Trasse/Vertrag	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	Bester fachlicher Schnitt
C: Hybrid (OpsDev + 2)	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Empfohlen
D: Spotify	⭐⭐⭐	⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	Zu komplex fuer 35 Personen

Empfehlung: Option C (Hybrid) mit Elementen aus A

Kernstruktur: OpsDev (permanent) + 2 fachliche Teams (permanent) Element aus A: Fuer grosse Features (GelV, ujBau) temporaer 2-3 Personen aus beiden Teams zusammenziehen → nach Abschluss zurueck + 1 Person in Hypercare

---

8. Hinweise fuer weiteren Research

Zu klaeren

1. SV aufteilen? — Ist der Monolith (93K LoC) technisch teilbar? Oder muss ein Team ihn komplett ownen?
2. NAÄ als Querschnitt — Braucht es ein dediziertes "NAÄ-Feature-Team" (temporaer) oder eine feste Zuordnung?
3. Portal-Ownership — Portal zeigt Daten aus allen Services. Gehoert es zu "Bestellen" oder ist es ein eigener Querschnitt?
4. Abrechnung — Ist AC Trasse ein eigenes Team wert? Oder bleibt es bei "Verarbeiten"?
5. Personelle Passung — Wer kann/will wohin? Staerken-Mapping der 35 Personen.
6. Uebergangsphase — Wie lange dauert die Umstellung? Produktivitaetsverlust waehrend Transition?
7. PO-Struktur — 1 PO pro Team oder 1 uebergreifender PO + Feature-POs?
8. Metriken — Wie messen wir ob die Reorg erfolgreich war? (Bug-Rate, Durchlaufzeit, Deployment-Frequenz)

Daten die noch fehlen

• Git-Contributions pro Person/Service (wer kennt welchen Code?)
• Abhaengigkeits-Graph zwischen Services (Kafka-Topics, REST-Calls)
• Kundenfeedback: Welche Features werden am meisten nachgefragt?
• Camunda-Prozess-Instanzen: Wie oft laeuft welcher Prozess?

---

9. Faktor TrassenOrder (Team TraPo)

Was ist TrassenOrder?

• Neues Produkt innerhalb SAB (gleiche Einheit wie pathOS)
• Zweck: Modernisiert den Bestellprozess fuer Gelegenheitsverkehr — medienbruchfreier Workflow
• Entwicklungsstart: Januar 2026
• Livegang: voraussichtlich Q4 2026
• Phase: EXPLORE
• Team: TraPo (eigenes Team in SAB)
• Jira: TRAPO-Projekt (systelone)

Ueberschneidung mit pathOS

• pathOS hat bereits Click&Ride (Anlage 4.2.2 INB) fuer kurzfristigen GelV
• ADR-72 (Click&Ride Anbindung) ist ein aktives CIB-Thema
• GelV-Erweiterungen sind ein TTT-Meilenstein (ab Sep 2026)
• TrassenOrder adressiert denselben Bereich — aber als separates Produkt

Implikationen fuer die Reorganisation

Fragen die geklaert werden muessen:

1. Abgrenzung: Was macht TrassenOrder, was macht pathOS/Click&Ride? Gibt es eine klare Grenze oder Ueberlappung?
2. Integration: Wird TrassenOrder ein Frontend fuer pathOS-Backend? Oder ein komplett separates System?
3. Team-Zuordnung: Gehoert GelV kuenftig zu TraPo oder zu pathOS? Oder beides?
4. Schnittstelle: Braucht pathOS eine API fuer TrassenOrder? Wer baut/pflegt die?
5. Kannibalisierung: Ersetzt TrassenOrder langfristig Click&Ride?

Auswirkung auf Optionen:

• Option A (Pool): TrassenOrder-Devs koennten Teil des Pools sein
• Option B (2 Teams): GelV-Schnitt (B2) wird fragwuerdig wenn TrassenOrder GelV uebernimmt
• Option C (Hybrid): Team "Bestellen" muesste Schnittstelle zu TrassenOrder definieren
• Generell: Wenn TrassenOrder den GelV-Bereich uebernimmt, kann sich pathOS auf Netzfahrplan + ujBau konzentrieren — das vereinfacht den fachlichen Schnitt erheblich

Empfehlung

Vor der Reorg-Entscheidung unbedingt mit TraPo-Team abstimmen:

• Roadmap-Abgleich (was baut wer bis wann?)
• Schnittstellen-Definition (API-Vertrag zwischen pathOS und TrassenOrder)
• Langfristige Vision: Ein System oder zwei?