Was vorher fertig sein muss
Das Team hat eine grundlegende Klarheit über Zweck, Mission und Hauptverantwortungen, schriftlich oder zumindest gemeinsam getragen.
Was vor Start vorliegen muss
Team-API-Template (z. B. von teamtopologies.com); Wiki- oder Repository-Seite; Liste der wichtigsten Stakeholder-Teams; aktuelle Service-Beschreibungen; bekannte Schnittstellen-Probleme; SLA-Vorlagen.
Ein Facilitator (Team Lead oder Coach); das gesamte Team (Engineering, Product, ggf. Operations); ein Stakeholder-Vertreter pro wichtigem Team für Validierung; Scribe für Dokumentation.
Aktuelle Team-Verantwortungen; bekannte Services (APIs, Plattformen); Stakeholder-Teams mit Kontaktwegen; bestehende SLAs oder informelle Erwartungen; geplante Roadmap-Items.
Half day (4 h) initial, danach quartalsweise Pflege
Template mit Sektionen: Team-Zweck und Mission, Verantwortungen, Nicht-Verantwortungen, Services, Schnittstellen, Service Level, Kommunikationswege, Roadmap, Onboarding-Hinweise. Wiki-Seite bereit.
Die eine Frage, die diese Methode beantwortet
Was bietet unser Team anderen Teams als Service, wie interagieren sie mit uns, und was können sie erwarten?
Marker: Sektion
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Sektion 1: Zweck und Verantwortungen | 30-45 min | Team-Zweck in 1-3 Sätzen. Hauptverantwortungen als 3-7 Bullet-Points. Nicht-Verantwortungen explizit (was wir nicht tun, auch wenn andere es erwarten). | Nicht-Verantwortungen sind oft wertvoller als Verantwortungen. Was wir nicht tun, klärt Eskalations-Erwartungen. Vage „kümmern uns um alles“-Sätze vermeiden. |
2Sektion 2: Services und Schnittstellen | 45-60 min | Pro Service: Name, Zweck, Konsumenten, technische Schnittstelle (API-URL, Slack-Channel, Ticket-Queue), Anfrage-Workflow. Drei bis acht Services typisch. | Services sind nicht nur APIs. Auch Beratung, Reviews, On-Call-Support sind Services. Konsumenten klar benennen, sonst werden Services für Falsche bereitgestellt. |
3Sektion 3: Service Level und Erwartungen | 30-45 min | Pro Service grobes SLA: Response-Zeit, Availability, Eskalations-Pfad. Erwartungen an Konsumenten (z. B. Issue-Template, On-Call-Trigger-Bedingungen). | SLAs müssen einhaltbar sein. Lieber konservativ („Antwort innerhalb 2 Werktage“) als aspirationell. Unrealistische SLAs zerstören Vertrauen schneller als keine SLAs. |
4Sektion 4: Kommunikationswege und Eskalation | 20-30 min | Wo melden Konsumenten Anfragen, Bugs, Incidents. Pro Kanal Zweck (z. B. Slack #team-X für Fragen, Jira für Tickets, PagerDuty für P1). Eskalations-Hierarchie für Konflikte. | Klare Kanal-Trennung. „Schreib mir auf Slack DM“ ist nicht skalierbar. Öffentliche Kanäle bevorzugen, dokumentierte Verläufe sichern Wissen. |
5Sektion 5: Roadmap und Onboarding | 20-30 min | Aktuelle Roadmap-Sektion mit nächstem Quartals-Fokus. Onboarding-Hinweise: Wie kann externes Team mit uns starten (Vorbereitung, Workshop, Dokumentation). | Roadmap-Sektion macht Erwartungs-Management einfacher. Sichtbarkeit über kommende Themen verhindert wiederholte „wann macht ihr X“-Fragen. |
Was am Ende rauskommt
Team-API-Seite im zentralen Wiki mit allen Sektionen, prominent verlinkt aus Engineering-Org-Übersicht. Sichtbar für alle Mitarbeiter. Markdown im Repo als zweite Form (für Versionskontrolle und Onboarding).
Quartalsweise Pflege. Änderungs-Log am Ende der Seite. Bei Major-Änderungen (neue Services, geänderte SLAs) breitere Kommunikation an Stakeholder-Teams. Onboarding-Hinweise nach jedem neuen Team-Mitglied prüfen.
Kompakte Arbeitsvorlage für Team API mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Team API Arbeitsvorlage
## Ziel
Beschreibt Aufgaben, Services und Erwartungen eines Teams als API.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Team-API-Dokument:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Team API - Platform Team „Identity & Access“, Stand 2026-05-18
**Zweck**: Wir stellen Authentifizierung, Autorisierung und User-Lifecycle als Plattform-Service für alle Produkt-Teams bereit.
**Hauptverantwortungen**
- SSO-Integration (Google, Microsoft, SAML)
- User-Management-API
- Berechtigungs-Modell (Roles, Permissions)
- Audit-Log für Zugriffe
- On-Call für P1-Authentifizierungs-Outages
**Nicht-Verantwortungen**
- UI-Komponenten für Login-Screens (das ist Produktteam-Aufgabe).
- Benutzer-Onboarding-Flows (Produktteam).
- Compliance-Audits über reine Authentifizierung hinaus (Compliance-Team).
**Services**
| Service | Konsumenten | Schnittstelle | Workflow |
|---------|--------------|---------------|----------|
| Auth-API (OAuth2) | alle Produktteams | api.internal/auth/v2 | Self-Service, Doku in /docs/auth |
| SSO-Onboarding für neue Mandanten | Sales-Engineering | Slack #identity-help | Ticket in Jira, SLA 2 Tage |
| Audit-Log-Export | Compliance, Security | API + Looker-Dashboard | Self-Service |
| Berechtigungs-Review (jährlich) | Compliance | Workshop-Format | Termin via Sandra @Compliance |
**Service Level**
- Auth-API: 99,95% Availability, P1 Outage Response <15 min.
- SSO-Onboarding: Antwort <2 Werktage, Lösung <5 Werktage.
- Audit-Log: Self-Service, kein expliziter SLA.
**Kommunikationswege**
- Allgemeine Fragen: Slack #identity-help.
- Bugs/Incidents (nicht P1): Jira-Project IDENTITY.
- P1 Incidents: PagerDuty-Service „identity-platform“.
- Eskalation: Team-Lead @ben, dann Engineering-Director @julia.
**Roadmap Q3/2026**
- Multi-Factor-Authentifizierung als Service (Launch August).
- API-Versions-Migration v2 -> v3 (Plan-Dokument im Wiki).
- Audit-Log-Retention auf 7 Jahre (Compliance-Anforderung).
**Onboarding für neue Konsumenten**
1. Doku in /docs/auth lesen.
2. Test-Mandant über Self-Service-Form anlegen.
3. Optional: 30-min-Kickoff-Call mit @ben (per Calendly buchen).
**Team-Mitglieder**
- @ben (Lead)
- @anna (Engineer)
- @marcus (Engineer)
- @lisa (SRE-Liaison, 50%)
**Letzte Aktualisierung**: 2026-05-18 (Quartals-Review).Symptome erkennen, gegensteuern
Team API listet nur was getan wird, andere Teams nehmen jede Anfrage als möglich an.
Nicht-Verantwortungen explizit auflisten. Was wir nicht tun, ist oft wichtiger als was wir tun. Verhindert Anfragen-Flut und falsche Erwartungen.
Service Level wird optimistisch formuliert („Response innerhalb 1 Stunde“), aber nicht eingehalten.
Konservativ formulieren. SLA muss realistisch eingehalten werden, sonst verliert Team API Vertrauen. Bei Schwankungen unterer Wert als SLA, oberer als Ziel.
Team API wird einmal geschrieben, hängt im Wiki, ist nach 6 Monaten veraltet.
Quartalsweise Review fest im Kalender. Änderungen am Team werden direkt aktualisiert. „Letzte Aktualisierung“-Datum sichtbar, alte Versionen abschrecken.
Team API existiert, aber andere Teams kennen sie nicht oder finden sie nicht.
Zentrale Engineering-Org-Übersicht mit Links zu allen Team APIs. Bei Onboarding neuer Mitarbeiter Team-API-Tour. Slack-Bot oder Backstage-Integration.
Services sind aufgelistet, aber niemand sagt klar, wer sie nutzen soll oder darf.
Pro Service Konsumenten-Liste explizit. „Alle Produktteams“ ist akzeptabel, „Externe Partner“ braucht eigene Sektion. Klare Zielgruppe vermeidet Missverständnisse.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.