So erstellen Sie mobile Software mit Wachstumsfokus

Anmerkung von mir: Dieser Artikel wurde von mir, Benjamin Grol (Partner und Head of Growth bei Atomico) und Hemant Bhonsle (Mobile Engineer bei Zenefits), mitautorisiert. Wenn Sie mehr Analysen und Einblicke wie diese wünschen, die monatlich (ish) in Ihren Posteingang geliefert werden, tragen Sie sich hier in die Bedienungsanleitung (unseren Newsletter) ein.

Dies ist der erste Beitrag in einer Reihe, die sich auf Wachstum, Datenanalyse und Best Practices für die Skalierung konzentriert und auf digitale Unternehmen abzielt, die nach dem Produktmarkt passen. Wir mischen es mit einer Vielzahl von Formaten, einschließlich Inhalten und Interviews mit Betreibern, die Herausforderungen und Erkenntnisse austauschen. Wenn Sie sich für ein Thema interessieren, lassen Sie es mich bitte wissen.

Ich habe kürzlich begonnen, ein Wachstumstreffen mit Joey Kotkins und Andy Young zu veranstalten, um andere Praktiker aus unserer Branche zusammenzubringen.

Die Erstellung von Software hat sich im letzten Jahrzehnt grundlegend geändert. Als im Jahr 2008 erstmals mobile Apps von Drittanbietern über den App Store verfügbar waren, hat sich die Art und Weise, wie wir Software verwenden, für immer geändert, hauptsächlich auf eine gute Art und Weise. Einige Dinge blieben jedoch für die meisten mobilen Apps leider zurück. schnelle Release-Zyklen, servergesteuerte Funktionen und A / B-Tests. Diese waren für viele Web-Produkte vor der mobilen Revolution durchaus üblich, waren jedoch im Allgemeinen nicht Teil der ersten Welle der mobilen Entwicklung und treten erst heute wieder in vollem Umfang in Kraft. Es macht mich traurig, an all die Produktivitätsverluste und die daraus resultierenden erhöhten Kundenschmerzen zu denken.

In diesem Beitrag erhalten Sie einen umfassenden Überblick darüber, wie Sie mobile Software auf eine Weise erstellen, die auf Geschwindigkeit und Lernen abgestimmt ist. Dies sind zwei Dinge, die für das Wachstum Ihres Unternehmens von entscheidender Bedeutung sind und die Kernelemente von Running Lean sind.

Grundsatz Nr. 1: (Bi) wöchentliche Veröffentlichungen für Sprints zur mobilen und wöchentlichen Ausführung

Wenn Sie ein kleines Unternehmen sind, beispielsweise weniger als zehn mobile Ingenieure, ist eine zweiwöchentliche mobile Veröffentlichung ein guter Ausgangspunkt. Je größer Ihr Entwicklungsteam wird, desto schneller können Sie Ihren Fortschritt beschleunigen, wenn Sie zu einer wöchentlichen Trittfrequenz übergehen.

Um klar zu sein, besteht das Ziel hier nicht darin, jede Woche dieselbe Binärdatei herauszuschieben, sondern mindestens einen neuen Hypothesentest zu starten, um zu lernen, wie Sie Ihre Kunden am besten bedienen können. Die Priorisierung der auszuführenden Tests kann eine eigene Aufgabe sein. Kurz gesagt: Suchen Sie nach der kostengünstigsten Validierung der existenziellen Fragen, die Sie zu Ihrem Produkt oder Ihrer Dienstleistung haben. Hier ist ein großartiger Beitrag von Sean McBride, der einen Ansatz zur Priorisierung von Experimenten beschreibt.

