Релиз приложения: кто, что и сколько

В конце июля 2021 года трудно было пропустить новости о запуске ракеты-носителя «Протон-М». Носитель понёс обитателям МКС (международной космической станции) модуль «Наука» с необходимыми штуками на борту. «Науку» строили около 20 лет, несколько раз планировали и переносили запуск, а когда запустили — столкнулись с нештатной ситуацией. У модуля включились двигатели, и он начал вращаться вокруг своей оси. К счастью, никто не пострадал. Модуль достиг цели и пристыковался к МКС, а космонавты получили дополнительную каюту, солнечные батареи и вторую уборную.

При чём здесь космос? Да в общем ни при чём. Но эта аналогия поможет понять, что такое разработка приложения и его последующий релиз в магазины приложений (далее — «сторы», от слова store).

Что такое релиз?

Релиз — это как запуск ракеты-носителя с многофункциональным модулем. История ракеты началась в 1960-х, и работа над её модернизацией продолжается по сей день. Модуль строили 20 лет — и похоже, ещё есть над чем работать. Полагать, что эти сложнейшие разработки, над которыми работали поколения инженеров, можно запустить простым нажатием кнопки — как минимум легкомысленно. Запуск — сверхответственный процесс, к которому долго готовится вcя команда.

Схожие процессы — пусть и в меньшем масштабе — работают с программными продуктами, в том числе мобильными приложениями.

Разработка цифрового продукта требует месяцев кропотливого труда разработчиков, тестировщиков, дизайнеров, аналитиков и проджект-менеджера. А релиз проверяет готовый продукт этого труда на прочность на реальных пользователях.

Перед релизом вся команда переводится в режим готовности номер 1. Требуется максимальная концентрация и внимание. Аудитория может составлять миллионы пользователей, а продукт должен выполнять задачи пользователя и обеспечить позитивный пользовательский опыт.

Чтобы продукт справлялся с этими функциями, мало его выпустить. Его нужно поддерживать и улучшать. Вся жизнь здорового приложения — с первого выпуска и через каждое улучшение — измеряется релизами.

Рассказываем, какие виды релизов существуют, что у каждого «под капотом» и кто над этим работает.

Виды релизов

1. Плановые.

Название говорит само за себя. Даты (или диапазон дат) плановых релизов зафиксированы в плане проекта. К ним готовятся заранее.

1_1. Первый запуск.

В сторы выпускают первую стабильную версию приложения. Процессы различаются в зависимости от того, в какой магазин загружается приложение. Но есть общие процедуры, которые не обойти ни в App Store, ни в Google Play.

• Регистрация аккаунта разработчика

В App Store можно зарегистрироваться как разработчик или как компания. Во втором случае необходимы D-U-N-S number организации и примерно 20 дней. В Google Play эта процедура имеет только один сценарий и занимает как правило не более дня.

На этом этапе как правило происходят основные потери времени. Опытный релиз- или проджект-менеджер не спотыкается на вопросах вроде где взять D-U-N-S или кто должен отправить заявку на его присвоение в Interfax, представляющий D-U-N-S в России.

• Предрелизное тестирование

Разумеется, сам процесс разработки предполагает регулярное тестирование каждой фичи. А зрелые продуктовые команды используют подход TDD (test driven development) — его суть в том, что автотест, определяющий требования к коду фичи, пишется раньше, чем сам код фичи. Однако перед выпуском продукт ещё раз тестируют целиком.

• Сборка приложения

Это процесс получения продукта из исходного кода. Чаще всего включает компиляцию исходного кода и сборку приложения. В результате мы получаем:

— Для Google Play: App Bundle — файл в формате .aab.

— Для App Store: билд — файл в формате .ipa.

Приложение подписывают специальными сертификатами (ключами) — они подтверждают, что приложение разработано именно вами и не позволяют кому-то ещё вносить в него изменения. Кстати, если разработка ведётся на заказ, то сертификат должен принадлежать компании-заказчику.

• ‍Подготовка маркетингового контента

Для выпуска приложения готовят краткое и развернутое описание, скриншоты, свойства версии, политику конфиденциальности и — опционально — видеоролик. Кстати, Google Play выше ранжирует приложения с промороликом в описании.

Контент нужно перевести на все языки, которые поддерживает приложение. Если приложение рассчитано на пользователей из Британии, Франции и Германии и локализовано на соответствующие языки, потребуется три комплекта материалов — на английском, французском и немецком. Это заметно помогает дистрибуции приложения, да и просто считается хорошим тоном.

Чтобы пользователи легче находили приложение, при подготовке маркетингового контента применяют техники продвижения приложений в сторах (App Store Optimization, ASO).

• ‍Загрузка сборки на ревью

Google говорит, что обзор приложения обычно занимает несколько дней, но может занять и семь дней, и больше. На Reddit есть сообщения о том, что приложение находилось в статусе ревью около 25 дней.

В App Store 90% заявок на ревью рассматриваются в течение 24-48 часов. Однако некоторые приложения могут потребовать дополнительного времени на рассмотрение. Кроме того, в течение года бывают периоды, когда объём заявок выше среднего. Это приводит к задержкам в рассмотрении.

Если плановая дата релиза поджимает — можно попробовать написать письмо модераторам сторов. Это не гарантирует, но может помочь с ускоренным ревью.

