Connect with us

Разработка

Как получить мобильное приложение ОЧЕНЬ быстро: кейс Tutu.ru

От 6 месяцев до года — таков средний срок создания мобильного приложения: от составления ТЗ до выпуска приложения в магазин. Мы расскажем о том, как Tutu.ru и 65apps удалось сделать приложение за три недели до новогоднего ажиотажа.

65apps

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

/

     
     

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

Решение объединить все и выпустить единое приложение было окончательно принято в октябре и до самого пика поездок и покупок билетов в декабре оставался всего месяц. Можно ли за это время выпустить полноценное рабочее приложение? Да, если работать правильно и основываться на правильной архитектуре и управлении проектом.

Постановка задачи

У заказчика были «продуктовые» приложения для каждого вида транспорта. И хотя у них существовал свой индивидуальный функционал, по структуре и алгоритмам работы они были схожи.

До начала работы над новым приложением мы уже длительное время работали с Tutu.ru —  делали приложение «Автобусы».

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

Задача по созданию приложения к нам поступила в конце октября и срок реализации от получения первых вводных до сдачи проекта на приемку не должен был превысить месяца. Мы управились за три календарные недели — первый релиз состоялся 23 ноября 2017.

Первый релиз Единого приложения

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

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

Экраны рейсов с детализированной информацией о каждом рейсе:

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

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

В виде нативных экранов также были реализованы экраны помощи (FAQ и контакты), адаптированные под три вида транспорта, а экран дополнительной информации («Другое») был реализован ссылками на другие приложения.

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

Разработка

Какие этапы в разработке мы прошли:

На основе «Автобусов» мы создали единую архитектуру нового проекта с возможностью в дальнейшем поддерживать развитие всех приложений сразу.

До реализации проекта, в приложениях использовался разный подход к проектированию архитектуры, и если ЖД и «Автобусы» были во многом схожи, то в Авиа был реализован совершенно иной подход. Необходимо было производить рефакторинг кода, чтобы обернуть его в единую архитектурную стилистику нового приложения.

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

Наконец, требовалось объединить и структурировать существующие данные для использования на единых новых экранах.

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

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

Модули

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

Личный кабинет

Личный кабинет у пользователя единый на все виды транспорта — наша задача была реализовать универсальный отдельный модуль авторизации, который в дальнейшем можно будет подключить во все приложения, включая единое и продуктовые по покупке билетов отдельно на Авиа, ЖД и «Автобус».

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

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

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

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

Логирование событий

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

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

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

  • Получить больший приоритет по сравнению с обычным сервисом, меньше шансов, что система убьет сервис данного модуля.
  • Увеличивает количество памяти для работы модуля, что позволяет минимизировать эти затраты для самого приложения.
  • При возникновении критических ошибок, приложение продолжает работать в штатном режиме.

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

Что позволило нам уложиться в срок

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

Готовая архитектура — у нас была готовая архитектура одного приложения (на основе «Автобусов»). Фактически, ее надо было расширить для нескольких видов транспорта — на основе одной нашей платформы мы объединили три разные кодовые базы в одну.

Мы не просто писали код, а привнесли в проект свою бизнес-экспертизу — наши разработчики активно участвовали в обсуждении функционала, с целью оптимизировать разработку и выпустить приложение в нужные сроки.

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

Собрать самую качественную команду — над проектом работало всего три разработчика и два тестировщика. Известное правило: «то, что один программист может сделать за месяц, два могут сделать за два» — сработало и для нас. Маленькая качественная команда, пусть и небольшого размера, работает быстрее и лучше, чем большая и неповоротливая.

Проблемы и их решения

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

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

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

Как компании-заказчику подготовиться к срочной разработке

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

Выводы

Новое приложение в Google Play скачали более 500 000 раз. Пользователи отлично приняли его, и оценка в магазине стремится к пяти баллам, растет количество продаж.

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

 

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

You must be logged in to post a comment Login

Leave a Reply

Новости

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

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

AppTractor

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

/

Автор:

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

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

Дизайн и прототипирование

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

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

AppTractor

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

/

Автор:

Дмитрий Нор, директор компании SkySoft

  

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

После того, как требования известны, мы приступает к созданию прототипа. В основном мы используем программу Balsamiq Mockups, так как в ней можно делать прототипы для веб-сайтов и мобильных приложений. Программа простая и очень удобная. И с помощью нее можно решить практически любые задачи по созданию прототипов. Иногда мы используем Axure RP. Выбор программы зависит от задач проекта и в основном он делается так: в чем удобнее, там и рисуем.

После того как прототип или прототипы (опять же зависит от сложности проекта и его задач) мы отдаем его на согласование клиенту и рассказываем, как потом все будет работать (если он сам не понимает). Если у клиента не возникает желания что-то переделать, то пускаем в дальнейшую работу, если возникает – переделываем и после утверждения пускаем в дальнейшую работу.

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

После того, как макет дизайна готов – мы отдаем на согласование клиенту. Если возникают правки – делаем, еще раз согласовываем и запускаем в дальнейшую работу.

Дина Мильштейн, руководитель отдела дизайна EastBanc Technologies

    

В нашей компании создание дизайна неотделимо от создания всего решения. Мы анализируем функции и задачи, которые решает мобильное приложение, кто будет им пользоваться. Главное понять смысл и логику работы будущего решения.

На старте проекта для каждого мобильного приложения мы вырабатываем дизайн-концепцию на 5-10 экранов и согласовываем с заказчиком.

Итак, мы договорились об основах, как будет выглядеть и работать мобильное приложение. В сказках всё кончается словами «Они поженились и жили долго и счастливо», а на деле тут-то и начинается самая большая и кропотливая работа. Также и у нас.

