Orchestrator/bahn/Analyse-O2C-C2S/sources/o2c/O2C-Einfachbahn/25-Team-Reorganisation-Optionen.md

25. Team-Reorganisation (Optionen)

Version: 3 | Last modified: 2026-05-07T14:47:08.689+02:00 Source: confluence page ID 586386850

---

Team-Reorganisation pathOS — Optionen und Bewertung Stand: 2026-04-30 | Status: Entwurf zur Diskussion

Dieses Dokument analysiert Optionen fuer die Neuaufstellung der pathOS-Teams. Ziele: Schnellere Umsetzung, weniger Komplexitaet, bessere Qualitaet und Verantwortlichkeit.

Ausgangslage

Team | Personen | Verantwortung | Services | Problem |

Team 404 | ~10 | Portal UI + Middleware | 2 (68K LoC) | 33% Bug-Rate, steigend |

Team CIB | ~13 | Prozesse, Backend, Camunda | ~15 (122K LoC) | SV-Monolith (93K, 2214 Smells) |

Team Zero | ~9 | TAF/TAP Schnittstellen | ~9 (38K LoC) | OPs-Rotation belastet |

OPs Squad | 2 fest + rot. | Infrastruktur, Betrieb | Infra-Repos | Nur 2 feste Mitglieder |

DevOps | ~7 | CI/CD, Tooling | Pipelines | Jan Lubenow = 39% SPOF |

Ziele

Primaer | Nachrangig |

Schnelle Umsetzungsgeschwindigkeit | Staerkenorientierter Einsatz |

Weniger Komplexitaet | Wissen breiter verteilen |

Weniger Abhaengigkeiten | Flexibilitaet bei Prioritaetswechsel |

Bessere Qualitaet | |

Bessere Verantwortlichkeit | |

Option A: OpsDev + Feature-Pool Modell OpsDev Team (permanent, ~8-10): Betrieb, Bugs, kleine Features. Lead OpsDev ohne PO.

Feature-Pool (~20-25): Entwickler + BAs + Feature-POs. Bilden temporaere Feature-Teams (3-5 Pers.) fuer grosse Features. Nach Abschluss: 1 Dev → OpsDev (Hypercare).

Vorteile | Nachteile |

Feature-Team ownt end-to-end | Kontextwechsel, Onboarding-Aufwand |

Keine Cross-Team-Deps fuer Features | Kein stabiles Team, Teambildung leidet |

Flexibel nach Prioritaet | OpsDev wird Muellhalde fuer Bugs |

Wissenstransfer durch Hypercare | PO-Overhead (3-4 POs parallel) |

Option B: Fachlicher Schnitt (4 Varianten)

B1: Bestellen vs. Abwickeln

Team "Bestellen" | Team "Abwickeln" |

Portal UI + MW, Common Interface, Stammdaten, Kundendaten, TAF/TAP-Konverter | Steuerung Vertrieb (Camunda), Auftrags-Verwaltung, IFP-Connector, Vertragsdaten, Archivierung, Abrechnung |

Fokus: Was der Kunde sieht | Fokus: Was nach der Bestellung passiert |

✔ Klarer Kundenfokus | ✘ NAÄ betrifft beide, SV ist Monolith

B4: Trasse vs. Vertrag (bester fachlicher Schnitt)

Team "Trasse" | Team "Vertrag" |

Trassenanmeldung (Portal+CI), Trassenkonstruktion (IFP), Stammdaten, TAF/TAP | Angebot + Vertrag (SV), Abrechnung, Stornierung, Rahmenvertraege, Vertragsdaten |

Vom Kundenwunsch bis Konstruktionsauftrag | Vom Angebot bis zur Rechnung |

✔ Sauberster Schnitt entlang Geschaeftsprozess, Abrechnung hat eigenes Team | ✘ SV muesste aufgeteilt werden, Portal zeigt beides

Option C: Hybrid — EMPFOHLEN

Empfohlenes Modell: OpsDev (permanent) + 2 fachliche Teams (permanent) + temporaere Feature-Squads fuer grosse Themen.

OpsDev (~6 Pers.) | Team "Bestellen" (~12) | Team "Verarbeiten" (~12) |

Betrieb, Deployment Monitoring, Infrastruktur Bug-Triage Lead: OpsDev-Lead | Portal UI + MW Common Interface Stammdaten, Kundendaten TAF/TAP Konverter Click&Ride PO + BA + Devs | Steuerung Vertrieb Auftrags-Verwaltung IFP-Connector Archivierung Vertragsdaten, Abrechnung PO + BA + Devs |

Bugs: Infrastruktur | Bugs: Portal, CI, STB | Bugs: SV, AV, IFP |

Fuer grosse Features (GelV, ujBau, NAÄ): Temporaer 2-3 Personen aus beiden Teams zusammenziehen. Nach Abschluss: zurueck + 1 Person Hypercare in OpsDev.

Gesamtbewertung

Option | Speed | Komplexitaet | Deps | Qualitaet | Ownership |

A: OpsDev + Pool | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |

B1: Bestellen/Abwickeln | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |

B4: Trasse/Vertrag | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |

C: Hybrid (empfohlen) | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |

D: Spotify | ⭐⭐⭐ | ⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |

Noch zu klaeren

SV aufteilen? — Ist der Monolith (93K LoC) technisch teilbar?

NAÄ als Querschnitt — Dediziertes Feature-Team oder feste Zuordnung?

Portal-Ownership — Portal zeigt Daten aus allen Services. Eigener Querschnitt?

Abrechnung — Eigenes Team wert? Oder bei "Verarbeiten"?

Personelle Passung — Staerken-Mapping der 35 Personen

Uebergangsphase — Dauer, Produktivitaetsverlust?

PO-Struktur — 1 PO pro Team oder uebergreifend + Feature-POs?

Metriken — Bug-Rate, Durchlaufzeit, Deployment-Frequenz als Erfolgsmessung

Fehlende Daten fuer Entscheidung

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?

Faktor TrassenOrder (Team TraPo) — NEU

TrassenOrder ist ein neues Produkt innerhalb SAB (gleiche Einheit wie pathOS), das den Bestellprozess fuer Gelegenheitsverkehr modernisiert. Entwicklungsstart Jan 2026, Livegang vsl. Q4 2026.

Aspekt | TrassenOrder | pathOS (Click&Ride) |

Fokus | GelV medienbruchfrei, attraktiver Workflow | GelV kurzfristig (<5 Arbeitstage), Gueterverkehr |

Phase | EXPLORE (seit Jan 2026) | Produktiv (seit Dez 2025) |

Livegang | Q4 2026 | Bereits live |

Team | TraPo (eigenes Team in SAB) | CIB (ADR-72) |

Jira | TRAPO (systelone) | O2CCIB / O2C404 |

Implikationen fuer Reorganisation

Abgrenzung klaeren: Was macht TrassenOrder, was macht pathOS/Click&Ride?

Integration: Frontend fuer pathOS-Backend? Oder separates System?

GelV-Ownership: Gehoert GelV kuenftig zu TraPo oder pathOS?

Vereinfachung: Wenn TraPo GelV uebernimmt, kann pathOS sich auf Netzfahrplan + ujBau konzentrieren — vereinfacht den fachlichen Schnitt erheblich

Empfehlung: Vor Reorg-Entscheidung unbedingt mit TraPo-Team abstimmen (Roadmap-Abgleich, Schnittstellen, langfristige Vision).