Der Nachtlauf und der Morgen

Was ein Auftrag technisch tatsächlich tut

JiCo arbeitet nicht ausschliesslich im direkten Gespräch mit einem Menschen, der Frage für Frage stellt und auf jede Antwort wartet. Es kann auch im Auftragsbetrieb laufen: einzeln angestossen, als Warteschlange mehrerer Aufgaben hintereinander, oder nach einem bewusst lesbaren Zeitplan wie „werktags um 06:00 Uhr" — ausdrücklich nicht als kryptische Cron-Notation, die man erst in einer Tabelle nachschlagen müsste, um zu verstehen, wann etwas eigentlich passiert.

Ein solcher Lauf liest Tickets, prüft sie gegen die hinterlegten Regeln und Konventionen, formuliert konkrete Vorschläge — und endet grundsätzlich und ausnahmslos im Zustand „wartet auf Freigabe", niemals in „erledigt". Ein Auftrag, der von sich aus etwas tatsächlich verändert hätte, wäre streng genommen kein Auftrag im Sinne von JiCo mehr. Er wäre genau die unbeaufsichtigte Automatisierung, die JiCo an dieser einen Stelle ausdrücklich nicht sein will — auch dann nicht, wenn der Auftrag nachts lief und niemand live zusah.

Warum 400 Rohvorschläge morgens keine Erleichterung wären

400 einzelne, unsortierte Vorschläge am nächsten Morgen der Reihe nach durchzuklicken, wäre keine echte Arbeitserleichterung. Es wäre eine neue, subtilere Form derselben Arbeit — nur schlechter lesbar als das ursprüngliche Ticket selbst, weil der eigentliche Zusammenhang zwischen ähnlichen Fällen verloren ginge und jede Zeile für sich isoliert betrachtet werden müsste.

Deshalb werden die Befunde eines Laufs nicht einfach aneinandergereiht, sondern gruppiert und thematisch verdichtet: Ähnliches wird zusammen vorgelegt, mit der Möglichkeit, jede Gruppe bei Bedarf einzeln aufzuklappen, wenn man eine bestimmte Entscheidung genauer nachvollziehen möchte, statt der zusammenfassenden Einschätzung blind zu vertrauen. Aus 400 einzelnen Zeilen wird auf diese Weise eine überschaubare, tatsächlich zu bewältigende Zahl an thematischen Gruppen — nicht, weil weniger geprüft worden wäre, sondern weil erkennbar Ähnliches gebündelt vorgelegt wird, statt jeden Einzelfall isoliert zu präsentieren.

Offene Fragen werden benannt, nicht stillschweigend geraten

Ein Detail, das den eigentlichen Unterschied zwischen einem vertrauenswürdigen und einem bloss beeindruckenden System ausmacht, betrifft den Umgang mit Unklarheiten: Stösst ein Modell während eines Laufs auf etwas Mehrdeutiges — ein Feld, das sich unterschiedlich interpretieren liesse, eine Angabe, die im Ticket schlicht fehlt, ein Zusammenhang, der sich nicht eindeutig herstellen lässt —, landet das als eigene, ausgewiesene Kategorie in der fertigen Freigabe-Mappe: als offene Frage, klar benannt, statt stillschweigend zu einer Annahme verarbeitet und in einem fertig klingenden Vorschlag versteckt zu werden.

Eine geratene Antwort, die selbstsicher formuliert in einem Vorschlag auftaucht, wäre am Ende deutlich schwerer zu entdecken als eine ehrlich benannte Lücke, die von vornherein als solche gekennzeichnet ist. Genau deshalb ist diese Trennung kein optionales Detail, sondern ein fester Bestandteil jeder Mappe: Was das System sicher weiss, steht als Vorschlag. Was es nicht sicher weiss, steht als Frage.

Was nach der Freigabe noch offen bleiben kann

Eine einmal freigegebene Änderung ist nicht zwangsläufig das Ende der Geschichte, auch wenn man das im ersten Moment annehmen könnte. Manche Entscheidung hat Folgen an einer ganz anderen Stelle im System, die auf den ersten Blick nichts mit der ursprünglichen Änderung zu tun zu haben scheinen — ein geänderter Status, der laut den hinterlegten Konventionen ein zweites Feld nach sich ziehen sollte, ein Kommentar, der eine Information an anderer Stelle im Ticket nachziehen müsste, damit der Datensatz insgesamt konsistent bleibt.

Diese Folgepflichten landen in einer eigenen, separat geführten Nachzieh-Liste, statt schlicht darauf zu hoffen, dass sich irgendjemand im Team zufällig daran erinnert, oder dass die verantwortliche Person sie sich handschriftlich notiert. Der Nachtlauf endet damit am Ende nicht einfach mit einer Mappe voller Ja- und Nein-Entscheidungen, sondern mit drei sauber voneinander getrennten Kategorien: was jetzt konkret zu entscheiden ist, was dabei noch unklar geblieben ist, und was sich aus einer bereits früher getroffenen Entscheidung zwingend noch ergibt.

Ein lesbarer Zeitplan statt einer kryptischen Notation

Ein kleines, aber im Alltag überraschend wirksames Detail betrifft die Art, wie ein solcher Lauf überhaupt geplant wird. Viele vergleichbare Systeme verlangen an dieser Stelle eine Cron-Notation — eine knappe Folge von Zahlen und Sternchen, die zwar mächtig, aber für die meisten Menschen ohne Nachschlagen kaum lesbar ist. Ein falsch gesetztes Zeichen dort kann dazu führen, dass ein Lauf zur falschen Zeit oder gar nicht stattfindet, ohne dass es jemandem auffällt, bis am nächsten Morgen die erwartete Mappe fehlt.

JiCo verzichtet an dieser Stelle bewusst auf diese Notation zugunsten eines Satzes, den jeder ohne Vorwissen sofort versteht: „werktags 06:00". Wer diesen Satz liest, weiss auf Anhieb, wann der Lauf stattfindet, ohne eine Tabelle konsultieren zu müssen — ein kleines Beispiel dafür, dass Fachsprache statt technischer Abkürzung nicht nur bei Freigabe-Vorschlägen gilt, sondern konsequent auch bei der Einrichtung des Systems selbst.

Warum sich dieser Aufwand überhaupt lohnt

Man könnte einwenden, dass diese ganze Verdichtung, Gruppierung und Nachverfolgung selbst wieder Aufwand bedeutet — und das stimmt zweifellos. Der Unterschied liegt darin, wo dieser Aufwand anfällt: einmal, im System, automatisiert und nachvollziehbar, statt jeden Morgen aufs Neue im Kopf einer einzelnen Person, die versucht, sich an gestern zu erinnern und den Überblick über hunderte Einzelfälle zu behalten. Diese Verlagerung ist der eigentliche Nutzen des Auftragsbetriebs — nicht, dass weniger geprüft würde, sondern dass die Prüfung an der richtigen Stelle stattfindet und ihr Ergebnis in einer Form vorliegt, mit der ein Mensch tatsächlich etwas anfangen kann.