Das Marketing Team von Whitepages hatte sich zum
Ziel gesetzt, die Conversion Rate zu erhöhen und
die Zahl der Mitgliedschaften für das monatliche
Abonnement zu steigern, indem die Struktur der
Preisseite verbessert und den Kunden der Vergleich
erleichtert wird.

Erfahre in dieser Case Study, wie Whitepages die Conversion Rate um 23 % und die Anzahl der monatlichen Mitgliedschaften um 31 % mit AB Tasty‘s Feature Experimentation erhöht hat.

The post Whitepages steigert die Anzahl an Abos mit AB Tasty‘s Feature Experimentation appeared first on abtasty.

Da es jedoch Millionen von Apps gibt, sind der Wettbewerb und die Ansprüche und Erwartungen der Verbraucher so hoch wie nie zuvor. Das bedeutet, dass deine App in einem überfüllten Markt herausstechen muss.

Es ist wichtig, darauf hinzuweisen, dass die Entwicklung mobiler Apps nicht demselben Prozess folgt wie die einer Website App.

In diesem Artikel gehen wir auf die Herausforderungen beim Mobile App Deployment – also der Bereitstellung und Veröffentlichung von mobilen Apps – ein und erläutern, wie du mithilfe von Feature Flags optimierte Mobile Apps erstellen kannst, die den Bedürfnissen deiner Kunden entsprechen.

Diese Inhalte erwarten dich in diesem Blogartikel:

Die Herausforderungen beim Mobile App Deployment

Der Wert von Feature Flags für die Bereitstellung und Freigabe mobiler Apps

Wie kannst du Feature Flags beim Mobile App Deployment verwenden?

Mobile Feature Flags: Use Cases
Use Case 1: Decathlon
Use Case 2: EDF
Use Case 3: Ornikar

Fazit: Feature Flags – Das ultimative Tool für Mobile App Deployment und bessere mobile Erlebnisse

Die Herausforderungen beim Mobile App Deployment

Mobile Entwicklungsteams sind besonders anfällig für Bugs und lange, langwierige Veröffentlichungszyklen.

Kurz gesagt gibt es zwei Hauptprobleme, wenn es um die Freigabe oder Aktualisierung von Funktionen für mobile Anwendungen geht:

1. Du musst warten, bis die App-Stores die Freigabe erteilen (was einige Zeit dauern und die Veröffentlichung erheblich verzögern kann).
2. Danach musst du warten, bis die Nutzer die Aktualisierung manuell aus dem Store herunterladen (was ebenfalls viel Zeit in Anspruch nehmen kann).

Betrachten wir zum Beispiel folgendes Szenario: Du arbeitest an einem Update für deine mobile App. Du gibst es schließlich frei, um dann festzustellen, dass du einen Fehler übersehen hast, der zum Absturz deiner App führt.

In der Zeit, in der du ein neues Update mit einer Fehlerbehebung veröffentlichst, auf die Veröffentlichung im App Store wartest und darauf wartest, dass die Benutzer das Update herunterladen, riskierst du den Verlust einer beträchtlichen Anzahl von Benutzern.

Entwickler und Techniker von Mobilgeräten sind mit einem solchen Szenario nur allzu vertraut. 

Daher kann es ein mühsamer und langwieriger Prozess sein, bis eine Version genehmigt wird. Nach der Genehmigung muss jede fehlerhafte Version korrigiert werden und den App-Store-Genehmigungsprozess von neuem durchlaufen, was zu weiteren Verzögerungen führt. 

Obwohl sich die Überprüfungszeit in den letzten Jahren verbessert hat, kann es zu weiteren Verzögerungen kommen, wenn deine App nicht den Prüfungsrichtlinien des App Stores entspricht. Dies bedeutet, dass du keine Echtzeit-Updates für die Produktion bereitstellen kannst, wie dies bei Web Apps der Fall ist.

Vereinfacht gesagt, ist der Prozess des Mobile App Deployments nicht so einfach wie die Bereitstellung von Web Apps. 

Im Gegensatz zu Web Apps, die automatisch aktualisiert werden, sobald Besucher auf die Website zugreifen, müssen Benutzer eine Aktualisierung der mobilen App in ihrem Store herunterladen, um die neueste Version zu erhalten.  Da sich die Updates nach dem Überprüfungsprozess stapeln, hast du keine Kontrolle darüber, ob die Nutzer die neuesten Versionen herunterladen. 

Daher kann die Bereitstellung von Updates für mobile Apps im Vergleich zu Web Apps mehr Zeit in Anspruch nehmen. Und in einer Zeit, in der die Kunden immer das Beste verlangen, ist es nicht machbar, sie so lange auf ein Update warten zu lassen, vor allem, wenn es sich um einen Fehler handelt, ganz zu schweigen von der Bereitstellung einer neuen App-Version, sobald der Fehler behoben ist.  

In der modernen Softwareentwicklung, in der eine kontinuierliche Bereitstellung unerlässlich ist, um wettbewerbsfähig zu bleiben und die sich schnell ändernden Anforderungen der Kunden zu erfüllen, müssen die Teams auf eine andere Lösung zurückgreifen, um eine höhere Veröffentlichungsfrequenz zu erreichen.

Bleibe up to date in Sachen Customer Experience Optimization: Melde dich zu unserem Newsletter an. Jetzt anmelden!

Der Wert von Feature Flags für die Bereitstellung und Freigabe mobiler Apps

An dieser Stelle kommen Feature Flags ins Spiel.

Im Gegensatz zu clientseitigen Tests, bei denen sich die Experimente auf Webbrowser konzentrieren, geben Feature Flags den Teams die Möglichkeit, serverseitige Experimente über mehrere Kanäle, einschließlich mobiler Apps, durchzuführen.

Feature Flags ermöglichen es Teams, Funktionen für Benutzer ihrer Wahl zu aktivieren oder zu deaktivieren, um Risiken und negative Auswirkungen zu minimieren.

Das bedeutet, dass du Funktionen aus der Ferne ein- oder ausschalten kannst, ohne den Code erneut in den App-Stores bereitzustellen und auf die Genehmigung zu warten oder darauf warten zu müssen, dass alle Änderungen zur gleichen Zeit fertig sind, um deine eigenen Änderungen zu veröffentlichen. Auf diese Weise kannst du Code bereitstellen, wann immer du willst.

Lies mehr dazu: Was ist Remote-Konfiguration in der App-Entwicklung?

Auf diese Weise kannst du deine App auf der Grundlage des Feedbacks deiner Nutzer kontinuierlich und in Echtzeit aktualisieren, ohne ein Update an den App Store zu senden oder auf dessen Genehmigung zu warten. Außerdem kannst du nach und nach neue Funktionen freigeben, ohne dass die Nutzer ständig ihre App-Version aktualisieren müssen.

Mit Feature Flags können Mobile-Entwickler in der Produktion sicher mit einer vordefinierten Zielgruppe testen und Funktionen mit einem Kill Switch deaktivieren, falls Probleme auftauchen. Die Entwickler können dann daran arbeiten, das Problem zu lokalisieren und zu beheben, bevor sie die Funktion für alle Benutzer freigeben.

Wie kannst du Feature Flags beim Mobile App Deployment verwenden?

Feature Flags können nicht nur von Entwicklern, sondern auch von Produkt- und Release-Managern verwendet werden, um das mobile Erlebnis auf verschiedene Weise zu optimieren.

Hier sind einige Beispiele für den Einsatz von Feature Flags in mobilen Anwendungen:

• A/B-Testing: Mit Feature Flags kannst du deine Nutzer in Untergruppen aufteilen, wobei jede Gruppe von Nutzern eine andere Variante der Funktion erhält. Auf diese Weise kannst du testen und feststellen, welche Variante am besten abschneidet und an alle Benutzer verteilt werden sollte. Einfach ausgedrückt: A/B-Tests ermöglichen dir, wertvolles Live Feedback von deinen Nutzern zu sammeln, so dass du fundierte Entscheidungen über die Optimierung deiner Funktionen und Produkte treffen kannst.
• Gezielte Rollouts: Teams können Feature Flags verwenden, um ihre Ideen zu testen, indem sie ihre Funktion schrittweise einführen und nur einer begrenzten Anzahl von Nutzern einen “Early Access” zur App gewähren, z. B. durch Betatests. Auf diese Weise kannst du die Begeisterung für die neue Funktion wecken und die Auswirkungen auf diese ausgewählten Nutzer überwachen. Gezielte Rollouts ermöglichen es den Teams, fundiertere Entscheidungen darüber zu treffen, was zu optimieren ist, und die App auf der Grundlage des Live-Nutzerfeedbacks fein abzustimmen.
• Personalisierung: Feature Flags sind eine großartige Möglichkeit, das Erlebnis für verschiedene Arten von Nutzern zu personalisieren, anstatt ein einheitliches Erlebnis für alle Nutzer zu bieten. Indem du die Funktionen änderst, die bestimmte Benutzer erhalten, kannst du das Benutzererlebnis in mobilen Apps auf einzelne Benutzer oder Benutzersegmente abstimmen. So kannst du z. B. je nach Land, in dem sich der Nutzer aufhält, ein einzigartiges Erlebnis bieten.
• Rollback/Kill Switch: Das wirklich Einzigartige an Feature Flags ist, dass sie Teams in die Lage versetzen, fehlerhafte Updates schnell wieder rückgängig zu machen. Durch einfaches Deaktivieren des entsprechenden Feature Flags kannst du einen Fehler beheben, ohne den langwierigen App-Store-Review-Prozess zu durchlaufen.

Mobile Feature Flags: Use Cases

Wir haben bisher vor allem darüber gesprochen, wie Feature Flags beim Mobile App Deployment eingesetzt werden können. Sie sind aber auch eine großartige Möglichkeit, das Risiko bei der Bereitstellung und beim Testen mobiler Websites zu verringern, insbesondere wenn es um tiefgreifende Änderungen geht, die mit der Backend-Architektur verbunden sind, wie z. B. das Testen neuer Zahlungsmethoden.

Dies lässt sich mit einer Feature-Flagging-Plattform leicht bewerkstelligen, auf der Teams mit einer benutzerfreundlichen Plattform, die von allen Teams genutzt werden kann, regelmäßige Releases sicher bereitstellen können. 

Nehmen wir zum Beispiel an, du hast zwei Zahlungsfunktionen entwickelt: eine für den Desktop und eine für das Handy. Bevor du ein vollständiges Release veröffentlichst, möchtest du sie mit einer kleinen Gruppe von Early Adopters testen, um die Auswirkungen zu überwachen und die Nutzungsrate zu bestimmen.

Mit AB Tasty kannst du ganz einfach einen Anwendungsfall für das Umschalten von Funktionen in deinem AB Tasty Konto erstellen und den KPI auswählen, den du beobachten möchtest, in diesem Fall wären das die Klicks auf den Button „Zur Kasse gehen“ und dann „Conversion Rate“ als Unter-KPI.

Anschließend kannst du zwei Szenarien definieren: eines zur Aktivierung der Funktion auf dem Desktop und ein anderes zur Aktivierung auf mobilen Geräten. Du konfigurierst dann das Flag, das die neue Zahlungsmethode für jedes Szenario aktiviert, wie im Bild unten bei „Scenario mobile“ auf dem Dashboard zu sehen ist.

Mit AB Tasty kannst du ein Szenario speziell für mobile Geräte definieren. (Quelle: Screenshot von der AB Tasty Plattform für Feature Experimentation & Rollouts)

Als Nächstes sehen wir uns Beispiele aus der Praxis an, wie AB Tasty Kunden Feature Flags für mobile Tests verwenden:

Use Case 1: Decathlon

Decathlon, ein französischer Sportartikelhändler mit mehr als 2.000 Filialen in 56 Ländern, wollte die Platzierung von CTAs testen, um deren Wirkung auf allen Geräten, einschließlich Mobilgeräten, und Produktübersichtsseiten, auch Product Listing Pages (PLPs), mit Hilfe von Feature Flags zu messen.

In der ursprünglichen Version, die unten zu sehen ist, wollte das Team von Decathlon APAC eine frühere Platzierung des „In den Warenkorb“-Buttons auf Mobilgeräten auf der Hauptseite unterhalb des Produktbildes testen, um einen positiven Rollout zu gewährleisten und den Uplift zu messen. In der ursprünglichen Version mussten die Nutzer erst auf das Produkt klicken, um zur Produktdetailseite zu gelangen, bevor sie diesen Button sehen konnten.

Decathlon testete für die mobile Version das Hinzufügen eines Warenkorb-Buttons direkt auf der Produktübersichtsseite. (Quelle: Screenshots von Decathlon)

Mit der zuverlässigen Lösung von AB Tasty war das Team in der Lage, die Auswirkungen dieser neuen Funktion auf die Conversions zu testen. Die Änderung der CTA-Platzierung erwies sich als Erfolg und führte zu einem Anstieg der Transaktionsrate um 10,37 % und einem Anstieg des durchschnittlichen Bestellwerts um 11,27 $.

Use Case 2: EDF

EDF (Electricité de France) ist seit über 70 Jahren der größte Stromlieferant in Frankreich. Das Team von EDF wollte die Zahl der Online-Abonnements und -Anrufe über seine App erhöhen.

Insbesondere wollten sie die Auswirkungen einer Änderung des CTA-Designs in der App überwachen. Durch die Verwendung von Feature Flags zur Erhöhung der Sichtbarkeit der CTAs konnte das Team die Auswirkungen auf die Klicks für Online-Abonnements bzw. -Anrufe bei EDF-Beratern messen (und steigern).

Das Team führte einen A/B-Test durch, bei dem der CTA für das Abonnement vor einem orangefarbenen Hintergrund und der CTA für den Anruf vor einem grünen Hintergrund angezeigt wurde. Sie fügten auch Text hinzu, um die Öffnungszeiten zu kommunizieren.

EDF testete die Auswirkungen einer Änderung des CTA-Designs in seiner App. (Quelle: Screenshots von EDF)

Der Anruf-CTA war derjenige, der positivere Ergebnisse lieferte und es dem Team ermöglichte, mehr qualifizierte Leads zu generieren und die Zahl der Anrufe mit EDF-Beratern zu erhöhen.

Mit einem Anstieg der Anrufe um 20 % konnte das Team dann zuversichtlich eine angepasste Variante in der App entwickeln und einführen, bei welcher der neue Anruf-CTA besser sichtbar war.             

Bleibe up to date in Sachen Customer Experience Optimization: Melde dich zu unserem Newsletter an. Jetzt anmelden!

Use Case 3: Ornikar

Oft sind A/B-Tests eine todsichere Methode, um potenzielle Verzerrungen zu beseitigen, und können ein Unternehmen davor bewahren, in eine Optimierungskampagne zu investieren, die ansonsten viel wertvolle Zeit und Ressourcen in Anspruch nehmen würde.

Das war der Fall bei Ornikar, einer Fahrschulplattform in Frankreich mit mehr als 2,5 Millionen Kunden. Das Team wollte den Startbildschirm seiner App überarbeiten und musste herausfinden, welche Änderungen beibehalten und welche verworfen werden sollten.

Das Team richtete einen A/B-Test auf AB Tasty ein, um das bestehende Karussell mit vier Slides und zwei CTAs (linkes Bild) durch einen neuen Startbildschirm mit den Vorteilen von Ornikar, einer neuen CTA-Anordnung und einem detaillierteren Karussell (rechtes Bild) zu ersetzen.

Ornikar testete eine neue Variante des Startbildschirms seiner App. (Quelle: Screenshots von Ornikar)

Der Test wurde über einen Zeitraum von drei Wochen durchgeführt. Nach einer Woche stellte das Team fest, dass die neue Variante nicht so gut funktionierte wie erwartet. Daher pausierte das Team den Test, passte den CTA an und führte den Test erneut zwei Wochen lang durch.

Die Ergebnisse waren nach zwei Wochen immer noch negativ und das Team beschloss, den neuen Startbildschirm nicht in Betrieb zu nehmen.

Dank der Flexibilität der AB Tasty Plattform war das Team in der Lage, innerhalb eines kurzen Zeitraums schnelle Iterationen vorzunehmen. Vor allem konnte Ornikar den Verlust von Konversionen und die Verschwendung von Zeit und Ressourcen vermeiden und die negativen Auswirkungen minimieren, indem es den neuen Startbildschirm zunächst testete, bevor es ihn für alle seine Nutzer einführte.

Fazit: Feature Flags – Das ultimative Tool für Mobile App Deployment und bessere mobile Erlebnisse

