Vom Jira- und Slack-Chaos zum prüfbaren Projektstatus

Der Projektstatus wird oft erst am Freitag dringend. Die Projektleitung öffnet Jira, durchsucht mehrere Slack-Channel, fragt nach einem fehlenden Update und versucht anschliessend, aus Tickets, Chat-Nachrichten und Erinnerungen eine kohärente Geschichte zu machen. Das Ergebnis kostet Zeit – und ist trotzdem schwer zu prüfen: Wurde ein Risiko tatsächlich gemeldet? Ist ein Ticket noch offen? Oder war die Aussage einfach die plausibelste Erinnerung im Raum?

Ein KI-Agent kann diese Arbeit vorbereiten. Sein Nutzen besteht aber nicht darin, selbständig über ein Projekt zu urteilen oder Updates zu versenden. Er kann einen eng eingegrenzten Recherche- und Entwurfsprozess übernehmen: freigegebene Quellen durchsuchen, Beobachtungen den Quellen zuordnen und einen Statusentwurf erstellen, den die verantwortliche Person prüft und ergänzt.

Das Problem ist nicht nur zu viel Information

Jira enthält strukturierte Arbeit: offene Issues, Prioritäten, Fälligkeiten und Verantwortlichkeiten. In Slack stehen oft die Informationen, die in keinem Ticket auftauchen: ein blockierter Entscheid, eine verschobene Abhängigkeit oder ein Hinweis aus einem Kundengespräch. Keines der Systeme liefert allein einen belastbaren Projektstatus. Die Schwierigkeit liegt darin, die relevanten Signale zu finden, Widersprüche zu erkennen und klar zwischen belegten Fakten und Einschätzungen zu unterscheiden.

• Ein Ticket kann «in Bearbeitung» sein, obwohl ein Blocker bereits im Projekt-Channel diskutiert wird.
• Ein dringendes Slack-Update kann ohne Bezug zum zugehörigen Issue erscheinen.
• Eine Aussage wie «im Plan» ist ohne Quelle oder klaren Owner kaum prüfbar.
• Wenn der Bericht nur aus einem Chat-Entwurf besteht, ist später nicht ersichtlich, worauf er beruhte.

Beginnen Sie mit einem engen, wiederkehrenden Workflow

Der richtige erste Anwendungsfall ist nicht «den Projektstatus automatisieren». Er ist «jeden Donnerstag einen Entwurf für Projekt A vorbereiten». Definieren Sie dafür einen Owner, einen festen Berichtszeitraum, die zulässigen Quellen und die Empfänger des finalen Updates. Diese Begrenzung macht die Qualität messbar und verhindert, dass ein Agent Kontext aus ähnlichen, aber unpassenden Projekten vermischt.

Für einen ersten Versuch reichen beispielsweise ein Projekt in Jira und ein vereinbarter Slack-Channel. Der Agent darf dort nur mit explizit freigegebenen, schreibgeschützten Tools recherchieren. Er verändert keine Tickets, passt keine Prioritäten an und sendet keine Nachrichten. Das Team behält die bestehende Arbeitsweise; es erhält lediglich einen nachvollziehbar vorbereiteten Entwurf.

Quellen und Verantwortlichkeiten vorab festlegen

Ein prüfbarer Bericht beginnt nicht beim Prompt, sondern bei der Frage, welche Quelle für welche Aussage gilt. Jira kann beispielsweise die Quelle für Ticketstatus und Fälligkeiten sein. Der definierte Projekt-Channel kann Kontext für Blocker und Entscheidungen liefern. Eine Projektleitung bleibt verantwortlich dafür, Prioritäten zu bewerten und Aussagen zu bestätigen, die keine eindeutige Quelle haben.

• Definieren Sie Projekt, Jira-Filter und Slack-Channel ausdrücklich – nicht «alles, was relevant sein könnte».
• Legen Sie einen Berichtszeitraum fest, damit alte Chat-Nachrichten nicht als neue Signale erscheinen.
• Schliessen Sie sensible Channel und Daten aus, die für den Status nicht erforderlich sind.
• Benennen Sie eine Person, die Unklarheiten klärt und den finalen Bericht freigibt.

So sieht ein nachvollziehbarer Statusentwurf aus

Ein guter Entwurf trennt Fakten, offene Fragen und Bewertung. Statt «Die Migration ist gefährdet» sollte er etwa festhalten: «Risiko: Die Abhängigkeit X ist noch offen; das verknüpfte Jira-Issue hat den Status ‹Blocked›. Im Projekt-Channel wurde am Dienstag eine Entscheidung bis Freitag erwartet.» Die Projektleitung kann die Aussage bestätigen, relativieren oder korrigieren – und sieht sofort, welche Belege der Agent verwendet hat.

• Fortschritt: erledigte und relevante offene Arbeit mit Ticket-Links.
• Risiken und Blocker: klare Beobachtung, zugehörige Quelle und verantwortlicher Owner.
• Entscheidungen und nächste Schritte: nur wenn sie in den freigegebenen Quellen vorkommen; sonst als offene Frage markieren.
• Unsicherheit: fehlende Informationen oder widersprüchliche Quellen nicht glätten, sondern sichtbar machen.

Menschliche Prüfung ist der Kontrollpunkt, nicht der Ausnahmefall

Ein Agent erkennt Muster und fasst Material zusammen; er kennt jedoch nicht automatisch die politische, fachliche oder zeitliche Bedeutung eines Signals. Bevor der Bericht geteilt wird, prüft die Projektleitung deshalb Quellen, Tonalität, Priorisierung und vertrauliche Inhalte. Sie entscheidet auch, ob ein ausstehendes Ticket tatsächlich ein Risiko ist oder nur auf einen administrativen Schritt wartet. Die Freigabe bleibt dort, wo die Verantwortung liegt.

Erfolg nach vier Wochen messen

Messen Sie nicht nur, ob ein Text generiert wurde. Notieren Sie die bisherige Zeit für Recherche und Bericht, die Zeit bis zum freigegebenen Entwurf, die Zahl wesentlicher Korrekturen und die Zahl der Aussagen ohne ausreichend klare Quelle. Wenn der Entwurf zwar schnell, aber nicht vertrauenswürdig ist, verengen Sie Quellen oder Berichtsformat. Erst wenn die Projektleitung den Entwurf regelmässig als hilfreichen Ausgangspunkt nutzt, lohnt sich eine Ausweitung auf weitere Projekte.

Checkliste für den sicheren Start

• Wählen Sie ein Projekt mit einem klaren Statusrhythmus und einer verantwortlichen Projektleitung.
• Erlauben Sie nur die notwendigen, schreibgeschützten Jira- und Slack-Tools.
• Definieren Sie Quellen, Zeitraum, Berichtsformat und Umgang mit Unsicherheit.
• Testen Sie den Entwurf mit vergangenen Berichtsterminen und prüfen Sie jede Quelle.
• Behalten Sie die menschliche Freigabe bei und erweitern Sie den Zugriff erst bei verlässlichen Ergebnissen.

Ein Projektstatus wird nicht dadurch besser, dass ein Agent mehr Systeme sieht. Er wird besser, wenn er eine klar umrissene Recherche übernimmt, Belege sichtbar macht und der verantwortlichen Person Zeit für die eigentliche Einordnung verschafft. So wird aus Jira- und Slack-Chaos ein Status, den das Team nachvollziehen und vertreten kann.