Agiler Lebenszyklus — die unterstützende Seite des Lebens

Zusammenfassung

In meinem vorherigen Blog'Agiler Lebenszyklus — Die Projektseite des Lebens', erklärte ich die Vorteile der agilen Arbeitsweise in Projekten. Transparenz, Kommunikation und feste versus variable Aspekte sind für agiles Projektmanagement von entscheidender Bedeutung. Wenn Sie sich jedoch den gesamten Lebenszyklus einer Software ansehen, hört dieser nicht auf, nachdem das Projekt veröffentlicht wurde.

In unserem Fall liefert die Forschungs- und Entwicklungsabteilung ein Produkt, das beim Kunden vor Ort eingeführt wird (agile Entwicklung). Das Bereitstellungsteam ist für das Projekt und mögliche Anpassungen bei Bedarf verantwortlich und wird dies auf agile Weise handhaben (agile Projekte). Nach der Genehmigung übernimmt die Wartungsabteilung die Anwendung und wartet sie bestmöglich. Funktioniert das für uns?

Um es offen zu sagen, nein...

DIE BRÜCKE ZWISCHEN AGILEN PROJEKTEN UND AGILEM SUPPORT

Wenn Sie eine Anwendung von einem Bereitstellungsteam an ein Wartungsteam übertragen, müssen Sie eine gewisse Übergabe durchführen. Lean-Prinzipien legen immer Wert darauf, die Anzahl der Übergabezeitpunkte in Ihrem Prozess zu begrenzen, da dies als Verschwendung betrachtet wird und zu Risiken führt, die Sie vermeiden möchten. Obwohl unser Übergabeprozess optimiert ist, kommt das größte Risiko von einer anderen Seite. Der Kunde...

Wenn Sie Ihre Projekte agil ausführen, fördern Sie nicht nur Ihre Kunden, sondern lassen sie sich auch an eine bestimmte Arbeitsweise gewöhnen. Da die meiste Arbeit vor Ort beim Kunden erledigt wird, die Kommunikation direkt, transparent und häufig erfolgt und der Kunde die volle Kontrolle über alle Aspekte des Projekts hat, wecken Sie eine gewisse Erwartung. Diese Erwartung ist schwer zu erfüllen, wenn Sie die Anwendung auf herkömmliche Weise unterstützen und verwalten.

Die meisten Support-Abteilungen arbeiten mit einem ITIL-, ISM-, ASL- oder BiSL-Prozess. Diese Art von Prozessen oder Methoden ist bekannt für ihre Prozessvorlagen, Vereinbarungen und Best Practices. Aus Sicht des Supports ist an diesen Ansätzen nichts auszusetzen, aus Kundensicht jedoch schon.

Stellen Sie sich einen Kunden vor, der an einen agilen Projektansatz gewöhnt ist, bei dem er sofort mit dem Projektteam kommunizieren kann, er kann an jedem Aspekt des Projekts die Knöpfe drehen, Entscheidungen können zu sofortigen Maßnahmen führen und er hat die volle Kontrolle über die Liste der Elemente und die Priorisierung dieser Elemente. Und dann... wird das Projekt veröffentlicht und an die Support-Abteilung übergeben.
Plötzlich werden die Fragen, Probleme, Änderungen und Verbesserungen, die ein Kunde in der Anwendung haben möchte, als Ticket behandelt. Auswirkungen, Dringlichkeit und Priorität werden von der Support-Abteilung festgelegt, wobei der Kunde nur eingeschränkt oder gar nicht daran beteiligt ist. Die Reaktions- und Lösungszeiten werden auf der Grundlage der vertraglichen Vereinbarungen berechnet. Der Ablauf eines Tickets ist vordefiniert und lässt keine schnellen Änderungen zu.
Alles, was wir im Projekt für unseren Kunden getan haben, wird durch die Art und Weise, wie wir den Kunden bei der Wartung des Lebenszyklus unterstützen, zunichte gemacht.

Gibt es eine Möglichkeit, es anders zu machen? Ja, es gibt...

AGILER SUPPORT

Was wäre, wenn Sie Ihren Kunden agilen Support anbieten könnten? Was wäre, wenn Sie Ihrem Kunden ermöglichen könnten, alle Vorteile des agilen Ansatzes im Supportprozess zu nutzen?

