Wie Flagship das Leben der Tech Teams bei AB Tasty leichter macht

Wir haben Flagship – unsere Feature Management Platfform und Decision API – entwickelt, um Tech Teams mit effektiveren Möglichkeiten auszustatten, eine reibungslose Customer Experiences zu liefern. Selbstverständlich nutzen wir bei AB Tasty ebenfalls Flagship. Aber in der Vergangenheit mussten wir unsere Entwicklungszyklen auch ohne das Tool abwickeln.

In diesem Artikel möchten wir Ihnen gerne einen Einblick darüber geben, wie sich die Arbeit unserer Tech Teams dank Flagship geändert hat. Wie haben wir vorher gearbeitet? Was hat sich geändert? Und weshalb gefällt uns das Tool? Finden wir es kurzerhand heraus!

Wie sich ein typischer Entwicklungszyklus ohne Flagship darstellt

Zu Beginn eines typischen Entwicklungszyklus steht ein Problem oder ein User Need im Raum, für das wir eine Lösung finden möchten. Wir beginnen mit der Entdeckungsphase, in der wir dahingehend arbeiten, die Situation und die sich stellenden Fragen von Grund auf zu verstehen. So können wir Ideen für mögliche Lösungen generieren, die dann im Rahmen eines Proof of Concept (POC) bestätigt werden. Dazu implementieren wir in der Regel eine Quick and Dirty Variante – das Minimum Viable Product (MVP) – die wir dann für einen oder zwei KundInnen mit einem Canary Release testen.

Wenn wir den Eindruck haben, dass die Lösung auf die Bedürfnisse der KundInnen eingeht, beginnen wir mit der Iteration des MVP. Wir weisen dem Projekt mehr Ressourcen zu, um robuste, sichere und anwenderfreundliche Bedingungen zu erhalten. Im Laufe dieses Prozesses wechseln wir so lange zwischen Entwicklung, Bereitstellung und Testen ab, bis wir das Gefühl haben, die Lösung mit unserer gesamten Anwenderbasis wirklich teilen zu können. Das ist der Moment, wo wir wissen, wie unsere NutzerInnen auf die Lösung reagieren und wie diese Lösung in einer realistischen Umgebung performt.

Die Fallstricke dieses Ansatzes oder: Warum wir Flagship entwickelt haben

Schauen wir uns an, weshalb wir mit dieser Strategie nicht besonders glücklich waren und uns entschieden haben, sie zu optimieren. Hier einige wichtige Schwachpunkte, die wir entdeckt haben:

Testergebnisse, die nicht überzeugen

Ein Canary Release mit einem oder zwei KundInnen ist für einen ersten Eindruck gut, bietet aber keine zufriedenstellende Erkenntnis über die Auswirkung dieser Lösung auf eine breitere User Base. Uns fehlte es an qualitativen und quantitativen Testdaten. Auch hatten wir keine Möglichkeit, diese einfach und zielorientiert zu nutzen. Manuelle Versuche und Fehler bremsten uns aus. Und wir waren nicht immer mit den Ergebnissen unserer Iterationen zufrieden, sodass wir uns nicht auf sie verlassen konnten.

Instabiles Feature Management

Entwickler wurden aufgrund neuer Releases oft nervös, weil sie nicht wussten, wie sich das Feature unter einer höheren Belastung verhalten würde. Wenn in der Produktion etwas falsch lief, war es immer unglaublich anstrengend, den gesamten Entwicklungszyklus zu durchlaufen, um den fehlerhaften Code zu deaktivieren. Und das ist nur ein Beispiel dafür, weshalb wir eine einwandfreie Feature Management-Lösung brauchten.

Wir beobachten, dass Tech Teams rund um den Globus dieselben Schwierigkeiten erleben und fürchten. Genau deshalb haben wir Flagship entwickelt, um ihnen – und uns – zu helfen, Innovationen schneller denn je anzubieten und gleichzeitig Risiken und Kopfzerbrechen weitestgehend auszuschalten.

