Wenn Sie mit Hochdruck daran arbeiten, etwas zu versenden, übersehen Sie leicht die eine Sache, die über Erfolg oder Misserfolg Ihres Projekts entscheiden könnte. Und nein, ich spreche nicht von irgendetwas, das mit der Entwicklung des Produkts selbst zu tun hat.

Ich spreche darüber, was passiert nach der Start - Unterstützung.

70% der Softwareprojekte scheitern, weil sich nach dem Start niemand um sie kümmert.

Warum ist das so wichtig? Und wie macht man das eigentlich richtig?

‍

„Nach dem Go-Live? Es läuft jetzt einfach von selbst.“ (Spoiler: Das wird es nicht.)

Ihr Team steckt seit Wochen oder Monaten tief im Programmieren.

Du hast versendet. Nichts ist abgestürzt. Der Kunde ist glücklich. Zeit zum Feiern.

Hier ist der Haken. In vielen Fällen der riskanteste Teil beginnt jetzt. Und es geht nicht nur um Bugs.

Das ist der Zeitpunkt, an dem sich echte Nutzer ihre Meinung zu der ganzen Sache bilden. Das meiste, was den Leuten beim IT-Support wichtig ist, ist kein ausgefallenes Design oder eine lange Liste von Funktionen. Es ist ganz einfach: Wenn etwas kaputt geht, hilft mir jemand schnell und klar?

Die ersten 30 Tage = Test in der realen Welt

Beim Testen hat alles funktioniert. Jetzt haben Sie echte Daten, echte Benutzer und echte Randfälle.

Das Zeug wird kaputt gehen. Das tut es immer. Manche Probleme sind klein. Andere können den Wert des Projekts zunichte machen.

Wie vermeidet man es also, den Start zu vermasseln? Hier sind ein paar Dinge, die Sie sperren sollten vor du klickst auf „Deploy“:

‍

Wer ist der Ersthelfer?

Es klingt offensichtlich, aber das bringt so viele Teams zum Stolpern.

Sie benötigen eine Person oder ein Team, das für eingehende Probleme zuständig ist. PM, Lead Dev, Support — das spielt keine Rolle. Was zählt, ist, dass jemand weiß, dass er am Haken ist, wenn etwas kaputt geht.

Im ersten Monat sollte dies ihr Hauptaugenmerk sein. Anstatt „E-Mail senden und warten“, erhalten Benutzer eine schnelle Antwort.

Was ist, wenn etwas Wichtiges kaputt geht?

Sie benötigen kein formelles Playbook. Du brauchst einen Plan.

Wer kann eine Veröffentlichung rückgängig machen?
Wer erklärt den Nutzern, was los ist?
Wer prüft, ob das Problem unser Code oder etwas in der Infrastruktur ist?

Sonst versucht jeder auf einmal zu helfen, und das ist nicht gut. Deshalb macht eine Person, der der Prozess gehört, den Unterschied.

Wie schnell antworten Sie?

Wie ich bereits erwähnt habe, benötigen die Leute nicht immer eine sofortige Lösung. Aber sie müssen wissen, dass sie nicht ignoriert werden.

Selbst eine kurze Nachricht wie „Wir haben es gesehen, wir überprüfen es gerade, werden Sie später am heutigen Tag informieren“ macht einen großen Unterschied.

‍

Wie gehst du mit Feedback um?

Im Chaos der Anfangszeit ist es leicht, Tickets als Dinge zu behandeln, die man einfach reparieren und vergessen muss. Aber sie sind nicht nur das. Sie sagen dir, was die Nutzer erwartet haben und was nicht. Markiere sie deutlich. Bug, Funktionsanfrage, UX Problem, Dokumentationslücke. Und verfolgen Sie, ob dieselben Dinge mehr als einmal auftauchen.

Drei verschiedene Benutzer, die dasselbe melden? Das ist kein Randfall.

‍

Wann sind wir fertig?

Es klingt komisch, aber du brauchst eine Ziellinie. Andernfalls endet der „Launch Support“ nie wirklich.

Wählen Sie eine Regel — 30 saubere Tage, Benutzerabmeldung oder einen festen Termin. Stellen Sie einfach sicher, dass jeder weiß, wann das Projekt vom Startmodus zum normalen Support wechselt. Wenn Sie all dies vor der Inbetriebnahme einrichten, vermeiden Sie später eine Menge Stress und Ihr Post-Launch wird sich tatsächlich wie ein Erfolg anfühlen.

‍

Sie möchten mehr über dieses Thema erfahren?

Neugierig mehr zu erfahren? Lesen Sie die Meinung unserer IT-Supportleiterin Sue zu den sieben Prinzipien des Softwaretests. Sie erklärt es mit Tipps und Ratschlägen aus der Praxis.

‍

Benötigen Sie Hilfe beim Durchdenken Ihres Post-Launch-Prozesses? Greifen Sie auf uns zu! wir teilen gerne mit, was für uns funktioniert hat.