Мобильное приложение для туристов «Happy Camper»

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

App store

Клиент пришел к нам по рекомендации знакомого. Сам он уже действительно много лет в туристическом бизнесе в одном из самых туристически развитых городов России, поэтому на примере подобного приложения из другой страны увидел недостающую нишу у нас и решил ее поскорее закрыть. Как обычно, сначала была совместная работа над ФТТ. Даже это прошло не быстро, но главное, что мы очертили главные направления работы: нужно было мобильное приложение пользователя (туриста) и партнера, и личный кабинет партнера и администратора.

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

Наконец мы приступили к прототипу. Тут началось самое интересное — прототип плавно перетек в дизайн, потому что мы не сумели объяснить разницу. Спустя какое-то время мы уже практически завершали дизайн приложения, разработчики уже взяли его в работу (еще одна ошибка), как на стороне Заказчика появился новый сотрудник, которому поручили заниматься приложением и... он начал переделывать очень многое под себя. Да, некоторые предложения были очень толковыми, но некоторые вызывали бурное обсуждение у нашей команды. В итоге некоторые идеи мы отложили на новые этапы, потому что это не обсуждалось на этапе составления сметы, тем не менее, мы все-таки сделали уже очень много сверх технического задания (ошибка). В какой-то момент «хотелки» доросли до размеров нового, отдельного приложения.  

Тут мы сказали «стоп», давайте доделаем по техническому заданию (ТЗ), запустим первую версию и только потом берем в работу новые пожелания. На самом деле, этот запуск нужен был не только нам, но и заказчику — туристический сезон уже открылся, а приложение еще не было запущено даже в бета-версии.

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

Итак, какие уроки мы получили, проанализировав этот проект:

  1. Не экономить времени и сил на фиксации функциональных требований, прототипе и ТЗ. Все это должно быть детально проработано и с нашей стороны, и со стороны заказчика;
  2. Не начинать разработку, пока не утвержден дизайн. В противном случае это ведет к переделкам;

  3. Не делать новые доработки, пока не сделан функционал по ТЗ и не выпущен MVP. Всё остальное ждет. А иногда у нас остается время с оплаченной разработки — можем их потратить на доработки, которые появились в процессе работы;

  4. В целом, мы решили пересмотреть подходы к управлению проектами, разработке и т.д. Попробовали подход к разработке по методике SCRUM.