Wie wir gesehen haben, sind Feature Flags ein leistungsfähiges Tool, mit dem Teams in einem Unternehmen mehr Kontrolle über mobile Tests und Veröffentlichungen haben und gleichzeitig Risiken reduzieren können.

Feature Flags unterstützen dich nicht nur beim Mobile App Deployment und geben dir die volle Kontrolle über die Veröffentlichung neuer Funktionen trotz der Genehmigungsprozesse im App und Play Store, sondern ermöglichen es den Teams auch, ihre mobilen Anwendungen zu optimieren und das Benutzererlebnis zu personalisieren. Sie ermöglichen dir auch, Funktionen häufiger zu veröffentlichen und schnelles Feedback von deinen wichtigsten Nutzern zu erhalten.

Angesichts der zunehmenden Nutzung mobiler Geräte und der Millionen von Apps, mit denen du konkurrieren musst, ist es von entscheidender Bedeutung, die bestmögliche Benutzererfahrung auf mobilen Geräten zu bieten. Die Durchführung von Experimenten und die Verwendung progressiver Rollouts mit Feature Flags sind der Schlüssel zur Bereitstellung optimaler und großartiger mobiler Erlebnisse.

Die Verwendung einer Plattform eines Drittanbieters für Feature Flags erleichtert das Ein- und Ausschalten von Funktionen und die Fernkonfiguration deiner Flags direkt von der Benutzeroberfläche aus. Indem du alle deine Feature Flags in einem benutzerfreundlichen Web Dashboard kontrollierst, stellst du sicher, dass du mit den wichtigsten Best Practices Schritt hältst, um erfolgreich zu sein und dich von der Konkurrenz abzuheben.

The post Mobile App Deployment: Wie Teams Feature Flags gezielt nutzen können appeared first on abtasty.

Manchmal kann es zu viel des Guten geben, auch wenn es um Feature Flags geht.

Wir sind uns der vielen Vorteile und des Nutzens von Feature Flags für Produkt- und Entwicklungsteams bewusst, aber sie sind auch mit hohen Kosten verbunden, wenn sie nicht richtig verwaltet werden.

Zu Beginn der Entwicklung von Feature Flags mögen die Dinge noch einfach erscheinen. Sie beginnen vielleicht mit ein paar if/else-Anweisungen, aber je fortgeschrittener Ihre Anwendungsfälle werden, desto komplizierter wird es, alle Flags in Ihrem System zu verwalten.

Da aus einer Flag schnell 50 werden, kann die Anzahl der Flags schließlich so hoch werden, dass du leicht den Überblick über alle Flags verlierst, die du und deine Teams erstellt haben, was zu einer „Feature Flag Hell“ führt. Mit anderen Worten: Feature Flags werden zu einer Form von technischer Schuld.

Es gibt jedoch Möglichkeiten, die technischen Schulden in Schach zu halten, und zwar durch den Einsatz eines effizienten Tools, das dir hilft, den Überblick über alle von dir erstellten Flags zu behalten und sie dann zu entfernen, wenn sie ihren Zweck erfüllt haben. In diesem Sinne ist es wichtig, dass du Feature Flags sorgfältig und strategisch einsetzt.

In diesem E-Book stellen wir dir unsere wichtigsten Best Practices für Feature Flags vor, die du und dein Team kennen sollten, um die Fallstricke von Feature Flags zu vermeiden und stattdessen von deren Vorteilen zu profitieren:

• Plane deine Feature Flags sorgfältig
• Benenne deine Flags konsistent
• Richte eine Zugriffskontrolle ein und verwalte sie
• Begrenze und verdeutliche den Umfang der einzelnen Flags
• Bereinige Flags regelmäßig
• Schaffe eine klare Sichtbarkeit aller Flags
• Verwende ein Feature-Management-Tool

The post 7 Best Practices für Feature Flags appeared first on abtasty.

Dies bedeutet nicht, dass Ihre beliebten Rollout- und Feature-Management-Tools verschwinden. Es bedeutet vielmehr, dass wir ein neues, aufregendes Kapitel für AB Tasty aufschlagen, mit dem Ziel, alle unsere Features an einem Ort und unter einem Namen zur Verfügung zu stellen.

Wir haben die Websites von AB Tasty und Flagship zusammengeführt. Alle Ressourcen und Landing Pages, die zuvor auf der Flagship Website (flagship.io) gehostet wurden, können nun an einem Ort auf der AB Tasty Website (abtasty.com) gefunden werden.

Diese Entwicklung bringt mit sich, dass der Name Flagship nicht mehr weitergeführt wird und somit in den „Ruhestand“ geht. Wir fühlen uns zwar ein wenig nostalgisch gegenüber dem alten Namen, aber das Ziel ist es, den Zugang zu den AB Tasty-Lösungen und -Funktionen zu vereinfachen und sie miteinander zu verbinden, um unser Versprechen einzulösen, Ihre Go-to-Plattform für die Verbesserung und Optimierung der Customer Experience zu sein.

Wenn Sie Fragen dazu haben, was diese Änderung für Sie bedeutet, sind Sie hier genau richtig. Im Folgenden gehen wir auf die Änderungen, hilfreiche Links und Ressourcen sowie einige allgemeine FAQs ein.

Wie immer steht Ihnen unser Team an AB Tasty Magic Makers zur Verfügung, um alle zusätzlichen Fragen zu beantworten, die im Laufe der Zeit auftauchen könnten. Wenn Sie nach dem Lesen dieses Artikels noch weitere Fragen haben, zögern Sie nicht, uns eine E-Mail an contact_de@abtasty.com zu schicken, und wir werden diese Seite bei Bedarf aktualisieren.

Wie hängen AB Tasty und Flagship zusammen?

AB Tasty und Flagship waren schon immer ein und dasselbe Unternehmen, nur mit unterschiedlichen Namen für die serverseitigen und clientseitigen Lösungen.

Die Experimentier-Suite von AB Tasty ermöglicht es Marken, clientseitige A/B-Tests und Personalisierungen durchzuführen, um ein umfassenderes digitales Erlebnis zu bieten und die Konversionen zu steigern.

Flagship by AB Tasty wurde ebenfalls entwickelt, um durch risikofreies Feature-Management, serverseitige Experimente und Personalisierung umfassende Erlebnisse zu bieten, die zu Konversionen führen. Wie gesagt, dasselbe Unternehmen, nur unterschiedliche Ansätze, um Marken dabei zu helfen, ihren KundInnen das beste Erlebnis zu bieten.

Was meinen Sie, wenn Sie von Zusammenführung sprechen? Wird die Flagship-Website für immer verschwinden?

Ja, alles auf der Flagship-Website (flagship.io) ist auf die AB Tasty-Website (abtasty.com) umgezogen. Das bedeutet, dass alle Links zu bestehenden Landing Pages und Ressourcen auf AB Tasty umgeleitet werden, und alle neuen Ressourcen werden von nun an direkt auf AB Tasty veröffentlicht. Sie können ganz einfach auf Ressourcen wie E-Books, Blogs, Leitfäden und mehr zugreifen, indem Sie oben auf den Menüpunkt Ressourcen klicken oder dem Link hier folgen.

Warum führen wir die Websites und Namen von Flagship und AB Tasty zusammen?

Von Anfang an haben wir uns auf das konzentriert, was wir am besten können, nämlich unseren KundInnen die Werkzeuge an die Hand zu geben, die sie brauchen, um ihre Ideen zu validieren und gleichzeitig die Wirkung zu maximieren, das Risiko zu minimieren und die Markteinführung zu beschleunigen.

Marketing- und Technikteams arbeiten heute enger zusammen als je zuvor, um neue Funktionen auf den Markt zu bringen und wettbewerbsfähig zu bleiben. Unser kundenorientierter Ansatz bedeutet, dass wir unsere Funktionen leichter zugänglich machen und Ihnen die Tools zur Verfügung stellen möchten, die Sie für all Ihre Experimente und Personalisierungsanforderungen benötigen. Aus diesem Grund haben wir uns entschlossen, Flagship in die AB Tasty-Website zu integrieren und es als AB Tasty’s Feature Experimentation and Experience Rollouts zu positionieren, anstatt als separate Lösung.

Viele unserer clientseitigen KundInnen sind mittlerweile so weit mit ihren Experimenten, dass sie fortgeschrittene Experimente durchführen und erweiterte Funktionen einführen. Für unsere KundInnen, die bereit sind, mit serverseitigen Experimenten zu beginnen, macht es diese Änderung viel einfacher und schneller, alle Informationen und den Support, den sie für alle unsere Features benötigen, einschließlich unserer serverseitigen Funktionalität, an einem Ort zu finden.

Was geschieht mit all den Ressourcen (Blogbeiträge, Leitfäden, E-Books usw.) auf Flagship.io?

Wie bereits erwähnt, sind die Flagship-Inhalte jetzt migriert und alle Links von Flagship.io sind auf AB Tasty umgeleitet. Von dort aus können alle unsere Ressourcen, von Leitfäden bis hin zu Blogbeiträgen und E-Books zu den Themen Feature Management, Experimente und mehr, auf der AB Tasty-Website gefunden werden.

Sie werden schnell merken, dass Sie hier ganz einfach auf Ihre Lieblingsinhalte zugreifen können, wenn Sie nach den Themen „Rollouts“ und „Feature Experimentation“ filtern (Hinweis: Dies ist aktuell nur auf der englischen Seite möglich, die deutschen Inhalte werden aber zeitnah folgen).

Wie kann ich mich bei meinem Flagship-Konto anmelden? Und wo kann ich auf die Dokumentation und die SDK-Bibliotheken zugreifen?

Sie können auf Ihre Konten zugreifen, indem Sie abtasty.com besuchen und auf den „Login“-Button in der oberen rechten Ecke klicken.

Alle unsere Dokumentationen und SDKs haben die gleichen Links wie bisher. Sie können sie über die folgenden Links aufrufen:

• Dokumentation
• Bibliotheken and SDKs

Wie wird sich die Zusammenführung auf die bestehenden KundInnen von Flagship und AB Tasty und die Unterstützung, die sie erhalten, auswirken?

Alle unsere KundInnen, unabhängig davon, ob sie AB Tasty oder Flagship oder beides nutzen, werden davon nicht betroffen sein. Sie können unsere Plattform weiterhin für all Ihre Bedürfnisse rund um das Experimentieren nutzen, ohne dass sich etwas ändert.

Ebenso können Sie erwarten, dass Sie das gleiche Maß an Unterstützung erhalten und Zugang zu dem gleichen engagierten Team für client- und/oder serverseitige Experimente haben wie bisher.

Wie immer wird Ihr CSM Sie rechtzeitig informieren, wenn es Änderungen an der Plattform gibt.

Wie wird sich die Zusammenführung auf neue KundInnen auswirken? Wo kann ich mich für eine Demo für AB Tasty’s Feature Experimentation und Rollouts anmelden?

Wenn Sie neu sind und AB Tasty’s Feature Experimentation oder Experience Rollouts ausprobieren möchten, klicken Sie auf das Banner unten oder auf den „Demo anfragen“-Button oben rechts auf der Seite, um herauszufinden, wie serverseitige Experimente Ihr Unternehmen positiv beeinflussen können.

Ein ganz besonderes Dankeschön geht an unsere KundInnen und unsere PartnerInnen für die Unterstützung bei dieser spannenden Entwicklung von AB Tasty. Ihr Feedback und Ihre Unterstützung tragen dazu bei, wichtige Änderungen wie diese zu gestalten, und wir sind dankbar dafür.

Haben Sie weitere Fragen zu Flagship und AB Tasty? Schicken Sie uns eine E-Mail an contact_de@abtasty.com und bleiben Sie dran für weitere spannende Updates und Informationen, die in Zukunft kommen werden!

The post Neues Kapitel für Flagship: Zusammenführung mit der AB Tasty Website appeared first on abtasty.

Eine schnelle Auslieferung verkürzt auch die Zeit zwischen Softwareentwicklung und Feedback der UserInnen, ein entscheidender Faktor für Teams, die auf Continuous Integration und Continuous Deployment (CI/CD) setzen.

Vor diesem Hintergrund sollten Sie daran denken, Blue-Green Deployment in Ihr CI/CD Toolkit einzuführen. Mit diesem Prozess lassen sich technische und unternehmerische Risiken von Software-Releases reduzieren.

Bei diesem Modell werden zwei identische Produktionsumgebungen mit der Bezeichnung „Blau“ und „Grün“ parallel ausgeführt. Allerdings ist nur eine der beiden Umgebungen aktiv und erhält die Transaktionen der UserInnen. Die andere Umgebung ist produktionsfähig, aber nicht aktiv.

In diesem Artikel beschäftigen wir uns mit der Frage, wie Blue-Green Deployments funktionieren. Wir gehen näher auf die Pros und Kontras dieses Konzepts für Software-Releases ein. Darüber hinaus erklären wir, wie Blue-Green Deployments im Vergleich mit anderen Deployment-Methoden dastehen, und empfehlen Ihnen einige Best Practices für reibungslose Blue-Green-Deployments.

In diesem Artikel greifen wir folgende Punkte auf:

[toc]

Wie funktionieren Blue-Green Deployments?

Eine der größten Herausforderungen beim Deployment-Prozess ist das Cutover vom Testen auf die Produktion. Es muss schnell und reibungslos erfolgen, um die Ausfallzeit zu minimieren.

Das Blue-Green Deployment löst diese Aufgabe, indem zwei parallele Produktionsumgebungen verwendet werden. Dabei ist immer nur eine der beiden Umgebungen aktiv und erhält die Transaktionen der UserInnen. Im Bild unten ist es die grüne Umgebung. Das blaue – nicht aktive – System ist eine nahezu identische Kopie.

Ihr Team verwendet das blaue, nicht aktive System als Staging-Umgebung für die finale Testrunde, wenn ein neues Feature veröffentlicht werden soll. Sobald die neue Software in der blauen Umgebung problemlos funktioniert, kann Ihr Ops-Team den Datenverkehr auf die blaue Umgebung umleiten und dieses System dann live schalten. Anschließend können Sie das Feature in der grünen – inzwischen nicht aktiven – Umgebung implementieren, damit beide Systeme wieder synchron sind.

Damit wäre eigentlich das Wichtigste zum Blue-Green Deployment gesagt. Sie sind sehr flexibel, was die Strukturierung der parallelen Systeme und den Wechsel auf das jeweils andere System betrifft. Es könnte zum Beispiel sein, dass Sie keine parallelen Datenbanken pflegen möchten. In diesem Fall ändern Sie einfach das Routing und leiten den Datenverkehr auf Web- und App-Server weiter. Bei einem anderen Projekt könnten Sie ein Blue-Green Deployment verwenden, um ein noch nicht getestetes Feature im aktiven System zu veröffentlichen, wobei aber das Feature für A/B User-Tests hinter ein Feature Flag gesetzt wird.

Beispiel für ein Blue-Green Deployment

Angenommen, Sie sind in einem e-Commerce-Nischenunternehmen für ein DevOps-Team zuständig. Sie bieten Outfits und Accessoires an, die auf einem kleinen, jedoch hochwertigen Markt gefragt sind. Auf Ihrer Website können die KundInnen Produkte On-Demand personalisieren und bestellen.

Das Backend Ihrer Website enthält viele Microservices in einigen verschiedenen Containern. Sie haben Microservices für die Bestandsverwaltung, das Auftragsmanagement, Personalisierungs-Apps und ein integriertes soziales Netzwerk zur Unterstützung der Nischencommunity Ihrer KundInnen.

Ihr Team gibt frühzeitig und häufig Releases heraus, weil die anhaltende Beliebtheit Ihrer Website Ihrer Meinung nach dem CI/CD-Modell zu verdanken ist. Weil diese Nischencommunity auf der ganzen Welt verstreut ist, bleibt der Traffic auf Ihrer Website recht stabil. Deshalb ist es immer schwierig, einen relativ ruhigen Zeitpunkt zu finden, um Ihr Produktionssystem zu aktualisieren.

Sobald eines Ihrer Teams erklärt, dass das aktualisierte Customization Interface für den finalen Test in der Produktionsumgebung bereit steht, entscheiden Sie sich für ein Blue-Green Deployment, damit das Interface sofort veröffentlicht werden kann.

