Schnelle Rollbacks: Der beste Freund des Produktmanagers

Wenn Sie Features testen, ist die Zwickmühle schon vorprogrammiert.

Einerseits brauchen Sie Daten aus der realen Welt und Feedback von realen Usern. Sie wissen: Jedes neue Feature entwickeln Sie bestenfalls aus einer begründeten Vermutung darüber, was Ihre User aus der realen Welt von Ihnen erwarten. Egal, wie fundiert diese Vermutung sein mag und wie ausgiebig Sie das Feature intern validieren – aussagekräftige Daten und Feedback für ein neues Feature erhalten Sie nur, wenn Sie es für reale User veröffentlichen, damit sie das Feature in realen Umgebungen testen.

 Andererseits ist es riskant, Usern aus der realen Welt ein Feature zur Verfügung zu stellen, das sich noch nicht bewährt hat. Sie wissen, dass beim Release eines neuen Features nicht unbedingt alles rund läuft. Vielleicht haben Sie bei der Entwicklung ein technisches Problem übersehen. Oder das Feature deckt sich weniger mit den Benutzererwartungen als Sie sich erhofft haben. Egal, woran es liegt: Die Freigabe eines unerprobten Features kann der Beziehung der User zu Ihrer Marke ernsthaft schaden.

Dieses knifflige Problem wird sich nie vollständig lösen lassen. Zum Glück gibt es jedoch Methoden, mit denen Sie das Problem minimieren können: Sie sammeln reale Daten und reales Feedback und federn gleichzeitig die Auswirkungen ab, falls (unweigerlich) etwas schief läuft. 

In diesem Blogpost gehen wir näher auf eine dieser Methoden ein: das Rollback.

Was ist ein Rollback?

Das Rollback ist eine einfache Methode mit großer Tragweite.

Wenn Sie ein Rollback durchführen, nehmen Sie einige Codes aus einer Liveumgebung heraus. Früher konnten Rollbacks wirklich gigantisch sein. Zur Aktualisierung der Software wurden riesige neue Releases mit einer Fülle von Änderungen bereitgestellt – neue Features und signifikante Änderungen an bestehenden Features inklusive. Wenn eines dieser Releases ein paar schwerwiegende Bugs enthielt oder bei den Usern nicht gut ankam, musste eventuell alles zurückgesetzt werden (selbst wenn sich die Probleme nur auf wenige Elemente des Release beschränkten).

Das alles hat sich mit der Einführung der agilen Methode geändert. Releases werden immer kleiner und erfolgen in zunehmend engeren Abständen, genauso wie die Rollbacks. Die meisten Produktmanager setzen heute auf abgestufte Releasepläne, in denen jeweils nur ein einziges neues oder aktualisiertes Feature freigegeben wird – oft auch nur für einzelne Segmente. Und wenn Produktmanager heute mehrere neue oder aktualisierte Features auf einmal freigeben, sind die verschiedenen Features voneinander getrennt.

 Diese Entwicklung hat die Art und Weise verändert, in der Rollbacks durchgeführt werden. Nach einem neuen Release können die Produktmanager nun einzelne Features isolieren, die sich im Live-Betrieb nicht bewähren und ein gezieltes Rollback einzig für diese Features durchführen. Der ganze Rollback-Prozess ist jetzt deutlich schneller, flexibler und präziser und bietet wesentlich größere Vorteile.

Weshalb sollten Produktmanager Rollbacks durchführen?

Ein Produktmanager, der Rollbacks sorgfältig strukturiert und bereitstellt, schafft bessere Voraussetzungen, um neue Features in einer realen Umgebung mit realen Nutzern bei minimalem Risiko zu testen. Ein mangelhaftes Feature bedeutet nicht mehr das Ende der Welt. Bei einem Entwicklungsproblem oder sollte das Feature nicht richtig auf die Anforderungen der User abgestimmt sein, können Sie das Feature durch ein Rollback mit nur einem Klick in Echtzeit aus einer Liveumgebung entfernen.

Für Produktmanager ändert sich damit alles. Je ausgereifter die Rollback-Fähigkeit ist, desto eher können Sie sich Fehler erlauben. Ihr Risiko sinkt mit der Möglichkeit, mehr Features mit mehr Usern in einem früheren Stadium der Entwicklungszyklen zu testen. Sie können Ihre Produkte im Endeffekt immer schneller iterieren.

