Nichts zeigt, wie lange ein Zustand schon gilt

Ein Asset wechselt am Montagnachmittag auf Needs Review. Am Donnerstag wird es geprüft. Die Prüfung dauerte neun Minuten. Die drei Tage dazwischen stehen nirgends, weil in ihnen nichts geschah und nichts, was nicht geschieht, eine Spur hinterlässt.

Niemand hat das Warten festgehalten, denn Warten ist kein Ereignis. Systeme protokollieren, was passiert. Drei Tage, in denen nichts passiert, sind nichts zum Protokollieren.

Rechnet man das über eine Kampagne hoch, wird die Arithmetik unangenehm. Die Arbeit dauerte Stunden. Die Kampagne dauerte fünf Wochen. Niemand kann sagen, wo die Differenz blieb, und ohne Erklärung lautet der übliche Schluss, die Leute seien langsam.

Die Zeit liegt in den Lücken, und die Lücken sind ungemessen

Fragen Sie, woher eine Verzögerung kam. Die ehrliche Antwort ist meist eine Handvoll Intervalle, keines lang genug, um für sich ein Problem zu sein. Ein Tag, bis jemand die Benachrichtigung öffnete. Zwei Tage, weil die freigebende Person unterwegs war und niemand sonst wusste, dass sie es auch darf. Ein Nachmittag, weil das Asset bereit war und die wartende Person es nicht erfuhr.

Keines dieser Intervalle taucht in einer Statusansicht auf. Ein Board zeigt fünf Dinge in Needs Review. Es zeigt nicht, dass vier davon heute Morgen kamen und eines seit vorletztem Dienstag liegt.

Das ist keine Berichtslücke. Es verändert, worauf ein Team reagieren kann. Eine Fünf nennt die Menge. Sie nennt nicht, welches feststeckt, und Feststecken ist die einzige Kategorie, die überhaupt eine Handlung verlangt.

Die Kategorie antwortet mit mehr Nachrichten

Wer liest, was über Freigabeverzögerungen geschrieben wird, findet dieselbe Antwort. Automatische Erinnerungen. Eskalation bei überschrittener Frist. Ein Dashboard offener Punkte. Reaktionszeiten als Zielwert.

Jedes davon ist ein Push. Jedes setzt voraus, dass das System weiss, wer zu informieren ist. Innerhalb eines festen Teams stimmt das. Es scheitert, sobald eine Freelancerin, eine Agentur und eine Vertretung beteiligt sind. Wer es hätte wissen müssen, stand nicht auf der Liste, weil niemand daran dachte, ihn zu etwas hinzuzufügen, das vor seiner Ankunft eingerichtet wurde.

Mehr Nachrichten nutzen sich zudem ab. Ein Kanal, der bei jedem Zustandswechsel feuert, ist nach einem Monat stummgeschaltet. Danach ist die Benachrichtigung kein Signal mehr. Sie ist Rauschen, das zufällig eines enthält.

Ein lesbarer Zustand muss nicht angekündigt werden

Die Alternative ist keine bessere Benachrichtigung. Sie besteht darin, den Zustand dort lesbar zu machen, wo die Arbeit ohnehin liegt. Wer ihn braucht, findet ihn beim Hinsehen, statt informiert zu werden, wenn das System rät.

Das kehrt die Last um. Ein Push muss die richtige Person im richtigen Moment erreichen und scheitert regelmässig an beidem. Ein sichtbarer Zustand muss nur wahr sein. Wer das Asset öffnet, bekommt die Antwort, auch jene, an die niemand beim Benachrichtigen gedacht hätte.

Was weiterhin fehlt, ist die Dauer. Auch ein lesbarer Zustand beantwortet was, nicht wie lange, und wie lange trennt eine Warteschlange von einer Blockade. Ein Team, das das Alter jedes Zustands sähe, würde aufhören zu fragen, wer langsam ist. Es würde fragen, was seit Dienstag wartet. Diese Frage hat eine Antwort und eine nächste Handlung. Die erste hat keines von beidem.

Wo das gilt

Ein Team zu dritt in einem Raum braucht das nicht, dort ist der Zustand durch Aufblicken lesbar. Ebenso wenig Arbeit, die in einem Zug durchläuft und kein Warten enthält. Es zählt dort, wo Übergaben Organisationsgrenzen kreuzen und die Beteiligten zwischen Kampagnen wechseln. Am meisten zählt es dort, wo niemand aus dem Gedächtnis sagen kann, was gerade auf wen wartet, und wo diese Frage jede Woche kommt.