Как да изградим мобилен софтуер с фокус върху растежа

Забележка от мен: тази статия е съавторство от мен, Бенджамин Грол (партньор и ръководител на растежа в Atomico) и Хемант Бонсл (мобилен инженер в Zenefits). Ако искате повече анализи и поглед като това, доставяни ежемесечно във вашата пощенска кутия, регистрирайте се в ръководството на оператора (нашия бюлетин) тук.

Това е първата публикация от поредица, фокусирана върху растежа, анализа на данни и най-добрите практики за мащабиране, насочени към дигиталните бизнеси, които са подходящи за продуктовия пазар. Ще го смесим с различни формати, включително парчета със съдържание и интервюта с оператори, споделящи предизвикателства и научения - ако има някаква тема, която би ви интересувала, моля, уведомете ме!

Наскоро започнах да провеждам среща за растеж с Джоуи Коткинс и Анди Янг, за да събера други практикуващи в нашата индустрия.

Създаването на софтуер коренно се промени през последното десетилетие. Когато мобилните приложения на трети страни бяха достъпни за първи път през App Store през 2008 г., начинът, по който използваме софтуер, се промени завинаги, най-вече по добър начин. Някои неща обаче за съжаление бяха изоставени за повечето мобилни приложения; цикли за бързо освобождаване, контролирани от сървъра функции и A / B тестове. Те бяха доста често срещани за много уеб продукти, водещи до мобилната революция, но като цяло не бяха част от първата вълна на мобилното развитие и се връщат с пълна сила днес. Тъжно ми е да мисля за цялата загубена производителност и засилената болка на клиентите поради това.

Тази публикация ще бъде преглед на високо ниво за това как да изградите мобилен софтуер по начин, който е настроен за бързина и учене, две неща, които са от съществено значение, когато се опитвате да развивате бизнеса си, и са основни принципи на Running Lean.

Tenet # 1: (Bi) седмични издания на мобилни и седмични спринтове за изпълнение

Ако сте малка компания, да речем по-малко от десет мобилни инженери или така, мобилната версия на две седмици е добра отправна точка. С увеличаването на инженерния ви екип ще дойде време за преминаване към седмична каденция, което вероятно ще ускори напредъка ви.

За да е ясно, целта тук не е да изтласквате една и съща бинарна през всяка седмица, а да стартирате поне един нов тест за хипотеза, за да научите как да обслужвате най-добре клиентите си. Поставяне на приоритет кои тестове да се изпълняват може да бъде негова собствена публикация, но накратко, потърсете най-евтиното за изграждане валидиране на екзистенциалните въпроси, които имате относно вашия продукт или услуга. Ето страхотен пост от Шон Макбрайд, описващ един подход за приоритизиране на експериментите.

За да се освободи при този вид каданс, се препоръчва седмичен спринт. В четвъртък или петък направете среща за планиране на спринт за следващата седмица. След това в срещата за планиране на спринт:

  • Направете бърз пропуск на вашия (добре поддържан) залог с екипа. Трябва да отнеме 15 минути макс.
  • Помислете какво научихте досега тази седмица. Някакви корекции на курса?
  • След това екипът обсъжда какво да прави следващата седмица.
  • Всяка задача се взема от инженер, който се ангажира да я изпълни на следващата седмица.
  • Обикновено има „демонстрационна среща“ с напредването на седмицата, където инженерите могат да покажат готовата работа (или какъвто и да е напредък, който са постигнали). Това е изключително важно за постигане на фокус и отчетност.

С всичко това на мястото си, в понеделник сутрин, всички знаят какво точно правят за седмицата. Отзивите, които получих от екипи, които преминаха към този модел, е, че това ниво на яснота прави хората по-щастливи. Те знаят точно какво е приоритет и защо, с ясна цел да се удари.

