Veröffentlicht am 17. Januar 2018

Um schneller voranzukommen, experimentieren Sie mehr

Wenn Sie schon einmal eine Frist für ein Softwareprojekt vorhersagen mussten, werden Sie mit Hofstadters Gesetz nur allzu vertraut sein

Jon Noronha
von Jon Noronha
decorative yellow lines on background

Es dauert immer länger, als Sie erwarten, selbst wenn Sie das Hofstadtersche Gesetz berücksichtigen.

Es ist also keine Überraschung, dass jedes Produktentwicklungsteam "agiler" werden möchte. Für den naiven CTO ist "agil" nur ein Synonym für "schnell". Es ist ein magisches Schlüsselwort, das die Tretmühle beschleunigt und einem Team sagt, dass es schneller laufen, schneller starten und mit weniger mehr erreichen soll. Und wenn das alles ist, was Agilität in Ihrem Unternehmen bedeutet, dann werden Sie enttäuscht sein, wenn Sie auf eine Mauer aus verfehlten Erwartungen, ausgebrannten Mitarbeitern und stagnierenden Kennzahlen treffen.

Denn richtige Agilität ist nicht dasselbe wie Geschwindigkeit. Sie ist die Voraussetzung für Geschwindigkeit, nicht das Endergebnis. Agilität ist das Vertrauen, das Sie brauchen, um schnell zu handeln. Die meisten Entwicklungsteams sind nicht langsam, weil sie faul sind, weil die Arbeit zu schwer ist oder weil sie unterbesetzt sind. Sie sind langsam, weil sie Angst haben -und das meist aus gutem Grund.

Die Angst, von der ich hier spreche, ist die Angst vor dem Scheitern. Wenn Ihr Produkt einen gewissen Grad an Akzeptanz erreicht hat, dann kann so viel schief gehen. Wie ein Kartenhaus braucht eine Anwendung Jahre, um aufgebaut zu werden, und eine Sekunde, um sie umzustoßen. Es gibt eine Million Möglichkeiten, Ihre Site kaputt zu machen, Ihre Metriken zu verschlechtern und Ihre Benutzer zu verärgern, und nur sehr wenige Möglichkeiten, um sicher zu gehen, dass Sie diese Art von Fehler nicht machen. Je mehr unser Produkt also wächst, desto mehr Angst haben wir. Und ironischerweise ist diese Angst vor dem Scheitern am Ende genau das, was den Erfolg verhindert. Wir haben Angst, den falschen Weg einzuschlagen, also gehen wir langsam und vorsichtig vor. Wir werden nervös, wenn wir mutige Entscheidungen treffen, also warten wir auf einen Konsens. Und wir beginnen, Veränderungen zu fürchten, also klammern wir uns an den Status Quo.

Diese Angst hat etwas sehr Ursprüngliches an sich. Es ist, als ob wir Angst vor der Dunkelheit hätten. Erinnern Sie sich an das letzte Mal, als Sie die Toilette bei ausgeschaltetem Licht finden mussten oder ohne Taschenlampe nach draußen gegangen sind.

Wenn wir versuchen, uns im Dunkeln zu bewegen, gehen wir zögerlich. Wir halten die Hände vor uns und schlurfen langsam, aus Angst, über unsichtbare Hindernisse zu stolpern oder gegen schmerzhafte Barrieren zu stoßen. Wir machen vorsichtige Schritte und tasten uns nach Hinweisen ab, in der Hoffnung, dass wir uns nicht verirren. Wir klammern uns an die Gruppe und folgen den lautesten Stimmen, weil wir keinen klaren Weg sehen. Und egal, wie sehr wir uns bemühen, zusammenzubleiben, wir driften unweigerlich in verschiedene Richtungen ab.

Stellen Sie sich nun Ihren Chef vor, der vor all seinen Mitarbeitern steht, die im Dunkeln umherstolpern, und ruft: "SCHNELLER! WARUM RENNEN SIE NICHT?" Das kann alles nur noch schlimmer machen. Sie werden sich schneller treiben lassen, schneller zusammenstoßen, schneller stolpern und schneller fallen - aber sie werden nichts schneller erreichen, weil sie den Weg oder das Ziel nicht sehen können. Wenn sich die Softwareentwicklung in Ihrem Unternehmen so anfühlt, liegt das Problem nicht bei Ihren Mitarbeitern, sondern bei den Werkzeugen, mit denen sie versuchen, sich im Dunkeln zu bewegen. Langsamkeit ist ein Produkt der Angst, und Angst ist ein Produkt der Unsicherheit.

