Jak vytvořit mobilní software s důrazem na růst

Poznámka ode mě: tento článek jsem spoluautorem, Benjamin Grol (Partner a vedoucí růstu v Atomicu) a Hemant Bhonsle (Mobilní inženýr ve společnosti Zenefits). Chcete-li získat více analýz a podrobnější informace, doručené měsíčně do vaší doručené pošty, zaregistrujte se zde v Příručce operátora (náš zpravodaj).

Toto je první příspěvek v řadě zaměřený na růst, analýzu dat a osvědčené postupy pro škálování zaměřené na digitální podniky vhodné pro postprodukty na trhu. Budeme to kombinovat s různými formáty, včetně kusů obsahu a rozhovorů s operátory, kteří sdílejí výzvy a učení - pokud existuje nějaké téma, které by vás zajímalo, dejte mi prosím vědět!

Nedávno jsem zahájil růst Meet-Up s Joey Kotkinsem a Andy Youngem, abych spojil další odborníky v našem oboru.

Tvorba softwaru se v posledním desetiletí zásadně změnila. Když byly mobilní aplikace třetích stran poprvé dostupné v App Store v roce 2008, způsob, jakým používáme software, se změnil navždy, většinou dobrým způsobem. Některé věci však byly bohužel pozadu pro většinu mobilních aplikací; cykly rychlého uvolnění, funkce řízené serverem a testy A / B. Tito byli docela běžní pro mnoho webových produktů, které vedly k mobilní revoluci, ale obecně nebyly součástí první vlny vývoje mobilních zařízení a dnes se v plné síle vrací. Je mi smutno myslet na veškerou ztracenou produktivitu a zvýšenou bolest zákazníka v důsledku toho.

Tento příspěvek bude přehledem na vysoké úrovni o tom, jak vytvořit mobilní software způsobem, který je vyladěn pro rychlost a učení, dvě věci, které jsou nezbytné, když se snažíte rozvíjet své podnikání, a jsou základními principy společnosti Running Lean.

Princip č. 1: (Bi) týdenní vydání na mobilních a týdenních sprintech

Pokud jste malá společnost, řekněme, že méně než deset mobilních inženýrů nebo tak podobně, dvouměsíční mobilní verze je dobrým výchozím bodem. S tím, jak se váš technický tým zvětšuje, přijde čas, kdy přechod na týdenní kadenci pravděpodobně urychlí váš pokrok.

Abychom to vyjasnili, cílem zde není vytlačit stejný binární kód každý týden, je třeba zahájit alespoň jeden nový test hypotéz, abychom zjistili, jak nejlépe sloužit vašim zákazníkům. Prioritou toho, které testy spustit, by mohlo být jeho vlastní post, ale v kostce, podívejte se na nejlevnější-to-build ověření existenciálních otázek, které máte o vašem produktu nebo službě. Zde je skvělý příspěvek od Sean McBride popisující jeden přístup pro stanovení priorit experimentů.

Za účelem uvolnění při této kadenci je doporučenou cestou týdenní sprint. Ve čtvrtek nebo v pátek si naplánujte schůzku na sprintu na následující týden. Pak na plánovacím setkání sprintu:

  • Udělejte rychlý průchod svého (dobře udržovaného) nevyřízeného týmu. Měl by trvat max. 15 minut
  • Zvažte, co jste se tento týden naučili. Nějaké korekce kurzu?
  • Tým poté diskutuje o tom, co dělat příští týden.
  • Každý úkol je vyzvednut technikem, který se zavazuje, že ho splní následující týden.
  • V průběhu týdne se obvykle koná „demonstrační schůzka“, na níž mohou inženýři ukázat hotovou práci (nebo jakýkoli pokrok, kterého dosáhli). To je rozhodující pro soustředění a odpovědnost.

S tím vším, v pondělí ráno, každý ví přesně, co dělá za týden. Zpětná vazba, kterou jsem obdržel od týmů, které přešly na tento model, spočívá v tom, že tato úroveň jasnosti činí lidi šťastnějšími. Přesně vědí, co je prioritou a proč, s jasným cílem zasáhnout.