Am nächsten Tag entschließt sich Ihr Team vor der Mittagpause, den neuen Customizer bereitzustellen. Ab dieser Entscheidung wird der gesamte Traffic auf das blaue Produktionssystem geleitet. Sie aktualisieren die Software auf dem inaktiven grünen System und bitten die Tester und TesterInnen, eine QA durchzuführen. Weil alles in bester Ordnung zu sein scheint, verwendet Ihr Ops-Team einen Load-Balancer, um die User Sessions von „Blau“ auf „Grün“ zu leiten.

Nachdem der gesamte Traffic auf „Grün“ geleitet wurde, machen Sie diese Umgebung zur offiziellen Produktionsumgebung und setzen „Blau“ auf inaktiv. Ihr Dev-Team pusht den aktualisierten Customizer Code auf „Blau“, bestellt das Mittagessen und wirft einen Blick auf Ihren Backlog.

Pros von Blue-Green Deployments: Vorteile und Use Cases

Ein wesentlicher Vorteil von Blue-Green Deployments gegenüber anderen Strategien für Software-Releases ist ihre Flexibilität. Sie können in verschiedensten Umgebungen und vielen Use Cases nützlich sein.

Schnelle Releases

Für Product Owner, die innerhalb von CI/CD Frameworks arbeiten, sind Blue-Green Deployments eine ausgezeichnete Methode, Ihre Software in Produktion zu nehmen. Software können Sie praktisch zu jedem Zeitpunkt veröffentlichen.  Sie müssen den Release nicht mehr auf ein Wochenende verschieben oder außerhalb der Geschäftszeiten planen: Meistens können Sie die Software einfach durch Umschalten aktiv stellen. Weil mit diesen Deployments keine Ausfallzeiten verbunden sind, haben sie keine negativen Auswirkungen auf die UserInnen.

Sie sind auch für DevOps-Teams weniger disruptiv. Sie müssen Updates nicht mehr überstürzt in einem bestimmten Zeitfenster vornehmen, wodurch sich Deployment-Fehler und unnötiger Stress vermeiden lassen. Auch für Führungsteams hat diese Methode Vorteile. Sie müssen bei einem Ausfall nicht ständig auf die Uhr schauen und sich den Umsatzverlust ausrechnen.

Rollbacks leicht gemacht

Der umgekehrte Prozess kann genauso schnell durchgeführt werden. Weil Blue-Green Deployments zwei parallele Produktionsumgebungen verwenden, können Sie bei einem Problem in Ihrer Liveumgebung schnell auf die stabile Umgebung zurückschalten.

Dadurch lassen sich die Risiken beim Experimentieren während der Produktion reduzieren. Ihr Team kann Probleme durch die Umleitung auf die stabile Produktionsumgebung einfach beheben. Dabei besteht die Gefahr Transaktionen der UserInnen zu verlieren – wir kommen später noch darauf zurück – doch es gibt eine Reihe von Strategien, um mit dieser Situation umzugehen.

Sie können Ihre App während eines Cutover vorübergehend in den Read-Only Modus setzen. Oder Sie können rollierende Cutover mit einem Load-Balancer durchführen, während Sie den Abschluss der Transaktionen in der Liveumgebung abwarten.

Integriertes Disaster Recovery

Weil Blue-Green Deployments zwei Produktionsumgebungen verwenden, bieten sie implizit Disaster Recovery für Ihre Business-Systeme. Eine duale Produktionsumgebung fungiert als eigenes Hot Backup.

Load Balancing

Bei parallelen Blue-Green Produktionsumgebungen lässt sich der Load-Balancer leicht bewerkstelligen. Wenn zwei Umgebungen funktionsmäßig identisch sind, können Sie einen Load-Balancer oder ein Feature Toggle in der Software verwenden, um Traffic nach Bedarf auf verschiedene Umgebungen zu leiten.

Einfacheres A/B Testing

Ein weiterer Use Case für parallele Produktionsumgebungen ist A/B Testing. Sie können neue Features in die inaktive Umgebung laden und den Traffic dann mit einem Feature Toggle zwischen Ihrer blauen und Ihrer grünen Umgebung aufteilen.

Sammeln Sie Daten von diesen geteilten User Sessions, überwachen Sie Ihre KPI und wenn die Analysen der neuen Features in Ihrem Management-System in Ordnung zu sein scheinen, können Sie den Traffic auf die aktualisierte Umgebung umleiten

Kontras von Blue-Green Deployments: Probleme, über die Sie sich im Klaren sein sollten

Blue-Green Deployments bieten viele Vorteile, stellen DevOps-Teams jedoch auch vor große Herausforderungen hinsichtlich Infrastruktur und Praktiken. Bevor Sie Blue-Green Deployments in Ihren CI/CD-Prozess integrieren, sollten Sie diese Probleme verstehen.

Blue-Green Deployments sind ressourcenintensiv

Wie inzwischen klar ist, müssen Sie für ein Blue-Green Deployment Ressourcen für zwei Produktionsumgebungen bereitstellen und beide Umgebungen pflegen. Für einige Unternehmen können die entsprechenden finanziellen Kosten und der Zeitaufwand für den Sysadmin zu hoch sein.
Andere Unternehmen können diese Ressourcen möglicherweise nur für ihre besonders hochwertigen Produkte bereitstellen. Soll das DevOps-Team in diesem Fall Software nur für bestimmte Produkte in einem CI/CD-Modell veröffentlichen? Langfristig ist dies möglicherweise nicht tragbar.

Zusätzlicher Aufwand für die Datenbankverwaltung

Die Verwaltung einer bzw. mehrerer Datenbanken in parallelen Produktionsumgebungen kann kompliziert sein. Sie müssen daran denken, was sie nach einem Software Update brauchen, sowohl in der blauen als auch in der grünen Umgebung, wie zum Beispiel alle externen Services, die Sie aufrufen.
Was passiert zum Beispiel, wenn eine Spalte der Datenbank aufgrund einer Änderung des Features umbenannt werden muss? Sobald Sie den Namen der Spalte in der blauen Umgebung ändern, funktioniert die grüne Umgebung (mit dem alten Code) mit dieser Datenbank nicht mehr.
Kann Ihre gesamte Produktionsumgebung überhaupt mit zwei separaten Datenbanken funktionieren? Meistens nicht, nämlich wenn Sie Ihr Blue-Green System für Load-Balancing, Testing oder irgendeine andere Funktion verwenden, außer als Hot Backup.

Produktmanagement

Abgesehen von der Systemadministration, erfordert das Produktmanagement in zwei nahezu identischen Umgebungen auch mehr Ressourcen. Produktmanager brauchen zuverlässige Tools, um nachzuverfolgen, wie ihre Software performt, welche Services die verschiedenen Teams aktualisieren und wie sie die entsprechenden KPI überwachen können. Weil diese Aktivitäten überwacht und kontrolliert werden müssen, ist ein zuverlässiges Produkt- und Feature-Management Dashboard besonders wichtig.

Blue-Green Deployments und Rolling Deployments

Blue-Green Deployments sind selbstverständlich nicht die einzige Option für schnelle Software-Releases. Ein weiteres beliebtes Konzept ist das Rolling Deployment.

Auch Rolling Deployments benötigen eine Produktionsumgebung, bei der eine Applikation auf mehreren Servern gehostet wird. Oft, aber nicht immer, ist ein Load-Balancer vorgeschaltet, um den Traffic zu verteilen. Wenn das DevOps-Team für ein Update seiner Applikation bereit ist, wird ein gestaffelter Release konfiguriert, wobei die aktualisierte Applikation von einem Server zum nächsten gepusht wird.

Beim Ausrollen des Release läuft die aktualisierte Applikation auf einigen Live-Servern, während auf anderen noch die alte Version läuft. Beim Blue-Green Deployment hingegen ist die aktualisierte Software für alle UserInnen live oder inaktiv.

Wenn UserInnen eine Session mit der Applikation starten, leitet sie der Load-Balancer entweder auf die alte oder auf die neue Version der Applikation weiter. Wenn das Rollout abgeschlossen ist, wird jede eingehende neue User Session auf die aktualisierte Version der Software geleitet. Sollte während des Rollouts ein Fehler auftreten, kann das DevOps-Team die Aktualisierung stoppen und den gesamten Traffic auf die verbleibenden einwandfrei funktionierenden Server umleiten, bis der Fehler behoben ist.

Rolling Deployments sind eine praktikable Option für Unternehmen mit Ressourcen, die für das Hosting einer Produktionsumgebung dieser Größenordnung notwendig sind. Für diese Unternehmen sind sie eine effiziente Methode, um kleine, graduelle Updates zu veröffentlichen – genau wie Sie das bei agilen Entwicklungsmethoden machen würden.

In anderen Use Cases sind Blue-Green Deployments möglicherweise die bessere Wahl. Wenn Sie zum Beispiel ein wichtiges Update vornehmen möchten und die UserInnen keinen Zugriff auf die alte Version haben sollen, ist ein „alles oder nichts“ Konzept wie das Blue-Green Deployment genau richtig.

Angenommen, Ihre Applikation erfordert ein hohes Maß an technischem Support oder Kundensupport. In diesem Fall ist der Support während der Rolling Deployment Windows noch mehr gefordert, weil die Support-Mitarbeiter nicht wissen können, welche Version der Applikation bei einem User oder einer Userin läuft.

Blue-Green Deployments und Canary Releases

Rolling Deployments und Blue-Green Deployments sind nicht die einzigen Release Strategien. Canary Releases stellen eine weitere Möglichkeit dar. Bei einer Canary Release erhält zuerst nur ein Teil aller Produktionsumgebungen ein Software-Update. Doch statt das Deployment auf den Rest auszurollen, bleibt dieser partielle Release für Testzwecke auf den Teilbereich beschränkt. Ein Teil der UserInnen wird dann durch einen Load-Balancer oder ein Feature Flag zur neuen Software weitergeleitet.

Canary Releases sind sinnvoll, wenn Sie von identifizierbaren UserInnen Daten und Feedback zu einer aktualisierten Software erhalten möchten. Canary Releases fügen sich perfekt in umfassendere rollierende Deployments ein: Sie können die aktualisierte Software schrittweise an immer größere Segmente Ihrer User Base ausrollen, bis schließlich alle Produktionsserver aktualisiert sind.

Best Practices für Blue-Green Deployment

Sie haben viele Möglichkeiten, Software schnell zu veröffentlichen. Wenn Sie Blue-Green Deployment als neue Software Release-Strategie in Betracht ziehen, empfehlen wir Ihnen die folgenden Best Practices.

Automatisieren Sie, was automatisierbar ist

Beim Release-Prozess so oft wie möglich auf Scripting und Automatisierung zurückzugreifen, bietet viele Vorteile. Sie führen nicht nur schneller zum Cutover, sondern lassen auch weniger Raum für menschliche Fehler. Ein Entwickler kann nicht versehentlich einen Punkt auf einer Checkliste vergessen, wenn die Liste von einem Script oder einer Management-Plattform abgearbeitet wird. Wenn alles in ein Script gepackt wird, kann jeder das Deployment durchführen, ob Entwickler oder nicht. Sie müssen nicht warten, bis Ihr Systemexperte wieder im Büro ist.

Überwachen Sie Ihre Systeme

Überwachen Sie immer sowohl die blaue als auch die grüne Umgebung. Damit ein Blue-Green Deployment reibungslos verläuft, müssen Sie wissen, was im aktiven und im inaktiven System vor sich geht.

Beide Systeme benötigen wahrscheinlich dasselbe Warnsystem, für das jedoch verschiedene Prioritäten gesetzt werden. Sie möchten zum Beispiel sofort erfahren, wenn in Ihrem Live-System ein Fehler auftritt. Im inaktiven System hingegen reicht es, wenn der betreffende Fehler im Laufe des Arbeitstages behoben wird.

Schreiben Sie rückwärts und vorwärts kompatible Codes

In einigen Fällen können die neue und die alte Version Ihrer Software während eines Cutovers nicht gleichzeitig ausgeführt werden. Angenommen, Sie müssen das Datenbankschema ändern: In diesem Fall wäre es sinnvoll, Ihre Updates so zu strukturieren, dass sowohl das blaue als auch das grüne System über das gesamte Cutover funktionsfähig ist.

Eine Lösung wäre, Ihre Releases in eine Reihe von noch kleineren Release-Paketen aufzuteilen. Nehmen wir an, unser e-Commerce Unternehmen detailliert sein Sortiment und muss seine Datenbank aktualisieren. Um Klarheit zu schaffen, soll das Feld „Hemd“ in „langaermliges_Hemd“ umbenannt werden.

Dieses Update könnte folgendermaßen aufgegliedert werden:

• Veröffentlichung einer Zwischenversion des Codes, die mit einem Flag aktiviert wird und sowohl die Ergebnisse von „Hemd“ als auch von „langaermliges_Hemd“ interpretieren kann.
• Migration der gesamten Datenbank, um das Feld umzubenennen.
• Veröffentlichung der endgültigen Codeversion – oder Umlegen des Feature Flags – damit die Software nur „langaermliges_Hemd“ verwendet.

Führen Sie mehr und kleinere Deployments durch

Kleinere, häufigere Updates haben sich bereits als integraler Bestandteil der agilen Entwicklung und von CI/CD etabliert. Bei Blue-Green Deployments ist diese Vorgehensweise noch wichtiger. Geringere Deployment-Zeiten verkürzen die Feedback-Schleifen, die Informationen für das nächste Release liefern. Dadurch wird jedes inkrementelle Upgrade effektiver und wertvoller für Ihr Unternehmen.

Reorganisieren Sie Ihre Applikationen in Microservices

Diese Methode geht Hand in Hand mit kleineren Deployments. Durch die Restrukturierung des Applikationscodes in Microservices können Sie Updates und Änderungen einfacher verwalten. Verschiedene Features werden so unterteilt, dass sie leichter getrennt aktualisiert werden können.

Verwenden Sie Feature Flags zur weiteren Risikoreduzierung

An sich öffnen Blue-Green Deployments ein einziges, kurzes Risikofenster. Sie aktualisieren alles, alles oder nichts, können aber jederzeit einen Rückzieher machen, falls ein Problem auftritt.

Blue-Green Deployments verursachen mit jedem Cutover aber auch einen ziemlich konstanten Administrationsaufwand. Sie können diesen Mehraufwand zwar durch Automatisierung reduzieren, doch der Prozess bleibt gleich – egal ob Sie nur eine Codezeile oder Ihre gesamte e-Commerce Suite aktualisieren.

AB Tasty Feature Flag Service

Mit Feature Flags lässt sich bis ins Detail kontrollieren, wie und wann UserInnen neu verfügbare Software nutzen können. Feature Flags verhalten sich wie leistungsstarke „If“-Statements, ab denen während der Laufzeit mindestens einem von zwei oder mehreren verschiedenen Codepfaden abhängig von einer gegebenen Bedingung gefolgt wird.

Diese Bedingungen können einfache „Ja/Nein“ Prüfungen oder komplexe Entscheidungsbäume sein. Feature Flags machen Software Releases überschaubarer, denn mit ihnen lässt sich Feature für Feature kontrollieren, was ein- oder ausgeschaltet ist.

Ihr e-Commerce Unternehmen kann beispielsweise ein Blue-Green Deployment seines Microservices Customizer durchführen, aber den neuen Code im Live-System hinter einem Feature Flag inaktiv lassen. Das DevOps-Team kann das betreffende Feature dann je nach gewünschter Bedingung zum gewünschten Zeitpunkt einschalten.

Eventuell möchte das Team weitere A/B-Tests in Produktion nehmen oder weitere Tauglichkeitstests vornehmen. Oder es könnte für das Team sinnvoller sein, für eine identifizierte Gruppe von Early UserInnen ein Canary Release des Customizer durchzuführen.

Ihre Feature Flags können zusammen mit einem Load Balancer bestimmen, welche UserInnen welche Applikation und Feature-Subsets während eines Blue-Green Deployments zu sehen bekommen. Statt ganze Applikationen auf einmal umzuschalten, können Sie auf die neue Applikation wechseln und dann im aktiven und inaktiven System nach und nach einzelne Feature aktivieren und deaktivieren, bis das Upgrade vollständig durchgeführt ist. Dieser schrittweise durchgeführte Prozess reduziert das Risiko und hilft Ihnen, Bugs aufzuspüren, da die einzelnen Features nach und nach live geschaltet werden.

Sie können Feature Flags manuell in Ihrer Codebase steuern oder für eine effektivere Steuerung Feature Flag Services verwenden. Diese Plattformen bieten ein detailliertes Reporting und KPI-Tracking sowie ein ausführliches Spektrum von DevOps Management-Tools.