Stellen Sie sich nun eine Taschenlampe vor. Was wäre, wenn jeder Mitarbeiter einen Schalter umlegen könnte und plötzlich alles sehen könnte - wo er ist, wohin er geht und wie der Weg von hier nach dort aussieht. Dann bräuchten sie plötzlich nicht mehr zu schlurfen und zu stolpern. Sie könnten anfangen zu laufen, in der Gewissheit, dass jeder Schritt sie ihrem Ziel näher bringen würde.

Das ist die Lektion, die wir in der agilen Entwicklung immer wieder sehen. Wenn Ingenieure über automatisierte Tests verfügen, können sie alles überarbeiten, ohne sich Gedanken darüber zu machen, was kaputt gehen könnte. Wenn Teams Frameworks wie Scrum einsetzen, können sie ihren Ansatz in der Mitte eines Projekts ändern, um sich an die Kundenanforderungen anzupassen. Wenn die Markteinführung hinter Feature Flags geschützt ist, kann jeder eine kühne neue Idee einführen, in der Gewissheit, dass sie beim ersten Anzeichen von Problemen wieder zurückgenommen werden kann.

Jede dieser Praktiken deutet auf das Wesentliche der agilen Produktentwicklung hin: eine Kultur des Experimentierens. Diese Art von Kultur gibt Ihrem Team das Selbstvertrauen, kühne Änderungen vorzunehmen, indem es seine Ideen ständig mit Daten validiert. Experimentieren ist der Schlüssel zur Agilität, denn es macht Sie furchtlos. Es ist das Blitzlicht, das den gesamten Produktentwicklungsprozess erhellt und Ihrem Team die Klarheit gibt, die es braucht, um das bestmögliche Produkt für Ihre Benutzer zu entwickeln.

diagram

Was bedeutet das konkret? Es gibt viele Möglichkeiten zu experimentieren, vom einfachen A/B-Testing bis hin zu aufwendigen multivariaten Ansätzen. Es ist eher eine kulturelle Einstellung als ein bestimmtes Tool, aber im Allgemeinen sind einige wichtige Praktiken erforderlich.

diagram

Der erste Schritt ist die Festlegung von Metriken. Sie können keine Produkte effektiv entwickeln, wenn Sie nicht wissen, was Sie erreichen wollen und wie gut Sie diese Ziele verfolgen. Wie sieht der Erfolg für Ihr Produkt aus? Um diese Frage zu beantworten, müssen Sie vom Geschäftsmodell Ihres Unternehmens ausgehen, das vielleicht auf Abonnements, Werbeeinnahmen, In-App-Käufen oder anderen Aktivitäten basiert, die den Erfolg des Unternehmens ausmachen. Für jede Funktion sollten Sie konkrete Metriken finden, die ihre Auswirkungen auf diese Ziele erfassen, z. B. die Erhöhung der Kundenbindung, die Förderung von Aktionen wie Lesen und Teilen oder die Verringerung der Abwanderung hochwertiger Kunden. Wie auch immer die Metrik aussieht, Sie müssen sie zuverlässig messen und dann Ihr Team für die Verbesserung der Metrik verantwortlich machen.

Sobald Sie über Messgrößen verfügen, können Sie mit dem Hypothesendenken beginnen. Anstelle einer "Wasserfall"-Roadmap, die aus dramatischen Markteinführungen besteht, entwickeln Sie Theorien darüber, wie sich Ihre Benutzer verhalten und wohin sich Ihr Produkt entwickeln kann. Anstatt zum Beispiel zu erklären, dass wir den Anmeldeprozess neu gestalten müssen, könnten Sie sich fragen, warum sich nur 22% der neuen Benutzer anmelden. Sie könnten dann Ihre Metriken heranziehen, die Daten analysieren und eine Hypothese aufstellen, z.B.: "Wenn wir einen einfacheren Anmeldeprozess mit weniger Schritten im Vorfeld hätten, würden sich unsere Benutzer häufiger anmelden, weil sie schneller einen Nutzen aus dem Produkt ziehen würden."

timeline

Wie Satya Nadella von Microsoft es ausdrückt:

