# 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).