Wir empfehlen Ihnen, Feature Flags zu verwenden, wenn Sie ein Blue-Green Deployment für einen größeren Release der Applikation durchführen. Sie sind auch in kleineren Deployments praktisch, bei denen Sie nicht unbedingt zwischen den Umgebungen umschalten. Sie können nach und nach Features in der blauen Umgebung einzeln aktivieren und die grüne Umgebung im Standby als Hot Backup verwenden, falls ein ernsthaftes Problem auftritt. Die Kombination aus Blue-Green Deployments und Feature Flags eignet sich ausgezeichnet für eine Continuous Delivery jeder Größenordnung.

Ziehen Sie in Betracht, Blue-Green Deployments in das Arsenal Ihrer DevOps hinzuzufügen

Blue-Green Deployments eignen sich bestens für Software Releases jeder Größe, egal, ob es sich um eine ganze Applikation, größere Updates, einen einzigen Microservice oder das Update eines kleinen Features handelt.

Bevor Sie sich für Blue-Green Deployments entscheiden, müssen Sie auf jeden Fall prüfen, wie gut sie sich in Ihren aktuellen Delivery Prozess integrieren lassen. In diesem Artikel haben wir erklärt, wie Blue-Green Deployments funktionieren, was für und was gegen ihre Verwendung in Ihrem Delivery Prozess spricht und wie sie sich von anderen möglichen Deployment-Methoden differenzieren. Sie sollten sich jetzt eine Vorstellung davon machen können, ob Blue-Green Deployments für Ihr Unternehmen in Frage kommen.

The post Pros und Kontras von Blue-Green Deployments appeared first on abtasty.

Ein kritischer Punkt in der gesamten Product Experience ist User Onboarding: Wenn Sie alles richtig machen, gewinnen Sie loyale KundInnen. Machen Sie aber etwas falsch, verlieren Sie diese UserInnen für immer.

Also ist es sinnvoll, den User Onboarding-Prozess kontinuierlich zu optimieren – der perfekte Job für ein Produktteam. Ein solches Team setzt sich oft aus 5 bis 8 Mitarbeitern und Mitarbeiterinnen zusammen, u. a. aus ProduktmanagerInnen, DesignerInnen und EntwicklerInnen. Verschiedene Unternehmen arbeiten mit Produktteams unterschiedlicher Größe und Konfigurationen, je nachdem, was für ihren Use Case am besten ist. Allerdings sind DevOps Engineers selten Teil dieser Teams, denn für viele gelten DevOps nur als Instrument für erfolgreiche Feature Releases.

Letzten Endes sind es aber diese DevOps Engineers, die mitten in der Nacht aufstehen und ein neu implementiertes Feature korrigieren müssen, wenn es eine App zum Absturz bringt, sobald eine Userin oder ein User sich durch den Onboarding-Prozess navigiert.

Wir fragen Sie: Kann eine App, deren Onboarding-Prozess nicht funktioniert, erfolgreich sein, und haben Release Teams überhaupt einen signifikanten Einfluss auf die UX? Lassen Sie es uns herausfinden.

In diesem Artikel untersuchen wir genauer:
[toc content=“.entry-content“]

Wie Sie mit einer einwandfreien Onboarding-Experience dafür sorgen können, dass sich die UserInnen gleich heimisch fühlen

Die meisten Apps benötigen einen Onboarding-Prozess, um neuen UserInnen zu zeigen, wie sie ihre Ziele möglichst effizient und unkompliziert erreichen.

Dabei dürfen wir nicht vergessen, dass das Onboarding-Erlebnis Ihr Verhältnis zu potenziellen KundInnen beeinflussen kann – sowohl positiv als auch negativ.

Egal, wie gut Ihre App tatsächlich ist. Was zählt, ist der erste Eindruck!

Große Unternehmen wie Slack oder Dropbox überarbeiten häufig ihr User Onboarding, damit UserInnen bequem, heiter und zielführend in ihr Produkt einsteigen können. Überzeugen Sie sich selbst. Die folgenden Abbildungen zeigen einen Ausschnitt des Onboarding-Prozesses von Slack aus den Jahren 2014 und 2021. Das Design hat sich natürlich komplett geändert, aber statt der Beschreibung, wo der Name des Teams auf dem Interface von Slack später erscheint, werden nun das User Interface und der Name unseres Teams angezeigt. Diese Verbesserungen sind sicher nicht dem Zufall überlassen, sondern das Ergebnis sorgfältig koordinierter Optimierungsworkflows.

–

Da sogar große Unternehmen in die Optimierung ihrer Onboarding-Prozesse investieren, sollten auch wir das tun und uns nicht auf unseren Lorbeeren ausruhen. Es bleibt die Frage, wie Sie sicherstellen, dass Sie die richtige Onboarding-Experience auf die richtige Weise erstellen können?

Und genau hier kommen funktionsübergreifende Produktteams und Flagship ins Spiel!

Nutzen Sie Flagship, um Produktteams zusammenzubringen und eine einwandfreie UX sicherzustellen

Bei AB Tasty konzentrieren wir uns auf zwei Hauptthemen für eine einwandfreie User Experience:

1. Das richtige Feature veröffentlichen: Wir versetzen uns in unsere UserInnen und führen Experimente und Tests durch, damit das Feature einen Mehrwert und ein gutes Look and Feel bietet.
2. Das Feature richtig bereitstellen: Es geht nicht nur um Funktionalität und Look. Mit Feature Management stellen wir sicher, dass unser Produkt jederzeit und auf verschiedenen Plattformen einwandfrei funktioniert.
   –

–

Mit Flagship haben Sie die Mittel in der Hand, aus beiden Potenzialen das Beste herauszuholen: datenbasierte Experimente und Feature Management, um Features für einwandfreie Customer Experiences zu erstellen und zu veröffentlichen. Daher betrachten wir Release Teams als integralen Bestandteil in der Wertschöpfung für unsere UserInnen. Möglicherweise sind nicht alle derselben Auffassung. Trotzdem möchten wir Ihnen näher erklären, warum DevOps unserer Ansicht nach enger in die Produktteams eingebunden werden sollten.

Es ist kein Geheimnis, dass Teams, die ein gemeinsames Ziel verfolgen, ihr volles Potenzial eher erreichen als solche, die nicht dieselbe Richtung einschlagen. Wenn DevOps von Produktteams isoliert werden, können Sie wahrscheinlich nicht auf die positiven Effekte von Verbundenheit und leidenschaftlichem Einsatz zählen, die für die Entwicklung und den Release gelungener Produkte notwendig sind. Aus diesem Grund raten wir Produktteams, enger mit DevOps zusammenzuarbeiten. Auch Release Teams bemühen sich, UserInnen Mehrwert und großartige Experiences zu bieten. Und sie bringen die entsprechenden Skills dafür mit.

Flagship bietet ProduktmanagerInnen, EntwicklerInnen und DevOps Engineers eine gemeinsame Umgebung für Experimente und Feature Management. Sie haben alle Daten und Tools zur Hand, die Sie für ein produktives Gespräch über den Produktoptimierungsprozess in einer gemeinsamen datenbasierten Sprache brauchen. Spezifische Rollen und Verantwortlichkeiten werden nicht in Silos isoliert. Stattdessen kann sich jedes Mitglied des Produktteams auf seine Aufgabe konzentrieren und gleichzeitig weiterhin mit geballter Kraft arbeiten.

Werfen wir nun einen Blick darauf, wie Produktteams durch die Experimentier- und Feature Management-Funktionen von Flagship für herausragende User Experiences sorgen können.

Stellen Sie das Feature mit Feature Management richtig bereit

Sprechen wir zunächst über ein paar Beispiele, wie sich Feature Management und der richtige Release eines Features positiv auf das Onboarding-Erlebnis der UserInnen auswirken können.

Angenommen, Sie möchten Ihrem Onboarding-Prozess Tooltips hinzufügen, damit UserInnen sicher durch das Dashboard Ihres Produkts navigieren können. Das Produktteam bereitet das neue Feature entsprechend vor und testet seine Funktionsweise ausgiebig auf den Testservern. Nachdem alles zu funktionieren scheint, wird das neue Feature auf einen Schlag für alle UserInnen veröffentlicht. Hoffentlich nicht an einem Freitagnachmittag, denn die Umstellung könnte unvorhergesehene Probleme auf dem Produktionsserver verursachen, wie z. B.:

• Ihre UserInnen stecken in einer Endlosschleife, aus der es keinen Ausweg gibt
• Die Eingaben der UserInnen werden nicht gespeichert, z. B. in einem Formular
• Die App stürzt wiederholt ab
• Die UserInnen werden ohne ersichtlichen Grund wieder an den Start zurückgeschickt.

Stellen Sie sich vor, was das für die UserInnen bedeutet, die Ihren Onboarding-Prozess durchlaufen und sich schon darauf freuen, Ihr Produkt zu verwenden – und plötzlich funktioniert nichts mehr. Der magische Moment verpufft. Wegen einer schlechten UX haben die UserInnen höchstwahrscheinlich das Vertrauen in Ihre App verloren.

Flagship sorgt für eine stressfreie Code-Implementierung

Mit den Feature Management-Funktionen von Flagship können Ihre Produktteams neue Features unbesorgt veröffentlichen – sogar an einem Freitagnachmittag.

Mit Feature Management können Release Teams das neue Tooltips Feature einer ausgewählten Zielgruppe bereitstellen, bevor es für alle UserInnen veröffentlicht wird. Auf diese Weise können Sie sicher sein, dass das neue Feature unter realistischen Bedingungen funktioniert, d. h. auf Produktionsservern mit realen UserInnen.

Durch die Kontrolle und Überwachung der Rollouts wissen DevOps Teams sofort, wenn etwas nicht nach Plan verläuft. Dadurch können sie rechtzeitig reagieren und sich freuen, dass nur wenige UserInnen den Fehler bemerkt haben.

Nehmen wir zum Beispiel an, die EntwicklerInnen haben das Tooltip Feature in ein Feature Flag gepackt (was sie wirklich tun sollten). In diesem Fall können sie das Feature bei einem Problem schnell über das Flagship-Dashboard deaktivieren. Selbstverständlich können sie auch automatische Code-Rollbacks auf Basis von KPIs konfigurieren, um noch schneller zu reagieren.

Richtiges Feature Management kann gestresste Release Teams entlasten: Es macht Schluss mit schlaflosen Nächten zur Schadensbegrenzung! Wenn Sie mehr über die Vorteile von Feature Management für Tech Teams erfahren möchten, empfehlen wir Ihnen unseren Blogpost.

Veröffentlichen Sie das richtige Feature mit Experimenten

Vielleicht können Sie sich gut in Ihre Produktteams hineinversetzen und haben den Eindruck, Ihre UserInnen ziemlich gut zu kennen. Trotzdem sind Experimente und Tests sinnvoll, um einen Onboarding-Prozess zu erstellen, der Ihre UserInnen begeistert.

Werfen wir noch einmal einen Blick auf das Tooltip-Beispiel von vorhin. Angenommen, Ihr Produktteam hat die Tooltips erfolgreich im User Onboarding-Prozess integriert. Ihre Analysedaten weisen jedoch darauf hin, dass etwas nicht stimmen kann. Viele UserInnen wissen immer noch nicht, wie Ihre App genutzt wird, und brechen den Prozess auf halbem Weg ab. Wenn Sie das Problem nicht sofort identifizieren und beheben können, müssen Sie auf andere Mittel zurückgreifen, um die User Experience des Tooltips zu verbessern.

Stellen Sie zunächst sicher, dass aus technischer Sicht alles in Ordnung ist. Als Nächstes sollte Ihr Produktteam an möglichen Varianten im Hinblick auf eine bessere Präsentation und Funktionalität von Tooltips arbeiten. Sie können dann mit Experimenten und Tests in Flagship festlegen, welche Varianten und Ideen die beste User Experience bieten.

Zum Beispiel könnten Sie mit A/B-Tests herausfinden, ob ein Anleitungsvideo für UserInnen hilfreich wäre, bevor die Tooltips angezeigt werden und sie mit dem Produkt starten. Oder experimentieren Sie mit der Abfolge der Tooltips – vielleicht ist der Prozess verständlicher, wenn Sie die Reihenfolge der Tooltips ändern.

Sie können auch mit verschiedenen Farben, Texten, UI-Elementen, Call-to-Action usw. experimentieren. Damit Ihre Experimente möglichst aussagekräftig sind, können Sie festlegen, welche UserInnen welche Feature-Variante zu sehen bekommen, und die Nutzerakzeptanz, Testergebnisse und KPIs im Flagship-Dashboard verfolgen.

Ein weiterer Vorteil von Flagship ist die mögliche Verwendung einer 1-zu-1-Personalisierung auf Basis von Zielgruppensegmenten, um UserInnen einzigartige Erlebnisse zu bieten. Zum Beispiel können Sie UserInnen nach der Registrierung für ein zahlungspflichtiges Abo eine personalisierte Begrüßungsnachricht anzeigen und ihrem Onboarding-Erlebnis so einen Mehrwert verleihen.

… Was ist mit clientseitigen Tools für Experimente?

Viele clientseitige Tools für die Experience-Optimierung, wie beispielsweise unser AB Tasty Tool, können die meisten dieser Experimente ebenfalls durchführen – und das ohne Code-Deployment. Wenn Sie Ihre Experimente für einen kritischen Prozess wie User Onboarding codieren, hat das allerdings folgenden Vorteil: Sie verlangsamen den Prozess nicht potenziell mit automatisch generierten UI-Overlays. Hingegen sind Tests und Experimente mit Flagship schnell, sicher und „flickerfrei“, da sie direkt vom Server kommen und nicht im Browser der UserInnen berechnet werden müssen. Selbstverständlich haben clientseitige Tools nach wie vor ihre Berechtigung und ihre einzigartigen Einsatzmöglichkeiten – Flagship ist ein großartiges Tool, um Ihre clientseitige Strategie zu ergänzen.

Takeaway

Wenn Sie UserInnen die bestmögliche Onboarding-Experience bieten möchten, brauchen Sie funktionsübergreifende Teams, die wissen, wie das richtige Feature richtig veröffentlicht wird. Eines unserer Ziele ist es, die Bedeutung von Release Teams für eine einwandfreie UX zu propagieren – ob ein Produkt technisch einwandfrei funktioniert, ist genauso wichtig wie sein Erscheinungsbild und sein Verhalten.

Mit den Experimentier- und Feature Management-Funktionen von Flagship können Produktteams von einer Plattform profitieren, um zusammen produktiv und datenbasiert an der Verbesserung des Onboarding-Erlebnisses zu arbeiten.

Sie möchten Flagship für Ihre Produktteams ausprobieren? Buchen Sie eine Demo und sehen Sie wie Experimente und Feature Management die Onboarding-Experience Ihrer UserInnen von „okay“ zu „super“ verändern können.

The post Use Case User Onboarding: Welchen Einfluss haben Release Teams auf die UX? appeared first on abtasty.

Ist Ihre Organisation agil? Setzen Sie Continuous Integration und Continuous Delivery (CI/CD) ein? Entwickeln Sie eine Webapplikation? Eine mobile App? Eine lokale Desktop- oder eine Cloud-basierte Applikation? All diese Faktoren und viele weitere bestimmen über die Effizienz einer Bereitstellungsstrategie.

Aber ganz unabhängig von der Strategie dürfen Sie nicht vergessen, dass sich Probleme bei der Bereitstellung nicht vermeiden lassen. Ein „Merge“ kann schief gehen, es können Bugs auftreten oder ein menschlicher Fehler kann in der Produktion problematisch werden. Der Punkt ist, dass Sie sich von der Suche nach der perfekten Bereitstellungsstrategie nicht verrückt machen lassen sollten. Denn diese Strategie gibt es nicht.

Versuchen Sie stattdessen, eine Strategie zu finden, die äußerst belastbar ist und sich an Ihre Arbeitsweise anpassen lässt. Anstatt zu versuchen, unvermeidliche Fehler zu vermeiden, sollten Sie den Code so bereitstellen, dass Fehler minimiert werden und Sie schnell reagieren können, wenn sie dann doch auftreten. Für viele Teams liegt die Lösung dieses Problems in Canary Deployments.

Canary Deployments können Ihnen helfen, Ihren besten Code so effizient wie möglich in die Produktion zu geben. In diesem Artikel werden wir erklären, was Canary Deployments sind und was nicht. Wir gehen auf die Pros und Kontras von Canary Deployments ein, vergleichen sie mit anderen Bereitstellungsstrategien und zeigen Ihnen, wie Sie mit Ihrem Team ganz einfach Canary Deployments durchführen können.