За да резюмираме, положителните ефекти на бързото освобождаване и изпълнение на изпълнението:

  • По-бърз напредък - повече време между отделните версии може да доведе до включване в Закона на Паркинсон. Това е покана за размяна на прогрес за движение.
  • По-високо качество на продукта - Ако пускате две седмици, идентифицирането на първопричините за проблеми обикновено е много по-лесно. В 8-седмичен цикъл на освобождаване срещу двуседмичен цикъл на освобождаване може да има експоненциално повече софтуерни взаимодействия
  • Повече индивидуален фокус - Седмичните спринтове карат фокус, отчетност и щастие
  • По-бързо учене - Тъй като ще обхванем принцип 2, пускането на поне един смислен експеримент седмично ще направи вашия продукт или услуга по-добри по-бързо.

Забележка: когато стартирате седмично, обикновено е да се изгради кандидат за освобождаване, който се използва вътрешно (или бета група) в продължение на седмица и * след това * всъщност стартира в природата. Тъй като изданията се подреждат, имате едноседмична фазова смяна, но постоянният поток все още е седмичен. Качеството е изключително важно за поддържане, разбира се.

Tenet # 2: Контролирайте мобилните функции на клиента със сървърни контроли

Един много важен аспект на родното мобилно развитие днес е поддържането на контрол от страна на сървъра върху различни черти на клиента. Това стана такава норма през последните няколко години, че много фирми се появиха около тази концепция, което позволява на разработчиците лесно да конфигурират своите приложения за четене на флагове от сървъра и съответно да коригират UI / UX и само да покажат съответните функции. Много големи софтуерни компании изграждат системи, които правят това от нулата. Facebook имаше няколко системи, които направиха това, включително Gatekeeper (GK) и Quick Experiment (QE). Подобни системи са изградени в Uber, Pinterest, Zenefits и др. Някои примери за лесно достъпни инструменти, които правят това, включват Optimizely, Mixpanel, Apptimize и Firebase.

Има няколко причини, поради които клиентските черти, контролирани от сървъри, стават стандарт за мобилно развитие:

  • По-добро преживяване на клиентите - Поради закъснения между подаването на приложение и наличността за вашите клиенти, сривовете на клиенти и грешките могат да продължат да се появяват, докато не бъде публикувана актуална корекция. С контролирани от сървъра черти на клиента, тези видове повреди могат да бъдат смекчени (например нова функция причинява срив на Nexus 6 устройството, така че функцията се изключва на ниво сървър за всички потребители с това устройство и сривът спира). Това може би е по-малко проблем за приложенията за Android, но все пак може да има няколко часа закъснение между подаване и пускане. Освен това някои потребители нямат включена автоматична актуализация.
  • Още инсталирания - В свят, в който приложението се срива при старт за ден или повече, приложението може да получи много отрицателни отзиви. Това може да доведе до по-ниско класиране в Google Play Store / iOS App Store и по-нисък процент на конверсия от страницата на приложението към инсталирането на приложението (например, по-вероятно е да инсталирам приложение с 4,5 звезди от 3,5 звездна оценка) , Това дори не е причина за клиентите, които сте „изгорили“, които никога няма да се върнат, нито отрицателната преса, която може да навреди на вашата марка.
  • По-малко монолитна / по-течна разработка - Когато инженерите знаят, че една непълна функция може да бъде изключена със сървърна конфигурация, това намалява режийните разходи.

Тази способност обикновено се нарича „маркиране на функции“. Когато сесията на приложението започне, приложението прави api повикване за извличане на набор от булеви или „флагчета“, които ви казват какви кодови пътища са добре, за да поемете приложението ви.

Например:

  • Току-що сте изградили функция за разплащане с мобилни клиенти
  • Създадохте съответния флаг от страна на сървъра, наречен „Payment_v1“. Това е булева стойност, която може да бъде зададена или вярна или невярна
  • При първата сесия на клиента клиентът получава тази стойност. Ако стойността е вярна, клиентът ще покаже функцията, ако е невярна, клиентът няма да

Обикновено е предварително да се добави името на платформата, така че обикновено „ios_“ или „android_“ и да добавите датата, когато флагът е направен, така че нещо като „_aug_2017“. Така че за първата версия на функцията за плащания, която се пуска на iOS, може да видите флаг като „ios_payments_v1_aug_2017“. Наличието на дата помага, така че екипите да могат да поддържат мека времева линия в кода, когато са пуснати различни функции. Наличието на платформата помага, така че изключването на флага ще го изключи само за подходящата платформа, а не за всички потребители, ако сривът или проблемът са само на единия, а не на другия.