Souhrnně řečeno, pozitivní účinky rychlého uvolnění a provádění kadence:

  • Rychlejší postup - Více času mezi vydáními může vést k run-ins s Parkinsonovým zákonem. Je to pozvání zaměnit pokrok za pohyb.
  • Vyšší kvalita produktu - Pokud vydáváte každé dva týdny, identifikace hlavních příčin problémů je obvykle mnohem jednodušší. Během 8týdenního cyklu vydání může existovat exponenciálně více softwarových interakcí oproti 2týdennímu cyklu vydání
  • Více individuálního zaměření - Týdenní sprinty vedou k zaměření, odpovědnosti a štěstí
  • Rychlejší učení - Jak se budeme věnovat principu č. 3, spuštění alespoň jednoho smysluplného experimentu týdně zlepší váš produkt nebo službu dříve.

Poznámka: Při spouštění každý týden je běžné sestavení kandidáta na vydání, které se používá interně (nebo beta skupinu) po dobu jednoho týdne, a poté * ve skutečnosti spuštěné ve volné přírodě. Když se uvolnění hromadí, máte fázový posun o jeden týden, ale stabilní tok je stále týdenní. Kvalita je rozhodující pro zachování, samozřejmě.

Princip č. 2: Ovládání funkcí mobilního klienta pomocí ovládacích prvků serveru

Jedním z velmi důležitých aspektů dnešního vývoje mobilních zařízení je udržování kontroly různých vlastností klienta na straně serveru. To se během posledních několika let stalo takovou normou, že se kolem tohoto konceptu objevilo mnoho podniků, což vývojářům umožnilo snadno konfigurovat své aplikace tak, aby číst příznaky ze serveru, a podle toho upravovat své UI / UX a zobrazovat pouze příslušné funkce. Mnoho velkých softwarových společností staví systémy, které to dělají od nuly. Facebook měl několik systémů, které to provedly, včetně Gatekeeper (GK) a Quick Experiments (QE). Podobné systémy byly vytvořeny v Uber, Pinterest, Zenefits atd. Některé příklady snadno dostupných nástrojů, které to umožňují, jsou Optimizely, Mixpanel, Apptimize a Firebase.

Existuje několik důvodů, proč se vlastnosti klienta ovládané serverem stávají standardem pro mobilní vývoj:

  • Lepší zkušenosti se zákazníky - Z důvodu zpoždění mezi odesláním aplikace a dostupností pro vaše zákazníky může dojít ke zhroucení a chybě klienta, dokud nebude publikována oprava hotfix. U klientských vlastností řízených serverem lze tyto druhy poruch zmírnit (např. Nová funkce způsobí selhání zařízení Nexus 6, takže tato funkce je vypnuta na úrovni serveru pro všechny uživatele s tímto zařízením a zastavení selhání). Toto je pravděpodobně menší problém pro aplikace pro Android, nicméně mezi odesláním a uvolněním může stále ještě několik hodin zpoždění. Někteří uživatelé také nemají automatickou aktualizaci zapnutou.
  • Více instalací - Ve světě, kde se aplikace na jeden den zhroutí, může aplikace získat mnoho negativních recenzí. To může vést k nižšímu hodnocení v obchodě Google Play / iOS App Store a nižšímu konverznímu poměru ze stránky aplikace na instalaci aplikace (např. S ​​větší pravděpodobností nainstaluji aplikaci se 4,5 hvězdičkami než 3,5 hvězdičkami) . To ani neznamená, že jste „spálili“ zákazníky, kteří se nikdy nevrátí, ani negativní tisk, který by mohl poškodit vaši značku.
  • Méně monolitický / více plynulý vývoj - Pokud inženýři vědí, že neúplnou funkci lze vypnout pomocí konfigurace serveru, snižuje to režijní náklady na vývoj.

Tato schopnost se obvykle nazývá „příznakem funkce“. Po zahájení relace aplikace provede api volání, aby získala sadu booleovských řetězců nebo „příznaků“, které vám řeknou, jaké cesty k kódům jsou pro vaši aplikaci v pořádku.

Například:

  • Právě jste vytvořili funkci plateb mobilních klientů
  • Vytvořili jste odpovídající příznak na straně serveru s názvem „payments_v1“. Je to logická hodnota, kterou lze nastavit na true nebo false
  • Při první relaci klienta klient tuto hodnotu získá. Pokud je hodnota true, klient zobrazí funkci, pokud je nepravdivá, klient ji nebude zobrazovat

Je běžné předepsat název platformy, tedy obvykle „ios_“ nebo „android_“ a připojit datum, kdy byla vlajka vytvořena, takže něco jako „_aug_2017“. U první verze platební funkce, která se vydává na iOS, se tedy může zobrazit příznak jako „ios_payments_v1_aug_2017“. Mít datum pomáhá týmům udržet si měkkou časovou osu v kódu, kdy byly vydány různé funkce. Mít platformu pomáhá tak, že vypnutí příznaku ji vypne pouze pro příslušnou platformu, nikoli pro všechny uživatele, pokud dojde k selhání nebo problému pouze na jednom a ne na druhém.

