a man sitting at a table with a laptop and a sign

"Wird das neue Design bei den Kunden ankommen?

"...Wird die Erfahrung verbessert oder nicht?.."

"...Wie wird sich das auf die Konversionen auswirken?.."

"...Was, wenn es nicht funktioniert?.."

"...Das Management hat es mit einigen Hippo-Anforderungen genehmigt, mit denen ich nicht einverstanden war - wie werden sich deren Änderungen auf den Erfolg der Veröffentlichung auswirken?.."

Und so weiter, und so weiter...

Mindestens einmal pro Woche werde ich von einer anderen Produktfreigabe überrascht, die Millionen von Dollar an Umsätzen riskiert, sich bei der Entwicklung auf das Bauchgefühl (und nicht auf rationale Daten) verlässt und bei der kein Feature-Management für einen schnellen Wechsel bei Problemen integriert ist.

Ich sehe auch viele Veröffentlichungen, bei denen keine Experimente zum Testen der neuen Funktionen genutzt werden. Kein Wunder, dass Produkteinführungen emotional sind.

Aber das muss nicht so sein, und Sie müssen auch nicht "das Meer zum Kochen bringen", um den Prozess zu verbessern.

Hier sind meine besten Tipps, um schlaflose Nächte bei Ihrer nächsten Veröffentlichung zu vermeiden:


Erstens: Qualifizieren Sie die Art der Freigabe:

  • Wie wahrscheinlich ist es, dass die von Ihnen vorgeschlageneÄnderung negative Auswirkungen auf Ihre Benutzer oder Kunden haben wird? Wenn das Risiko hoch ist, sollten Sie vielleicht zunächst einen A/B-Test durchführen, um die möglichen Auswirkungen zu minimieren.
  • Die Komplexität der Änderung: Wie schwierig ist es, die vorgeschlagene Änderung umzusetzen? Wenn die Änderung komplex ist, sollten Sie zunächst eine Betaversion in Erwägung ziehen, um Feedback von einer kleinen Gruppe von Benutzern zu erhalten, bevor Sie die Änderung für alle einführen.
  • Die Dringlichkeit der Änderung. Wie wichtig ist es, die Änderung schnell durchzuführen? Wenn die Änderung dringend ist, sollten Sie den A/B-Test oder die Betaversion überspringen und die Änderung sofort für alle Benutzer einführen, wobei die Funktionsverwaltung eingebettet ist, um ein einfaches Rollback ohne Code zu ermöglichen.

Wählen Sie dann einen A/B-Test oder eine Betaversion:

  • Führen Sie einen A/B-Test durch, wenn:
    • Sie unsicher sind, wie die Benutzer auf die Änderung reagieren werden.
    • Die Änderung ist komplex und könnte unbeabsichtigte Folgen haben.
    • Sie eine Änderung an einer Kernfunktion Ihres Produkts oder Ihrer Dienstleistung vornehmen.
  • Führen Sie eine Betaversion durch, wenn:
    • Sie eine größere Änderung an Ihrem Produkt oder Ihrer Dienstleistung vornehmen.
    • Die Änderung ist neu und ungetestet.
    • Sie brauchen das Feedback der Benutzer, bevor Sie die Änderung für alle einführen.

Und schließlich: Sollten Sie in Erwägung ziehen, das Release in ein Feature Flag einzubauen?

Feature-Flags helfen Ihnen, das Risiko zu mindern, indem sie die Freigabe in Phasen steuern - dies könnte der beste Weg sein, um eine Beta-Phase zu starten, oder Sie könnten die Freigabe für eine bestimmte Zielgruppe oder ein bestimmtes geografisches Segment vornehmen wollen. Wenn es ein größeres Problem, einen Fehler oder einen Rückschlag gibt, können Sie einfach den Schalter umlegen und sofort zum vorherigen Zustand zurückkehren.

Alles, worüber wir hier gesprochen haben - A/B-Tests, Beta-Release und Feature Flagging - ist mit unserem kostenlosen Feature Flagging Tool möglich. Außerdem erhalten Sie alle Unterstützung, die Sie brauchen, von unseren Entwicklerressourcen und unserer Slack-Community.

#BBD0E0 "