In diesem Artikel greifen wir folgende Punkte auf:

[toc]

Was ist ein Canary Deployment?

Canary Deployments sind Best Practice für Teams, die sich für den Prozess Continuous Delivery entschieden haben. Bei einem Canary Deployment wird ein neues Feature zunächst einer kleinen Teilgruppe von UserInnen zur Verfügung gestellt. Das neue Feature wird je nach Traffic einige Minuten bis mehrere Stunden lang überwacht, oder zumindest so lange, bis aussagekräftige Daten vorhanden sind. Wenn das Team ein Problem feststellt, wird das neue Feature schnell zurückgezogen. Werden keine Probleme festgestellt, wird das Feature für alle UserInnen freigeschaltet.

Der Begriff „Canary Deployment“ hat eine faszinierende Geschichte. Er ist auf die englische Redewendung „Canary in a coal mine“ (Kanarienvogel im Kohlebergwerk) zurückzuführen, als Kanarienvögel oder andere kleine Singvögel in Kohlebergwerken als Frühwarnsystem eingesetzt wurden. Die Bergleute brachten Vögel in Käfigen unter Tage. Wenn die Vögel erkrankten oder starben, war dies ein Warnhinweis dafür, dass sich geruchlose giftige Gase, wie Kohlenmonoxid, ausbreiteten. Ein unmenschliches, aber wirksames Verfahren in Großbritannien und den USA, bis die Kanarienvögel 1986 durch elektronische Sensoren ersetzt wurden.

Ein Canary Deployment macht aus einer Teilgruppe von UserInnen – idealerweise eine fehlertolerante Menge – ein eigenes Frühwarnsystem. Diese Gruppe von UserInnen identifiziert Bugs, fehlerhafte Features und nicht-intuitive Features, bevor Ihre Software einer größeren Zielgruppe zugänglich gemacht wird.

Ihre Canary UserInnen können selbst identifizierte Early Adopters sein, ein demografisch festgelegtes Zielsegment, eine zufallsbedingte Stichprobe, d. h. ein Mix aus UserInnen, der am sinnvollsten ist, um Ihr neues Feature in der Produktion zu überprüfen.

Bei den Überlegungen zu Canary Deployments kann es hilfreich sein, an das Risikomanagement zu denken. Sie können neue, interessante Features regelmäßiger einführen, ohne sich Sorgen machen zu müssen, ob sich eins der neuen Features auf die User Experience aller UserInnen negativ auswirkt.

Canary Releases vs. Canary Deployments

Die Begriffe „Canary Release“ und „Canary Deployment“ werden gelegentlich auch wie Synonyme gebraucht. Aber in DevOps müssen sie unterschieden werden. Eine Canary Release ist ein Test Build einer vollständigen Applikation. Beispielsweise ein nächtlicher Release oder eine Beta-Version.

Manche Teams veröffentlichen Canary Releases oft in der Hoffnung, dass Early Adopters und Power UserInnen, die mit Entwicklungsprozessen besser vertraut sind, die neue Applikation herunterladen, um sie in der Praxis zu testen. Die Browser-Teams von Mozilla und Google und viele andere sind von dieser Release-Strategie begeistert.

Canary Deployments ihrerseits sind das, was wir bereits beschrieben haben. Ein Team veröffentlicht neue Features in der Produktion für Early Adopters oder verschiedene Teilgruppen von UserInnen, die über einen Load Balancer oder ein Feature Flag auf die neue Software geleitet werden. Der Großteil der UserInnen sieht weiterhin die aktuelle, stabile Software.

Canary Deployment – Pros und Kontras

Canary Deployments können als Release Strategie erfolgversprechend und effektiv sein. Aber sie sind nicht für jedes mögliche Szenario die richtige Strategie. Gehen wir auf einige Pros und Kontras von Canary Deployments ein, damit Sie besser entscheiden können, ob sie für Ihr DevOps-Team sinnvoll sind.

Pros

Unterstützung von CI/CD-Prozessen

Canary Deployments bewirken ein schnelleres Feedback zu neuen Features in Produktion. DevOps-Teams erhalten reale Nutzungsdaten schneller, wodurch sie die nächsten Features schneller und deutlich effektiver verfeinern und integrieren können. Solche kurzen Entwicklungsschleifen sind eines der Markenzeichen von Continuous Integration/Continuous Delivery.

Granulare Kontrolle über Feature-Bereitstellungen

Wenn Ihr Team zu kleineren, regelmäßigen Feature-Bereitstellungen schreitet, verringern Sie die Gefahr, dass Ihr Arbeitsablauf durch Fehler unterbrochen wird. Nicht viele UserInnen werden von einem Fehler im Canary Deployment betroffen sein. Diesen Fehler zu beheben, wird nur eine geringfügige Angelegenheit sein. Nicht alle Ihre UserInnen sind betroffen und Sie müssen keine KollegInnen von der geplanten Arbeit abziehen, um ein größeres Produktionsproblem zu lösen.

Realitätsnahe Tests

Interne Tests haben ihre Berechtigung, sind aber kein Ersatz für Test von Applikationen bei realen UserInnen. Canary Deployments sind eine ausgezeichnete Strategie für Tests in einem kleineren Umfang unter realen Bedingungen, ohne die erheblichen Risiken, die Sie eingehen, wenn Sie eine völlig neue Applikation in Produktion geben.

Schnell verbessertes Engagement

Neben besseren technischen Tests können Sie mit Canary Deployments auch schnell feststellen, wie UserInnen mit Ihren neuen Features umgehen. Werden die Sessions länger? Steigen die Kennzahlen für ihr Engagement in diesem Canary Deployment? Wenn keine Fehler gefunden werden, können Sie das Feature allen UserInnen anzeigen.

Sie müssen nicht warten, bis der Test einer umfangreichen Bereitstellung abgeschlossen ist. Binden Sie diese UserInnen ein und fahren Sie mit den nächsten Features fort.

Mehr Daten für Business Cases

Entwickler mögen zwar den Wert ihres Codes erkennen, DevOps-Teams aber müssen gegenüber der Geschäftsleitung und dem gesamten Unternehmen begründen, warum sie mehr Ressourcen brauchen.

Canary Deployments geben schnell Aufschluss darüber, welche Nachfrage für neue Features bestehen könnte. Führen Sie ein Canary Deployment für ein überzeugendes neues Feature bei einer kleinen Gruppe einflussreicher UserInnen durch, damit sie darüber sprechen können. Nutzen Sie Kennzahlen für Engagement und Werbung, um Argumente vorzubringen, warum Sie eine größere neue Initiative in Verbindung mit diesem Feature vorantreiben wollen.

Stärkeres Risikomanagement

Canary Deployments sind im Grunde genommen eine Reihe von Mikrotests. Wenn Sie schrittweise neue Features einführen und sie sukzessive mit Canary-Tests überprüfen, können Sie die Gesamtkosten von Fehlern oder größere Systemprobleme erheblich reduzieren. Sie werden niemals eine größere Version zurücknehmen müssen, einen PR-Schaden erleiden und eine große und komplizierte Codebase überarbeiten müssen.

Kontras

Mehr Betriebskosten

Wie jeder komplexe Prozess haben auch Canary Deployments einige Nachteile. Wenn Sie einen Load Balancer zur Aufteilung von UserInnen für ein Canary Deployment verwenden möchten, brauchen Sie eine zusätzliche Infrastruktur und müssen einen zusätzlichen Verwaltungsaufwand betreiben.

In diesem Szenario erstellen Sie eine zweite Produktionsumgebung und ein zweites Backend neben Ihrer primären Umgebung. Sie haben dann zwei Codebases, zwei App-Server, u. U. zwei Webserver und eine Netzwerkinfrastruktur, die gewartet werden muss.

Alternativ dazu verwenden viele DevOps-Teams Feature Flags, um ihre Canary Deployments auf einem einzigen System zu verwalten. Ein Feature Flag kann UserInnen in einen Canary-Test während der Laufzeit innerhalb einer einzigen Codebasis aufteilen. Canary-UserInnen sehen das neue Feature, während alle anderen den existierenden Code ausführen.

Die Bereitstellung lokaler Applikationen: keine leichte Aufgabe

Wenn Sie eine lokal installierte Applikation entwickeln, laufen Sie Gefahr, dass die UserInnen ein manuelles Update vornehmen müssen, um die neueste Version Ihrer Software zu erhalten. Wenn Ihr Canary Deployment in diesem letzten Update enthalten ist, wird Ihr neues Feature möglicherweise nicht auf allen Client-Systemen installiert, die Sie aber für gute Testergebnisse brauchen.

Mit anderen Worten: Je mehr Ihre Software clientseitig läuft, desto weniger ist sie für Canary Deployments geeignet. Ein vollständiges Canary-Release könnte sich hier besser eignen, um reale Testergebnisse zu erhalten.

UserInnen werden weiterhin mit Softwareproblemen konfrontiert

Ein Canary Deployment soll ein neues Feature zwar nur einigen wenigen UserInnen präsentieren und die breitere User Base auslassen, konfrontiert aber End-UserInnen weiterhin mit einem Code, der nicht ausgiebig getestet wurde. Wenn ein Ausfall eines bestimmten Features bei nur wenigen UserInnen schon zu große negative Auswirkungen für Ihr Unternehmen hat, sollten Sie auf ein Canary Deployment verzichten und strengere interne Tests durchführen.

Wann sollte man auf Canary Deployments verzichten?

Canary Deployments sind zwar eine ausgezeichnete Strategie für Unternehmen, die ständig auf Experimente und Innovationen setzen, sind aber nicht für jeden geeignet. Canary Deployments sind möglicherweise nicht die richtige Strategie, wenn:

• Fehler selbst in kleinen Bereitstellungen zu Regelverstößen bei einem bestimmten System beitragen können. Zum Beispiel im Gesundheitswesen, wenn es um Patientendaten bei einem Produktionssystem geht.
• Der Ausfall eines Dienstes lebensbedrohliche Folgen haben kann, wie z. B. bei Applikationen zur Verwaltung des Stromnetzes oder von Notdiensten.
• Die finanziellen oder organisatorischen Folgen des Ausfalls einer Applikation Ihrem Unternehmen irreparablen Schaden zufügen könnten.

Canary Deployments im Vergleich zu anderen Bereitstellungsstrategien

Canary Deployments sind nur eine mögliche Bereitstellungsstrategie für Ihr Team. Sie werden auch oft mit anderen ähnlichen, aber unterschiedlichen Prozessen wie A/B-Tests verwechselt. Sehen wir uns an, wie sich Canary Deployments mit anderen Bereitstellungsstrategien und ähnlichen Prozessen vergleichen lassen, mit denen sie oft verwechselt werden.

Canary Deployments vs. A/B-Tests

Sowohl bei Canary Deployments als auch bei A/B-Tests werden mehrere Produktionsumgebungen oder mehrere mit Flags versehene Codepfade zum Testen verwendet, wobei aber jedes Mal ein anderes Ziel verfolgt wird. DevOps-Teams nutzen Canary Deployments, um festzustellen, ob bei einer neuen Software technische Probleme vorliegen oder bei der Usability Schwierigkeiten bestehen. Bei einem A/B-Test werden zwei verschiedene funktionierende Varianten für bestimmte Punkte wie Usability und Engagement sowie andere UX-Kennzahlen verglichen, um festzustellen, welche unter bestimmten Bedingungen besser abschneidet.

Canary Deployments vs. Blue-Green Deployments

Canary Deployments werden auch mit Blue-Green Deployments verwechselt. In beiden Fällen können parallele Produktionsumgebungen verwendet werden – die mit einem Load Balancer oder Feature Flag verwaltet werden – um das Risiko von Softwareproblemen zu mindern.

Bei einem Blue-Green Deployment starten diese Umgebungen identisch, aber nur eine empfängt Traffic (der blaue Server). Ihr Team veröffentlicht ein neues Feature für die Hot Backup-Umgebung (den grünen Server). Dann verlagert der Router, das Feature Flag usw. nach und nach neue UserInnen Sessions von dem blauen auf den grünen Server, bis der gesamte Traffic zu 100 % auf dem grünen Server liegt. Nach dem Cutover aktualisiert das Team den jetzt alten blauen Server mit dem neuen Feature, der dann zur Hot Backup-Umgebung wird.

Wie die Umstellung bei den beiden Strategien gehandhabt wird, hängt vom gewünschten Ergebnis ab. Blue-Green Deployments sollen Ausfallzeiten vermeiden. Canary Deployments werden verwendet, um ein neues Feature in einer Produktionsumgebung mit minimalem Risiko zu testen. Canary Deployments sind gezielter.

Wie wird ein Canary Deployment durchgeführt?

Für ein Canary Deployment sind nur wenige Schritte erforderlich:

Identifizieren Sie Ihre Canary-Gruppe

Es gibt verschiedene Möglichkeiten, wie Sie UserInnen als Canary-Gruppe auswählen können.

Zufallsbedingte Teilgruppe

Wählen Sie verschiedene UserInnen wirklich nach dem Zufallsprinzip aus, zum Beispiel mit einem Load Balancer. Aber auch eine Flag Management Software kann einen bestimmten Prozentsatz des gesamten Traffics über ein einfaches Modulo an einen Canary-Test weiterleiten.

Early Adopter

Wenn Sie ein Early Adopter-Programm für besonders engagierte UserInnen durchführen, nutzen Sie diese als Canary-Gruppe. Machen Sie es zum Vorteil ihres Programms. Als Gegenleistung, die Bugs zu tolerieren, auf die sie bei einem Canary Deployment stoßen könnten, bieten Sie ihnen Treueprämien an.

Nach Region

Vielleicht möchten Sie bei Ihrem Canary Deployment auf eine bestimmte Region setzen. Legen Sie zum Beispiel fest, dass Ihr Canary Deployment in den späten Abendstunden an europäische IPs geleitet wird. So vermeiden Sie, dass UserInnen tagsüber Ihre neuen Features sehen, erhalten aber eine Handvoll UserInnen Sessions nach Feierabend.

Interne Testpersonen

Sie können jederzeit Sessions aus Ihren internen Subnetzen als Canary Deployment konfigurieren.

Entscheiden Sie sich für Ihre Canary-Kennzahlen

Zweck eines Canary Deployments ist, eine klare Antwort mit „Ja“ oder „Nein“ auf die Frage zu erhalten, ob Ihr Feature sicher ist, um es in die Produktion zu geben. Um diese Frage zu beantworten, müssen Sie zunächst entscheiden, welche Kennzahlen Sie verwenden wollen, und dann die Mittel zur Überwachung der Performance installieren.

Sie können zum Beispiel Folgendes überwachen:

• die Anzahl der internen Fehler
• CPU-Auslastung
• Speicherauslastung
• Latenzzeit

Sie können die Feature Management-Software schnell und einfach anpassen, um die Performance-Analyse zu überwachen. Diese Plattformen können sich als ausgezeichnete Tools erweisen, um die Experimentierkultur anzuregen.

Entscheiden Sie, wie sich der Übergang vom Canary Deployment zum vollständigen Deployment darstellen soll

Wie bereits erwähnt, sollten Canary-Releases nur einige Minuten bis Stunden dauern. Sie sind nicht für lange Experimente bestimmt. Aufgrund dieser knappen Zeit sollte Ihr Team bereits am Anfang entscheiden, wie viele UserInnen oder Sessions in die Canary-Phase eingebunden werden und wie zur vollständigen Bereitstellung übergegangen werden soll, sobald die Kennzahlen positive Benchmarks erreicht haben.

Sie können zum Beispiel ein zufälliges Canary Deployment von 5/95 wählen. Konfigurieren Sie ein Feature Flag, um 5 Prozent Ihrer UserInnen zufallsbedingt in den Canary-Test zu verschieben, während die restlichen 95 Prozent auf der stabilen Produktionsversion bleiben. Sind die Ergebnisse positiv, entfernen Sie das Flag und stellen das Feature vollständig bereit.

Vielleicht möchten Sie aber auch einen eher konservativen Ansatz wählen. Bei einer weiteren beliebten Canary-Strategie wird ein Canary-Test logarithmisch bereitgestellt, d. h. man geht von einer Stichprobe von einem Prozent auf zehn Prozent, sieht, wie das neue Feature einer höheren Last standhält, und erhöht dann auf 100 Prozent.

Bestimmen Sie die Infrastruktur

