methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Methoden-Session60-90 min Workshop, plus 2 h asynchrone Vorbereitung durch FacilitatorWorkshop oder asyncPostmortem Doc

Session: Blameless Postmortem

Der Plan übersetzt die Methode in einen konkreten moderierten Arbeitsblock. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.

Die App wählt

Methoden-Session mit 3-12. Der Plan nutzt die vorhandene Methodenlogik und das Run Sheet.

Run Sheet
  1. 1

    Phase 1: Timeline-Walkthrough

    20 min

    Facilitator liest die Timeline laut vor, Beteiligte ergänzen Lücken, korrigieren Zeitstempel und kennzeichnen Entscheidungspunkte. Keine Diskussion über Ursachen, nur Faktenbasis. Hinweis: Wenn das Team in Phase 1 in Diskussion rutscht, Facilitator stoppt und schiebt Punkte in Phase 3. Timeline ist Grundlage, nicht Bewertung. 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.

    FacilitatorPostmortem Doc
  2. 2

    Phase 2: Impact-Erfassung

    10 min

    Nutzer-Impact, Geschäfts-Impact und SLO-Verletzungen in Zahlen festhalten. Mindestens: Dauer der Beeinträchtigung, Anzahl betroffener Nutzer, geschätzter Umsatz- oder Reputationseffekt. Hinweis: Zahlen brauchen Quelle. Wenn Schätzungen, dann als Schätzung markieren. Impact treibt Priorität der Action Items. 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.

    FacilitatorAction Items
  3. 3

    Phase 3: Contributing Factors

    30 min

    Beitragende Faktoren in Kategorien sammeln: Technik, Prozess, Organisation, Information. Pro Faktor: was hat das System getan oder unterlassen, was hätte den Verlauf verändert. Sprache neutral halten. Hinweis: Facilitator unterbricht bei Personifizierungen und formuliert um. Statt „X hat vergessen“ wird daraus „der Prozess hatte keinen Kontrollpunkt“. 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.

    FacilitatorTimeline
  4. 4

    Phase 4: Action Items

    20 min

    Pro Contributing Factor 0-2 Massnahmen mit Owner, Frist und Priorität. Action Items als kleine, ausführbare Tickets, keine Programme. Detection-Massnahmen klar von Ursachen-Massnahmen trennen. Hinweis: Wenn alle Action Items „bessere Doku“ oder „mehr Training“ sind, fehlt System-Tiefe. Mindestens eine technische Massnahme pro relevantem Faktor. 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.

    FacilitatorPostmortem Doc
  5. 5

    Phase 5: Lessons und Sign-off

    10 min

    Drei Lessons Learned formulieren, die andere Teams interessieren könnten. Veröffentlichungs-Format und Adressaten klären. Sign-off durch Incident Commander und Facilitator. Hinweis: Lessons gehören in den teamübergreifenden Lernkanal, nicht nur in den lokalen Wiki-Ordner. Wenn Lessons nur intern bleiben, fehlt der Multiplikator-Effekt. 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.

    OwnerAction Items
  6. 6

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerPostmortem Doc
Nutzbares Artefakt

Session Brief

Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.

# Session Brief: Blameless Postmortem

## Ziel
Artefakt: Postmortem Doc

## Arbeitsfrage
Welche Systembedingungen und Entscheidungspunkte haben den Incident möglich gemacht, und welche konkreten Massnahmen verhindern die Wiederholung?

## Kontext
Incident-ID, Dauer, Impact in Zahlen (Nutzer, Umsatz, SLO-Verletzung); Timeline-Entwurf 24 h vor Termin; bekannte Workarounds; bisherige Hypothesen aus dem Chat-Verlauf; Datum und Owner des Termins.

## Setup
- Format: Methoden-Session
- Dauer: 60-90 min Workshop, plus 2 h asynchrone Vorbereitung durch Facilitator
- Modus: Workshop oder async
- Teilnehmende: Facilitator ohne direkte Incident-Beteiligung; Incident Commander des Vorfalls; alle Operatoren mit aktiver Handlung im Verlauf; ein Scribe für das Protokoll; optional ein neutraler Beobachter aus einem anderen Team für Externblick.
- Owner: Facilitator ohne direkte Incident-Beteiligung
- 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 Postmortem Doc hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Postmortem-Template (Header, Timeline, Impact, Root Cause, Contributing Factors, Action Items, Lessons); geteiltes Dokument; Log-Auszüge und Graphen vom Incident-Tag; Chat-Transkript aus dem Incident-Channel; Liste der Beteiligten.

## Vorbereitung
Termin maximal 5 Werktage nach Resolution. Template mit Header und Timeline-Skeleton vorab ausfüllen. Regel ansagen: Sprache fokussiert auf Systemverhalten, keine Namen in Ursachenformulierungen. Aufzeichnung optional, aber Konsens vorab.

