So dokumentiert ihr Jira-Automation-Regeln, ohne tausend Beschreibungen zu schreiben

Namen von Regeln (Flows) wie „Copy of copy of SLA v2" überleben die Menschen, die sie geschrieben haben. So bekommt ihr eine lesbare Beschreibung auf jede Regel, ohne tausend davon selbst zu tippen.

Fragt eine Admin, was eine Regel tut, und ihr bekommt den Namen. Der Name lautet oft Copy of copy of SLA v2. Die Person, die sie schrieb, ist 2023 gegangen, das begründende Ticket ist geschlossen, und die einzige echte Dokumentation einer Jira-Automation-Regel (Jira nennt sie inzwischen Flow) ist die Regel selbst — ein Baum aus Triggern, Verzweigungen und Smart Values, dessen Lektüre zehn Minuten dauert und der in keinen Satz passt.

Bei einer Regel ist das in Ordnung. Bei neunhundert nicht — und deshalb traut sich niemand, etwas zu löschen.

Warum der Name nie reicht

Der Name einer Regel wird einmal geschrieben, bei der Erstellung, von jemandem, der genau weiß, was gemeint ist. Alles danach — die zusätzliche Bedingung, die zweite Verzweigung, das umbenannte Feld — passiert, ohne dass sich der Name ändert. Nach zwei Jahren beschreibt der Name die ursprüngliche Absicht, nicht das aktuelle Verhalten, und es gibt kein Feld in Jira, das die Differenz hält.

Das Wissen liegt also an drei Orten, alle schlecht: in jemandes Erinnerung, auf einer Confluence-Seite, die nicht mehr gepflegt wird, oder im JSON der Regel.

Was die Regel tatsächlich tut, auf einem Bildschirm

Schritt eins: die Regel lesbar machen

Bevor ihr eine Beschreibung schreibt, müsst ihr die Regel lesen können. Automation Map zeigt jede Regel als Baum — Trigger oben, Bedingungen und Verzweigungen eingerückt darunter, Aktionen an den Blättern, Smart Values aufgelöst zu den Feldern, die sie anfassen. Aus zehn Minuten Klicken im Jira-Editor wird ein Bildschirm.

Das allein beantwortet die meisten Fragen. Für den Rest braucht ihr die Beschreibung.

Schritt zwei: die KI den ersten Entwurf schreiben lassen

Neunhundert Beschreibungen von Hand wird niemand schreiben. Eine einzelne Regel zu beschreiben ist dagegen genau die Aufgabe, in der ein Sprachmodell gut ist: strukturierte Eingabe, zwei Sätze Klartext als Ausgabe, und ein Mensch prüft es in fünf Sekunden.

Automation Map bringt einen Rovo-Agenten mit — in jeder Edition, auch Basic —, der die Struktur einer Regel liest und ein, zwei Sätze dazu schreibt, warum die Regel existiert, was sie in Ordnung hält und für wen; ist die Absicht unklar, fragt er die Eigentümerin der Regel, statt zu raten. Der Agent speichert die Beschreibungen als KI-geschrieben markiert, und die Karte kennzeichnet sie mit „AI". Eine Beschreibung, die ein Mensch geschrieben hat — in der Regel in Jira oder in der App —, wird nie überschrieben. Nach Jira wird nichts zurückgeschrieben: die Beschreibung liegt in der Wissensbasis der App neben der Regel.

Bittet den Agenten, „Bereich X zu dokumentieren", schreibt er eine vollständige Seite nach festem Muster; die Confluence-Seite legt er erst an, wenn ihr Ja sagt.

HINWEIS: Beschreibungen speichert die App, nicht Jira. Die App arbeitet mit einem Export eurer Regeln, den eine Admin hochlädt, und hat keine Berechtigung, in Jira etwas zu ändern. Eine Beschreibung ist eine Notiz zu einer Regel, nie eine Änderung an ihr.

Schritt drei: fragen statt Regeln lesen

Sobald Regeln Beschreibungen haben, ändert die Frage ihre Form. Statt „ich öffne mal elf Regeln und suche die, die dieses Feld setzt" fragt ihr einfach.

Derselbe Rovo-Agent antwortet aus der indizierten Struktur:

• „Wer füllt das Fälligkeitsdatum in PROJ?" — die Regeln, die dieses Feld schreiben, je mit Link zur Karte und zur Regel in Jira
• „Haben wir zwei Regeln, die dasselbe tun?" — Regeln mit demselben Trigger und denselben Aktionen, per Suche in der Logik gefunden, plus die „Copy of …"-Klone, die die Karte ohnehin verknüpft
• „Was passiert, wenn in PROJ ein Bug erstellt wird?" — jede Regel, die auf dieses Ereignis aufwacht, in einer Antwort

Jede genannte Regel kommt mit zwei Links: einem auf ihren Platz auf der Karte, einem auf die Regel in Jira zum Bearbeiten.

Was es nicht sagen kann

Alles über tatsächliche Läufe. Wie oft eine Regel lief, steht in Jiras Performance insights; was ein Lauf getan hat, im Audit-Log, 90 Tage lang. Für das Audit-Log gibt es keine öffentliche API, und die App liest keines von beiden. Fragen dieser Art bekommen eine Antwort aus der Struktur plus den ehrlichen Hinweis, dass Jira den Rest hat.

Und an ein Modell geht nichts, bevor eine Jira-Administratorin die KI einschaltet — und dann nur für die Bereiche (Projekte), die sie auswählt. Der Rovo-Agent läuft auf eurem eigenen Rovo, nicht über den KI-Schalter der App.

FAQ

Macht den Job der nächsten Admin möglich

Die Regeln überleben die Menschen, die sie schrieben, so oder so. Die einzige Wahl ist, ob sie auch die Erklärung überleben.

👉 Automation Map für Jira — Regeln lesen, beschreiben, durchsuchen