Wir haben uns mit einigen unserer Tech KollegInnen unterhalten, um herauszufinden, wie sich ihr Arbeitsleben verändert hat, seitdem sie Flagship nutzen. Uns fielen einige wichtige Themen auf, auf die im Folgenden näher eingegangen wird.

Wir kennen die Auswirkung eines neuen Features

Unsere Produktteams müssen einen klaren Zusammenhang zwischen einem Business KPI und einem getesteten Feature herstellen. In der Vergangenheit haben wir mit Google Analytics getrickst, um eine grobe Vorstellung zu erhalten. Aber ohne eigenständige Kontroll- und Testgruppen für unsere Experimente konnten wir nicht wissen, ob unsere Änderungen etwas bewirkten.

Mit Flagship gehört das Ratespiel der Vergangenheit an und wir können einem eher wissenschaftlichen Ansatz folgen. Wir wissen jetzt mit Sicherheit, ob sich das betreffende Feature positiv auf ein Business KPI auswirkt.

Angenommen, wir veröffentlichen ein neues Feature während das Marketingteam eine Kampagne startet, ohne dass wir darüber informiert sind. Wir könnten anormale Testergebnisse wie erhöhte Zahlen bei Traffic, Engagement und Klicks erhalten. Das Problem: Wie können wir die reelle Wirkung unseres Features messen?

Mit Flagship können wir Kontrollgruppen definieren, um diese Gefahr nahezu auszuschalten. Und dank der statistischen Modellierung (Bayessche Statistik) erhalten wir präzise Daten, aus denen wir verlässliche Schlüsse ziehen können.

Die Entdeckungsphase steht und fällt mit qualitativen Informationen – aber wie können Sie verlässliche Daten erhalten? Unsere Antwort: mit kontrollierten Experimenten und progressivem Deployment.

Einmal haben wir an einer neuen Version einer unserer APIs gearbeitet und Flagship für Lastentests verwendet. Zum Glück haben wir bemerkt, dass der Dienst an einem bestimmten Punkt zusammenbrach, als wir die Anzahl der User (Lasten) langsam steigerten. Das Problem lag nicht zwangsläufig am Feature selbst, sondern an den Änderungen der Umgebung, die bei traditionellen Web-Testingstrategien leicht übersehen werden können. Wir konnten die Bereitstellung jedoch unverzüglich stoppen und die End-UserInnen oder unsere SLAs vor API-Änderungen schützen. Stattdessen konnten wir die API weiter stabilisieren und allen UserInnen sicher zur Verfügung stellen.

Wir trennen Code Releases von Bereitstellungen der Features für eine schnellere Iteration

Häufig stellen wir halbfertige Features für die Produktion bereit – selbstverständlich „hüllen“ wir sie im Hinblick auf ihren Status und ihre Sichtbarkeit in Feature Flags. Mit dieser Technik können wir den iterativen Prozess deutlich schneller als zuvor abwickeln. Wir müssen nicht mehr darauf warten, bis das Feature präsentabel ist, um unsere ersten Experimente und Tests zu starten. Stattdessen sind wir vollkommen flexibel und können genau festlegen, wann und mit wem wir testen.

Zudem müssen wir nicht länger mühsam herausfinden, wer sehen kann, was während der Feature-Entwicklung in Produktion ist, weil wir diese Dinge nicht mehr in unseren Code integrieren müssen. Stattdessen verwenden wir die Decision API, um Features mit der Admin-Schnittstelle von Flagship zu verbinden, über die wir die Zielgruppen jederzeit festlegen und ändern können.

Darüber hinaus kann theoretisch jeder im Team dieses Interface nutzen und sehen, wie das neue Feature performt, ohne die Entwickler einzubinden. Eine enorme Zeitersparnis, wodurch sie sich auf ihre eigentlichen Aufgaben konzentrieren können.

