# 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?