Приложений совсем без багов просто не бывает. Поэтому в любой команде разработки всегда есть QA-инженер или целый отдел тестирования — такие специалисты моделируют сценарии, как может использоваться приложение, и записывают все найденные баги в отчет. Потом приходят разработчики и делают «работу над ошибками». Но даже при таком раскладе баги на релизе будут, и даже автотесты от них не защитят.

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

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

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


Как мы помогаем бизнесу

Что делать, если по каким-то причинам команда разработчиков рассталась с проектом?

В 65apps мы берем на техподдержку не только приложения и сервисы, которые разработали сами, но и чужие. Почему? Потому что можем.

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

Наша техподдержка делится на два вида — базовый и расширенный.

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

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

У нас есть три тарифных плана.

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

Цена годового фикса зависит от разных показателей и рассчитывается индивидуально для каждого клиента. Обычно первый год жизни приложения самый рискованный, и саппорт в этот период обходится до 50% от стоимости разработки. Больше, когда речь идет о бэке и внешней интеграции. Если это не первый релиз, и приложение работает стабильно, цена может составлять около 20% от стоимости разработки.

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

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

Инцидентный пакет. Компания покупает пакет обращений. Клиент присылает запрос — мы исправляем баг (читай "любой дефект") и списываем одно обращение.

Стоимость пакета также рассчитывается индивидуально и зависит от сложности системы и количества привлекаемых специалистов.


В среднем минимальный пакет из 10 инцидентов стоит 300–400 тысяч рублей. Договор заключается на год, и если пакет заканчивается раньше, клиент может докупить нужное количество обращений.

Time & Material. Клиент вносит годовую сумму и сам решает, на что ее тратить — на исправление багов, добавление новых функций или на расширенные сервисы: мониторинг отзывов, работа с отзывами и многое другое. Деньги списываются позадачно.

Раз в месяц мы делаем отчеты о выполненных работах и выписку с информацией о балансе.

Минимальная сумма договора в среднем составляет 500 тысяч, но, как и в предыдущих случаях, рассчитывается индивидуально и зависит от объема приложения. Если деньги на балансе заканчиваются, то у клиента есть возможность пополнить баланс в рамках текущего договора.

Дополнительные услуги технической поддержки

В 65apps можно получить не только любой уровень техподдержки, но и дополнительные услуги. Саппорт — это одна часть огромной компании. Если клиент хочет улучшить интерфейс или добавить новые фичи, он просто пишет об этом своему менеджеру, и мы все согласовываем в рамках сервиса технической поддержки. То есть клиенту не нужно заключать новый договор и согласовывать скоуп задач — все вопросы мы решаем в режиме «одного окна».

Не стоит забывать об инструментах, которые работают на лояльность ваших клиентов: мониторинг отзывов в сторах и соцсетях, ответы и комментарии на них. Мы можем взять это на себя, чтобы внедрять улучшения, которых ждут пользователи. Все это входит в расширенные сервисы поддержки.

Итак, что нужно для того, чтобы передать проект на техподдержку в 65apps?

Какие проекты мы берем на саппорт

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

✔️ В первую очередь мы смотрим состав продукта на поддержку (iOS, Android, backend) и обсуждаем условия SLA.

✔️Когда мы принимаем на поддержку приложение от стороннего разработчика, то обязательно заглядываем ему под капот: проводим code review и test review программного продукта. А также смотрим документацию.

Вот необходимый перечень для безболезненной и максимально быстрой передачи проекта на саппорт:

1. Техническое задание или функциональные требования с указанием актуальности.
   
   
2. Исходники дизайна — карта экранов.
   
   
3. Актуальная спецификация API.
   
   
4. Исходники мобильного приложения: бэкенд и фронтенд.
   
   

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


Но если нет, работаем с тем, что есть. После сбора и анализа информации, мы считаем риски и предлагаем возможные форматы работы.