Wenn Sie eine risikofreudige Kultur haben wollen, können Sie nicht jedes Scheitern als Fehlschlag betrachten, sondern müssen in der Lage sein, das Scheitern als Lernmöglichkeit zu sehen....Anstatt zu sagen: "Ich habe eine Idee", wie wäre es, wenn Sie sagen: "Ich habe eine neue Hypothese, lassen Sie uns diese testen, um zu sehen, ob sie gültig ist, und fragen Sie, wie schnell wir sie validieren können." Und wenn sie nicht stichhaltig ist, gehen Sie zum nächsten Schritt über.

Es schadet nicht, einen Misserfolg zu beklagen, wenn die Hypothese nicht funktioniert. Wenn ich neue Wege finde, Dinge zu tun, neue Wege, um zu definieren, was ein Misserfolg und was ein Erfolg ist, wie man zum Erfolg kommt - dann durch eine Reihe von Misserfolgen, durch eine Reihe von Hypothesentests. Das ist in gewissem Sinne das eigentliche Streben.

Mit einer klaren Hypothese bewaffnet, können Sie beginnen, Ideen durch schrittweise Einführung und A/B-Testing zu validieren. Bei jeder Benutzeroberfläche, die Sie entwerfen, oder jeder API, die Sie entwickeln, müssen Sie sich die Frage stellen: "Haben wir das erreicht, was wir uns vorgenommen haben?" Um diese Frage überhaupt stellen zu können, müssen Sie zunächst Ihre Ziele definieren, sie mit Hilfe von Metriken messen, das Problem definieren, eine Lösung finden und diese Lösung hinter einem Feature Flag verstecken. Erst dann können Sie sie validieren, indem Sie sie so früh und so häufig wie möglich mit Ihren Benutzern in Kontakt bringen. Sie können eine neue Funktion durch eine schrittweise Einführung validieren und dabei Ihre Metriken überwachen, oder Sie können sie direkt messen, indem Sie einen A/B-Test durchführen, bei dem die Hälfte Ihrer Benutzer die neue Funktion erhält und die andere Hälfte nicht.diagram

Und schließlich können Sie das Experimentieren nutzen, um verschiedene Varianten einer Idee zu testen. Der Begriff "A/B-Testing" ist eigentlich eine Fehlbezeichnung, denn die effektivsten Experimente haben mehr als nur zwei Varianten und durchlaufen viele Verbesserungszyklen. Stellen Sie sich statt einer linearen Roadmap, bei der jede Funktion entweder eingeführt oder gestrichen wird, einen Gabelungsbaum vor, bei dem jede Funktion in vielen Varianten getestet und optimiert wird. Ein Grund dafür, viele Möglichkeiten auszuprobieren, ist die höhere Wahrscheinlichkeit, ein besseres Ergebnis zu erzielen. Die Daten von Optimizely zeigen, dass Experimente mit einer einzigen Behandlung im Durchschnitt nur eine 14%ige Chance auf eine signifikante Verbesserung der Metriken haben, aber Tests mit vier Behandlungen verdoppeln diese Chance auf fast 28%.

Diese Zahlen sollen verdeutlichen, dass die meisten Experimente scheitern, und genau das ist der Punkt. Indem Sie viele Hypothesen und viele Varianten eines jeden Ansatzes testen, lenken Sie Ihr Team in Richtung der größten Auswirkungen für das Unternehmen. Außerdem lernen Sie auf diese Weise wertvolle Lektionen, die Sie im Laufe der Zeit zu weiteren Hypothesen für ehrgeizigere Experimente anregen. A/B-Testing wird oft als reiner Trick missverstanden, um Klicks auf Formulare zu erzeugen. Aber Experimentieren ist breiter und tiefer als das. Die besten Produktteams setzen A/B-Tests nicht nur als Instrument zur Steigerung der Conversions ein, sondern auch als kulturelle Praxis, die Agilität freisetzt, indem sie Ingenieuren und Product Managern das Vertrauen gibt, intelligente Risiken einzugehen.

Wenn Sie also wollen, dass Ihr Team schneller vorankommt, fordern Sie es auf, mehr zu experimentieren.

graphical user interface, application

Dies ist der erste Teil einer Reihe von Artikeln darüber, wie Sie durch Experimentieren bessere Produkte entwickeln können. Unser Ziel ist es, den Prozess des A/B-Testing und des Feature-Rollouts zu entmystifizieren. Teilen Sie uns also Ihre Fragen und Ihr Feedback in den Kommentaren mit. Und wenn Sie bereit sind, Ihr Experimentieren mit Produkten auf die nächste Stufe zu heben, sollten Sie Optimizely Full Stack Experimentation ausprobieren.