Wenn Sie sich den Wartungsteil des Lebenszyklus ansehen, haben Sie einen Ansprechpartner auf Kundenseite, Sie haben eine Liste mit Tickets, die repariert oder entwickelt werden müssen, Sie haben eine verantwortliche Person an Ihrer Seite und Sie müssen ein neues Paket von Leistungen liefern. Es scheint, dass alle Komponenten für einen agilen Ansatz vorhanden sind. Warum also nicht agil damit umgehen?

Wie wirken sich die Begriffe der agilen Entwicklung auf den Support aus?

STELL DIR DAS VOR...

Ein Kunde hat ein Problem (Anwenderbericht). Sie können das Problem bei uns protokollieren und wir werden es dem hinzufügen Rückstand. Ein Mitarbeiter des Kunden (Produkteigentümer) kann priorisieren Sie das Problem. Nicht nach ITIL-Methode der Priorisierung (hoch, mittel, niedrig), sondern auf agile Weise bedeuten 20 Stockwerke 20 Prioritäten. Das Problem mit Priorität 1 wird also zuerst bearbeitet, bis es behoben ist oder der Product Owner feststellt, dass ein anderes Problem eine höhere Priorität hat. Der Kunde hat die volle Kontrolle über die Priorisierung seines Problems und es wird niemals eine Diskussion darüber geben, in welcher Reihenfolge die Tickets bearbeitet werden sollen.

Wenn ein Ticket vom Kunden erstellt wird, bestimmt die Support-Abteilung die“Punkte“ von diesem Ticket. Dies bestimmt nicht die Priorität des Problems, sagt aber etwas über dessen Umfang und Komplexität aus. Da die Priorität auch anhand der Anzahl verwandter Probleme gemessen werden kann, bestimmt der Support auch das Verhältnis zu bereits vorhandenen Tickets. Wenn Sie die Punkte zu den Tickets hinzufügen, können Sie leicht feststellen, ob die Support-Abteilung die Angelegenheit selbst bearbeiten kann oder ob wir dafür Backup-Techniker hinzuziehen müssen.

Durch eine enge Kommunikation mit dem Kunden (steh auf) können wir direktes Feedback zur Ticketliste haben (Sprint-Protokoll) und die Dinge, auf die wir warten. Jeden Tag werden wir diesen Stand Up veranstalten, sodass der Kunde immer über den Status der Probleme, die Dinge, die wir von ihm erwarten und, was noch wichtiger ist, über die Dinge, die er von uns erwarten kann, informiert ist. Auch wenn nichts passiert ist, ist es trotzdem ratsam, den Kunden auf dem Laufenden zu halten. Dies berücksichtigt die gegenseitigen Erwartungen und wird zu wenig bis gar keinen Diskussionen führen.
Stories (oder Tickets) haben keinen ITIL-Status (wie „Neu“, „Akzeptiert“, „Unterbrochen“, „In Bearbeitung“, „Gelöst“, „Geschlossen“), sondern können einfach „Zu erledigen“, „Wird ausgeführt“, „Erledigt“ lauten. Da eine enge Kommunikation besteht, ist es nicht erforderlich, dass alle möglichen Situationen im Ticketstatus berücksichtigt werden.

Durch die Einführung einer Evaluierungsphase (Rückblick) nach einer Wartungsversion oder dem Rollout eines Patches können wir feststellen, wie zufrieden der Kunde ist und welche Dinge wir in einem zukünftigen Patch oder Release verbessern können.

IST DAS WIRKLICH NOTWENDIG?

In naher Zukunft sind die Funktionen der von Ihnen gelieferten Produkte möglicherweise nicht mehr das Hauptunterscheidungsmerkmal zwischen Ihnen und Ihren Mitbewerbern. Sie könnten sich für eine Preisdifferenzierung entscheiden, aber es kann nur einen geben, der am günstigsten ist. Ich bin davon überzeugt, dass Differenzierung im Service erfolgen muss. Wenn Sie ein agiles Erlebnis bieten, können Sie ein herausragendes Serviceunternehmen sein. Bitte teilen Sie mir mit, was Sie von diesem Blogbeitrag halten. Ich bin wirklich neugierig auf deine Meinung.