Провеждане на сесия за растеж с портфолиовите компании на Local Globe в Лондон

Tenet # 3: Разширете сървърните контроли на мобилни функции до A / B тестове, за да увеличите максимално обучението

Контролирането на функции само в двоичен начин (true == show, false == скрий) е чудесно като превключвател за включване и изключване на нещата за потребителите. В много случаи обаче искаме да внесем различни варианти на функции, за да научим какво искат нашите клиенти въз основа на използването им.

Правим това с A / B тестване на мобилни устройства. Концепцията за мобилни тук е същата като A / B тестване навсякъде другаде - искаме да проведем експеримент и да тестваме няколко различни варианта за най-добри резултати. Така че освен флагчета за функция за включване и изключване на поведението на клиента, ключовите имена на вариантите за показване се връщат от сървъра. Въз основа на получения вариант приложението ви ще показва съответния потребителски интерфейс / UX.

Този процес ни позволява да:

  • Изберете победителя - Проучвайки и тествайки опциите, можете да изберете най-доброто.
  • Бавно преобръщане на рискова / спорна функция (вероятно към бета група) - Понякога стартираме функции, които могат да нарушат съществуващата функционалност по неизвестни начини. Може да се използва нов бек-енд или нов бит на функционалност, който до голяма степен е непроверен. Стартирайки при малък процент от потребителите, често можете да смекчите по-широката болка на клиента. Друг вариант за обмисляне е да разчитате на бета група от лоялни клиенти. Виждал съм ситуации, когато тези умират фенове на продукта като изключителността да бъдат в ранни версии на приложението ви.
  • Създайте по-добро изживяване с приложението - Когато получите навика да измервате данни за използване и навигация в мобилното си приложение, естествените приложения често стават очевидни. Това ви позволява да оптимизирате приложението си към действителното поведение на клиента.

Разширяване на примера на функцията за плащания, която обсъждахме по-рано:

Изпълнете теста:

  • Искаме да тестваме цвета на бутона за плащане, за да видим дали има ефект върху потребителските покупки
  • В допълнение към флаг „Payment_v1“ ние изпращаме от сървъра ключ „Payment_v1_button_color“ с варианти, т.е. „син“, „зелен“, „червен“
  • Изчакайте докато получите статистически значими резултати от проследяването на клиента

Вземете решение за резултат:

  • Да речем, че „зеленото“ се представя най-добре…
  • Със следващия цикъл на пускане актуализирайте клиентския код, за да показва винаги зеления цвят на бутона.
  • Почистете сървърния код, за да връщате винаги „плащания_v1_button_color“ като „зелени“, така че и по-старите клиенти ще показват това

Извадете A / B теста, когато е безопасно:

  • Почистете отново сървърния код, след като съотношението на вашите потребители към по-възрастните клиенти е незначителен процент
  • Изтрийте напълно бутона „Payment_v1_button_color“
  • Ако сте разработили с обратна съвместимост предвид (така че ако ключът не е изпратен от сървъра), клиентът се връща към показване на някаква по подразбиране - подобно на случая по подразбиране на оператор за превключване

Заключение:

С малко работа, разработването на мобилни приложения може (и трябва) да бъде почти толкова гъвкаво, безопасно и да създава знания, колкото уеб базирана разработка. Аз съм оптимист, че дори можем да видим непрекъснато внедряване на мобилни приложения през следващото десетилетие.

TL; DR версия

  • Започвайки със седмичен спринтов процес, ние насочваме фокуса и яснотата към работата, която вършим.
  • Следвайки седмично или двуседмично внедряване на приложения, използващи A / B тестови варианти на мобилното клиентско изживяване, ние увеличаваме максимално нашето обучение, като в същото време минимизираме риска за качеството.

Ако искате повече анализи и поглед като това, доставяни ежемесечно във вашата пощенска кутия, регистрирайте се в ръководството на оператора (нашия бюлетин) тук.