Von wiederkehrenden Incidents zum Verbesserungs-Backlog
Beispielhafter Anwendungsfall, keine Fallstudie.
Wiederkehrende Vorfälle werden nach wahrscheinlicher Ursache gruppiert und gegen ihre Ticketkosten bewertet, damit der Verantwortliche Korrekturen in einem Verbesserungs-Backlog priorisieren kann.
Das Problem
Dieselben Incidents kommen jeden Monat zurück: eine ausfallende Schnittstelle, ein Bericht, der beim Abschluss in den Timeout läuft, eine Konfiguration, die nach jedem Release abdriftet. Jeder wird für sich gelöst, niemand ist für das Muster verantwortlich, und das Supportbudget zahlt immer wieder für dasselbe Problem.
So läuft es heute
Incidents werden einzeln geschlossen, sobald das Symptom verschwunden ist. Ein Monatsbericht zählt Tickets nach Kategorie. Eine Ursachenanalyse findet nur bei Major Incidents statt. Verbesserungsanfragen konkurrieren mit neuen Projektanforderungen und werden selten eingeplant, sodass die wiederkehrende Arbeit in der Support-Warteschlange bleibt.
Das Szenario ansehen
Kurzüberblick
Beispielhafter Arbeitsablauf. Mit Untertiteln.
Transkript
- Dieselben Incidents kommen jeden Monat zurück. Jeder wird für sich gelöst, niemand ist für das Muster zuständig, und das Supportbudget bezahlt dasselbe Problem erneut.
- Gelöste Incidents werden nach wahrscheinlicher Ursache gruppiert. Für jede Gruppe wird der Behebungsaufwand geschätzt und mit den Tickets und Arbeitsstunden verglichen, die durch das Wiederauftreten entstehen.
- Der Verantwortliche gibt Behebungen für das Verbesserungs-Backlog frei. Änderungen durchlaufen Release-Prüfungen, und die Incident-Daten zeigen, ob das Problem zurückkehrt.
- Gemessen an der Wiederauftretensrate und den Supportstunden für wiederkehrende Incidents. Beispielhafter Anwendungsfall. Sprechen wir über Ihren.
Ausführliches Szenario
Illustratives Szenario. Eine fiktive Fachkraft im Anwendungssupport macht aus einem Vorfall, der jeden Monat wiederkehrt, eine vom Verantwortlichen priorisierte Verbesserung, die Release-Prüfungen durchläuft. 1:05
Transkript
- Sam erkennt das Ticket schon vor dem Öffnen. Dasselbe Symptom ist zurück, und mit ihm dieselbe Untersuchung.
- Einzeln wurden die Vorfälle gelöst. Zusammen deuten sie auf ein wiederkehrendes Problem hin, das einen Verantwortlichen verdient.
- Gruppieren Sie die Vorfälle nach wahrscheinlicher Ursache, prüfen Sie das Muster und vergleichen Sie den Aufwand einer Behebung mit der Supportarbeit, die das Wiederauftreten verursacht.
- Der Verantwortliche entscheidet, ob die Behebung ins Verbesserungs-Backlog gehört und wo sie gegenüber anderen Prioritäten steht.
- Freigegebene Änderungen durchlaufen Release- und Regressionsprüfungen. Eine vorgeschlagene Verbesserung ist keine Erlaubnis, die Produktion zu ändern.
- Verfolgen Sie nach dem Release, ob das Problem zurückkehrt und wie viel Supportaufwand es bindet. Welches wiederkehrende Problem sollte Ihr Team als Nächstes untersuchen?
- [Schlusstafel] Welches wiederkehrende Problem sollte Ihr Team als Nächstes untersuchen? Ihre wiederkehrenden Incidents besprechen. qxorbit.ai/de/contact
- Beispielhafter Anwendungsfall, keine Fallstudie.
Vorgeschlagener Arbeitsablauf
- Gelöste Incidents anhand der Incident-Taxonomie, der Lösungsnotizen und der betroffenen Komponenten nach wahrscheinlicher Ursache gruppieren
- Für jede wiederkehrende Gruppe die Behebung bemessen: die nötige Änderung, die berührten Umgebungen, der Release- und Regressionsaufwand
- Die Behebung den wiederkehrenden Kosten gegenüberstellen: Tickets pro Monat, Engineer-Stunden, von den Verantwortlichen beschriebene Geschäftsauswirkung
- Die gereihten Kandidaten dem Anwendungsverantwortlichen vorlegen, der entscheidet, was ins Verbesserungs-Backlog aufgenommen wird
- Freigegebene Behebungen über den Release-Prozess mit Regressionsprüfungen ausliefern und das Wiederauftreten nach dem Release beobachten
Wo ein Mensch die Kontrolle behält
- Gruppierung und Bemessung sind Vorschläge; der Verantwortliche entscheidet, was behoben wird und in welcher Reihenfolge
- Geplante Verbesserungen folgen dem vereinbarten Release- und Regressionsprozess; dringende Änderungen erfordern die vereinbarte Notfallfreigabe
- Wiederauftretensdaten über einen vereinbarten Beobachtungszeitraum prüfen, bevor entschieden wird, ob der Verbesserungspunkt geschlossen wird
Die Plattformzuordnung nennt die Umgebungen, in denen diese Idee geprüft werden kann. Die tatsächliche Umsetzung hängt von Konfiguration, Lizenzen, APIs, Daten und Berechtigungen ab. Der Nutzen wird qualitativ beschrieben; Zahlenangaben erfordern eine dokumentierte Ausgangsbasis.