С момента загрузки вся команда находится в состоянии полной готовности. Приложение могут отклонить и вернуть на доработку — это называется реджектом. Есть миллион причин, по которым приложение может быть отклонено, и лишь часть из них описаны в официальной документации магазинов.

• Тестирование на обратную совместимость

Новая версия приложения должна сохранить пользовательские данные, созданные в предыдущей версии. Убедиться в этом помогает тестирование обратной совместимости. Если сервис не работает вовсе или пользователь утратил что-то важное — ценность новой фичи, ради которой вы запустили обновление, стремится к нулю. Стабильно работающий сервис гораздо ценнее, чем любая новая фича.

• ‍Пострелизное тестирование

Хорошая практика — сразу после первого релиза скачать приложение и прогнать основные пользовательские сценарии. И нет, предрелизное тестирование не отменяет пострелизного. Каким бы дотошным ни было тестирование перед запуском — на этом этапе есть шанс заметить ошибку и исправить её по горячим следам.

1_2. Релизы-обновления

Показатель развития продукта — регулярные обновления приложения. Пользователь видит, что разработчик продолжает работать над продуктом, прислушивается к отзывам и делает его лучше.

Обновление — повод напомнить о приложении, а значит, стимулировать активность пользователя.

Нет однозначных рекомендаций о том, как часто следует выпускать обновления. В конечном счёте если нечего показать/сказать — то обновление не несёт ценности. Выпускать апдейт ради апдейта бессмысленно.

С другой стороны мы все видели обновления с комментарием разработчика типа minor bug fixes. Это тоже хорошо. Даже если исправлена ошибка, которую увидел один-единственный пользователь — об этом можно и нужно сказать. И даже о небольших улучшениях лучше рассказать подробно, а не отделываться дежурной формулировкой.

Хорошо, если приложение обновляется каждые 2-4 недели — это не даёт аудитории забыть о продукте. Правда, с учётом трудозатрат, которые требует каждый релиз, это не всегда возможно. Кроме того, выпуская обновление, стоит помнить, что дополнительный трафик на устройстве. Это может быть особенно чувствительно, если ваше приложение прилично весит.

Каждое обновление — тоже релиз, хотя и не такой масштабный, как первый. Как и при первом релизе продукта, к релизу-обновлению требуются направленные усилия всей команды.

Состав релиз-команды может отличаться в зависимости от продукта, но в ней не обойтись без разработчиков, тестировщиков и проектного менеджера. Кто-то должен подготовить release notes — это текст, который поясняет, что именно пользователь получит, скачав обновление. Если обновления затронули визуальную составляющую продукта — дизайнер готовит актуальные скриншоты.

Как и в случае с первым выпуском приложения, сборка с обновлением проходит ревью со стороны App Store и Google Play. Проверка может занимать от пары часов до нескольких дней. Всё это время релиз-команда находится в режиме повышенной готовности на случай реджекта, чтобы быстро исправить проблему и вновь загрузить обновление на ревью.

2. Внеплановые

Бывают и такие. Цифровые продукты существуют в условиях неопределённости, а значит, должны быстро реагировать на изменения. И порой это происходит не по расписанию.

Почему приходится обновлять приложения вне плана? Вот лишь несколько примеров:

• Ребрендинг/рестайлинг/редизайн. Изменение визуальных элементов бренда затрагивает все точки касания с клиентом — в том числе и приложение. Иногда достаточно заменить только логотип, а бывает так, что меняется вся визуальная концепция приложения. Впрочем, к такому обычно готовятся заранее.
  ‍
• Программный сбой. Если в приложении что-то сломалось — команда срочно реагирует и выкатывает исправленную версию. Такие обновления часто называют хотфиксами или экстра-хотфиксами.
  ‍
• Изменения законодательных норм. Например, в приложении для доставки еды, может быть опция доставки алкоголя. Законодательство в регионе или стране меняется, и требования к продаже алкоголя через мобильные приложения становятся более строгими. Могут поменяться правила лицензирования или налогообложения, ограничения по возрасту или часам продажи, Придётся обновить мобильное приложение — его функциональность, пользовательский интерфейс, уведомления и документацию.

Каждое внеплановое обновление — тоже релиз, и требует работы команды в том же составе — аналитика, дизайнера, разработчиков, тестировщика, проектного менеджера, специалиста по ASO или контент-менеджера.

2_1. Внеплановые во внеурочное время.

И такое случается — релиз необходимо сделать в нерабочее время. Это крайне нежелательный, но возможный сценарий. Классика жанра — поломка в приложении, которую в авральном режиме устраняют к утру, когда в приложение придёт основная масса пользователей.

TL; DR

1. Релиз — важная часть процесса разработки, и не сводится к «нажатию соответствующей кнопки».

2. В релизе участвует практически вся команда разработки, а иногда и дополнительные сотрудники — например, маркетолог.

3. Процедура релиза требует знания массы правил и нюансов. Чем более опытный сотрудник руководит процессом — тем больше шансов, что релиз пройдёт гладко.

4. Релиз — не точка, а запятая. После выпуска приложения или обновления приложение проходит ревью на стороне магазинов и может получить реджект. Вновь нужны усилия команды, чтобы быстро исправить причины реджекта и отправить на проверку новую версию продукта.