Um diese Trittfrequenz zu erreichen, wird ein wöchentlicher Sprint empfohlen. Führen Sie an einem Donnerstag oder Freitag ein Sprint-Planungstreffen für die folgende Woche durch. Dann im Sprint-Planungstreffen:

  • Machen Sie einen kurzen Überblick über Ihren (gut gepflegten) Rückstand mit dem Team. Sollte maximal 15 Minuten dauern.
  • Überlegen Sie, was Sie diese Woche bisher gelernt haben. Irgendwelche Kurskorrekturen?
  • Das Team bespricht dann, was nächste Woche zu tun ist.
  • Jede Aufgabe wird von einem Ingenieur übernommen, der sich verpflichtet, sie in der folgenden Woche zu erledigen.
  • Im Verlauf der Woche findet in der Regel ein „Demo-Meeting“ statt, bei dem die Ingenieure die abgeschlossenen Arbeiten (oder die erzielten Fortschritte) zeigen können. Dies ist entscheidend für die Fokussierung und Verantwortlichkeit.

Mit all dem wissen alle am Montagmorgen genau, was sie für die Woche tun. Die Rückmeldungen von Teams, die auf dieses Modell umgestellt haben, lauten, dass diese Klarheit die Menschen glücklicher macht. Sie wissen genau, worauf es ankommt und warum, und haben ein klares Ziel vor Augen.

Um es zusammenzufassen, die positiven Effekte einer schnellen Freigabe und Ausführungskadenz:

  • Schnellerer Fortschritt - Mehr Zeit zwischen den Veröffentlichungen kann zu Verstößen gegen das Parkinson-Gesetz führen. Es ist eine Einladung, Fortschritt gegen Bewegung einzutauschen.
  • Höhere Produktqualität - Wenn Sie zweiwöchentlich veröffentlichen, ist es in der Regel viel einfacher, die Hauptursachen für Probleme zu ermitteln. In einem 8-wöchigen Release-Zyklus können exponentiell mehr Software-Interaktionen auftreten als in einem 2-wöchigen Release-Zyklus
  • Mehr individueller Fokus - Wöchentliche Sprints steigern den Fokus, die Verantwortlichkeit und das Glück
  • Schneller lernen - Wie wir in Grundsatz 3 behandeln werden, können Sie Ihr Produkt oder Ihre Dienstleistung schneller verbessern, wenn Sie mindestens ein aussagekräftiges Experiment pro Woche starten.

Hinweis: Beim wöchentlichen Start ist es üblich, dass ein Release Candidate-Build eine Woche lang intern (oder in einer Beta-Gruppe) verwendet und dann tatsächlich in freier Wildbahn gestartet wird. Während sich die Releases stapeln, haben Sie eine einwöchige Phasenverschiebung, aber der stetige Fluss ist immer noch wöchentlich. Qualität ist natürlich von entscheidender Bedeutung.

Grundsatz Nr. 2: Steuern Sie die Funktionen des mobilen Clients mithilfe von Serversteuerelementen

Ein sehr wichtiger Aspekt der nativen mobilen Entwicklung ist heutzutage die serverseitige Kontrolle über verschiedene Client-Merkmale. Dies ist in den letzten Jahren zu einer solchen Norm geworden, dass sich viele Unternehmen diesem Konzept verschrieben haben. So können Entwickler ihre Anwendungen auf einfache Weise so konfigurieren, dass sie Flags vom Server lesen und ihre Benutzeroberfläche / UX entsprechend anpassen und nur die entsprechenden Funktionen anzeigen. Viele große Softwareunternehmen bauen Systeme, die dies von Grund auf tun. Facebook hatte einige Systeme, die dies taten, darunter Gatekeeper (GK) und Quick Experiments (QE). Ähnliche Systeme wurden bei Uber, Pinterest, Zenefits usw. entwickelt. Einige Beispiele für sofort verfügbare Tools, die dies tun, sind Optimizely, Mixpanel, Apptimize und Firebase.

