Veröffentlicht am 17. März 2020

Skalieren von Experimentieren: Wie man qualitativ hochwertige Experimente entwickelt, startet und QA durchführt

Ich bin Becca Bruggman, Optimizelys Experimentation Manager. Meine Aufgabe ist es, dafür zu sorgen, dass wir "unseren eigenen Champagner trinken" und ein erstklassiges Programm zum Experimentieren durchführen.

Becca Bruggman
von Becca Bruggman
decorative yellow lines on background

Dies ist der zweite Teil einer sechsteiligen Serie, die Ihnen helfen soll, ein erstklassiges Programm zum Experimentieren durchzuführen. In dieser Serie gehen wir auf alles ein, was Sie brauchen, um Ihr Programm zu erstellen, zu entwickeln und es effizient laufen zu lassen sowie es sichtbar zu machen. Die vorherigen Beiträge finden Sie hier und hier.

Wenn Sie meinen letzten Beitraggelesen haben , sollten Sie Ihre wichtigsten Stakeholder kennen, einen Plan für die Programmstruktur haben, die Ihr Team nutzen wird, und einen ersten Zielbaum haben. Lassen Sie uns nun untersuchen, wie das Team, das Sie zusammengestellt haben, qualitativ hochwertige Experimente in großem Maßstab durchführen kann. Das große Geheimnis: Dokumentation und Abstimmung!

Als wir bei Optimizely an der Formalisierung unserer Prozesse und unseres Programms arbeiteten, wurde uns schnell klar, wie wichtig eine umfassende Dokumentation ist, die von allen wichtigen Beteiligten geprüft und auf die sie sich geeinigt haben, um Experimente zu starten. Nicht jeder liebt Prozesse, aber ein guter Prozess kann Teams in einigen wichtigen Punkten entlasten:

  • Sie können mit ihren Experimenten etwas bewirken und kreativ sein, anstatt jedes Mal herausfinden zu müssen, welche Schritte notwendig sind, um ein Experiment sicher und erfolgreich zu starten.
  • Es ist hilfreich, den Prozess des Experimentierens für das Onboarding dokumentiert zu haben, um im Grunde genommen selbst zu skalieren und den Bedarf an 1:1-Sitzungen mit dem Team zu minimieren. (Und als Mensch skaliere ich nicht).
  • Und wenn jemand Änderungen am Prozess vornehmen möchte, gibt es eine zentrale Anlaufstelle, an der diese Änderungen diskutiert und vorgenommen werden können.

Im Folgenden gehe ich auf die Kerndokumentation ein, mit der wir das Experimentieren vereinfachen. Ich zeige Ihnen Screenshots davon, wie diese bei Optimizely aussehen, und Sie finden Vorlagen für alle diese Dokumente in meinem Experimentierprogramm-Toolkit.

Erstens - eine durchgängige Dokumentation zur Durchführung eines web-/client-seitigen Experiments! Vorlage[hier]

graphical user interface, text, application, email

text

Teil der Dokumentation von Optimizely für die Durchführung eines Web-Experiments

Dazu gehören Dinge wie:

  • Wo man eine Idee für ein Experiment protokolliert
  • Wo Sie das Experiment selbst erstellen können
  • Welche Komponenten am besten zu verwenden sind
  • Wie Sie eine Codeüberprüfung und SLAs erhalten
  • Schritte zur QA
  • Checkliste vor der Markteinführung
  • An wen man sich wenden kann, wenn man nicht weiterkommt

Am Anfang kann sich dies etwas überwältigend anfühlen, aber sobald das Team es ein- oder zweimal durchgegangen ist, wird vieles davon zur zweiten Natur. Und wenn sich herausstellt, dass ein Prozess aktualisiert oder entfernt werden muss, ist es einfacher, wenn Sie eine einzige Quelle der Wahrheit haben.

Die Nutzung des Zielbaums, den Sie in meinem letzten Beitrag erstellt haben, und die Einrichtung und Qualitätssicherung all Ihrer Schlüsselereignisse kann ebenfalls dazu beitragen, die Erstellung von Experimenten und die Qualitätssicherung in Zukunft zu optimieren. Sobald diese Ereignisse erstellt sind, hilft eine entsprechende Dokumentation, in der alle Ihre Hauptereignisse (für uns sind das Ereignisse wie Lead Form Submits) aufgeführt sind, dabei, eine einzige Quelle der Wahrheit zu haben. So erhalten Sie einen vollständigen Überblick darüber, welches Nutzerverhalten diese Ereignisse verfolgen und wo auf Ihrer Site sie stattfinden.

Ich empfehle, für diese Kernereignisse eine einheitliche Namenskonvention zu verwenden, damit sie leicht auffindbar sind und leicht zu verstehen ist, worauf sie in Ihrem Programm zum Experimentieren abzielen. Wir verwenden die Namenskonvention "[MASTER]", um Ereignisse zu kennzeichnen, die vom Kernteam entwickelt und geprüft wurden, so dass sie von allen vertrauensvoll genutzt werden können.

graphical user interface, application

Optimizely verwendet "MASTER" zur Kennzeichnung von Kernereignissen