Прототипирование UI/UX — бумага и Sketch

Чтобы разобраться, как будет работать мобильное приложение, мы делаем первые наброски на бумаге, а потом переносим их в Sketch. Мы прошли путь от Photoshop к Sketch, эргономичной программы, сделанной для разработки интерфейсов. От Photoshop категорично не отказываемся, он идеально подходит для работы с растрами. Выбор инструмента всегда зависит от задачи. Всё должно быть уместным.

Нужен цифровой бренд-бук. Если его нет — надо создать

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

Иллюстрации в Illustrator

Мы делаем наши приложения «тёплыми», чтобы люди, работая с ними, испытывали не только удобство, но и теплые эмоции. Поэтому в случаях, когда это уместно, мы добавляем иллюстрации в наши приложения. Идеальным инструментом для создания иллюстраций, на наш взгляд, является программа Illustrator.

Интерактивный прототип — Invision

Когда логика и стилистика готовы, мы примеряем этот «костюм» на заказчика и представляем ему решение. Чтобы презентовать задуманное, используем анимированный прототип решения в Invision. Это повышает эффективность коммуникации как с заказчиком, так и с разработчиками.

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

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

Анимация и поведение — Flinto

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

Нарезка и передача в разработку — Zeplin

Дальше двигаемся итерациями: отрисовали, согласовали с заказчиком, отдали разработчикам в Zeplin. И так до финального релиза — методично и кропотливо трудимся над разделами в рамках согласованной концепции, сохраняя первоначальное качество.

Качественный результат гарантирован процессом

Мы щепетильно относимся к мелочам и фактам. Всё должно соответствовать задаче и выглядеть достоверным, чтобы заказчик сразу соотносил увиденное со своими рабочими процессами.

На каждом этапе разработки UI/UX от идеи до готового продукта мы последовательно фиксируем понятный, ограниченный и полностью проработанный элемент визуальной платформы. На рынке постоянно дорабатываются существующие и появляются новые инструменты. Главное держать в голове, зачем они нужны именно вам и какой именно результат вы планируете получить.

Евгения Горбунова, Finch

  

Мы уже 10 лет создаем приложения для крупных брендов вроде ТНТ, Спартака, ТВ-3, Столото. В нашей работе мы используем достаточно стандартный набор инструментов: Sketch, Zeplin, Sympli, Adobe Photoshop, Adobe Illustrator.

Для дизайна макетов в основном используем Sketch. Что касается самого процесса разработки дизайна, то тут всегда по-разному. Обычно мы работаем по алгоритму «бумага» → «прототип» → «дизайн». То есть наш дизайнер сперва тратит время на поиска решения на бумаге, затем начинает рисовать прототипы и макеты в Sketch и только после этого занимается дизайном. На последнем этапе, как правило, клиенты оставляют наибольшее количество правок: цвета не те, иконки другие, форму стоит поменять и т.д. Поэтому у нас бывали случаи, когда после финального дизайна, мы начинали все по новой и вновь ныряли с головой в проект, чтобы найти другое решение.

Ольга Костина, ведущий UI/UX дизайнер Seven Winds Studio

   

В нашей студии разработка дизайна мобильных приложений происходит следующим образом. На основе ТЗ создаётся прототип. До настоящего времени мы использовали для прототипирования NinjaMock, но планируем перейти на другую платформу. Сейчас присматриваемся к другим сервисам, среди которых Marvel, Invision и Flinto.

Дизайн интерфейса создаём в Sketch, и затем экспортируем готовые экраны в Zepelin для работы верстальщиков с ними. Иногда, наравне со Sketch, используем Figma. Этот сервис удобен тем, что над одним проектом могут работать несколько дизайнеров одновременно, и все изменения сохраняются в одном проекте, c которым впоследствии работают те, кто верстает экраны.

Юлия Гулюк, Grapheme

    

Раньше для проектирования и разработки интерфейсов мы использовали связку Sketch Zeppelin, а для демонстрации дизайна клиенту мы создавали интерактивные прототипы в Marvel или Invision. Когда макет дизайн был утвержден, мы прибегали к помощи моушн-дизайнера, чтобы упростить коммуникацию с верстальщиками. Он визуализировал идеи команды дизайнеров, чтобы разработчикам можно было наглядно объяснить, какие эффекты задумали дизайнеры и как их нужно реализовать. В общем, это был достаточно сложный процесс. Он требовал применения различных инструментов и отнимал много времени специалистов. Особенно много времени и сил уходило на коммуникацию. Но самым большим недостатком этого подхода была невозможность установить Sketch на любые другие платформы, кроме macOS.

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

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

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

Подкаст AppTractor: дизайн мобильных приложений

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

Новости

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

В новом дайджесте рассказы про Material Design, ухудшающие A/B тесты и, как обычно, улучшения продуктивности – теперь для соло-разработчиков.

AppTractor

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

/

Автор:

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

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

Медиа

Podlodka #60: Женщины в IT

Для юбилейного выпуска выбрали щекотливую тему – женщины в IT.

AppTractor

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

/

Автор:

Podlodka

Несмотря на довольную веселую подачу с шутками и прибаутками, авторы попытались разобраться в сложной теме дайверсити. Действительно ли есть такая проблема, а главное, что с этим всем делать, чтобы не перегнуть палку? Выпуск полон историй из жизни Кати Петровой из стартапа и Аси Кононовой из Яндекса, а также присыпан щепоткой микроагрессии от Егора и Стаса. Словарное слово выпуска: “цисгендер”.

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

Реклама

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

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

Вакансии

Популярное

X
X

Спасибо!

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