Es gibt einige Gründe, warum servergesteuerte Client-Eigenschaften zum Standard für die mobile Entwicklung werden:

  • Besseres Kundenerlebnis - Aufgrund von Verzögerungen zwischen App-Übermittlung und Verfügbarkeit für Ihre Kunden können Client-Abstürze und Fehler auftreten, bis ein Hotfix veröffentlicht wird. Mit servergesteuerten Clientmerkmalen können diese Arten von Fehlern verringert werden (z. B. führt eine neue Funktion zu einem Absturz auf dem Nexus 6-Gerät, sodass die Funktion auf Serverebene für alle Benutzer mit diesem Gerät deaktiviert wird und der Absturz beendet wird). Dies ist wohl weniger ein Problem für Android-Apps, es kann jedoch immer noch einige Stunden Verspätung zwischen Einreichung und Veröffentlichung geben. Bei einigen Benutzern ist die automatische Aktualisierung nicht aktiviert.
  • Weitere Installationen - In einer Welt, in der die App nach einem Tag oder länger abstürzt, kann es vorkommen, dass die App viele negative Bewertungen erhält. Dies kann zu einem niedrigeren Ranking im Google Play Store / iOS App Store und einer niedrigeren Conversion-Rate von der App-Seite zur App-Installation führen (z. B. installiere ich eher eine App mit 4,5 Sternen als mit 3,5 Sternen). . Dies berücksichtigt nicht einmal Kunden, die Sie "verbrannt" haben und die niemals wiederkommen, oder negative Presse, die Ihrer Marke schaden könnte.
  • Weniger monolithisch / flüssigere Entwicklung - Wenn Ingenieure wissen, dass eine unvollständige Funktion mit einer Serverkonfiguration deaktiviert werden kann, verringert sich der Entwicklungsaufwand.

Diese Funktion wird in der Regel als "Feature-Flagging" bezeichnet. Wenn eine App-Sitzung beginnt, ruft die App eine API auf, um eine Reihe von Booleschen Werten oder "Flags" abzurufen, die Ihnen mitteilen, welche Codepfade für Ihre Anwendung in Ordnung sind.

Zum Beispiel:

  • Sie haben gerade eine Zahlungsfunktion für mobile Kunden erstellt
  • Sie haben ein entsprechendes serverseitiges Flag mit dem Namen "payments_v1" erstellt. Es ist ein boolescher Wert, der entweder auf true oder false gesetzt werden kann
  • In der ersten Clientsitzung ruft der Client diesen Wert ab. Wenn der Wert true ist, zeigt der Client das Feature an. Wenn er false ist, wird der Client das Feature nicht anzeigen

Es ist üblich, den Plattformnamen voranzustellen, also normalerweise "ios_" oder "android_", und das Datum anzuhängen, an dem das Flag erstellt wurde, also so etwas wie "_aug_2017". Für die erste Version der Zahlungsfunktion, die auf iOS veröffentlicht wird, wird möglicherweise ein Flag wie "ios_payments_v1_aug_2017" angezeigt. Das Datum hilft dabei, dass die Teams einen weichen Zeitplan für die Veröffentlichung der verschiedenen Funktionen haben. Die Plattform zu haben hilft dabei, dass das Deaktivieren des Flags nur für die entsprechende Plattform und nicht für alle Benutzer deaktiviert wird, wenn der Absturz oder das Problem nur auf einem und nicht auf dem anderen auftritt.

Durchführung einer Wachstumssitzung mit den Local Globe-Portfolio-Unternehmen in London

Grundsatz 3: Erweitern Sie die Serversteuerung mobiler Funktionen auf A / B-Tests, um das Lernen zu maximieren

Das rein binäre Steuern von Features (true == show, false == hide) ist ideal, um Dinge für Benutzer ein- und auszuschalten. In vielen Fällen möchten wir jedoch verschiedene Funktionsvarianten einführen, um zu erfahren, was unsere Kunden basierend auf ihrer Nutzung der Funktion wünschen.

Wir machen das mit A / B-Tests auf dem Handy. Das Konzept für Mobilgeräte ist hier dasselbe wie für A / B-Tests an anderen Orten - wir möchten ein Experiment durchführen und verschiedene Varianten testen, um die besten Ergebnisse zu erzielen. Zusätzlich zu den Feature-Flags zum Aktivieren und Deaktivieren des Client-Verhaltens werden die Schlüsselnamen der anzuzeigenden Varianten vom Server zurückgegeben. Abhängig von der erhaltenen Variante zeigt Ihre Anwendung die entsprechende UI / UX an.