## Agenda
1. Phase 1: Timeline-Walkthrough (20 min)
   Owner: Facilitator
   Aktion: Facilitator liest die Timeline laut vor, Beteiligte ergänzen Lücken, korrigieren Zeitstempel und kennzeichnen Entscheidungspunkte. Keine Diskussion über Ursachen, nur Faktenbasis. Hinweis: Wenn das Team in Phase 1 in Diskussion rutscht, Facilitator stoppt und schiebt Punkte in Phase 3. Timeline ist Grundlage, nicht Bewertung. 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: Postmortem Doc

2. Phase 2: Impact-Erfassung (10 min)
   Owner: Facilitator
   Aktion: Nutzer-Impact, Geschäfts-Impact und SLO-Verletzungen in Zahlen festhalten. Mindestens: Dauer der Beeinträchtigung, Anzahl betroffener Nutzer, geschätzter Umsatz- oder Reputationseffekt. Hinweis: Zahlen brauchen Quelle. Wenn Schätzungen, dann als Schätzung markieren. Impact treibt Priorität der Action Items. 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: Action Items

3. Phase 3: Contributing Factors (30 min)
   Owner: Facilitator
   Aktion: Beitragende Faktoren in Kategorien sammeln: Technik, Prozess, Organisation, Information. Pro Faktor: was hat das System getan oder unterlassen, was hätte den Verlauf verändert. Sprache neutral halten. Hinweis: Facilitator unterbricht bei Personifizierungen und formuliert um. Statt „X hat vergessen“ wird daraus „der Prozess hatte keinen Kontrollpunkt“. 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: Timeline

4. Phase 4: Action Items (20 min)
   Owner: Facilitator
   Aktion: Pro Contributing Factor 0-2 Massnahmen mit Owner, Frist und Priorität. Action Items als kleine, ausführbare Tickets, keine Programme. Detection-Massnahmen klar von Ursachen-Massnahmen trennen. Hinweis: Wenn alle Action Items „bessere Doku“ oder „mehr Training“ sind, fehlt System-Tiefe. Mindestens eine technische Massnahme pro relevantem Faktor. 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: Postmortem Doc

5. Phase 5: Lessons und Sign-off (10 min)
   Owner: Owner
   Aktion: Drei Lessons Learned formulieren, die andere Teams interessieren könnten. Veröffentlichungs-Format und Adressaten klären. Sign-off durch Incident Commander und Facilitator. Hinweis: Lessons gehören in den teamübergreifenden Lernkanal, nicht nur in den lokalen Wiki-Ordner. Wenn Lessons nur intern bleiben, fehlt der Multiplikator-Effekt. 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: Action Items

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: Postmortem Doc

## Abschluss
- Ergebnisartefakt aktualisieren: Postmortem Doc
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

# Postmortem Doc: Blameless Postmortem

## Arbeitsfrage
Welche Systembedingungen und Entscheidungspunkte haben den Incident möglich gemacht, und welche konkreten Massnahmen verhindern die Wiederholung?

## Kontext
Incident-ID, Dauer, Impact in Zahlen (Nutzer, Umsatz, SLO-Verletzung); Timeline-Entwurf 24 h vor Termin; bekannte Workarounds; bisherige Hypothesen aus dem Chat-Verlauf; Datum und Owner des Termins.

## Beteiligte
- Owner: Facilitator ohne direkte Incident-Beteiligung
- Teilnehmende: Facilitator ohne direkte Incident-Beteiligung; Incident Commander des Vorfalls; alle Operatoren mit aktiver Handlung im Verlauf; ein Scribe für das Protokoll; optional ein neutraler Beobachter aus einem anderen Team für Externblick.

## Input
Postmortem-Template (Header, Timeline, Impact, Root Cause, Contributing Factors, Action Items, Lessons); geteiltes Dokument; Log-Auszüge und Graphen vom Incident-Tag; Chat-Transkript aus dem Incident-Channel; Liste der Beteiligten.

## Vorlage
# Blameless Postmortem

## Zusammenfassung

Was ist passiert, welche Wirkung hatte es?

## Impact

- Kundenauswirkung:
- Dauer:
- Betroffene Systeme:

## Timeline

Link oder Auszug der Timeline.

## Beitragende Faktoren

- ...

## Was lief gut?

- ...

## Was verbessern wir?

| Maßnahme | Owner | Datum | Erwartete Wirkung |
|---|---|---|---|

## Follow-up

Review-Termin und Status.

## Fertigstellungscheck
- Postmortem Doc 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
Vorlagenbasis

Blameless Postmortem

# Blameless Postmortem

## Zusammenfassung

Was ist passiert, welche Wirkung hatte es?

## Impact

- Kundenauswirkung:
- Dauer:
- Betroffene Systeme:

## Timeline

Link oder Auszug der Timeline.

## Beitragende Faktoren

- ...

## Was lief gut?

- ...

## Was verbessern wir?

| Maßnahme | Owner | Datum | Erwartete Wirkung |
|---|---|---|---|

## Follow-up

Review-Termin und Status.
Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Postmortem Doc.
  • Pro Incident ein Dokument mit Incident-ID im Titel. Status-Feld (draft, review, signed-off, follow-up-done). Action-Item-Status wird im Dokument-Header aktuell gehalten. Spätere Erkenntnisse als datierter Anhang, nicht durch Überschreibung.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.