Der Tag, an dem ich unseren Backlog um 2000% vergrößerte - ohne ein einziges neues Ticket
Ein gespeicherter Filter verbarg ein Jahrzehnt lang Geisterkunden - und mein Dank dafür war die Bitte, sie wieder verschwinden zu lassen
Vor einigen Jahren, in einem sehr großen Unternehmen mit einer sehr ausgereiften Support-Organisation, übernahm ich ein Nebenprojekt: unsere Mean Time To Resolution senken (MTTR - die durchschnittliche Zeit von Ticketerstellung bis zur Lösung). Standardkost. Tooling analysieren, Workflow straffen, Slides präsentieren, höflichen Applaus einsammeln.
Stattdessen fand ich ein schwarzes Loch.
Der Workflow war wie aus dem Lehrbuch. Kunde eröffnet ein Ticket, Techniker löst es, Techniker schließt es. Jeder Techniker nutzte denselben gespeicherten Filter - dokumentiert im Onboarding-Wiki, vererbt an jeden Neuzugang seit ungefähr der Erfindung des Smartphones: "Zeige meine offenen Tickets."
Beim Umbau unserer Ansichten änderte ich eine einzige Zeile. Mein Filter lautete jetzt: "Zeige meine offenen Tickets UND geschlossene Tickets mit einer eingehenden Kundennachricht."
Hunderte Tickets tauchten aus dem Nichts auf.
Die meisten waren harmlos. "Nochmals vielen Dank für Ihre Unterstützung!" Liebenswerte Menschen, die höflich ins Leere sprachen. Aber dazwischen, verstreut zwischen den Dankeschöns: "Das Problem besteht weiterhin, bitte helfen Sie mir." "Ich möchte diesen Fall erneut öffnen." "Ist da jemand?"
Hunderte Kunden, über Jahre hinweg, die nach der Schließung zurückkamen und das Firmenäquivalent eines Besetztzeichens erhielten.
Der Teil, der wirklich zählt: Ein Zustand ohne Besitzer existiert nicht
Niemand war faul. Niemand war zynisch. Ich arbeitete mit herausragenden Technikern 🐎, die für diese Kunden über glühende Kohlen gegangen wären - hätten sie die Nachrichten jemals gesehen.
Hier ist der Mechanismus, und er reicht weit über den Support hinaus: Nicht das Organigramm in der Personalabteilung zeigt Ihnen Ihre echte Aufbauorganisation - es sind die offenen Fälle und Filter Ihrer Leute. Die Ansichten, die Ihre Mitarbeiter morgens öffnen, sind die vollständige Liste dessen, was Ihr Unternehmen überhaupt wahrnehmen kann. Alles, was in einem Zustand lebt, den keine Ansicht anzeigt, hat keinen Besitzer. Und alles ohne Besitzer existiert nicht als Arbeit. Es existiert nur als Schaden.
Conway's Law - die Beobachtung, dass Systeme am Ende die Kommunikationsstruktur der Organisation widerspiegeln, die sie baut - wird normalerweise im Kontext von Softwarearchitektur zitiert. Es wirkt auch in die Gegenrichtung. Und zwar härter. Unser Tooling hatte einen Zustand namens "geschlossen mit neuem Kundeninput." Unsere Organisation hatte keine Rolle, die diesen Zustand verantwortete. Also gewann das Tool. Zehn Jahre lang, in eine Richtung.
Und achten Sie darauf, wie dieser Zaun entstand: Niemand hat ihn gebaut. Chesterton's Fence besagt, man soll keinen Zaun einreißen, bevor man weiß, warum jemand ihn dort errichtet hat. Die unbequeme Folgerung, die niemand zitiert: Manche Zäune wurden von niemandem errichtet. Sie sind gewachsen. Ein Standardfilter, geschrieben von einer Person, die vor einem Jahrzehnt das Unternehmen verließ, ins Wiki kopiert, durch Wiederholung geheiligt und irgendwann mit einer bewussten Entscheidung verwechselt. Es gab keine Logik, die man hätte respektieren können. Nur Ablagerungen.
Die Umkehrung ist das, was mich bis heute zusammenzucken lässt. Wenn Sie mich gebeten hätten, eine Support-Organisation zu entwerfen, die stillschweigend Vertragsverlängerungen ruiniert, während jedes Dashboard grün leuchtet - ich hätte genau eine Sache getan: Ich hätte die verzweifeltste Rückmeldung des Kunden in einen Zustand geleitet, den kein Report abfragt. Das ist alles. Keine Inkompetenz nötig. Kein Bösewicht. Ein Filter.
Warum die erste Reaktion des Managements ein Feueralarm war
Das Backlog sprang über Nacht um rund 2000% nach oben, und man bat mich - mit echtem Nachdruck -, das rückgängig zu machen, was auch immer ich getan hatte.
Denken Sie über diesen Reflex nach. Das Problem war zehn Jahre alt. Das einzig Neue im Gebäude war Sichtbarkeit. Aber Sichtbarkeit ist nicht neutral: Ein Jahrzehnt lang war die MTTR eine ehrliche Antwort auf eine unehrliche Frage gewesen. Die Kennzahl hatte nie gelogen. Sie hatte nur nie das Elend mitgezählt, weil das Elend aus der Abfrage herausgefiltert wurde, bevor sie überhaupt lief. Korrigieren Sie die Karte, und plötzlich sieht das Gelände so aus, als hätte es Zähne bekommen.
Genau hier scheitern gute Techniker. Ich kam mit Daten. Daten lesen sich wie Anklage. Womit ich hätte anfangen sollen - und was am Ende auch funktionierte - war ein Rahmen: Diese Altlast existiert bereits, sie existiert seit bevor die meisten von uns angefangen haben, und wir sind das erste Team auf der Welt, das sie sehen kann. Dieselben Fakten, eine völlig andere emotionale Form. Logik bewegt niemanden, der gerade ausrechnet, wie er dabei aussieht.
Wir arbeiteten den Berg ab. Entschuldigten uns großzügig und ohne Ausreden, was Kunden sehr viel bereitwilliger verzeihen als Schweigen. Schrieben den Filter in die tägliche Routine und ins Wiki. Rund neunzig Tage später lag unsere Kundenzufriedenheit um etwa vier Punkte höher. Keine KI-Initiative (die es damals ohnehin noch nicht gab), keine Reorganisation, keine siebenstellige Tool-Migration. Eine Zeile in einer Filterdefinition, später ausgerollt an jedes Support-Team im Unternehmen.
Mein Lohn war ein Händedruck. Der Lohn des Managements war, sagen wir, etwas liquider. Ich habe meinen Frieden damit gemacht. Weitgehend.
👉 Prüfen Sie Ihre Standardansichten so gründlich wie Ihren Produktivcode. Listen Sie für jedes Objekt in Ihrem System die Zustände auf, die es einnehmen kann, und prüfen Sie dann, welche davon in irgendjemandes Morgenansicht auftauchen. Die Zustände, die nirgends erscheinen, sind Ihre schwarzen Löcher - und sie enthalten mit Sicherheit Ihre wütendsten Kunden.
👉 Eine Kennzahl ist eine Abfrage plus ein Filter. Alle streiten über die Kennzahl. Niemand liest den Filter. Der Filter ist der Ort, an dem gelogen wird - und meist lügt er durch Auslassung, geschrieben vor Jahren von jemandem, der es gut meinte.
👉 Bevor Sie das Licht einschalten, formulieren Sie den entscheidenden Satz vor. "Das ist kein neuer Schaden, das ist neu sichtbarer Schaden" kauft Ihnen eine Arbeitssitzung statt einer Hexenjagd.
👉 Der günstigste Zufriedenheitsgewinn ist fast nie eine neue Funktion. Er entsteht dadurch, eine laufende Beleidigung zu beenden, von der Sie nicht wussten, dass Sie sie aussprechen.
Jede Organisation hat Kunden, die in einen Zustand hineinschreien, den niemand verantwortet. Die gesunden Unternehmen können diesen Zustand benennen. Die übrigen haben ein sehr beeindruckendes Dashboard.
👇 Welche Zustände in Ihren Systemen haben keinen Besitzer - und wer würde es als Erster erfahren, wenn ein Kunde darin feststeckt?
Dieser Artikel ist auch auf English verfügbar.
TrenchOps DE 🇩🇪🐎
0 comment(s)
No comments yet. Be the first to comment.
Leave a comment