Sobald sich Ihr Team einig ist, müssen Sie sicherstellen, dass die gesamte Infrastruktur passt, damit Ihr Canary Deployment reibungslos verläuft.

Sie brauchen ein System zur Aufteilung der User Base und zur Leistungsüberwachung. Sie können die Aufteilung mit einem Router oder Load Balancer vornehmen, aber auch direkt in Ihrem Code mit einem Feature Flag. Feature Flags sind oft kostengünstiger und schneller einzurichten und können leistungsfähiger sein.

Verwenden Sie Feature Flags für bessere Canary Deployments

Auf den Punkt gebracht ist ein Feature Flag nichts anderes als eine „if“-Anweisung, ab der UserInnen während der Laufzeit verschiedenen Codepfaden abhängig von einer oder mehreren Bedingungen folgen. Bei einem Canary Deployment lautet diese Bedingung, ob der oder die UserIn der Canary-Gruppe angehört oder nicht.

Feature Flag – Beispiel

Angenommen, wir betreiben eine vollkommen neue Social Network Website für E-Sport-Fans. Unser DevOps-Team hat hart an einer Content-Empfehlungsfunktion gearbeitet, die UserInnen basierend auf den angeschauten Livestreams Empfehlungen in Echtzeit gibt. Das Team hat dieses Empfehlungsfeature so verbessert, dass es deutlich schneller ist. In internen Tests hat es sich gut bewährt. Jetzt wollen sie sehen, wie es sich unter realen Bedingungen schlägt.

Das Team möchte für ein Canary Deployment keine Zeit und kein Geld in die Installation einer neuen physischen Infrastruktur investieren. Stattdessen beschließt das Team, ein Feature Flag zu verwenden, um die neue Empfehlungsmaschine zufallsbedingt 5 % der UserInnen-Base zugänglich zu machen.

Das Feature Flag teilt die UserInnen mit einem einfachen Modulo in zwei Gruppen auf, wenn sie einen Livestream laden. Innerhalb weniger Minuten erhält Ihr Team die Ergebnisse von einigen Tausend User Sessions mit dem neuen Code. Tatsächlich wird der Stream schneller geladen und das Engagement der UserInnen verbessert. Aber es kommt zu einem unerwarteten Spike bei der CPU-Auslastung auf dem Produktionsserver. Das Ops-Team erkennt, dass die Leistung sinkt und „killt“ das Canary-Flag.

Das Team beschließt, mit dem Rollout erst fortzufahren, wenn es bei dem neuen Code die Ursache für die unerwartete Spitze der CPU-Auslastung auf dem Server beheben kann. Dank der realen Testergebnisse des Canary Deployments hat das Team eine relativ gute Vorstellung davon, was passiert ist, und macht sich wieder an die Arbeit.

Canary Deployments sind ein wesentlicher Bestandteil Ihres DevOps-Toolkits

Die Strategien der Softwarebereitstellung haben sich in den letzten Jahrzehnten rasant weiterentwickelt. Canary Deployments zählen zu den leistungsstärksten Strategien, die nun für Teams verfügbar sind, die DevOps-Methoden wie CI/CD folgen möchten.

Canary Deployments sind effiziente Strategien, da sie aussagekräftige Daten schnell bereitstellen und liefern können und für nahezu jede App oder jedes Feature eingesetzt werden können, die getestet werden sollen. Sie bieten Ihrem Team schnelles Feedback, wodurch Entwicklungszyklen verkürzt und neuer Code schneller in Produktion gegeben werden kann. Tests des Canary Deployments bieten aussagekräftige Ergebnisse, die Ihnen helfen, dem Unternehmen Business Cases für neue Initiativen aufzustellen.

In diesem Artikel haben wir erklärt, was Canary Deployments sind, welche Vor- und Nachteile sie haben, wie sie im Vergleich zu anderen Bereitstellungsstrategien abschneiden und wie Sie bei der Planung eines Canary Deployments in Ihrem Team vorgehen können. Es gibt viele Management-Tools für Deployments, aber Feature Flags sind möglicherweise die effektivste Option, die Ihr DevOps-Team schon heute nutzen kann.

Feature Flags optimieren und vereinfachen das Testen von Canary Deployments. Features Flags verringern den Bedarf einer zweiten Produktionsumgebung. Mit einer Feature Management Software wie Flagship sind anspruchsvolle Tests und Analysen möglich. Ganz gleich, für welche Methode Sie sich entscheiden, Canary Deployments helfen Ihnen, Ihren UserInnen die beste Software schnell zur Verfügung zu stellen.

The post Canary Deployments: Alles, was Sie wissen müssen appeared first on abtasty.

Entwickler können zum Erstellen von Features Toggles einen „Decision Point“ coden, an dem das System ein bestimmtes Feature ausführt, abhängig davon, ob bestimmte Bedingungen erfüllt werden oder nicht. Mit anderen Worten, mit Feature Toggles können Sie kontextsensitive Software schnell und effizient ausliefern.

Feature Toggles haben viele Einsatzmöglichkeiten, von der Unterstützung der agilen Entwicklung bis hin zu Markttests und zur Optimierung laufender Operationen. Hinter dieser Fähigkeit steckt aber auch die Gefahr, dass Ihr Code unnötig komplexer wird. Sie müssen mit Feature Toggles richtig umgehen können, um das Beste aus ihnen herauszuholen.

In diesem Artikel bieten wir Ihnen einen Überblick darüber, was Feature Toggles bewirken und wie Sie sie in Ihren Entwicklungs- und Produktionsumgebungen implementieren können. Darüber hinaus stellen wir Ihnen einige Best Practices vor, die wir zur Verwendung dieser Toggles empfehlen.

[toc content=“.entry-content“]

Was genau ist ein Feature Toggle?

Einfach gesagt ist ein Feature Toggle ein leistungsstarkes „If“-Statement, ab dem während der Laufzeit mindestens einem oder zwei verschiedenen Codepfaden abhängig von einer oder mehreren Bedingungen gefolgt wird. Hier ein konkretes Beispiel:

normalFeature = {
‚id‘: 1,
‚description‘: u’basic service‘,
’newstuff‘: False
}

testFeature = {
‚id‘: 2,
‚description‘: u’much better service‘,
’newstuff‘: True
}

@app.route(‚/ourapp/api/v1.1/storefront‘, methods=[‚GET‘])
def get_tasks():
if internalTester == True:
return jsonify({‚feature‘: testFeature})
else:
return jsonify({‚feature‘: normalFeature})

Hier haben wir zwei verschiedene generische Features definiert: normalFeature und testFeature. Während der Laufzeit prüft die Applikation in der Konfiguration, ob das Feature von einem oder einer interne(n) Test-UserIn geladen wird. Wenn ja, lädt die Applikation das Test-Feature, das sich in der Entwicklung befindet. Wenn nicht, sieht der oder die „normale“ KundIn das aktuelle Feature.

Feature Toggles können alles sein, ein einfaches „If“-Statement oder komplexe Entscheidungsbäume, die auf viele verschiedene Variablen einwirken. Um festzulegen, welche Richtung ein Toggle nehmen soll, können zahlreiche Bedingungen verwendet werden, u. a. Ergebnisse von Tauglichkeitstests aus anderen Features in der Codebase, eine Einstellung in der Feature Management Software oder eine Variable aus einer Konfig-Datei.

Verschiedene Feature Toggles für verschiedene Aufgaben

Gehen Sie mit Feature Toggles jeweils unterschiedlich um, je nachdem, wie Sie sie bereitstellen möchten. Es kann nützlich sein, Toggles in Kategorien nach zwei Aspekten zu unterteilen: wie lange Toggles in der Entwicklung sind bzw. live geschaltet bleiben und wie dynamisch ihre Funktion ist. Demzufolge können wir Feature Toggles in vier verschiedene Kategorien unterteilen:

• Release Toggles
• Experiment Toggles
• Ops Toggles
• Permission Toggles

Ein Diagramm der vier Kategorien der Feature Toggles (Quelle)

Release Toggles

Diese Toggles unterstützen Entwicklerteams, wenn sie neue Features schreiben. Statt einen Zweig zu erstellen, in dem das Team das neue Feature schreibt, generiert es ein Release Toggle in der Master Codebase, wobei der Code inaktiv bleibt, während an ihm gearbeitet wird. Die Entwickler können den Trunk Code nach wie vor in die Produktion geben, um ihre Auslieferungsziele zu erfüllen.

Release Toggles sollen in der Regel kein fester Bestandteil Ihrer Codebase sein. Sobald das zugehörige Feature endgültig ist, sollten die Toggles entfernt werden. In der Praxis bedeutet dies in der Regel, dass diese Toggles einen Lebenszyklus von einigen Tagen bis zu einigen Wochen durchlaufen und sich in puncto Langlebigkeit somit auf einer Skala im unteren Bereich befinden. Release Toggles sind auch nicht besonders dynamisch. Entweder steht das Feature zur Freigabe bereit oder nicht.

Beispiel für ein Release Toggle

Ein e-Commerce-Unternehmen entwickelt auf Anfrage eines hochkarätigen Kunden eine neue Konfiguratorfunktion. Der Konfigurator überwacht Artikel, die der Kunde bereits zusätzlich ausgewählt hat, und schlägt Artikel-Sets vor, um seine Bestellung abzurunden.

Das Unternehmen möchte dieses Feature im Endeffekt allen Kunden anbieten. Aber derzeit funktioniert der Konfigurator nur nach den Vorgaben dieses einen Kunden. Das Entwicklerteam dieses Konfigurators aktiviert für dieses neue Feature ein Release Toggle, das es inaktiv lässt.

Experiment Toggles

Diese Toggles werden verwendet, um A/B-Tests oder multivariable Tests einfacher zu machen. Sie erstellen einen Toggle Point, hinter dem zwei oder mehrere Codepfade mit den zu testenden Features liegen. Während der Laufzeit teilt das System – oder das Toggle selbst – Nutzer in verschiedene Kohorten auf, an denen diese Features getestet werden.

Durch die Verfolgung aggregierter Experience-Daten bei jeder Kohorte können Sie die Wirkung der verschiedenen Features vergleichen. Experiment Toggles sind eine beliebte Methode für die Optimierung von Marketing-Initiativen, User Experiences und anderer Features für UserInnen.

In der Regel sollten Experiment Toggles nur so lange existieren, bis keine Daten zum Feature-Testing mehr gesammelt werden müssen. Der exakte Zeitrahmen hängt vom Traffic-Volumen bei diesem Feature ab, beläuft sich aber in der Regel auf mehrere Wochen bis mehrere Monate. Diese Einschränkung bezieht sich eher auf den Test selbst als auf das Toggle. Der Nutzen der gesammelten Daten verliert sich im Laufe der Zeit, wenn andere Feature- und Code-Updates Vergleiche mit zuvor gesammelten Nutzerdaten entkräften.

Beispiel für ein Experiment Toggle

Unser e-Commerce-Unternehmen hat die Fehler in seinem neuen Konfigurator beseitigt. Aber es wird darüber diskutiert, welcher der beiden Vorschlagsalgorithmen die beste Experience bietet. Man entschließt sich für einen A/B-Test, um Daten aus der realen Welt zu erhalten.

Das Unternehmen fügt ein Experiment Toggle zum Produktionskonfigurator mit zwei verschiedenen Vorschlagsalgorithmen dahinter hinzu. Das Toggle teilt die UserInnen in zwei Kohorten mit einem Modulo auf, wenn sie versuchen, den Konfigurator zu laden. Nach drei Wochen ist das Team der Meinung, endgültige Daten zu haben, die zeigen, dass mehr UserInnen ihre Bestellungen mit dem Algorithmus B abschließen. Das e-Commerce-Unternehmen entfernt das Experiment Toggle und der Algorithmus B wird für alle UserInnen live geschaltet.

Ops Toggles

Ops Toggles werden zum Abschalten von Features verwendet – wie ein „Kill Switch“ – oder um die Performance der Features anzupassen. Wenn zum Beispiel bestimmte Bedingungen nicht erfüllt werden und etwa KPI-Ziele unter einem Schwellenwert liegen, schaltet das Toggle das betreffende Feature ab, bis sich die Bedingungen verbessern. Ops Toggles sind für die Programmierung neuer Features kurz nach dem Testing oder bei ressourcenintensiven Features nützlich.

Die Langlebigkeit von Ops Toggles hängt von den jeweiligen Anwendungsfällen ab. Wenn Sie ein Ops Toggle zum Einstellen eines neuen Features kurz nach der Entwicklung verwenden, dann brauchen Sie das Toggle wahrscheinlich nur ein paar Monate. Ein Kill Switch-Toggle wird in der Regel jedoch als permanenter Bestandteil des Codes erstellt. Ops Toggles sind in der Regel genauso statisch oder dynamisch wie die Bedingungen, unter denen das kontrollierte Feature genutzt wird. Beispielsweise sind Ops Toggles tendenziell relativ statisch, wenn sie nur mit einer Leistungskennzahl verbunden sind.

Beispiel für ein Ops Toggle

Unser e-Commerce-Unternehmen bereitet sich auf eine Traffic-Spitze für den jährlichen Schlussverkauf vor. Das ist der erste Sale, bei dem der Konfigurator in der Produktion ist. Während der Tests haben die Entwickler festgestellt, dass der vom User bevorzugte B-Algorithmus Systemressourcen stark beansprucht.

Die Operators verlangten einen Kill Switch für den Konfigurator, bevor die Sales-Angebote live geschaltet wurden. Sie wollten nur ein einziges Toggle, auf das sie in der Release Management Software klicken mussten, falls die Performance nachlassen sollte. Und siehe da, am ersten Tag des Schlussverkaufs begann die Performance beim Konfigurator zu fallen. Und das Ops-Team konnte das Feature schnell abschalten, bevor es von zu vielen UserInnen wahrgenommen wurde.

Permission Toggles

Permission Toggles sollen langlebiger sein oder sogar ein fester Bestandteil in Ihrem Code. Sie werden als Methode verwendet, um einem bestimmten Teil von UserInnen Features anzuzeigen. Beispielsweise können Sie ein Permission Toggle verwenden, um ausschließlich Premium UserInnen auf Ihrer Website Premium Inhalte anzubieten. Permission Toggles sind generell die dynamischsten Toggles unter den vier hier definierten Kategorien, da sie in der Regel für eine oder einen UserIn getriggert werden.

Beispiel für ein Permission Toggle

Das einfache Beispiel am Anfang dieses Artikels lässt sich praktisch mit einem Permission Toggle vergleichen. Nach dem jährlichen Schlussverkauf ist unser e-Commerce-Unternehmen der Meinung, Algorithmus B sei zu ressourcenintensiv, um das Feature allen UserInnen anzuzeigen. Stattdessen entscheidet sich das Unternehmen, ein Premium Feature zu erstellen. Das Permission Toggle kann sich wie folgt darstellen:

normalFeature = {
‚id‘: 1,
‚description‘: u’basic service‘,
‚configurator‘: False
}

premiumFeature = {
‚id‘: 2,
‚description‘: u’the better configurator‘,
‚configurator‘: True
}

@app.route(‚/ourapp/api/v1.1/storefront‘, methods=[‚GET‘])
def get_tasks():
if premiumUser == True:
return jsonify({‚feature‘: premiumFeature})
else:
return jsonify({‚feature‘: normalFeature})

Feature Toggles vs. Feature Flags

Eine kleine Randbemerkung: Es gibt einige Diskussionen über den Begriff Feature Toggle verglichen zum Begriff Feature Flag. „Toggle“ trifft eher zu, wenn der Code bei mehreren Hauptzweigen des Codes ein- oder ausgeschaltet ist. „Flag“ trifft eher zu, wenn auf einen Entscheidungspunkt multikonditionale oder eine große Anzahl an Codepfaden folgen.

Feature Toggles in Ihre Roadmap zur Unterstützung agiler Workflows integrieren

Mit Feature Toggles in Ihrem Entwicklungsprozess werden neuere agile Ansätze unterstützt. Sie können eine Software veröffentlichen, während noch Code Sprints für neue Features bearbeitet werden. Diese Features müssen lediglich hinter Toggles verborgen werden, bis sie für die Veröffentlichung, Marketingtests oder den nächsten Schritt im Entwicklungsprozess tauglich sind.

In der Regel würden Sie die kürzlich vom User oder von der Userin gewünschten Features auf Code-Verzweigungen unter einem eher herkömmlichen Wasserfallmodell schreiben. Diese Features würden im Anschluss einen langen Test- und QA-Prozess durchlaufen, bevor Ihr Team die Features wieder in den Trunk Code zurückführen kann. Mit Feature Toggles können Sie den gesamten Entwicklungs- und Testprozess direkt auf dem Trunk Code durchführen.

