Всем привет!
На связи Дима Бобылев, CTO СберМаркета. В своей первой статье я рассказывал про взрывной рост нашего сервиса и какие неприятности с нами случились. Знайте, мы не только выжили, но и продолжаем расти дальше и берем новые вызовы.
Сегодня хочу поделиться историей, как мы запустили новое мобильное приложение. Для старта разработки накопилось достаточно причин: мы хотели развивать мобильную витрину и улучшать показатели конверсии, расширять штат и компетенции специалистов и реализовать подход mobile first.
Переделывать старый апп во время бурного роста сервиса — все равно, что выходить в открытый космос без скафандра.
— Разве вы не испытывали удовольствия?
— Иногда. В промежутках между припадками ужаса.
(с) «Сами Боги», Айзек Азимов
Но риски оправдались: в июле 2021 года приложение СберМаркета находилось на втором месте среди сервисов eGrocery по накопленной популярности и количеству новых установок.
Сделать упор на мобильную разработку мы решили еще в конце 2020-го. На тот момент приложением занимались трое разработчиков. Это в десятки раз меньше, чем команда сайта. Приложение — наследство от Instamart (так назывался наш сервис до ребрендинга). Оно практически не менялось с 2017-го.
Расти в 3 раза быстрее рынка и продолжать «донашивать» старую разработку — нельзя. Так что мы решили, что будем меняться.
Смело идти туда, куда не ступала нога аутстаффера
Главная миссия СберМаркета — экономить время и силы покупателей для чего-то более важного, чем поход в магазин. Как это делать? С помощью широкого ассортимента и дружелюбного, удобного и быстрого сервиса.
Старое приложение более-менее справлялось с этой миссией. Через него шло 82% всех заказов. Зачем тогда его менять? Вот три важных фактора, которые подтолкнули нас к изменениям:
Недостаток специалистов. За время пандемии ИТ-команда СберМаркета выросла в 10 раз — с 35 до 400 человек. Когда мы только открывали найм новых сотрудников, мобильной разработкой занимались всего 3 аутстаф-специалиста (!) Необходимо было сформировать полноценные мобильные команды.
Конверсия. Приложение редко обновлялось, не успевало за актуальными трендами и иногда подвисало. Для e-commerce есть две ключевые вещи: веб- и мобильная витрины. В нашем случае одна из них работала не в полную силу. Мы теряли пользователей.
Подход mobile first. Не менее важный фактор, чем первые два. Мы просто обязаны предложить людям приложение, которое им понравится.
В процессе подготовки к перезапуску мы переосмыслили саму роль приложения в стратегии СберМаркета. Так как большая часть выручки идет через мобилку — нам было мало просто улучшить разработку. Мы планировали сделать из нее локомотив компании.. Ну, или межгалактический крейсер.
Мы быстро перешли от четырех аутстафферов к 60 мобильным разработчикам и 15 QA-инженерам внутри компании. Собрали в команду специалистов из самых разных сфер. Основными проблемами были узкий рынок нужных нам спецов и недостаток осведомленности о СберМаркете как классном ИТ-бренде.
Что нам в помогло в онбординге:
Крутая мотивация. Если в крупной компании уже есть популярное приложение— разработчикам редко предоставляется возможность построить его с нуля, так как есть легаси. А мы предложили им создать собственный продукт — это интересно.
Новый стэк технологий. С переходом на Swift UI мы ворвались в топ iOS-разработчиков. Нас вообще не было на рынке, а тут мы быстро попали в окружение компаний, которые давно занимаются мобильной разработкой.
Внутренняя миграция. Основная часть команды разработки под Android была переброшена на клиентское приложение с приложения для курьеров и сборщиков, которое было написано на React Native. А чтобы не искать готовых React Native специалистов на стороне (это совсем небольшой рынок), иногда мы приходили к своим спецам по React и говорили с ними о перспективах мобильных приложений. То есть предлагали сменить на смартфон привычные им компьютер, десктоп и браузер.
Сложность была в том, что React Native все-таки достаточно нишевая вещь: люди не очень хотят переходить туда из React и больше интересуются развитием внутри веба, другими фреймворками и подходами.
Самое главное на межгалактическом корабле — его экипаж. У нас получилось две космических команды, которые работают в одном темпе: одна — для разработки под Android, вторая — для iOS.
Мы отбирали и обучали их параллельно. Это был настоящий вызов: Swift UI, с которым работала команда iOS, например, на тот момент совсем недавно вышел в первой версии. А React Native, несмотря на более солидный возраст, оставался узкой нишей, в которой сложно найти свободного специалиста. В итоге для работы со Swift UI мы нанимали специалистов по UIkit, который, в общем, и был на старте у него под капотом, а нативные модули учили писать ребят, которые переходили с React.
О технологиях под капотом
Фактически разработку мы стартовали в феврале, но готовиться к перезапуску начали в ноябре 2020-го.
В старой версии мы использовали язык C# и кроссплатформенную технологию Xamarin. Но Xamarin сложно развивать, так как мало разработчиков на рынке. Платформа почти не развивается. Тренд на Xamarin идет только вниз, взамен него разработчики больше интересуются Flutter или нативной разработкой.
Сперва мы с нашим вице-президентом по продукту Марией Малышевой посетовали друг другу, что дела идут не очень: разработчиков мало, рук не хватает. Затем решили что-то делать. Провели оценку календарного плана проекта, посчитали необходимые задачи и назначили дату перезапуска — 12 апреля.
Позже в честь этого дня у нас даже появился корпоративный мерч: запуск приложения для нас сравним с запуском ракеты.
Мы сторонники декларативных подходов в UI-разработке. Декларативные инструменты позволяют работать быстро и много экспериментировать. Здесь нам изначально повезло с командой: так сложилось, что у СберМаркета уже были люди с неплохой компетенцией в React Native. Мы использовали его на Android, хотя это и не родная технология Google.
Когда мы только начинали работать над новым приложением, Apple создала Swift UI. Был риск, что это мы не затащим: это была новая технология, непроверенная временем, да и другие разработчики еще не набили шишки.
Довольно сырая первая версия Swift UI не могла решить некоторые технологические задачи. Например, просто не вывозила большие списки и постоянно из-за них лагала. Со второй версией фреймворка разработка набрала высоту. А вот Swift UI со своими маленькими модулями оказался довольно изящным: он напоминал о построении интерфейсов в вебе и давал новые возможности.
Так что под капотом нового приложения — многомодульная разработка. То есть приложение как бы состоит из микросервисов. Каждый такой модуль, покрытый тестами, мы можем выдернуть и переместить. Переход с Xamarin на Swift UI был нашей фишкой в разработке нового приложения, и это оказалось эффективным решением.
Как раскатывали приложение
В процессе написания приложения его тестируют QA. На этом этапе мы никогда не можем быть уверены, что сделали все идеально.
Когда ты выпускаешь новый продукт и открываешь его широкому кругу людей, все идет постепенно. Нужно время, чтобы приложение потестили на 1 000 человек, потом на 10 000, на 100 000.
Даже после тестов оставался страх, что клиентам чего-то не хватит — это могло обрушить конверсию. Поэтому мы никогда не ставили себе цель «зарелизиться в день Х любой ценой». Она звучала так: мы выпускаем бета-версию, готовую к продакшн-раскатке, 12 апреля. И мы с этим справились.
Дальше нужно было перевести пользователей текущего мобильного приложения на новое. Для этого в Google Play есть два удобных инструмента: около 4 тысяч бета-тестеров и регулировка процента раскатки. С iOS все не так просто.
На Android ты можешь провести тесты сначала с внутренним кругом пользователей (альфа-тестерами), а затем — с внешними добровольцами (бета). Еще можно запланировать показ нового приложения, например, для 3% клиентов. И алгоритмы Google обновят приложение для 3% людей, которые его загрузили. Если ты увидишь, что в этом узком сегменте что-то не так, то в любой момент можешь остановить релиз.
В это же время на iOS ты запускаешь релиз сразу для 100% пользователей. Автоматическая раскатка (от 1% до 100%) идет 7 дней. Этот процесс можно ставить на паузу, но он все равно неотвратимо идет к релизу. Если где-то есть ошибка, все пользователи столкнутся с проблемами. Плюс для старых пользователей раскатка происходит поэтапно, а новым вся версия становится доступна сразу.
Мы боялись катить приложение на большое количество пользователей, т.к. оно станет доступно для всех новых клиентов. Поэтому сначала мы решили выпуститься отдельным приложением и проверить его. Так мы создали в AppStore приложение специально для тестов, назвали его СберМаркет 2.0 и повели трафик туда. Нам нужно было статистически значимое количество пользователей: с их помощью мы быстро (примерно за месяц) убрали баги и затем понемногу начали раскатывать новое приложение поверх старого. А в СберМаркет 2.0 уже после раскатки повесили баннер, который приглашал в старое приложение: мы сообщали, что полностью переехали туда. Еще разослали пуши с промокодами — в благодарность пользователям, которые помогли нам с тестами.
На что ориентировались
Основным референсом было наше старое приложение. Это забавно: ты говоришь клиентам «новое мобильное приложение», но на самом деле не переписываешь всю систему сразу.
Бэкенд, например, остается старым. Он не самый оптимальный, что-то тормозит, но в начале ты можешь сгладить эти проблемы. Например, снабдить все красивой анимацией, сделать ожидание более мягким и повысить техническое качество приложения. Создать у всех впечатление чего-то нового и быстрого, хотя серверы и бэкенд еще не поменялись — сложная, но посильная задача. Дизайн мы практически не изменили — люди этого не любят.
Наше первое приложение создавалось с оглядкой на Instacart. Это американский сервис, чью бизнес-модель сборки и доставки продуктов с полок магазина мы успешно «привезли» в Россию.
Когда мы были маленьким стартапом, то хотели быть похожими на них. Забавно, что в этом году все поменялось. Нам написал разработчик Instacart: сказал, что знает, что мы опирались на их опыт, и попросил поделиться опытом работы на Swift UI в ответ.
О результатах
Мы стартовали с новым приложением недавно, и вот что у нас получилось на сегодняшний день:
Мы привлекли в команду крутых специалистов. До запуска обновлений над мобильным приложением работали 4 разработчика из сторонней компании, а сегодня платформы поддерживают 60 штатных сотрудников СберМаркета.
Мы приобрели опыт разработки на новых технологиях. Возможно, мы первые с таким продакшн-опытом (если говорить о Swift UI).
Мы зарабатываем: конверсия в заказ выросла на 10% на Android и iOS (по сквозной метрике).
Нам доверяют: согласно бюллетеню Data Insight за июль 2021 года, СберМаркет стал вторым сервисом eGrocery по количеству новых установок мобильного приложения. По нашим данным, на новое приложение переехали больше 95% пользователей.
Мы радуемся: в честь запуска у нас была крутая вечеринка!
Комментарии (16)
BaDP1nG
08.10.2021 13:17+2Использование SwiftUI для создания прототипов очень экономит время, но когда появляется куча мелких окон и различных алертов, то сложность начинает расти лавинообразно. Вообще, Алерты в SwiftUI - отбельная боль, как по мне.
MFilonen2
08.10.2021 16:30А в чем там проблема? Со SwiftUI не разбирался, но вроде бы как раз простота создания «мелких окон» должна быть вроде бы его преимуществом…
BaDP1nG
08.10.2021 17:20+1Если коротко, то коллекция компонентов неполная, а это значит, что приходится клепать обертки uiviewrepresentable, чтоб использовать uikit, например.
Sbermarket
12.10.2021 09:36Доброе утречко! SUI созрел для прода, мы потратили большие усилия чтобы сравнить с UIKit. Мы используем SUI 2, он достаточен чтобы писать большие приложения. Проблем с алертами не испытываем, в будущем надеюсь расскажем, как их правильно готовить )
apachik
12.10.2021 19:21а что вы делаете со старыми осями на проде? отправляете их в мобильный веб?
ну в принципе вполне себе решение.
apapacy
08.10.2021 15:35Вопрос нтереснее по первой статье когда пытались масштабировать MySQL? Вы по-преднему на MySQL? Как спраляетесь с возврошей загрузкой?
ChPr
08.10.2021 15:43+3А почему iOS не на ReactNative? Мотивация взять ReactNative более менее понятна, но когда вы уже выбрали его набирать отдельную команду iOS разработки, чтобы делали все тоже самое что уже сделано на кроссплатформе выглядит не очень.
Sbermarket
12.10.2021 09:35Доброе утро! Изначально хотели и андроид на нативе сделать, но оказалось у нас на старте есть хорошая компетенция в RN. iOS изначально планировался только на нативе делать. RN требует большой команды для интеграции платформеных фичей, поэтому никто и не думал его брать на обе платформы.
chilicoder
02.11.2021 16:49А не подскажите, что вы вкладываете в слово "планировался только на нативе"?
Исходя из чего принималось это решение?
Sbermarket
03.11.2021 10:38Доброе утро. «Планировался только на нативе» – это swift для iOS.
\ Исходя из чего принималось это решение?
Планы по развитию приложения составляли с акцентом на платформенный функционал в будущем.
AveryanovSergey
12.10.2021 09:36Сервисом пользуюсь давно и постоянно, но вот что расстраивает – так это потеря части фукциональности приложения при обновлении. Раньше была возможность доукомплектации уже оформленного заказа (забыл включить в заказ на завтра печеньки – не беда, их можно добавить и к сформированному заказу). В новой версии приложения она пропала, обещают через твитор вернуть "когда-нибудь".
LabEG
Немного не пойму математику
`над мобильным приложением работали 4 разработчика из сторонней компании, а сегодня платформы поддерживают 60 штатных сотрудников`
`конверсия в заказ выросла на 10%`
т.е. при переходе с xamarin на более попсовые технологии стоимость разработки и поддержки выросла в 15 раз, а прибыль всего в 1.1 раза?
apapacy
Ну у меня есть кейс когда четырех парттайм разработчиков нашей команды на аутстафе заменили 150 человеками фултайм "своими". А еще раньше это все далал парттайм один разаботчик, но его обманул его бухгалтер который вступил в сговор с менеджером заказчика и они распиливали бюджет заказчика, — чего этот разработчик какое-то время не знал и был против такого рода эксплуатации. Это же корпорация.
apachik
x15 vs x1.1 звучит конечно дико, но это только на первый взгляд,
ибо надо учитывать еще и базу, к которой этот множитель применяется.
И каждый следующий процент будет давать еще большими усилиями. угу.