jpantsjoha/ai-native-developer-experience

Lagebericht (Sitrep)

Lageberichte sind für die Person, die nicht im Raum war. Schreiben Sie für sie.

Ein Lagebericht ist kein Aktivitätstagebuch. Er ist ein komprimiertes, handlungsorientiertes Bild des aktuellen Zustands. Drei Fragen: Was ist erledigt, was ist blockiert, was kommt als Nächstes. Alles, was nicht eine dieser drei Fragen beantwortet, gehört nicht in den Lagebericht.

Wann verwenden

• Tägliche Standup-Zusammenfassung aus Arbeitslogs, Commits oder Ticketstatus
• Zusammenfassung am Sprintende für Stakeholder
• Vorfall-Lagebericht während oder nach einem aktiven Vorfall
• Übergabezusammenfassung beim Wechsel des Kontexts oder der Übergabe von Arbeit an einen anderen Agenten oder eine andere Person
• Wenn ein Stakeholder fragt „Wo stehen wir?“ und die ehrliche Antwort lautet „Es ist kompliziert“

Vorgehen

1. Sammeln Sie den aktuellen Arbeitsstatus – lesen Sie aus verfügbaren Quellen:

   • Offene und kürzlich geschlossene Issues/Tickets
   • Aktuelle Commits (letzte 24–48 Stunden für ein Standup; letzter Sprint für eine Sprintzusammenfassung)
   • Projektstatus- und Roadmap-Dokumente (z.B. docs/operating-model/PROJECT-OPERATING-PROFILE.md, docs/ROADMAP.md oder entsprechend der Projektstruktur)
   • Eventuelle Blockierungsflags, Risikoregistereinträge oder Eskalationsnotizen

2. Klassifizieren Sie Elemente in drei Kategorien:

   • Erledigt – abgeschlossen und nachweislich geschlossen (Tests bestanden, Ticket geschlossen, deployed)
   • Blockiert – Arbeit, die ohne eine bestimmte ungelöste Abhängigkeit nicht vorankommen kann (nennen Sie die Blockade präzise)
   • Als Nächstes – die wichtigsten Elemente, die als Nächstes bearbeitet werden (nach Priorität geordnet)

3. Schreiben Sie den Lagebericht – Struktur:

   ## Lagebericht — <Datum> [<Umfang: Sprint / Vorfall / Übergabe>]
   
   **Erledigt**
   - <Element> — <ein Satz darüber, was geliefert wurde und sein Nachweis>
   
   **Blockiert**
   - <Element> — blockiert durch <spezifische Abhängigkeit / Verantwortlicher / ETA falls bekannt>
   
   **Als Nächstes**
   - <Element> — <Prioritätsreihenfolge, wichtigstes zuerst>
   
   **Risiken / Flags** (optional – nur wenn wesentlich)
   - <Risiko> — <Auswirkung, falls ungelöst> — <Verantwortlicher>
   

4. Wenden Sie den Kompressionstest an – für jede Zeile: Wenn das Entfernen nichts an dem ändert, worauf der Leser reagieren muss, entfernen Sie sie.

5. Benennen Sie Blockaden präzise – „durch Backend blockiert“ ist kein Blockadeeintrag. „Blockiert durch API-Vertrag für /v2/orders – warte auf @owner, ETA unbekannt“ ist einer.

6. Bewerten Sie den Fortschritt nicht – „gute Fortschritte gemacht“ ist Rauschen. „X geliefert, was Y entblockt“ ist Signal.

Ergebnisse

• Ein Lagebericht im obigen Format
• Optional: Eine einleitende Zusammenfassung für Stakeholder, die noch weniger benötigen

Leitplanken

• Keine Aktivitätsberichte. „Am Auth-Modul gearbeitet“ ist kein Lageberichtseintrag. „Auth-Modul: JWT-Validierung abgeschlossen, Token-Refresh schlägt unter Last fehl – wird untersucht“ ist einer.
• Blockiert bedeutet blockiert. Wenn etwas langsam vorankommt, aber nicht tatsächlich blockiert ist, gehört es mit einem Hinweis zu „Als Nächstes“, nicht zu „Blockiert“.
• Erledigt bedeutet erledigt. „Zu 95 % erledigt“ ist nicht erledigt. Wenn es nicht nachweislich abgeschlossen ist, ist es „Als Nächstes“.
• Länge ist nicht Qualität. Ein fünfzeiliger Lagebericht, der die drei Fragen beantwortet, ist besser als ein zwanzigzeiliger, der das nicht tut.