„Mit Flagship kann ich wieder die Kontrolle über meine eigenen Features erhalten. In meinem alten Job musste ich in Echtzeit nachweisen, was ich machte. Und manchmal hatte ich Schwierigkeiten, meine eigenen Daten hinsichtlich CDP MOA zu erhalten. Jetzt bekomme ich sie.“

Julien Madiot, Technical Support Engineer

Wir können uns auf sichere Bereitstellungen verlassen

Richtiges Feature Management hat definitiv zu Veränderungen geführt, d. h. wie wir arbeiten und unsere Arbeit betrachten. Und mit dem Management der Feature Flags dank Flagship hat sich der gesamte Prozess für unsere großen und diversen Teams vereinfacht.
JEDES Feature muss in ein Feature Flag „gepackt“ werden – wahrscheinlich eine der wichtigsten Regeln in der Entwicklung. Aber es lohnt sich:

  1. Es sind EIN/AUS-Schalter. Seien wir ehrlich: Wir machen immer noch Fehler oder übersehen Probleme. Aber das bedeutet nicht das Ende der Welt. Vor allem nicht, wenn unser Code in einem Feature Flag eingeschlossen ist, sodass wir ihn „abschalten“ können, wenn es problematisch wird! Mit Flagship als wichtigste Grundlage für Feature Management können wir dies sofort machen, ohne den Code bereitstellen zu müssen.
  2. Features Flags helfen uns, kontrollierte Experimente durchzuführen. Wir verwenden Feature Flags und Flagship, um Tests und Experimente unter reellen Bedingungen, d. h. in der Produktion sicher durchzuführen. EntwicklerInnen oder sogar NutzerInnen, die keinem Tech Team angehören, können die Testzielgruppen im Flagship Dashboard festlegen, ändern und erweitern. Dadurch müssen wir diese Änderungen nicht programmieren oder uns an unsere Codebase heranwagen!
  3. Sie beseitigen den Stress bei den Bereitstellungen. Manchmal möchten wir den Code in die Produktion pushen, wollen aber noch nicht, dass er aktiviert wird. Praktisch, wenn ein Feature fertig ist. Aber wir warten auf das endgültige „Go!“ des Produktowners. Wenn die Zeit gekommen ist, können wir das Feature mühelos im Dashboard von Flagship aktivieren.

DevOps-Ingenieure tragen eine große Verantwortung, wenn die Software ausgeliefert werden soll. Unsere Feature Flags mit Flagship zu managen, ist eine effiziente Möglichkeit, um die Last von ihren Schultern zu nehmen:

Seitdem wir Flagship mit Flagship verwenden, schlafe ich deutlich besser, ganz ehrlich 🙂 Weil ich derjenige bin, der donnerstags die Dinge in Produktion gibt. Wenn gesagt wird „Hoppla, wir haben das versehentlich in die Produktion geschickt“, kann ich jetzt sagen; „Ja, aber mit Flag.“

Guillaume Jacquart, Technical Team Leader

Takeaway

Wir hoffen, dass der Blick hinter die Kulissen von AB Tasty für Sie sowohl interessant als auch informativ war. Und falls Sie sich gefragt haben, ob wir Flagship auch für die Entwicklung von Flagship Features nutzen, die Antwort ist: ja. So können wir das Produkt verbessern und sicher sein, dass es seinem Zweck dient und für moderne Tech Teams ein wertvolles Tool ist. Möchten Sie erfahren, wie Produktteams in Ihrem Unternehmen von unserem Tool profitieren können? Probieren Sie Flagship aus! Folgen Sie diesem Link, um eine Demo zu buchen.

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

Ressourcen für Ihre Experience Optimierung

Alles, was Sie über Experimente, Personalisierung und Feature-Management für Ihre Websites, Apps und Geräte wissen müssen.
Werfen Sie Ihren hart verdienten Traffic nicht weg
Lassen Sie Ihre Website Überstunden machen - damit Sie es nicht tun müssen.
+250%
Click-Through-Rate
+19%
Conversion Rate
+5%
Durchschnittlicher Warenkorbwert
Trusted by

Demo anfragen