Provádění růstové relace s portfoliovými společnostmi Local Globe v Londýně

Princip č. 3: Rozšiřte ovládání serveru z mobilních funkcí na testy A / B a maximalizujte tak učení

Ovládání funkcí pouze binárním způsobem (true == show, false == hide) je skvělé jako přepínač pro zapnutí a vypnutí věcí pro uživatele. V mnoha případech však chceme zavést různé varianty funkcí, abychom zjistili, co naši zákazníci chtějí na základě jejich použití.

Děláme to testováním A / B na mobilu. Koncept pro mobilní zařízení je stejný jako u A / B testování kdekoli jinde - chceme provést experiment a otestovat několik různých variant, abychom dosáhli nejlepších výsledků. Takže kromě příznaků funkcí, které zapínají a vypínají chování klientů, server vrací názvy klíčů variant, které se mají zobrazit. Na základě přijaté varianty aplikace zobrazí odpovídající UI / UX.

Tento proces nám umožňuje:

  • Vyberte vítěze - Prozkoumáním a testováním možností si můžete vybrat to nejlepší.
  • Pomalu rolujte riskantní / spornou funkci (pravděpodobně do skupiny beta) - Někdy spustíme funkce, které mohou neznámou cestou narušit stávající funkčnost. Může to být použití nového back-endu nebo nového kousku funkčnosti, který je do značné míry netestovaný. Spuštěním na malé procento uživatelů můžete často zmírnit větší bolest zákazníků. Další možností je zvážit spoléhání se na beta skupinu věrných zákazníků. Viděl jsem situace, kdy tito umírají tvrdí fanoušci produktu, jako je exkluzivita předčasného vydání vaší aplikace.
  • Vytvořte lepší zážitek z aplikace - Když si zvyknete měřit údaje o využití a navigaci v mobilní aplikaci, přirozená použití se často stanou samozřejmými. To vám umožní optimalizovat vaši aplikaci na skutečné chování zákazníků.

Rozšíření příkladu funkce plateb, o které jsme diskutovali dříve:

Spusťte test:

  • Chceme A / B otestovat barvu tlačítka platby a zjistit, zda to má vliv na nákupy uživatelů
  • Kromě příznaku „payments_v1“ nyní odešleme ze serveru klávesu „payments_v1_button_color“ s variantami, tj. „Modrý“, „zelený“, „červený“.
  • Počkejte, až získáte statisticky významné výsledky ze sledování klientů

Rozhodněte o výsledku:

  • Řekněme, že „zelený“ fungoval nejlépe…
  • Při dalším cyklu vydání aktualizujte kód klienta tak, aby se vždy zobrazovala barva zeleného tlačítka.
  • Vyčistěte kód serveru, abyste vždy vrátili „payment_v1_button_color“ jako „green“, takže starší klienti to také zobrazí

Pokud je to bezpečné, odeberte test A / B:

  • Vyčistěte kód serveru znovu, jakmile bude poměr vašich uživatelů na starších klientech na zanedbatelném procentu
  • Zcela odeberte klíč „payments_v1_button_color“
  • Pokud jste se vyvinuli s ohledem na zpětnou kompatibilitu (takže pokud klíč není odeslán ze serveru), klient se vrátí k zobrazení některých výchozích hodnot - podobně jako výchozí případ příkazu switch

Závěr:

S trochou práce může být vývoj mobilních aplikací (a měl by) být téměř stejně flexibilní, bezpečný a vytvářející znalosti jako vývoj na webu. Jsem optimistický, že v příštím desetiletí můžeme dokonce pozorovat neustálé nasazení v mobilních aplikacích.

TL; DR verze

  • Zahájením týdenního procesu sprintu se soustředíme a vyjasňujeme práci, kterou vykonáváme.
  • Tím, že sledujeme týdenní nebo dvoutýdenní nasazení aplikací využívajících testovací varianty A / B zážitku mobilního klienta, maximalizujeme naše učení a zároveň minimalizujeme riziko kvality.

Chcete-li získat více analýz a podrobnější informace, doručené měsíčně do vaší doručené pošty, zaregistrujte se zde v Příručce operátora (náš zpravodaj).