Rollbacks sind allerdings keine Wunderwaffe. Sie müssen trotzdem alles daran setzen, um im Vorfeld des Tests möglichst hochwertige Features zu entwickeln. Allerdings ermöglichen Ihnen Rollbacks, neue Features mit mehr Zuversicht und weniger Bedenken hinsichtlich eventueller Probleme für die User zu testen. 

Wann sollten Sie ein Rollback durchführen? Zwei allgemein verbreitete Use Cases

 Für die meisten Produktmanager gibt es zwei allgemein verbreitete Use Cases, die möglicherweise ein Rollback notwendig machen.

Rollback Use Case 1: Ihr Feature hat einen Bug

Dieser Use Case erklärt sich eigentlich von selbst.

Sie verfügen vielleicht über die aussagekräftigsten und gründlichsten QA- und Testverfahren der Welt. Trotzdem weisen Ihre neuen Features höchstwahrscheinlich immer noch einen oder mehrere Bugs auf, wenn sie in einer Liveumgebung freigeschaltet werden. Dabei kann es sich um Probleme handeln, nach denen Sie gar nicht erst gesucht haben, oder Sie wussten nicht, wie sie suchen sollten. Oder die Probleme tauchen erst in der Liveumgebung auf, nachdem Hunderte von realen Usern mit dem Feature herumexperimentiert haben.

Wie auch immer: Wenn in Ihrem neuen Feature ein signifikantes technisches Problem auftritt, werden Sie wahrscheinlich ein Rollback für das betreffende Feature durchführen, um das Problem zu beheben. Mit dem richtigen Rollback-Verfahren können Sie auf diese Fehler nahezu in Echtzeit reagieren und das Feature in Minutenschnelle entfernen – und möglicherweise sogar reparieren, bevor zu viele User von den Auswirkungen betroffen sind. 

Rollback Use Case 2: Ihr Feature wird schlecht angenommen

Der zweite Use Case ist etwas komplexer.

Wenn Sie ein neues Feature freigeben, beobachten Sie im Prinzip, wie die User darauf reagieren und in welchem Maße die KPIs Ihres Unternehmens erreicht werden. Falls Ihr neues Feature nicht die gewünschten Ergebnisse erzielt und Nutzungsdaten sowie User Feedback negativ sind, können Sie das betreffende Feature durch ein Rollback aus seiner Liveumgebung entfernen. Sollte das Feature die gesetzten Geschäftsziele nicht erreichen oder zumindest nicht auf dem richtigen Weg sein, ist es wahrscheinlich nicht sinnvoll, es in der Liveumgebung zu lassen.

Wenn Sie Ihr Feature zurücksetzen, können Sie entweder die gesammelten Daten und das Feedback nutzen, um das Feature zu reparieren und besser auf die Erwartungen der User und die Anforderungen des Unternehmens abzustimmen. Oder Sie entfernen das Feature, weil es Ihrer Meinung nach grundsätzlich ungeeignet war.  

Mit dem richtigen Rollback-Verfahren können Sie sich zudem mit den Nutzungsdaten und dem User Feedback befassen und nahezu in Echtzeit entsprechend reagieren. So vermeiden Sie, dass sich zu viele User über ein Feature ärgern, das sein Ziel verfehlt.

Was haben die beiden Use Cases gemeinsam?

In einem Wort: Tempo. 

In beiden Fällen sind Rollbacks sehr effizient – und weniger risikoreich – wenn Sie in der Lage sind, zuerst die Leistung des Features in Echtzeit zu überwachen, dann aufgrund dieser Leistung eine schnelle „Ja/Nein-Entscheidung“ für oder gegen ein Rollback zu treffen und zum Schluss diese Entscheidung möglichst schnell umzusetzen. 

Je schneller Sie diesen ganzen Prozess abwickeln, desto geringer ist die Wahrscheinlichkeit einer längeren negativen User Experience. In manchen Szenarien muss innerhalb weniger Minuten ein Rollback entschieden und durchgeführt werden. 

Eine gewaltige Aufgabe. Hier finden Sie jedoch ein paar Tipps, die Ihnen dabei helfen sollten.

Wie Sie schneller Rollback-Entscheidungen treffen

Es ist eine echte Herausforderung, auf der Stelle eine Entscheidung für oder gegen das Rollback eines Features zu treffen. Selbst beim besten Feature kann das Release komplex und unübersichtlich sein.

Viele Komponenten müssen überwacht werden…

 Viele verschiedene Daten und Feedback-Punkte müssen berücksichtigt werden…

Und es sind viele Emotionen im Spiel…

