В процессе разработки нашего приложения мы столкнулись с необходимостью синхронизации игрового процесса на разных устройствах пользователя. Приложение простое — сканворды на русском языке. Однако, как показал опыт, даже для простого приложения интенсивность разработки, если включать в неё исправление ошибок, после релиза убывает не так активно, как хотелось бы. График интенсивности для нашего приложения “Сканворды” схематично выглядит следующим образом (рис.1):
Рисунок 1 — Интенсивность разработки в зависимости от времени
I этап — инициация. На этом этапе у нас происходил постепенный “набор высоты”, когда ещё точно не ясно, что и как нужно программировать. У нас он занял несколько недель.
II этап — плановая разработка. Время, когда получается планировать спринты длительностью в неделю. На этом этапе всё достаточно понятно. В нашем случае этап длился около 2-х месяцев.
III этап — пострелизный. Этап берёт своё начало в день, точнее, в ночь релиза, когда звонят знакомые с вопросом, почему не работает приложение. Наш вывод из этих ночных звонков: релиз в пятницу вечером — это плохая практика. Третий этап хоть и пульсирующий из-за выявления новых багов, но колеблющийся на уровне “полочки” второго этапа. Дело в том, что процесс генерации идей на тему нового функционала в нашей команде не закончился после релиза: звуки, вторая клавиатура, анекдоты, новый алгоритм перехода на следующее слово и многое другое было придумано уже после даты публикации рабочей версии. К концу третьего этапа мы реализовали примерно 60 % того, что напридумывали, после чего нового функционала в составе недельных спринтов становилось всё меньше. Мы всё больше внимания уделяли ошибкам на разных устройствах и в разных ситуациях. Приведу один нетривиальный для нас пример. Один из наших постоянных пользователей, который активно пишет отзывы на google play, утверждал, что приложение не работает без интернета. Каждый из нас по несколько раз закачал выпуски сканворов, отключил wi-fi, отключил мобильный интеренет, запустил сканворды — всё работает. Что думать? Ситуация, наверное, ещё долго бы оставалась в таком состоянии, если бы у одного из нас в одни прекрасные выходные не кончились деньги на телефоне, и вот тогда оказалось, что приложение действительно виснет на экране загрузки! Вывод, сделанный нами: к отзывам своих пользователей нужно относиться с предельной внимательностью и доверием.
Деление между III и IV этапами условное, критерием служит внутреннее ощущение команды, что пора “отшлифовать” приложение. Четвёртый этап менее интенсивный, но со вспышками при выявлении багов. В этот период была возможность подумать над версией 3.0, ключевая характеристика которой — это синхронизация игрового процесса на разных устройствах пользователя, о чём писали в отзывах практически со дня релиза.
В бета-тестировании версии 3.0 мы столкнулись со сложностью поиска тестировщиков. Нам не удалось найти несколько десятков сторонних людей. Мы даже пытались привлечь пользователей, написавших нам отзывы на google play через предложение участвовать в закрытом тестировании, но никто не отозвался. Пришло ощущение ступора: новая версия готова, но выкатить мы её не можем, потому что она не протестирована, а протестировать тоже не можем. Проходит одна неделя, за ней вторая, а мы на том же месте. Нужно было что-то делать, и нами принято следующее решение: выкатывать версию 3.0, но предупреждать пользователя о том, что авторизация и синхронизация работает в тестовом режиме (рис. 2):
Рисунок 2 — Информирование пользователя о тестовом режиме авторизации
Решение рискованное, так как при выявлении критичных багов исправления нужно будет делать не только в функционале, но и писать обработки пользовательской информации, накопленной в базе данных. Приводим график активных установок из консоли google play на дату написания этой статьи, чтобы в её продолжении сделать выводы о принятом решении (рис.3):
Было бы интересно услышать в комментариях к этой статье альтернативные варианты того, как можно поступить в подобной ситуации.