ankn
a5f8fb49ab
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
341 lines
17 KiB
Markdown
341 lines
17 KiB
Markdown
# 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?
|