Sie haben die Geschichte schon gehört, oder?
Kohleabbau war eine gefährliche Arbeit. Jederzeit konnten sich Kohlebergwerke mit tödlichen, aber nicht wahrnehmbaren Gasen füllen. Also haben sich Bergleute einen ganz einfachen Trick ausgedacht, um am Leben zu bleiben: Sie nahmen einen Kanarienvogel mit nach unten. Die Kanarienvögel reagierten auf diese tödlichen Gase empfindlicher als Bergleute. Wären giftige Gase in die Mine eingedrungen, wären die Kanarienvögel als Erste gestorben. Die Bergleute wären somit gewarnt gewesen und hätten den Stollen verlassen, bevor ihnen dasselbe Schicksal widerfahren wäre.
Softwareentwickler nahmen sich diese Geschichte zu Herzen und entwickelten ihre eigene Methode, Gefahren in ihrer Arbeit aufzudecken, bevor es für ihre Applikation zu spät ist. So entwickelten sie „Canary Releases“ – eine bewährte Methode im Rahmen des Feature Releasemanagements, bei der eine neue Funktion einer kleinen User-Gruppe bereitgestellt wird, um sie in einer Live-Umgebung zu testen. Sollte etwas bei dem neuen Feature vollkommen falsch laufen, würden die Entwickler vom Canary Release gewarnt werden, bevor das Feature für die breite User Base freigeschaltet wird und dann wirklichen Schaden anrichten würde.
Softwareentwickler sollten nicht ihr eigenes Leben, sondern das Überleben der Software schützen, die sie entwickelten. Sie waren in der Lage, Probleme zu suchen und zu beheben, in der Realität genutzte Daten zu sammeln, die im Hinblick auf eine bessere Software umgesetzt werden, und allgemein das Risiko besonders kritischer Momente im Lebenszyklus der Softwareentwicklung und des Release zu minimieren.
Für Produktmanager sind Canary Releases mittlerweile zu einem „Must-do“ geworden. Selbst ein einziger Bug oder ein falsch ausgerichtetes Feature kann Monate harter Arbeit vernichten, wenn nicht sofort gegengesteuert wird, solange die Probleme noch gering sind und unter Kontrolle gehalten werden können.
Das sind die schlechten Nachrichten. Die gute Nachricht aber ist: Sie können diesem potenziellen Krisenszenario mit einem Canary Release vorbeugen, das sogar schnell, einfach und intelligent durchgeführt werden kann, wenn Sie sich die folgenden drei wichtigen Fragen stellen.
Frage 1: Welche User kommen für Ihr Canary Release in Frage?
Eine entscheidende Frage. Leider gibt es aber nicht die eine „richtige“ Antwort. Welche User-Gruppe Sie wählen, hängt konkret von der Art Ihres Canary Release ab und davon, was Sie sich von dem Release erhoffen.
Generell gibt es hier zwei Denkmodelle:
- Release für eine „warme“ Zielgruppe.
- Release für eine „kalte“ Zielgruppe.
Nach dem ersten „warmen“ Denkmodell müssten Sie Ihr Canary Release Erstanwendern bereitstellen, die Ihnen dann eine Frühwarnung geben. Prinzipiell kennen Sie diese User und wissen, dass sie Ihnen gegenüber positiv eingestellt sind und das Produkt schätzen, ja ständig verwenden. Nachdem Sie die User ausgewählt haben, informieren Sie sie im Voraus darüber, dass sie einige neue Features erhalten, die noch nicht perfekt sind, sodass sie mit kleinen Problemen rechnen müssen.
Der Vorteil hier ist simpel – Sie erhalten Feedback und Daten von Usern, die mit Ihren neuen Features in einer realen Umwelt herumexperimentieren. Allerdings scheuen Sie dabei möglichst jedes Risiko.
Der Nachteil ist etwas subtiler. Da Sie Ihr Feature für eine „warme“ Zielgruppe freigeben, können Sie sich nicht sicher sein, ein zu 100 % ehrliches Feedback zu erhalten. Und da diese Gruppe oft aus Erstanwendern und Power Usern besteht, ist es auch nicht sicher, dass sie genauso wie normale Durchschnittsnutzer mit den neuen Features herumspielen und technische Probleme umgehen.
Nach dem zweiten, dem „kalten“ Denkmodell sollten Sie User nach dem Zufallsprinzip auswählen, die Sie im Voraus benachrichtigen oder nicht, dass sie einige neue, potenziell fehlerhafte Features testen werden.
Bei dieser User-Gruppe bestehen deutlich größere Risiken, wenn neue Features getestet werden. Allerdings erhalten Sie auch Daten, die vertrauenswürdiger, realistischer und nutzbarer nicht sein könnten. Sie werden sehen, wie eine Vielzahl von Usern Ihr Feature nutzt. Sie werden deutlich größeres, glaubwürdiges Feedback generieren (vor allem, wenn etwas nicht richtig funktioniert) und insgesamt werden Sie eine deutlich klarere Vorstellung davon erhalten, was tatsächlich passiert, wenn Sie heute Ihr neues Feature freischalten würden.
Welche User-Gruppe sollten Sie also wählen?
In der Praxis werden Sie vermutlich eine User Base wählen, die zwischen diesen beiden Extremen liegt. Sie werden wahrscheinlich eine etwas erweiterte Segmentierung und Personalisierung vornehmen, mit denen Ihre neuen Features für eine Zielgruppe freigegeben werden, die für diese getesteten Features besonders relevant und geeignet ist, aber auch hinreichend untergliedert ist, damit Sie nicht Gefahr laufen, unter dem Strich Ihrem Produkt dauerhaft zu schaden, sollte das Release schlecht sein.
Genau genommen können Sie sich mit dem richtigen Ansatz an beide Gruppen wenden – Tests mit mehreren Zielgruppen durchführen, die Ihnen jeweils verschiedene Formen von wertvollem Feedback und Daten bieten. Sie können sogar mehrere Tests mit mehreren Zielgruppen für mehrere Features deutlich einfacher als zuvor durchführen.
Hier die Gründe, weshalb.
Frage 2: Welche Features werden Sie in Ihrem Canary Release testen?
Diese Frage müsste sich einfach beantworten lassen. Sie konnten ein Canary Release eigentlich nur für eine relativ begrenzte Anzahl von Feature-Tests bereitstellen. Aber in den letzten Jahren sind Ihre Möglichkeiten regelrecht explodiert. Hier, was sich geändert hat.
In der Vergangenheit waren für den Launch von Canary Releases relativ viele Ressourcen notwendig. Sie konnten Ihre Codebasis gefährden und Sie viel Zeit, Aufmerksamkeit und Mühe kosten. Und sie konnten den Entwicklungsprozess insgesamt drastisch verlangsamen. Immer wenn Sie ein Canary Release durchführen wollten, mussten Sie sicherstellen, dass sich dieser Aufwand auch 100 % lohnt – und das schränkte die Art von Funktionen, die Sie testen konnten, stark ein.
Größtenteils lohnten sich Canary Releases nur für besonders sichtbare High-Touch-Funktionen, die für die Applikation grundlegend waren, d. h. Dinge wie die umfassende Überarbeitung einer ganzen Funktionsreihe oder funktionaler Eckpunkte Ihrer Anwendung. Im Großen und Ganzen lohnte es sich nicht, Ressourcen im Rahmen eines Canary Release für den Test einer einzigen, kleinen, isolierten Funktion einzusetzen.
Dadurch waren Ihre Möglichkeiten begrenzt und Sie konnten nicht schnell, agil und reaktiv vorgehen. Sie mussten abwarten, bis genügend Funktionen bereitgestellt wurden, bevor Sie auch nur eine von ihnen testen konnten. Sie konnten nach einem Feedback oder nach dem Erhalt von Daten aus Ihrem Release nicht jede Funktion auf die Schnelle erneut in Angriff nehmen. Kurz gesagt – Ihr Canary Release war nicht besonders agil.
Aber heute sind Sie mit dem richtigen Ansatz deutlich flexibler, wenn Sie entscheiden müssen, welche Funktionen während Ihres Canary Release getestet werden sollen. Jetzt können Sie eine einzige, kleine, isolierte Funktion testen, sobald sie bereitgestellt werden kann – in einer realen Umgebung, ohne substanziellen Mehraufwand für Ihr Team.
Und so wird‘s gemacht
Frage 3: Wie führen Sie Ihr Canary Release faktisch durch?
Canary Releases waren derart ressourcenintensiv, weil alle damit verbundenen Vorgehensweisen mehr oder weniger manuell verliefen.
Sie mussten einen Weg finden, die aktualisierte Version Ihrer Applikation nur bestimmten Usern bereitzustellen. Sie mussten sowohl kurz- als auch langfristige Änderungen an Ihrem Code vornehmen, konfigurieren und überwachen. Sie mussten jede einzelne User-Gruppe im Rahmen verschiedener Tests manuell verfolgen und die Nutzung, das Feedback und jeden KPI dokumentieren, der von den Tests direkt betroffen war. Und all dies mussten Sie abwickeln, während die Funktionen der Standardversion Ihrer Anwendung perfekt aufrecht gehalten werden mussten.
Für den gesamten Prozess waren viele Stunden notwendig. Ein fehlerträchtiger Prozess. Und es war nicht möglich, schnelle, komplexe Tests durchzuführen, auch nicht mit den besten Teams an Ihrer Seite.
Was hat sich also geändert?
Mit einem Wort: die Software.
Jetzt können Sie viele Prozesse im Rahmen eines Canary-Tests und jedes Experiment mit einem einzigen Dashboard auf einer einzigen zentralen Plattform durchführen.
Mit der richtigen Plattform können Sie:
- den gesamten Test gestalten und konfigurieren
- mehrere Funktionen unabhängig voneinander testen
- mehrere besonders personalisierte Segmente erstellen und Testroutinen erstellen
- alle Tests mit einem Button-Klick starten
- die Leistung jeder Funktion und User-Gruppe in Echtzeit überwachen
- alles selbst durchführen, ohne viel Zeit zu investieren
Das Beste von allem: Mit der richtigen Plattform wird das Risiko im Zusammenhang eines Canary Release sogar noch weiter reduziert. Mit einem einfachen Feature-Flagging können Sie die einzelnen getesteten Funktionen als Reaktion auf ihre Echtzeit-Leistung jederzeit aktivieren und deaktivieren. Sie müssen nicht Ihr gesamtes Release zurückschrauben, wenn nur eine Funktion in nur einer Funktionsgruppe falsch funktioniert – Sie können diese Funktion für eine bestimmte User-Gruppe ausschalten und die restlichen Funktionen weiterhin testen.
Wir haben diese Funktionalität und weitere Elemente auf unserer eigenen Plattform – Flagship – gebündelt. Wir sind der Überzeugung, dass Canary Releases ein kritisches Element jedes agilen Produktentwicklungsplans sind. Und wir haben getan, was wir konnten, damit diese Releases so simpel, einfach und kostengünstig wie möglich durchgeführt werden können.
Klicken Sie einfach hier, um mehr über unsere Plattform zu erfahren und SOFORT mit Ihrem ersten Canary Release zu beginnen.