Unsere Best Practices für die Verwendung von Feature Toggles

Wie bereits erwähnt, stehen Feature Toggles für eine leistungsstarke und flexible Entwicklungsmethode. Wenn Sie Ihre Toggles nicht sorgfältig implementieren und managen, können sie schnell eine chaotische Codebase erhalten.

Es wurden viele verschiedene Best Practices zum Coden von Feature Toggles  vorgeschlagen, aber wir wollten Ihnen einige unserer eigenen Toggles anbieten. Sobald ein unsauberer Entscheidungspunkt in Ihre Codebase geschrieben wird, scheinen viele weitere zu folgen. Wenn diese Best Practices von Anfang an befolgt werden, können Sie solche Probleme in Schach halten.

Verwenden Sie Feature Toggles, um langsam zur agilen Entwicklung zu wechseln

Wenn Ihr Team agile Entwicklungs- und Testmethoden ausprobieren möchte, ohne sich völlig in eine neue Entwicklungsmethode stürzen zu müssen, dann sind Feature Toggles in Ihrer Roadmap ein ausgezeichnetes Mittel für den Anfang. Die Kosten für diese Versuche sind gering. So könnte zum Beispiel zunächst nur ein Team ein Experiment Toggle für einen ersten Canary Release verwenden.

Wenn der Versuch gelingt, können Sie das Experiment Toggle durch ein Ops Toggle ersetzen, wenn das Feature in die Produktion geht. Dann weiten Sie die Nutzung des Toggles auf andere Teams oder Prozesse aus. Führen Sie dieses Toggle früher in die Entwicklungszyklen ein als Release Toggles. Dann sind Sie langsam aber sicher auf dem Weg zur völlig agilen Entwicklung.

Verwenden Sie Toggles sowohl für interne als auch externe Features

Jetzt müsste klar sein: Feature Toggles haben während des gesamten Entwicklungs- und Produktionslebenszyklus Ihrer Software Ihren Zweck. Schränken Sie die Toggle-Nutzung nicht auf Features ein, die nur von KundInnen gesehen werden. Sie können Release und Ops Toggles auch für Backend-Features verwenden. Die Toggles bieten DevOps Teams eine besonders granulare Stufe beim Kontroll- und Risikomanagement des Codes, was wichtig sein kann, wenn Backend-Features geändert werden, die einen entscheidenden Einfluss darauf haben, wie Ihr System performt.

Lassen Sie die Toggle-Planung in Ihre Design-Phase einfließen

Vom Toggle-Namen und den Konfigurationseinstellungen bis zum Entfernen der Toggles und der Zugangskontrolle – alles hängt davon ab, wie Sie neue Features gleich zu Beginn entwerfen. Bauen Sie diese Toggle-Planung in Ihren Designprozess ein und die nächsten sechs Monate Ihres Feature Managements werden um einiges einfacher sein.

Verwenden Sie ein standardisiertes Toggle Namensschema

Viele Unternehmen verwenden einen Style Guide für Entwickler, der festlegt, wie sie Code schreiben und organisieren sollen, wie sie zum Beispiel Abstände, Reihenfolge und Klammern beim Naming anwenden. Wenn Sie Feature Toggles verwenden wollen, sollten Sie auch den Naming-Stil schon frühzeitig im Einführungsprozess Ihrer Toggles standardisieren.

Kurz und bündig zu sein, ist beim Coden für andere Aspekte wichtig. Wenn es aber um Toggle-Namen geht, seien Sie ausführlich. Details bedeuten Klarheit. Ausführliche Toggle Namen helfen Entwicklern und Ops Teams außerhalb Ihres Kernteams zu verstehen, was sie prüfen, wenn ihr einziger Bezug der Toggle Name ist, den Sie sechs Monate zuvor aus einer Laune heraus gewählt haben.

Einige weitere Toggle-Namenskonventionen, die wir vorschlagen:

• Binden Sie den Namen des Teams oder Projekts ein.
• Binden Sie das Datum ein, an dem das Toggle erstellt wurde.
• Identifizieren Sie die Kategorie des Flags.
• Beschreiben Sie das tatsächliche Toggle-Verhalten.

Hier ein Beispiel: algteam_10-12-2021_Ops_configurator-killswitch

Dieser Name bietet einige nützliche Informationen, aus denen jeder oder jede in einem Team ableiten kann, worum es sich handelt, wenn ein Toggle in einer Fehlermeldung genannt wird. Sie wissen, wer das Toggle geschrieben hat, wie lange es in der Codebase war und was das Toggle bewirkt.

Unterschiedliche Toggles unterschiedlich handhaben

Es scheint selbstverständlich, ist aber ein wichtiger Punkt, den es hervorzuheben gilt. Wie wir bereits oben erwähnt haben, können Feature Toggles in vier allgemeine Kategorien unterteilt werden. Sie sollten die einzelnen Kategorien unterschiedlich handhaben.

Denken Sie an den oben erwähnten Konfigurator, als er die Entwicklungsphase, dann Markttests und anschließend den laufenden Betrieb durchlief. Der Konfiguratorcode befand sich die gesamte Zeit hinter einem dieser Features Toggles. Aber die Art und Weise, wie die Entwicklungs- und Produktteams mit diesem Toggle interagieren, muss in jedem Stadium geändert werden.

Zu Beginn der Entwicklung kann das Toggle einfach in der Versionskontrolle konfiguriert werden. Während das e-Commerce-Unternehmen A/B-Tests durchführt, kann das Toggle auf einer Feature Management-Plattform sein. Wenn das Ops-Team einen Kill Switch hinzufügt, kann es sich entscheiden, es in derselben Feature Management-Plattform, aber auf einem anderen Dashboard zu lassen.

AB Tasty Flagship Dashboard (Source)

Feature Toggle-Konfigurationen immer darlegen

Wie bei jedem anderen Codeobjekt auch, ist es besser, Feature Toggle-Konfigurationen als Metadaten zu dokumentieren, damit andere Entwickler, Tester und Produktionsteams ein Dokument in Papierform haben, dem sie folgen können, um genau zu verstehen, wie Ihr Feature Toggle in einer bestimmten Umgebung läuft. Am besten, Sie speichern Ihre Toggle-Konfiguration in einem für Menschen lesbaren Format, damit auch andere außerhalb Ihres Teams verstehen, was ein Toggle bewirkt.

Diese Best Practice ist für die Features nützlich, bei denen längerfristig Toggles verwendet werden sollen. Denken Sie wieder an unser Konfiguratorbeispiel. Ein völlig neuer Product Operator, der versucht, einen plötzlichen, unerwarteten Performance-Rückgang zu verstehen, würde sehr dankbar für eine Datei sein, die für Menschen lesbar ist und ihm erklärt, dass der B-Algorithmus bei Tests ein Jahr zuvor plötzlich ressourcenintensiv wurde.

Behalten Sie die Haltekosten für Feature Toggles im Auge

Wenn Sie Feature Toggles zum ersten Mal benutzen, sollten Sie sich nicht hinreißen lassen, alle auf einmal überall im Code zu verwenden. Feature Toggles lassen sich zwar einfach erstellen, müssen aber richtig gehandhabt und getestet werden, um einen wirklichen Nutzen zu ziehen. Setzen Sie nach und nach mehr Feature Toggles ein oder ziehen Sie die Integration einer Feature Management-Plattform in Ihre Entwicklungs- und Ihre Testumgebung in Betracht.

Stellen Sie Feature Toggles strategisch bereit und halten Sie Ihren Toggle-Bestand so niedrig wie möglich. Verwenden Sie sie, wenn es notwendig ist. Aber überprüfen Sie, ob Toggles die angemessene Methode für die Lösung eines bestimmten Problems sind.

Lassen Sie keine alten Toggles in Ihrem Code. Streichen Sie die Toggles zusammen, sobald sie ausgedient haben. Je mehr inaktive Toggles im Code, desto größer der Mehraufwand für Ihr Team, diese Toggles zu managen. Sie können Toggles entfernen, wenn Sie Code Cleanups auf die To-Do-Liste Ihrer Teams setzen oder diesen Prozess in Ihre Management-Plattform integrieren.

Halten Sie den Toggle Scope möglichst klein

Aufgrund der Wirkung der Toggles neigt man dazu, große Codeabschnitte von einer komplexen Toggle-Reihe zu steuern. Bleiben Sie „standhaft“ und halten Sie den Toggle Scope bei jeder Aufgabe möglichst klein.

Sollte ein Toggle auf mehrere Features übergreifen, kann es für den Rest des Teams zum Albtraum werden, Bugs zu beheben, die Wochen oder Monate zurückliegen und sich jetzt auf die Arbeit des Teams auswirken.

Nehmen wir noch einmal unser Konfiguratorbeispiel. Unser Dev-Team erstellt vier separate Widgets, die der oder die UserIn im Konfiguratortool benutzt. In diesem Szenario würden wir fünf Toggles empfehlen: eins für den Konfigurator selbst und eins für jedes einzelne Widget. Coden Sie die Widget Toggles abhängig vom Konfigurator-Toggle. Wenn in diesem Framework eines der Widgets nicht richtig lädt, werden die anderen dem oder der UserIn angezeigt.

Feature Toggles können den gesamten Entwicklungsprozess verändern

Feature Toggles sind für die Entwicklung, Tests und Steuerung von Code Features im Framework der Continuous Integration und Continuous Delivery eine wirkungsvolle Methode. Sie stehen für eine einfache Methode, mit der Ihr Team einen stabileren Code höherer Qualität nach agilen Prinzipien ausliefern kann.

In diesem Artikel haben wir erklärt, wie Feature Toggles funktionieren, welche Toggles Sie erstellen und wie Sie diese Toggles in Ihrem agilen Prozess verwenden – oder sie in einem Entwicklungsprozess ausprobieren können. Darüber hinaus haben wir Ihnen einige unserer empfohlenen Best Practices vorgestellt, damit Ihr Unternehmen das Beste aus Feature Toggles herausholen kann.

Fangen Sie klein an, um im größeren Rahmen fortzufahren

Es gibt keinen Grund, nicht schon heute Feature Toggles zu nutzen. Fangen Sie klein an und nutzen Sie zunehmend mehr Features Toggles, wenn Ihr Team sich daran gewöhnt und verstanden hat, wie diese Toggles funktionieren. Wenn Sie gerade beginnen, ein vollkommen neues Feature zu coden, richten Sie ein Release Toggle im Trunk Code ein. So brauchen Sie keine Verzweigung. Wenn Sie mit Markttests beginnen, richten Sie ein Experiment Toggle für Split Testings ein.

Wenn Ihr Team sich im Klaren ist, wie es Feature Toggles verwenden möchte, ziehen Sie eventuell eine Feature Management-Plattform für eine optimierte Administration der Toggles in Betracht. Die Optimierung von Entwicklung und Testing war genau das, woran wir gedacht hatten, als wir Flagship, unsere Release- und Feature Management-Plattform, entwickelt haben.

Mit Flagship hat Ihr Team das richtige Tool zur Hand, um Toggle Workflows und Kommunikation zu optimieren. Unabhängig von den Aufgaben oder dem Fokus eines Teams bringt Flagship, unser Feature Management-Tool, alle Voraussetzungen mit, um die richtigen Features auf richtige Weise bereitzustellen.

The post Feature Toggles: Ein Überblick & unsere Best Practices appeared first on abtasty.

Flagship, die Feature Management Plattform von AB Tasty, wurde als Leader ausgezeichnet in „The Forrester New Wave: Feature Management And Experimentation, Q2 2021.“

Der Bericht des unabhängigen Analyseunternehmens gibt einen Überblick über den aufstrebenden Markt: Die Gesamtergebnisse werden in vier Kategorien eingeteilt: Herausforderer, Mitbewerber, starke Leistungsträger und – schließlich – Marktführer.

• Lernen Sie Angebot, Strategie und der Marktpräsenz der Anbieter kennen
• Erhalten Sie Zugriff auf die 10 Kriterien, die diesen austrebenden Markt definieren
• Sehen Sie, warum Flagship als Leader ausgezeichnet wurde

Kostenlos Zugang erhalten

The Forrester New Wave
Feature Management and Experimentation, Q2 2021

Flagship gehört zu den sieben „bedeutendsten Anbietern“, die Forrester im aufstrebenden Markt für Feature Management und Experimentieren identifiziert hat: ConfigCat, Featureflow, LaunchDarkly, Optimizely, Split und Unleash.

Der Bericht bewertet den aufstrebenden Markt für Feature-Management und Experimentieren, indem er sieben Anbieter anhand von 10 Kriterien analysiert.

Die 10 Kriterien für die Bewertung in Feature-Management und Experimentieren

Laut Forrester gehört AB Tasty zu den führenden Anbietern in diesem Markt – dank unserer differenzierten Bewertungen in den Kriterien Feature Management, Audience Targeting, Sicherheit und Datenschutz, Architektur und Vision.

Die „Cloud-native Architektur von Flagship bietet ein ausgewogenes Verhältnis zwischen Feature-Management und A/B-Testing-Funktionen, was App-EntwicklerInnen und Produktverantwortlichen gleichermaßen zugutekommt. Außerdem verfügt es über eine robuste Sicherheit mit unabhängig verifizierten Sicherheitstests und Zertifizierungen“, heißt es in dem Bericht.

Flagship “verfügt über eine reaktionsschnelle Cloud-native Architektur, die es Teams ermöglicht, schnell mit dem Feature-Management zu beginnen.”

The Forrester New Wave: Feature Management And Experimentation, Q2 2021

KundInnen vertrauen uns beim Feature Management

Flagship wurde speziell für Produkt- und Entwicklerteams in Großunternehmen entwickelt und stattet sie mit den richtigen Tools aus, um die Bereitstellung validierter Ideen durch einfache Implementierung zu beschleunigen, z. B. durch KPI-gesteuerte Rollbacks oder die Entkopplung von Code- und Feature-Releases. Unsere Feature-Flagging-Plattform stellt sicher, dass Teams die volle Kontrolle darüber haben, wie Features veröffentlicht werden und welche Auswirkungen sie auf die Endbenutzererfahrung sowie auf die Geschäfts-KPIs haben.

Flagship ist geschaffen für moderne Engineering- und Produkt-Teams.
Möchten Sie mit Sicherheit liefern?

Jetzt anschauen

The post AB Tasty’s Flagship reitet auf der Spitze der neuen Forrester Wave™ appeared first on abtasty.

Nein, ein Produktmanager und ein Product Owner haben nicht dieselbe Rolle. Sie verfolgen zwar ein gemeinsames Ziel – Produkte, die Usern lieben und nutzen – haben jedoch nicht denselben Verantwortungsbereich.

In der Regel sind Produktmanager für das Warum verantwortlich. Sie erstellen die Produkt-Roadmap auf Grundlage der Bedürfnisse und Wünsche der User. Sie konzentrieren sich auf Geschäftskennzahlen und darauf, ob sich ein Produkt in die richtige Richtung entwickelt.

Product Owner ihrerseits sind für die Erstellung und Abwicklung des Product Backlogs verantwortlich. Sie sind im operativen Prozess involviert und an eine Deadline gebunden. Für sie dreht sich alles um Scrum, das Hin und Her mit den Entwicklern und darum, anstehende Aufgaben zu erledigen.

Doch oft lässt sich keine klare Trennlinie zwischen den beiden ziehen. Je nachdem, wo Sie arbeiten, sind Sie möglicherweise an unterschiedliche Situationen gewöhnt. Um die Unterschiede und die Ähnlichkeiten zwischen diesen beiden Jobs besser zu verstehen, haben wir unseren firmeninternen Produktmanager Yoann Grange gebeten, Klarheit zu schaffen.

Sie haben nur wenig Zeit? Klicken Sie direkt auf den Abschnitt, der Sie interessiert.

[toc]

Welche Verantwortlichkeiten hat der Product Manager? Welche der Product Owner?

Diese Frage beschäftigt mich schon seit über fünf Jahren. Und das so sehr, dass ich bereits 2016 25 Video-Interviews [auf Französisch] mit Product Ownern, Produktmanagern, Heads of Product usw. geführt habe.

Meine Antwort lautet kurz und knapp: Kommt drauf an.

Sie denken jetzt bestimmt „Na klar! Gilt das nicht für alles?“

