Meine Session planen

# Session Brief: Team API

## Ziel
Artefakt: Team-API-Dokument

## Arbeitsfrage
Was bietet unser Team anderen Teams als Service, wie interagieren sie mit uns, und was können sie erwarten?

## Kontext
Aktuelle Team-Verantwortungen; bekannte Services (APIs, Plattformen); Stakeholder-Teams mit Kontaktwegen; bestehende SLAs oder informelle Erwartungen; geplante Roadmap-Items.

## Setup
- Format: Methoden-Session
- Dauer: Half day (4 h) initial, danach quartalsweise Pflege
- Modus: Workshop oder async
- Teilnehmende: 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.
- Owner: Ein Facilitator (Team Lead oder Coach)
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf Team-API-Dokument hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

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

## Vorbereitung
Template mit Sektionen: Team-Zweck und Mission, Verantwortungen, Nicht-Verantwortungen, Services, Schnittstellen, Service Level, Kommunikationswege, Roadmap, Onboarding-Hinweise. Wiki-Seite bereit.

## Agenda
1. Sektion 1: Zweck und Verantwortungen (30-45 min)
   Owner: Facilitator
   Aktion: 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). Hinweis: Nicht-Verantwortungen sind oft wertvoller als Verantwortungen. Was wir nicht tun, klärt Eskalations-Erwartungen. Vage „kümmern uns um alles“-Sätze vermeiden. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Team-API-Dokument

2. Sektion 2: Services und Schnittstellen (45-60 min)
   Owner: Facilitator
   Aktion: Pro Service: Name, Zweck, Konsumenten, technische Schnittstelle (API-URL, Slack-Channel, Ticket-Queue), Anfrage-Workflow. Drei bis acht Services typisch. Hinweis: Services sind nicht nur APIs. Auch Beratung, Reviews, On-Call-Support sind Services. Konsumenten klar benennen, sonst werden Services für Falsche bereitgestellt. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Team-API-Dokument

3. Sektion 3: Service Level und Erwartungen (30-45 min)
   Owner: Facilitator
   Aktion: Pro Service grobes SLA: Response-Zeit, Availability, Eskalations-Pfad. Erwartungen an Konsumenten (z. B. Issue-Template, On-Call-Trigger-Bedingungen). Hinweis: SLAs müssen einhaltbar sein. Lieber konservativ („Antwort innerhalb 2 Werktage“) als aspirationell. Unrealistische SLAs zerstören Vertrauen schneller als keine SLAs. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Team-API-Dokument

4. Sektion 4: Kommunikationswege und Eskalation (20-30 min)
   Owner: Facilitator
   Aktion: 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. Hinweis: Klare Kanal-Trennung. „Schreib mir auf Slack DM“ ist nicht skalierbar. Öffentliche Kanäle bevorzugen, dokumentierte Verläufe sichern Wissen. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Team-API-Dokument

5. Sektion 5: Roadmap und Onboarding (20-30 min)
   Owner: Owner
   Aktion: Aktuelle Roadmap-Sektion mit nächstem Quartals-Fokus. Onboarding-Hinweise: Wie kann externes Team mit uns starten (Vorbereitung, Workshop, Dokumentation). Hinweis: Roadmap-Sektion macht Erwartungs-Management einfacher. Sichtbarkeit über kommende Themen verhindert wiederholte „wann macht ihr X“-Fragen. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Team-API-Dokument

6. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: Team-API-Dokument

## Abschluss
- Ergebnisartefakt aktualisieren: Team-API-Dokument
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Team-API-Dokument: Team API

## Arbeitsfrage
Was bietet unser Team anderen Teams als Service, wie interagieren sie mit uns, und was können sie erwarten?

## Kontext
Aktuelle Team-Verantwortungen; bekannte Services (APIs, Plattformen); Stakeholder-Teams mit Kontaktwegen; bestehende SLAs oder informelle Erwartungen; geplante Roadmap-Items.

## Beteiligte
- Owner: Ein Facilitator (Team Lead oder Coach)
- Teilnehmende: 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.

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

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

## Fertigstellungscheck
- Team-API-Dokument ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren