Если не крутить педали, рано или поздно велосипед упадет.

Зачем мобильному приложению техподдержка

Разделим жизненный цикл мобильного приложения на три обширных этапа:

1. Подготовка. Идея, исследования конкурентов и пользователей, проверка жизнеспособности идеи, разработка схем, мокапов, первых прототипов.
2. Разработка. Самая затратная и важная часть.
3. Поддержка и развитие. После релиза жизнь продукта только начинается.

До недавнего времени и заказчики, и разработчики основное внимание уделяли лишь разработке продукта. Сегодня конкурентная среда диктует другие правила: этап подготовки в крупных проектах растягивается на месяцы, так как вкладывать бюджет в сырые идеи слишком накладно.
Так же накладно оставить продукт неизменным после релиза. Продукт должен жить и меняться вместе со средой, отвечать на угрозы, приспосабливаться к изменениям устройств и операционных систем, реагировать на отклики пользователей о его удобстве и функциональности. Именно для этого необходима техподдержка мобильного приложения разработчиками и бизнес-аналитиками. Они помогают правильно крутить педали велосипеда.

Какая поддержка нужна мобильному приложению после релиза

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

1. Приложению нужно помочь познакомиться с первыми пользователями. В идеале стратегия продвижения разрабатывается заранее, до релиза. Приложения обитают в жестокой конкурентной среде, где успешные получаю все, а другие, лишь немногим уступающие первым, гибнут. Инструментов и каналов продвижения становится все больше, стратегии придумываются все изощренней. И затрагивают они не только “внешние” факторы, но могут потребовать и изменения самого приложения.

Ошибка: продвигать приложение бессистемно, не имея стратегии. К сожалению, времена дешевой и внезапной популярности приложений прошли.

2. Приложению нужно развитие. Да, вы все продумали на этапе подготовки к разработке продукта. Но любое исследование и экспертный опыт всего лишь гипотезы, до тех пор пока приложение не увидело свет. Лишь реальные пользователи покажут вам, успешна ли гипотеза. И если статистика приложения и отзывы пользователей показывают обратное, не стоит отчаиваться, это нормально. Нужно воспользоваться данными из статистики и “вылизать” приложение — функционал, юзабилити, способ монетизации и прочее. Процесс развития должен быть непрерывным. Не меняясь, продукт сдает позиции и постепенно умирает.

Ошибка: влюбляться в продукт. То, что вы выпустили, должно меняться, подстраиваясь под среду. Это нормально и другого пути создать идеальный продукт нет.

3. Приложению нужна техническая поддержка. С вашей стороны и со стороны технических профессионалов (Идеально, если это разработчики продукта, они знают его лучше всех. Но если вы недовольны сотрудничеством, то продукт можно передать на техподдержку в другую компанию). На вашей стороне будет осуществляться администрирование и общение с пользователями. Команда IT-партнера осуществит быстрое введение доработок и развитие функциональности, адаптацию под новые устройства и новые версии операционных систем.

Ошибка: забросить приложение после релиза и ждать прибыли. К сожалению, пока приложения не могут успешно функционировать без помощи человека. А любые гипотезы и идеи имеют срок годности, поэтому вводить и проверять их нужно в кратчайшие сроки. Промедление — потеря прибыли. Хорошо, если у вас будет технический партнер, который всегда на связи.

4. Приложению нужна защита. Не только от хакеров и вирусов, но и от обычных мошенников. Если приложение собирает данные пользователей, то вы обязаны поручиться за их безопасность. Если предусмотрен личный кабинет и программа лояльности, вы так же в ответе за бонусы пользователя. И если ими воспользуется кто-то другой, в глазах клиента виновным окажетесь вы. Обеспечить безопасность и работоспособность продукта помогут разработчики в рамках техподдержки.

Ошибка: забыть об информационной безопасности мобильного приложения. Не реагировать на угрозы безопасности, а узнавать об утечках и сбоях только из гневных отзывов пользователей.

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

Ошибка: позволять приложению съедать бюджет. Если это происходит, а цели не достигаются, нужно звать аналитиков и разработчиков на помощь.

Что нужно — понятно. Но как это реализовать на практике?

Эффективная техподдержка мобильного приложения или сайта

1. Для техподдержки нужен отдельный договор
   Вид техподдержки индивидуален и содержание договора выясняется на этапе согласования. В нем прописываются задачи, решаемые в рамках поддержки. Какие-то задачи могут выходить за рамки техподдержки, но такой договор даст вам уверенность в завтрашнем дне. Вы всегда сможете положиться на помощь технических профессионалов — они знают ваш продукт изнутри и сумеют быстро реагировать на задачи.
2. Гарантия и техподдержка — разные вещи
   Гарантия прописывается в основном договоре на разработку. Работы по гарантии — это исправления багов или доработка функционала по техническому заданию.
   Техподдержка выходит за рамки техзадания и требует отдельного документа с прописанными задачами, условиями, сроками реагирования. По сути, техподдержка — это срочное решение проблем, мешающих качественному функционированию цифрового продукта. Мы разделяем эти проблемы на три категории:
   Аварийный уровень. Это форс-мажорные ситуации, которые решаются прежде всего. Например, пользователи не могут отправить заказ, зарегистрироваться или в принципе войти в приложение.
   Средний уровень. Например, ошибки в интерфейсе, которые критически не влияют на возможность осуществить заказ или другое важное действие. Такие проблемы обычно решаются в течение рабочего дня, если нет аварийных ситуаций.
   Низкий уровень. Например, незначительные ошибки в функциях и экранах, не относящихся к заказу или другому критически важному функционалу сервиса.
3. Вид оплаты можно подобрать индивидуально
   Крупные высоконагруженные проекты, для которых критичны вопросы безопасности, нуждаются в ежедневном контроле, а задач хватает на существенную загрузку команды. Таким клиентам удобна ежемесячная “абонентская плата”. Другие же менее крупные проекты не требуют постоянного мониторинга. Для таких клиентов мы предусмотрели оплату “по факту”: возможные задачи прописываются заранее в договоре, запуск работ по задаче и оплата происходит по мере необходимости. Стоимость услуг рассчитывается исходя из часов, потраченных на решение задачи.
4. С договором техподдержки быстрее решаются форс-мажорные ситуации
   Форс-мажор может стать причиной недоступности приложения или некоторых его функций для пользователей. А это влечет потерю прибыли. В договоре мы прописываем четкие условия решения форс-мажорных ситуаций: степени важности ситуаций и скорость реакции в разные дни и время суток. Такой регламент позволяет клиенту работать и спать спокойно.
5. После релиза разработчик не обязан поддерживать приложение, если договора на техподдержку нет
   Все доработки, что выходят за грань технического задания, — вне основного договора на разработку. Поэтому, если договора на поддержку нет, компания-разработчик, например, не обязана адаптировать приложение под новую версию операционной системы. Да, можно заключить дополнительный договор, но компания вправе отказать. Не всегда найдутся свободные руки на небольшую, но срочную задачу. Не всегда это выгодно. Поэтому мы советуем заключать договор на техподдержку любого более менее значимого проекта.

Развитие тоже может быть частью поддержки

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

Что в итоге

Неожиданно, но техподдержка — это не только про стабильность. А еще про последовательное (умное) развитие продукта. В нашей компании техподдержка часто перерастает в нечто большее, иногда в партнерство, иногда в долгосрочное сотрудничество. И продукты, над которыми мы работаем вместе с клиентами, становятся все более зрелыми, стабильными и прибыльными.

Совет один: не переставайте крутить педали!