Dieser Prozess ermöglicht es uns:

  • Auswahl des Gewinners - Durch Erkundung und Testen der Optionen können Sie die besten auswählen.
  • Langsames Rollen einer riskanten / umstrittenen Funktion (möglicherweise für eine Betagruppe) - Manchmal starten wir Funktionen, die vorhandene Funktionen auf unbekannte Weise beeinträchtigen können. Möglicherweise wird ein neues Back-End oder eine neue Funktionalität verwendet, die weitgehend ungetestet ist. Indem Sie einen kleinen Prozentsatz der Benutzer ansprechen, können Sie häufig die Schmerzen der Kunden lindern. Eine weitere Option ist, sich auf eine Beta-Gruppe treuer Kunden zu verlassen. Ich habe Situationen erlebt, in denen diese Fans des Produkts wie die Exklusivität, in früheren Versionen Ihrer App zu sein, sterben.
  • Bauen Sie ein besseres App-Erlebnis auf - Wenn Sie es sich zur Gewohnheit machen, Nutzungs- und Navigationsdaten in Ihrer mobilen App zu messen, werden die natürlichen Nutzungen häufig offensichtlich. Auf diese Weise können Sie Ihre App für das tatsächliche Kundenverhalten optimieren.

Erweitern des zuvor beschriebenen Beispiels für die Zahlungsfunktion:

Führen Sie den Test durch:

  • Wir möchten, dass A / B die Farbe der Zahlungsschaltfläche testet, um festzustellen, ob sich dies auf die Einkäufe der Benutzer auswirkt
  • Zusätzlich zu einem "payments_v1" -Flag senden wir jetzt vom Server einen "payments_v1_button_color" -Schlüssel mit den Varianten "blue", "green", "red".
  • Warten Sie, bis Sie statistisch signifikante Ergebnisse aus dem Client-Tracking erhalten

Entscheide dich für ein Ergebnis:

  • Sagen wir, "grün" schnitt am besten ab ...
  • Aktualisieren Sie beim nächsten Release-Zyklus den Client-Code so, dass immer die Farbe der grünen Schaltfläche angezeigt wird.
  • Bereinigen Sie den Servercode so, dass "payments_v1_button_color" immer als "grün" zurückgegeben wird, damit auch ältere Clients dies anzeigen

Entfernen Sie den A / B-Test, wenn dies ohne Gefahr möglich ist:

  • Bereinigen Sie den Servercode erneut, sobald das Verhältnis Ihrer Benutzer auf älteren Clients einen vernachlässigbaren Prozentsatz aufweist
  • Entfernen Sie den Schlüssel "payments_v1_button_color" vollständig
  • Wenn Sie im Hinblick auf die Abwärtskompatibilität entwickelt haben (damit der Schlüssel nicht vom Server gesendet wird), zeigt der Client wieder einige Standardeinstellungen an - ähnlich wie bei einer switch-Anweisung

Fazit:

Mit ein wenig Arbeit kann (und sollte) die Entwicklung mobiler Apps fast so flexibel, sicher und wissensbasiert sein wie die Entwicklung im Internet. Ich bin optimistisch, dass wir im nächsten Jahrzehnt sogar eine kontinuierliche Bereitstellung auf mobilen Apps sehen werden.

TL; DR-Version

  • Indem wir mit einem wöchentlichen Sprintprozess beginnen, konzentrieren wir uns auf die von uns geleistete Arbeit und sorgen für Klarheit.
  • Indem wir wöchentliche oder zweiwöchentliche App-Bereitstellungen mit A / B-Testvarianten der mobilen Client-Erfahrung durchführen, maximieren wir unser Lernen und minimieren gleichzeitig das Qualitätsrisiko.

Wenn Sie mehr Analysen und Einblicke wie diese wünschen, die monatlich (ish) in Ihren Posteingang geliefert werden, tragen Sie sich hier in die Bedienungsanleitung (unseren Newsletter) ein.