Всем привет! В этой заметке я хочу поделиться мыслями, опытом и советами на тему экономии ресурсов (время/деньги/внимание) при разработке мобильных приложений. Думаю, что материал будет актуален тем, кто уже ведет разработку мобильных приложений или только собирается это делать. Поехали!
Разработкой в целом я занимаюсь с 2006 года, а мобильной разработкой с 2014, писал приложения сам, руководил командами мобильных разработчиков, выступал на профильных конференциях, таких, как AppsConf, Mobius итд, митапах iOS разработчиков CocoaHeads, писал статьи на Хабр. В числе прочего я руковожу мобильной платформой в одной из пожалуй самых известных онлайн-школ английского языка.
Зная про мой интерес к мобильной разработке и то, что я периодически ищу в свои команды мобильных разработчиков, тестировщиков и дизайнеров, по несколько раз в год ко мне с вопросом приходят друзья и знакомые, которые хотят запустить мобильные приложения. Кто-то за рекомендацией конкретных исполнителей, кто-то прицениться, кто-то за советом по технической части.
Здесь я собрал советы по экономии ресурсов и оптимизации затрат при разработке мобильных приложений, которые я обычно даю бизнесу. Если вас интересуют более глубокие технические моменты по оптимизации процессов разработки, не ищите их в этой статье, посмотрите запись митапа, где я делал доклад на эту тему для технических менеджеров.
1. Самая большая экономия – не делать мобильное приложение до момента, пока вы будете уверены, что продукт/услуга востребованы и что мобильное приложение действительно необходимо.
Если вы только проверяете гипотезу о необходимости вашего продукта или услуги, начните с тех площадок, на которых ваша аудитория уже есть. К примеру, можно сделать мини-приложение в ВК или бот в Телеграм.
Таким образом, вы:
- не будете тратить время/деньги на дизайн и разработку,
- максимально упростите регистрацию/вход,
- снимите вопросы про дистрибуцию приложений через App Store и Google Play,
- сделаете максимально простой способ подключения – пользователю не нужно скачивать приложение из сторов, а потом искать его иконку среди многих десятков других на телефоне.
Возможно, сэкономленные в этом случае деньги и время позволят сделать ваши предложения дешевле для клиентов.
К слову, в Китае подход с мини-апами крайне востребован, об этом хорошо написала команда Додо Пиццы на хабре. В момент, когда продукт ориентирован только на Россию, сделать мини-приложение в ВК кажется вполне разумно, учитывая, что сейчас в эту соцсеть, как и в Телеграм приходит все больше людей.
2. Если приложение вам все-таки нужно, возможно, для вашего бизнеса есть готовые приложения, которые можно взять по подписке. К примеру, у вас небольшая сеть кафе, салонов красоты, фитнес-клубов (интернет-магазин, мероприятие итд). Для таких кейсов уже есть готовые шаблонные приложения, которые можно заполнить своим контентом и айдентикой. Вы быстро получаете готовое приложение под ключ. При этом там скорее всего будет множество готовых модулей (программы лояльности, аналитика итд) и интеграций.
Когда будете выбирать шаблонное приложение, рекомендую найти несколько приложений, сделанных на этих шаблонах, и сделать 2 вещи. Во-первых, попробовать их функционал как пользователь, пройти основные сценарии. Во-вторых, пообщаться с представителями компаний, которые уже используют такие приложения, спросить насколько они довольны.
3. Используйте в самих приложениях вместо нативных экранов WebView, в случаях, когда:
- на экран заходят не очень часто,
- у экрана очень сложная верстка,
- внешний вид и содержимое экрана часто меняются.
В этих случаях UX пользователя не сильно пострадает, а вы сможете дешевле и быстрее вносить изменения, которые сразу будут появляться во всех версиях приложения.
4. Расширяйте функционал готовыми модулями и SDK. Если вы понимаете, что в приложении нужна форма сбора обратной связи, оплата через Apple Pay или банковской картой, чат со службой поддержки или сторисы с новостями и акциями итд, не обязательно реализовывать этот функционал своими силами. Вы можете взять готовое SDK, которое внедряется в имеющееся мобильное приложение. Модель оплаты может быть разной, но чаще привязана к размеру аудитории приложения.
Примеры:
- Сторис от https://storyly. io
- Чаты от https://sendbird. com/features/chat-messaging/sdk
- Опросы от https://survicate.com/
5. Детально проектируйте интерфейсы приложений до передачи в разработку, проверяйте их не мышкой в браузере, а именно пальцами на телефоне, например через такие инструменты прототипирования, как Figma Mirror. Покажите их разработчикам и пользователям, соберите обратную связь, внесите правки в макет, а уже потом запускайте разработку. Это гораздо дешевле и быстрее, чем сделать приложения по макету на обе платформы, а потом переделывать.
6. Если есть возможность, не разрабатывайте приложение на обе платформы параллельно. Поймите, на какой из платформ большая часть вашей аудитории или наиболее платежеспособная, начните с нее. Разрабатывать приложения для второй платформы будет значительно быстрее, имея перед глазами работающее приложение для второй платформы и бэкенд.
7. Заложите в приложение механизм принудительного обновления Force Update. Приложения отличаются от сайтов тем, что трудно найти пользователя версии сайта, вышедшей год назад, но с приложениями такое случается постоянно – пользователи не торопятся обновлять версии скачанных приложений. Процесс раскатки новых фич и фиксов багов растягивается на недели и месяцы, бэкенд в это время вынужден поддерживать несколько версий API. Если у вас будет возможность удаленно поднять минимальную версию приложения, это может сэкономить массу времени и денег. О том, как реализовать этот механизм я писал на хабре. Помните, что Force Update, как стоп-кран в поезде – он нужен на экстренный случай, а не при каждой остановке, иначе пользователям надоест постоянно обновляться.
8. Используйте кросс-платформенные фреймворки, чтобы написать приложение 1 раз на обе платформы. Речь идет про такие технологии, как Flutter, React Native, Xamarin итд. Вы вряд ли создадите с их помощью конкурентов Instagram, TikTok и Facebook, но если ваше приложение не претендует на то, чтобы пользователь находился в нем несколько часов в день, вы точно сможете выпустить на них полностью работающие решения. Многие из приложений, которые вы используете, написаны с помощью данных технологий и вы об этом можете даже не знать.
Лично мой фаворит тут Flutter, по опыту скажу, что он достаточно прост и стабилен. На Android разницу будет заменить сложно, но в iOS пристальный взгляд может заметить небольшие отличия от нативного приложения. Пользователям в большинстве случаев это неважно. Все больше компаний выпускают приложения на Flutter, посмотрите на Medium, VC и Хабре статьи со словом flutter, чтобы увидеть примеры.
9. Привлекайте в консультанты и ревьюверы опытных разработчиков/тимлидов. Скорее всего, вам сложно будет конкурировать за подобных специалистов на полную ставку с крупными компаниями, в которых они работают. К тому же, вам будет сложно удержать их. Есть специальные сайты, где опытные разработчики предлагают свои услуги в роли ревьюверов и менторов. От такого сотрудничества могут выиграть все: вы получите технически надежный и развиваемый продукт, эксперт – небольшую подработку и глоток свежего воздуха, а команда разработки – опытного наставника, у которого можно учиться.
10. Объясните разработке требования к вашему продукту и ваши приоритеты. Попросите повторить, как они поняли. Не стесняйтесь периодически напоминать и информировать об изменениях. Для разработчика далеко не всегда очевидно, что сейчас важнее продукту – цена, скорость или качество, а чем вы готовы жертвовать. Проговорите это явно, иначе есть риск, что вы ждёте быстрых итераций и крупных переделок, а разработчик делает решения с заделом на стабильность и масштабирование, фрустрирует от необходимости частых переделок.
Большое значение имеет и опыт разработчиков. К примеру, если разработчик долгую часть карьеры работал в крупном энтерпрайзе, где не предъявляют большие требования к скорости или сочнейшему UX, но требуют высокого качества, будьте готовы, что по инерции вы можете получать отличный код с хорошим тестовый покрытием, но редкие релизы и сомнительного качества UX.
В приведенных советах нет каких-то откровений, но для тех, кто только собирается связаться с мобильной разработкой или делает в этом направлении первые шаги, может быть большая польза и экономия. Поделитесь своим опытом и советами по оптимизациям в мобильной разработке в комментариях.