Если долго создавать цифровой продукт для смартфонов, можно отстать от рынка. В мире, где часто обновляются операционные системы, а каждые несколько месяцев появляются новые устройства, слишком долгий цикл производства может сыграть против вас. Именно поэтому в релиз выпускают простые приложения с минимальным набором функций.
Залог успешности — постоянное развитие приложения и регулярный сбор обратной связи. Крутые приложения не создаются сразу, они становятся таковыми со временем. После запуска команда разработки должна поддерживать приложение — выпускать апдейты, проверять на соответствие требованиям маркетплейсов и операционных систем, исправлять баги и добавлять новые фичи.
В поддержку приложения после выхода на рынок входит регулярная диагностика — так разработчики узнают о багах мобильного приложения. Второй вариант, когда сами пользователи отправляют отчёт об ошибке.
Пост-релизные ошибки неизбежны, даже если во время разработки у специалистов не было проблем, а сам процесс создания был идеальным. Это не значит, что QA-инженеры плохо работали. Их задача состояла в сборе информации об ошибках, классификации и присвоении им приоритета в зависимости от разных факторов. Например, если ошибки мешают работе приложения, то их определяют как «критические» и решают в первую очередь.
Пример критического бага — это ошибка, которая не даёт пользователям совершить целевое действие, например, построить маршрут, оплатить заказ или отправить заявку. Менее серьёзные ошибки, которые не слишком влияют на приложение, попадают в бэклог и исправляются по мере того, как появляется возможность.
Очерёдность исправления ошибок и их место в бэклоге — важный параметр. Если разработчики будут исправлять каждую мелкую ошибку, приложение подорожает в несколько раз, а релиз будет возможен через пару лет. Все ИТ-команды стараются выпускать цифровые продукты без критических багов, когда идея ещё популярна, а аудитория нуждается в них наиболее сильно.
Масштабирование необходимо, если количество юзеров резко выросло. Например, до релиза бизнес ориентировался на 100 тысяч новых пользователей в месяц. Но продукт оказался слишком востребованным, и пользователей стало миллион. От того, как приложение будет расти и какие функции будут добавляться, зависит и финальная стоимость проекта.
Чаще всего масштабируются стартапы. Это объяснимо, сначала на рынок выходит MVP с ограниченным набором функций, чтобы протестировать идею на целевой аудитории. После того как реальные пользователи дали обратную связь, а команда нашла ошибки и точки роста, MVP постепенно превращают в полномасштабный продукт.
AppStore и GooglePlay регулярно обновляют требования к мобильным приложениям, чтобы обезопасить пользователей. Машинный алгоритм и разработчики вручную проверяют, как приложения хранят и передают данные. Если обнаруживается утечка, то владельца приложения уведомляют и обязывают исправить ошибку.
Например, AppStore даёт 30 дней, чтобы выпустить улучшенную версию приложения. Если разработчики проигнорируют предупреждение, пропустят сроки или вовсе откажутся от нового релиза, онлайн-магазин временно скроет приложение от пользователей. Из бана можно выйти только после загрузки обновления.
Как часто выпускать обновления
Мобильные приложение нужно обновлять, чтобы привлекать новых пользователей и оставаться актуальными на рынке. Нет единого правильного ответа, как часто нужно выпускать новые версии. Некоторые приложения рационально обновлять каждую неделю, а для других можно выпускать апдейты раз в несколько месяцев — всё зависит от особенностей приложения.
От частоты обновлений зависит стоимость поддержки приложения, а значит и всего проекта. Поэтому новые версии нужно заложить в общий бюджет ещё на этапе планирования.
Моментальное реагирование. Применяется, если возник форс-мажор в работе мобильного приложения. Например, приложение стало недоступным или у пользователя не работают определённые функции. Или если данные пользователя похитили и информация утекла в сеть.
Техподдержка автоматически отслеживает ключевые метрики работоспособности мобильного приложения. Если возникла нештатная ситуация, сотрудники техподдержки сразу же блокируют все действия, которые нарушают процесс работы, и исправляют поломку.
Поддержка работоспособности. В долгосрочных проектах всегда есть доработки и нововведения, над которыми должна постоянно работать команда специалистов. Доработки часто нужны, когда обновляются устройства или ОС, есть сбои в работе, у приложения много негативных отзывов от аудитории о функциональности.
Доработка функциональности. К команде техподдержки могут обратиться, чтобы получить разовые услуги по доработке согласно техническому заданию или получить постоянные услуги по доработке согласно договору по абонентскому обслуживанию.
Техническая поддержка проекта после выпуска — обязательная услуга для владельцев приложений. Она необходима, чтобы оставаться в тренде, делать полезный и актуальный продукт, удерживать аудиторию и улучшать пользовательский опыт. Без пост-релизной поддержки невозможно поддерживать новые тенденции и быть востребованным у пользователя.