Als Nächstes folgt eine durchgängige Dokumentation zur Durchführung eines Full Stack Experiments! Es wird wahrscheinlich einige Überschneidungen zwischen dem Web- und dem Full Stack-Dokument geben, insbesondere bei der Checkliste vor dem Start und bei der Frage, an wen Sie sich wenden können, wenn Sie nicht weiterkommen. Aber angesichts der Unterschiede in der Codebasis, dem QS-Prozess und den Genehmigungen ist es in der Regel hilfreich, diese Punkte getrennt zu behandeln. Vorlage[hier]

Dazu gehören Dinge wie:

  • Wo Sie eine Idee für ein Experiment protokollieren
  • Wo Sie das Experiment selbst aufbauen können (d.h. welche Codebasen zu welchem Produkt passen, welche Optimizely-Projekte zu verschiedenen Teilen der Codebasis passen)
  • Links zur Dokumentation über die SDK-Konfiguration und das Eventing
  • Wie Sie eine Codeüberprüfung und SLAs erhalten
  • Schritte zur QA
  • Checkliste vor der Markteinführung
  • An wen Sie sich wenden können, wenn Sie nicht weiterkommen

Für jeden dieser Punkte ist es hilfreich, die Zustimmung Ihrer wichtigsten Programmstakeholder, der Endnutzer des Prozesses und aller Personen einzuholen, die von dem Prozess betroffen sind, wie z. B. Code-Reviewer. Diese Dokumente werden sich ständig weiterentwickeln. Ich empfehle, sie vierteljährlich zu überprüfen, um sicherzustellen, dass sie aus Sicht des Prozesses und der Stakeholder noch relevant sind. Für Optimizely war es hilfreich, sicherzustellen, dass die Systeme, mit denen wir begonnen haben, auch dann noch Sinn machen, wenn unser Programm an Reife gewinnt und das Experimentieren weiter wächst.

Dank des Software-Ingenieurs Derek Hammond verfügen wir nun auch über eine Dokumentation, wie wir neue Komponenten/Einheiten (Seiten, Zielgruppen, Metriken usw.) in unserer Optimizely Web-Instanz erstellen können. Vorlage[hier]

graphical user interface, text, application, email

Optimizelys Dokumentation über neue Web-Entitäten

Dieses Dokument haben wir etwa ein Jahr nach Beginn unseres Programms erstellt. Ich wünschte, wir hätten es schon früher erstellt, da ich nach etwa einem Jahr unseres Programms feststellte, dass unser Webprojekt mit doppelten oder nur einmal verwendeten Seiten, Zielgruppen und Metriken überfüllt war. Daher musste ich mir mehrere Tage Zeit nehmen, um unsere Instanz zu bereinigen und sie auf das zu reduzieren, was aktiv genutzt wurde und nützlich war. Sie können mich dabei im Januar 2019 sehen:

a person standing next to a table with a computer and a large screen

Ich mitten im Aufräumen des Webprojekts im letzten Jahr

graphical user interface, text, application, email

Wie ich dem Team mitteile, dass ich aufgeräumt habe!

Lernen Sie aus meinen Fehlern! Ich empfehle Ihnen, dieses Dokument von Anfang an einzurichten und einen regelmäßigen Rhythmus für die Archivierung alter Komponenten in Ihrem Webprojekt festzulegen. Dadurch wird der Prozess für andere, die Experimente erstellen möchten, viel einfacher, da sie sich nicht durch die Projektkomponenten wühlen müssen, um das zu finden, was sie für ein Experiment benötigen.

Aus Sicht der Governance ist die Slack-Integration, die Optimizely mit Slack verbindet, sehr hilfreich, um zu sehen, welche Experimente in Ihrem gesamten Konto erstellt und gestartet werden. Dies kann hilfreich sein, um in Echtzeit zu sehen, ob etwas außerhalb des vereinbarten Prozesses erstellt oder gestartet wird, und bei Bedarf den Kurs zu korrigieren. Bei Optimizely haben wir einen Kanal namens #experiment-feed, in den all diese Benachrichtigungen direkt einfließen:

table

#experiment-feed Slack-Kanal bei Optimizely

Ein wichtiger Hinweis zum Schluss: Sie sollten davon ausgehen, dass all dies mit Ihrem Programm wachsen und sich weiterentwickeln wird, insbesondere Ihr End-to-End-Prozess. Außerdem sollten Sie immer daran denken, "Crawl/Walk/Run" so zu gestalten, dass es zu Ihrem Unternehmen passt. Auch wenn es anfangs wichtig ist, diesen Prozess zu dokumentieren, wird es wahrscheinlich einige Zeit dauern, bis sich das Team daran gewöhnt hat, ihn konsequent zu nutzen, und er wird auch auf der Grundlage des Feedbacks des Teams und der sich ändernden Anforderungen Ihres Programms aktualisiert werden müssen. Stellen Sie sich also darauf ein und seien Sie bereit, sich anzupassen!

Sie können alle oben genannten Vorlagen[hier] finden.

Welche Verfahren verwendet Ihr Team derzeit zum Experimentieren? Was habe ich übersehen? Kommentieren Sie unten oder tweeten Sie mir @bexcitement.

Wir sehen uns im nächsten Beitrag über die Ideenfindung für Experimente und die Erstellung Ihrer Roadmap!