Sie haben mit Ihrem Team gerade Wochen, manchmal sogar Monate mit Schweiß, Blut und Tränen alles für den Entwurf und die Entwicklung des Features gegeben, das gerade getestet wird. Wenn das neue Feature Ihren Usern gefällt, kommt Euphorie auf. Sie wissen, dass Sie Ihren Job gut gemacht haben und können sich einfach zurücklehnen und zusehen, wie die richtigen Daten und positives Feedback hereinströmen. Wenn Ihre User jedoch nicht sofort so positiv wie erwartet reagieren, kann es leicht zu einem emotionalen Tief kommen. Sie wollen das Feature zurücksetzen, bevor Sie überhaupt wissen, ob die Reaktion allgemein negativ ist. Ganz zu schweigen davon, dass Sie keine Ahnung haben, wie Sie Ihre Fehler in der nächsten Iteration beheben können. 

Aus diesen und noch vielen anderen Gründen ist es sehr schwierig, bei einem Feature Release-Test sofort die richtige Rollback-Entscheidung zu treffen. Deshalb ist es besser, Ihre Rollback-Entscheidungen zu treffen, bevor Sie Ihre neuen Features auf die User „loslassen“.  

Hier erfahren Sie, was wir damit sagen wollen.

Bevor Sie neue Features für reale User freischalten, entscheiden Sie im Grunde genommen, wie sich Erfolg und Misserfolg für dieses Feature nach objektiven, datengetriebenen Kriterien darstellen sollen. 

Dann entscheiden Sie, wie viele Daten Ihr Release generieren muss, bevor Sie genau beurteilen können, ob das Feature ein Erfolg ist oder nicht.

Und schließlich nutzen Sie diese Parameter während der freigeschalteten Release, um objektive „Ja/Nein-Entscheidungen“ darüber zu treffen, ob das Feature an einer bestimmten Stelle zurücksetzt werden soll. Statt kalt erwischt zu werden, überwachen Sie einfach die Leistungskennzahlen, die Sie für besonders wichtig halten. Sobald die Kennzahlen die Grenzwerte erreichen, die Sie vor der Release festgelegt haben, gehen Sie nach Plan vor und setzen das Feature zurück – oder auch nicht. Sie müssen sich in diesem Fall nicht in Echtzeit zu einer Entscheidung durchringen.

Wie Sie Rollbacks schneller durchführen

Früher war ein schnelles Rollback aus technischer Sicht nahezu unmöglich. Sie brauchten ein technisches Team, das bereitsteht und darauf wartet, sich in den Code zu vertiefen, um Live-Features abzuschalten oder die gesamte Plattform wieder in den vorherigen Zustand zu versetzen. Der gesamte Prozess war langsam, arbeitsintensiv und hielt unsere technischen Teams von ihrer wertvollen Entwicklungsarbeit ab.  

Jetzt macht Software Schluss mit diesen Problemen. Mit unserer eigenen Plattform – Flagship – können Sie ein Feature in Echtzeit zurücksetzen, indem Sie ein einziges Feld mit nur einem Klick umschalten. Sie brauchen kein technisches Know-how. Sie müssen vor dem Release eines Features kein komplexes Rollback-Verfahren entwickeln und testen. Sie müssen sich nicht einmal über die technischen Details Gedanken machen – sie können sich diese Überlegungen zu den richtigen strategischen Entscheidungsbäumen sparen, die wir oben erläutert haben.

Flagship bietet Ihnen oder jedem beliebigen User, der kein Techniker ist, die Möglichkeit, anspruchsvolle Feature Releases und Rollbacks durchzuführen. Sie können mehrere Features auf einen Schlag freigeben, überwachen, wie jedes einzelne Feature performt und nur die Features zurücksetzen, die nicht die gewünschten Ergebnisse erzielen. Sie können ein Feature für eine Reihe von User Segmenten veröffentlichen und nur das betreffende Feature bei den einzelnen Segmenten zurücknehmen, die nicht wie erhofft reagieren. Wir haben Flagship konzipiert, um die Durchführung von Rollbacks schneller, einfacher und wesentlich intuitiver zu machen als je zuvor.

Sie möchten eine Webdemo von Flagship und sehen, wie Rollbacks funktionieren? Oder Sie möchten mit uns darüber diskutieren, wie sich eine effiziente Rollback-Strategie für Ihre Use Cases darstellen könnte? Vereinbaren Sie noch heute eine kostenlose, unverbindliche Demo. 

 

Share on linkedin
Share on Linkedin
Share on facebook
Share on Facebook
Share on twitter
Share on Twitter