Aber hier, in diesem Fall, hängt dies tatsächlich von vielen verschiedenen Faktoren ab. Einige werden in diesem Artikel näher behandelt.

Product Manager vs Product Owner: Was wann in Betracht ziehen sollte

Wir dürfen nicht aus den Augen verlieren, dass es Produkte unterschiedlichster Art gibt: Industrieprodukte, landwirtschaftliche Produkte, Dienstleistungen, Chemikalien, Modeprodukte … und Softwareprodukte.

Im SaaS MarTech Bereich herrscht die Meinung vor, dass alle Produkte gleich aufgebaut sind und alle Unternehmen die gleiche Struktur aufweisen. Die Branche tendiert zur Annahme, dass hinter jedem Feature ein Produktmanager und ein Product Owner steckt.

Die Wirklichkeit sieht aber anders aus: Manchmal ist es der eine oder der andere, manchmal beide oder sogar keiner von beiden. Welche Faktoren bestimmen diese Struktur? Sehen wir uns ein paar davon näher an.

1. Dynamik

Das wichtigste Kriterium ist „die Dynamik des Unternehmens“. Was verstehe ich unter diesem Begriff?

Wie neu/alt ist das Unternehmen?

Diese Frage ist wichtig. Sie steht nicht in direktem Zusammenhang mit der Größe des Unternehmens. Sie bezieht sich auch nicht auf die Anzahl der Kunden. Ich kenne zum Beispiel ein Unternehmen mit neun Personen und über 200.000 zahlenden Kunden. Die Firma ist mittlerweile „schon“ sechs Jahre alt und die Produkt-Funktion wird hier mehr oder weniger von allen wahrgenommen.

Wie weit ist das Unternehmen von einem bestimmten „Schlüsselmoment“ entfernt?

Unter „Schlüsselmoment“ verstehe ich Schlüsselphasen oder Ereignisse im Lebenszyklus eines Unternehmens. Zum Beispiel:

• Gründung des Unternehmens
• Verkauf des Unternehmens
• neue Finanzierung
• Steuerprüfung
• Release eines Mitbewerbers
• Krise
• Neuer CEO
• … Sie wissen, wovon ich spreche.

Diese verschiedenen Schlüsseletappen wirken sich auf die Praxis der Produktentwicklung aus.

Sie bestimmen deshalb, was ein Produktmanager und was ein Product Owner macht.

Kurz nach der Gründung eines Unternehmens ist der CEO wahrscheinlich am besten geeignet, die Produktrollen zu betreuen. Häufig ist der CEO (zumindest in skalierbaren SaaS Unternehmen) derjenige, der die Funktion von PO, PM, QA und Support inne hält, was weder eine bewusste Entscheidung noch eine Strategie ist, sondern einfach nur das, was im entsprechenden Moment notwendig ist.

Wie man mit der Dynamik eines Unternehmens umgeht, bestimmt in der Regel außerdem wie „gut“ sich das Unternehmen macht.

Wurde der gegenwärtige Moment antizipiert oder ist er nur das Ergebnis der Reaktion auf den vorhergehenden Moment? Sie können davon ausgehen, dass ein Unternehmen umso „agiler“ ist, je öfter es reagiert. Je mehr Momente antizipiert werden, desto „visionärer“ das Unternehmen. Gleichzeitig agil und visionär zu sein, ist eine große Herausforderung.

2. Die Größe zählt

Mit Größe meine ich nicht nur die Anzahl der Mitarbeiter. Die Größe eines Unternehmens bezieht sich auch auf die Anzahl der:

• Produkte
• Modelle
• Features
• Scopes
• Preistabellen
• oder Märkte, die das Unternehmen anspricht.

Produkte auf die richtigen „Dimensionen“ zurechtzuschneiden und zu entscheiden, ob sie nach Markt, Produktlinie oder Thema aufgeteilt werden sollen, kann eine Lebensaufgabe sein: Die Dinge ändern sich ständig und je schneller sich ein Unternehmen entwickelt, desto öfter sind Änderungen nötig.

Die Größe kann auch durch die Anzahl der User, Kunden, Partner, Händler, Sprachen, Einheitensysteme usw. definiert werden. Noch häufiger aber ergibt sich aus einer Kombination all dieser Faktoren, wie viele PMs, POs und Heads of Product Ihr Unternehmen benötigt.

In vielen NGOs zum Beispiel hängt die Anzahl der Produktmanager von den Spender-Personas ab. Es gibt einen PM für kleine Spendenbeträge (z. B. 10 $ bis 500 $), einen für größere Beträge (500 $ bis 10 000 $) und einen weiteren für noch höhere Beträge. Warum? Weil sich die Erwartungen der verschiedenen Typen von Personas stark unterscheiden. Die Fähigkeit, auf jede Persona einzugehen, trägt langfristig zum Wachstum gemeinnütziger Unternehmen bei.

Kurz gesagt, die Größe eines Unternehmens (sein Kundenportfolio, sein Produktkatalog usw.) kann darüber entscheiden, was der PM macht, was der PO macht und wie viele PMs und POs eingesetzt werden.

3. Weitere Kriterien

Wie viele PMs, POs oder andere Mitarbeiter im Produktbereich benötigt werden, hängt nicht nur von den genannten Faktoren ab. Es können noch zahlreiche andere Faktoren einfließen, z. B.:

• Anzahl der Entwickler
• Anzahl der Designer
• Versandgeschwindigkeit
• technische Stacks
• Tools
• Produktlebenszyklus
• individuelle Wünsche
• Wachstumspotenzial
• abgedeckter Anteil des existierenden Bedarfs
• Legacy-Anteil
• Personalpolitik
• der Markt, den Sie ansprechen
• Schließlich kommt es auch noch darauf an, welche Politik das Unternehmen verfolgt.

Im Großen und Ganzen ist man sich (zumindest in SaaS Unternehmen) darüber einig, dass sich die Trennlinie zwischen PM und PO folgendermaßen ziehen lässt: Vision vs. operative Prozesse, Planung vs. Dringlichkeit, Nutzen vs. Kennzahlen. Doch beide gehören zusammen.

Obwohl sich die beiden Rollen voneinander abgrenzen, sind sie letztlich nicht voneinander zu trennen.

Kein Unternehmen gleicht dem anderen. Deshalb gibt es keine Standardantwort auf die Frage, was ein PM im Vergleich macht. Sie müssen Ihren eigenen Weg finden. Manche Unternehmen werden viele PMs und POs brauchen, manche überhaupt keine. Es ist schon schwierig genug, dafür zu sorgen, dass Menschen erfolgreich zusammenarbeiten. Einfach eine Methode zu kopieren, hilft nicht. Sie müssen Ihr eigenes Konzept finden.

Sollte ich die Frage dennoch beantworten müssen, würde ich sagen, dass PMs eher das letzte Wort bei der Priorisierung haben und für Unternehmenskennzahlen verantwortlich sind. POs hingegen sind für die Einhaltung der Termine des Teams verantwortlich. Doch auch diese Antwort ist immer noch zu simpel.

Kann eine Person sowohl die Rolle des Produktmanagers als auch die Rolle des Product Owners übernehmen?

Ja. Absolut. Das bedeutet nicht, dass es so sein muss, aber dass es definitiv möglich ist.

Tatsächlich ist das bei relativ vielen Startups in ihrer Anfangsphase der Fall. Meistens treten mindestens zwei Personen auf den Plan: eine der beiden ist technikorientiert, die andere eher geschäftsorientiert. Oft übernimmt die geschäftsorientierte Person die Produktfunktion. Sie kann aber auch von beiden oder von der technikorientierten Person übernommen werden.

Wie gesagt sind Vision vs. operative Prozesse, Planung vs. Dringlichkeit, Nutzen vs. Kennzahlen die zwei Seiten von drei verschiedenen Dingen, die die Product-Person bei jeder Entscheidung berücksichtigen muss.

Die Konfiguration aus einem PM mit mehreren POs ist häufiger anzutreffen als ein PO mit mehreren PMs. Aber im Endeffekt, warum nicht? Alles hängt von den oben genannten Kriterien ab.

Besteht Deiner Erfahrung nach ein Gehaltsunterschied zwischen Product Owner und Produktmanager?

Ja. Produktmanager verdienen eher mehr als Product Owner. Auch hier liegt der Grund darin, dass es für beide Rollen eine gewisse Standardauslegung gibt und die Rolle des Product Owners als weniger anspruchsvoll betrachtet wird. Dabei handelt es sich einfach nur um zwei verschiedene Rollen. Pure kognitive Verzerrung.

Der Report Stand der Produktführerschaft 2020 von Pendo zeigt überraschenderweise eine negative Korrelation zwischen „Glücksgefühl“ und Gehalt der befragten Produktmanager auf. Es dreht sich also nicht alles nur ums Geld.

Welche Fähigkeiten muss ein guter Produktmanager und/oder Product Owner mitbringen?

Das ist meine Lieblingsfrage, auf die jeder eine andere Antwort hat. Doch sind sich mehr oder weniger alle einig, dass der Rahmen relativ weit gefasst ist.

Mir sträuben sich die Haare, wenn ein Stellenangebot in etwa so beginnt: „Fachhochschule oder Master-Abschluss in Informatik …“ Für Produktler braucht es mehr als nur technische Kompetenz. Je geradliniger die Menschen denken, die an Ihrem Produkt arbeiten, desto geradliniger ist auch Ihr Produkt. Und desto schneller wird es angenommen.

Zoom und Fokus

Ich würde sagen, dass ein PM/PO in erster Linie fähig sein muss, verschiedene Perspektiven einzunehmen, um ein Problem sowohl aus der Mikro- als auch aus der Makroperspektive zu erfassen.

Manchmal müssen Sie ins kleinste Detail gehen. In anderen Fällen müssen Sie das Gesamtproblem verstehen, das durch das Produkt oder Feature gelöst werden soll. Jederzeit die Perspektive zu ändern, ist der Schlüssel zum Erfolg. Die Makroperspektive hilft Ihnen, die Konkurrenz und den Markt zu verstehen, die Mikroperspektive ermöglicht es, die Details einer Komponente zu verstehen. Sie müssen sich jederzeit vor Augen halten, warum Sie was tun.

Semantik und Semiologie

Mein Fremdsprachen-Hintergrund hat mir gleich zu Beginn geholfen, als Schnittstelle zwischen Entwicklern und Usern/Kunden zu agieren. Ich komme auch heute noch ziemlich oft darauf zurück, um zu entscheiden, was wichtig ist und was nicht. Dieser Hintergrund hilft, sich bei einem User Test auf eine bestimmte Anmerkung zu konzentrieren und bei einem zehnminütigen Video zu erfassen, was wichtig ist. Außerdem versteht man dadurch besser, warum ein Symbol problematisch ist und weshalb die Kombination eines bestimmten Labels mit einem bestimmten Symbol nicht funktioniert, warum beide notwendig sind, warum es besser wäre, überhaupt darauf zu verzichten (allerdings nur für einige User) …

Ob technisch oder funktional, schriftlich oder mündlich, optisch oder akustisch: Bei Sprachen geht es in erster Linie darum, den Sinn zu vermitteln. Von Team zu Team, vom User zur Maschine, von der Spezifikation zum fertigen reellen Feature: Alles dreht sich darum, einander zu verstehen. Obwohl diese Evolution seit so vielen Jahren in Gang ist, sind wir auf diesem Gebiet nicht viel besser geworden.

Das Design zählt ebenfalls dazu. Wer Wireframes und Mockups erstellen kann, hat schon viel gewonnen. Selbst wenn sie nicht in Ihren Aufgabenbereich fallen, können diese Visualisierungsformen einen Prozess beschleunigen oder den Weg für andere Lösungen ebnen.

Wichtig ist auch, was jeder Einzelne unter „Kommunikation“ versteht, denn Sie haben es mit Usern, Dritten, Stakeholdern aller Art, manchmal auch mit den Medien usw. zu tun. Deshalb ist es von Vorteil, wenn Sie eine Präsentation, ein Webinar oder eine Schulung abhalten.

Zu guter Letzt sollten Sie gerne Geschichten schreiben und erzählen. Die meisten Menschen lieben es, Geschichten zu hören, aber nicht jeder schreibt sie auch gerne.

Iteration und Lernprozess

Weitere wichtige Fähigkeiten schließen alles ein, was unter „testen -> messen -> verbessern“ fällt.

„Testen“ heißt zweifeln. Wer sich seiner Sache allzu sicher ist, riskiert zu scheitern. Die Fähigkeit, eine Hypothese aufzustellen ist ebenfalls wichtig. Nehmen Sie nie etwas als Selbstverständlich hin.

Und in puncto Messung kann die Erfahrung mit einem wissenschaftlichen Ansatz hilfreich sein, ebenso wie die Fähigkeit, die Dinge klar zu erkennen und die Performance zu messen. Das schließt analytische (quantitative) Kenntnisse oder verhaltensanalytische (qualitative) Skills ein.

Philosophisch gesehen muss ein erfolgreicher Produktmanager oder Product Owner schon im Vorfeld des Versuchs ein Scheitern in Kauf nehmen. Und er muss akzeptieren, dass er irgendwann mit den Verbesserungen Schluss machen muss, wenn sich der Erfolg einstellt. Eine hundertprozentige Perfektion ist einfach nicht möglich.

Mit welchen KPIs lässt sich der Erfolg von Product Ownern und Product Managern messen?

Ich versuche, nicht mehr jede Frage mit „Kommt ganz darauf an“ zu beantworten. Aber … es kommt wirklich ganz darauf an. Meiner Meinung nach sollten die KPIs von Produktmanagern auf Unternehmenskennzahlen basieren: Wachstum, Umsatz, Abwanderung, Kosten … Für Product Owner zählen Lieferung, Qualität, Teamzufriedenheit.

Welche Kurse kann man belegen, um ein (besserer) Produktmanager zu werden?

Wie gesagt, das erforderliche/minimale Skillset ist extrem breit gestreut. Die gute Nachricht? Etwas Neues zu lernen macht Sie zu einem besseren Menschen und damit auch zu einem besseren Product Mitarbeiter.

Sehen Sie sich selbst zunächst als Person. Wenn Sie sich als Produkt positionieren, neigen Sie dazu, sich auf fehlende oder falsche Dinge zu konzentrieren. Wenn Sie sich als Person sehen und einen ganzheitlichen Blickwinkel einnehmen, ist jede neue Fähigkeit von Interesse.

Wir fungieren auch als Bindeglied zwischen Usern und technischen Teams, um das Beste aus minimalen (oder fortgeschrittene) technischen Kenntnissen herauszuholen, damit Sie die technischen Teams und ihre komplexen Aufgabenstellungen verstehen können.

In den letzten 15 Jahren habe ich für 17 Unternehmen gearbeitet und empfehle deshalb jedem, das Unternehmen oft zu wechseln. Sie wechseln dabei auch noch die Branche? Umso besser!

Welche Lektüre würdest du empfehlen?

Die meisten PM, PO, VP, Heads of Product legen Ihnen eine lange Liste von Bestsellern zum Thema Produktmanagement nahe. In der Regel geht es dabei um Titel wie „Lean UX“, „Lean Startup“, „Wie werde ich ein erfolgreicher Produktmanager“ usw. Ich versuche mich mit einer etwas anderen Liste.

Ich empfehle eher Klassiker, weil sie sich auf die Grundlagen konzentrieren. Selbst bei Klassikern besteht nur eine geringe Chance, dass andere Produktmanager oder Product Owner sie gelesen haben. Die Welt dreht sich immer schneller, doch die Grundlagen ändern sich nicht.

Im Product arbeiten wir für die Menschen. Unser Job ist es, die Menschen zu verstehen, damit wir ihnen helfen können. Wir versuchen, echten Problemen der Menschen mit möglichst risikoarmen Lösungen zu begegnen. Wir sind weit davon entfernt, die Komplexität der Menschheit in ihrem vollen Ausmaß zu verstehen. Einige Menschen stechen jedoch aus der Masse heraus und haben uns Meisterwerke geschenkt:

• Das Reich der Zeichen – Roland Barthes
• Wie man Freunde gewinnt. Die Kunst, beliebt und einflussreich zu werden – Dale Carnegie
• Vorlesungen zur Einführung in die Psychoanalyse – Sigmund Freud
• Strukturale Anthropologie – Claude Lévi-Strauss
• Die Kunst des Krieges – Sun Tzu

NB: Lesen ist gut. Experimentieren ist besser.

The post Product Manager vs. Product Owner: Wo liegt der Unterschied? appeared first on abtasty.