Softwareversionierung: So startet ihr mit WENIGER Beschwerden

Es kann sich um Version 2 oder Version 12 handeln – doch grundsätzlich gilt: Je komplexer ein System mit der Zeit wird und je mehr Funktionen hinzukommen, desto wahrscheinlicher treten bei der Einführung einer Version Probleme auf.

Und je größer die Nutzerbasis wird – über verschiedene Geräte, Betriebssysteme und Browser hinweg, um nur einige zu nennen –, desto mehr Möglichkeiten gibt es nach einem Launch für Bedienfehler, Bugs und Incidents.

Manchmal ist es unvermeidlich: Ganz gleich, wie hart und gewissenhaft wir arbeiten, wir sind nicht perfekt. Aber es ist ehrlich gesagt erstaunlich, wie viele Probleme sich bei einem neuen Versions-Release durch einfache, wirksame Kommunikation mit euren Nutzern vermeiden lassen.

Und vergesst, eure Release Notes, Listen mit „HEISSEN NEUEN FEATURES!“ oder Pressemitteilungen per E-Mail zu verschicken. Denn die Hälfte dieser E-Mails landet direkt im Spam. Der Rest wird entweder ignoriert oder falsch verstanden.

Zum Glück gibt es bessere Wege, mit eurer Nutzerbasis zu kommunizieren und einen reibungslosen Übergang zwischen Versionen sicherzustellen – mit weniger Beschwerden und Support-Tickets.

Nach dem Release beschweren sich Nutzer über eingeschränkte Funktionen – obwohl weiterhin alles vorhanden ist

Ein großes Release kann anstrengend sein, noch bevor Änderungen übernommen und ausgerollt werden. Doch sobald Nutzer die Anwendung verwenden, kann es unübersichtlich werden.

Manchmal werden Funktionen und Features verschoben, um Platz für andere, neuere oder höher priorisierte Features zu schaffen. Wenn ihr das euren Nutzern nicht wirksam kommuniziert habt, könnt ihr mit einer Vielzahl an Support-Tickets rechnen, in denen gefragt wird, warum sie „diese eine Sache“ nicht mehr tun können.

Denkt daran: Nicht jeder hat Zeit, seine E-Mails zu durchsuchen und Versionshinweise zu lesen. Viele Postfächer filtern automatisierte E-Mails heraus, insbesondere in schnelllebigen Organisationen mit hohen Anforderungen. Eine automatisierte E-Mail ist für euch zwar eine einfache Lösung, doch die Menschen, auf die es wirklich ankommt, erhalten entweder nicht die Informationen, die sie brauchen, oder sie werden in einem völlig ineffektiven Format präsentiert.

Auf jeden Fall braucht ihr Release Notes für eure Versionen. Aber muss sie wirklich jeder lesen? Überlegt, wie ihr das Release-Erlebnis für Nutzer verbessern könnt:

• Fügt dem Login- oder Startbildschirm ein Pop-up zu „neuen Features“ hinzu. Haltet es kurz und einfach, um Frustration zu vermeiden.

• Lasst eure PR- und Marketingteams bei der Entwicklung zentraler Botschaften helfen, oder: Schreibt wie eine Boulevardzeitung – gebt euren Nutzern SCHLAGZEILEN zu neuen Features und verlinkt anschließend auf die vollständigen Release Notes. Probiert ein kurzes Erklärvideo zu „Was ist neu in Version X?“ aus.

• Kommuniziert über mehrere Kanäle, nicht nur per E-Mail. Sorgt über alle Kanäle hinweg für eine klare Botschaft und verlinkt auf die Release Notes.

• Schreibt wie eine Boulevardzeitung – gebt euren Nutzern SCHLAGZEILEN zu neuen Features und verlinkt anschließend auf die vollständigen Release Notes.

• Probiert ein kurzes Erklärvideo zu „Was ist neu in Version X?“ aus.

Um einen Schritt voraus zu sein, schaut in Foren nach häufigen Problemen bei anderen Releases – nicht unbedingt euren eigenen – und versucht, dort auftretende Probleme vorbeugend zu entschärfen.

Oh oh. Das IST tatsächlich ein Incident!

Incidents passieren. Und sie sind ernst. Bei einem schwerwiegenden Incident ist die Reaktionsgeschwindigkeit euer größter Vorteil – stellt also sicher, dass ihr vorbereitet seid.

Verbindet eure CI/CD-Pipeline mit Jira Service Management (oder anderen ITSM-Plattformen), damit euer Team Probleme, die gerade in die Produktivumgebung ausgerollt wurden, schneller identifizieren kann.

Hier kommt es auf gute Organisation an: Erstellt Kategorien anhand mehrerer Attribute, damit Elemente mit hoher Priorität zuerst auffallen. Legt Schwellenwerte für die Anzahl verknüpfter Incidents fest und definiert anschließend automatisierte Eskalationswege.

Jira Service Management Service Centre und Confluence können zusammenarbeiten, um dies zu beschleunigen und während eines Incidents klar zu kommunizieren. Verwendet Tags und Keywords, um Inhalte vor dem Absenden einer Anfrage anzuzeigen.

Bei einem schwerwiegenden Incident folgt ihr wahrscheinlich eurem Major-Incident-Prozess. Ein Teil davon findet in eurem Workflow statt, mit Automatisierung und Integration zwischen eurem ITSM sowie Dokumentations- oder kollaborativen Arbeitsbereichen.

Ein Teil davon liegt außerhalb des ITSM: das Management von Ressourcen und Beziehungen.

Die Geschäftsleitung wird Fragen stellen. Kunden werden Druck machen.

Währenddessen wird euer Dev-Team hart arbeiten, um den Incident zu beheben. Es kann verlockend sein, sie mit Statusanfragen zu überhäufen, wenn ihr selbst ständig danach gefragt werdet. Bedenkt jedoch, welche Auswirkungen das auf ihren Fokus, ihre Effektivität und ihr Wohlbefinden hat.

Und behaltet auch eure eigenen im Blick.

Schwerwiegende Incidents sind selten. Doch wenn sie eintreten, möchtet ihr wissen, dass ihr darauf vorbereitet seid, die Folgen zu begrenzen.

Sind euer Jira und Confluence darauf vorbereitet, nach einem Versions-Release einen schwerwiegenden Incident zu bewältigen?

Engagiert einen Atlassian-Experten, um eure Workflows auf das nächste Level zu bringen

ClearHub ist darauf spezialisiert, die besten Atlassian-Auftragnehmer weltweit zu finden – geprüft, auf ihre Fähigkeiten getestet und bereit, eure DevOps- und ITSM-Plattformen auf alles vorzubereiten.

Δ