Connect with us

Разработка

4 этапа интенсивности при разработке простого мобильного приложения

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

AppTractor

Опубликовано

/

     
     

Команда GMSoft поделилась с нами своей историей разработки и ее этапами.

В процессе разработки нашего приложения мы столкнулись с необходимостью синхронизации игрового процесса на разных устройствах пользователя. Приложение простое – сканворды на русском языке. Однако, как показал опыт, даже для простого приложения интенсивность разработки, если включать в неё исправление ошибок, после релиза убывает не так активно, как хотелось бы. График интенсивности для нашего приложения “Сканворды” схематично выглядит следующим образом:

Интенсивность разработки в зависимости от времени

Интенсивность разработки в зависимости от времени

I этап: инициация

На этом этапе у нас происходил постепенный “набор высоты”, когда ещё точно не ясно, что и как нужно программировать. У нас он занял несколько недель.

II этап: плановая разработка

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

Сканворды
Сканворды
Разработчик: GMSoft+
Цена: Free

III этап: пострелизный

Этап берёт своё начало в день, точнее, в ночь релиза, когда звонят знакомые с вопросом, почему не работает приложение. Наш вывод из этих ночных звонков: релиз в пятницу вечером – это плохая практика. Третий этап хоть и пульсирующий из-за выявления новых багов, но колеблется на уровне “полочки” второго этапа. Дело в том, что процесс генерации идей на тему нового функционала в нашей команде не закончился после релиза: звуки, вторая клавиатура, анекдоты, новый алгоритм перехода на следующее слово и многое другое было придумано уже после даты публикации рабочей версии. К концу третьего этапа мы реализовали примерно 60% того, что напридумывали, после чего нового функционала в составе недельных спринтов становилось всё меньше. Мы всё больше внимания уделяли ошибкам на разных устройствах и в разных ситуациях.

Приведу один нетривиальный для нас пример. Один из наших постоянных пользователей, который активно пишет отзывы в Google Play, утверждал, что приложение не работает без интернета. Каждый из нас несколько раз закачивал выпуски сканворов, отключал wi-fi, отключал мобильный интеренет, запускал сканворды – всё работает. Что думать? Ситуация, наверное, ещё долго бы оставалась в таком состоянии, если бы у одного из нас в одни прекрасные выходные не кончились деньги на телефоне, и вот тогда оказалось, что приложение действительно виснет на экране загрузки! Вывод, сделанный нами: к отзывам своих пользователей нужно относиться с предельной внимательностью и доверием.

IV этап: шлифовка

Деление между III и IV этапами условное, критерием служит внутреннее ощущение команды, что пора “отшлифовать” приложение. Четвёртый этап менее интенсивный, но со вспышками при выявлении багов. В этот период была возможность подумать над версией 3.0, ключевая характеристика которой – это синхронизация игрового процесса на разных устройствах пользователя, о чём писали в отзывах практически со дня релиза.

В бета-тестировании версии 3.0 мы столкнулись со сложностью поиска тестировщиков. Нам не удалось найти несколько десятков сторонних людей. Мы даже пытались привлечь пользователей, написавших нам отзывы на Google Play через предложение участвовать в закрытом тестировании, но никто не отозвался. Пришло ощущение ступора: новая версия готова, но выкатить мы её не можем, потому что она не протестирована, а протестировать тоже не можем. Проходит одна неделя, за ней вторая, а мы на том же месте. Нужно было что-то делать, и нами было принято следующее решение: выкатывать версию 3.0, но предупреждать пользователя о том, что авторизация и синхронизация работает в тестовом режиме:

Информирование пользователя о тестовом режиме авторизации

Информирование пользователя о тестовом режиме авторизации

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

График установок на данный момент

Было бы интересно услышать в комментариях к этой статье альтернативные варианты того, как можно поступить в подобной ситуации.

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Медиа

Podlodka #79: Highload для начинающих

На этот раз Podlodka погрузилась в мир высоких нагрузок, и помог в этом Алексей Акулович, разработчик в команде backend инфраструктуры ВКонтакте.

AppTractor

Опубликовано

/

Автор:

Podlodka

Разобрались в том, когда начинается highload, с какими типовыми проблемами сталкиваются разработчики высоконагруженных систем и как с этим справляться. Варианты масштабирования, оптимизация работы с данными, шардирование, кэширование, мониторинги – тема масштабная, и разговор получился насыщенный. Не обещаем, что после выпуска вы сразу напишите свой первый production-ready высоконагруженный сервис, но понимание того, что происходит под капотом на бэкенде у крупных сервисов точно увеличится!

Комментарии
Продолжить чтение

Новости

Интересные материалы: 03.10

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

AppTractor

Опубликовано

/

Автор:

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

SDK

CleverPumpkin выпустила систему управления встроенными покупками CleverPay

Российская студия CleverPumpkin выпустила систему управления встроенными покупками для iOS и Android приложений. Она позволяет легко управлять платежными страницами, проводить сегментацию, валидацию, эксперименты с ценами.

AppTractor

Опубликовано

/

Автор:

CleverPay.io — это iOS/Android SDK с отдельной  административной частью для эффективной работы со встроенными покупками и подписками.

CleverPumpkin  объясняет, что с помощью этого инструмента (эксперименты с ценообразованием, триггерные скидки, распродажи с time-rush offer и пр.) в приложениях своих клиентов им удалось поднять конверсию с 3% до 7.5%, а чек — с $0.9 до $1.6.

CleverPay берет оплату каждый месяц по количеству активных пользователей приложения. От 0.8 до 0.6 центов – например, при MAU 11,000 пользователей использование SDK будет стоить 77 долларов в месяц.

Комментарии
Продолжить чтение

Новости

Интересные материалы: 02.10

Сегодня у нас квантовое программирование, курсы и открытые проекты, тренды и хаки.

AppTractor

Опубликовано

/

Автор:

Весь день мы собираем лучшие материалы о разработке и маркетинге технологий, стартапов, мобильных приложений и игр для iOS и Android из самых разных источников:

Комментарии
Продолжить чтение

Реклама

Наша рассылка

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.