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

Новости

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

У нас код полета на Луну, голосовые интерфейсы и эпические фейлы.

AppTractor

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

/

Автор:

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

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

Разработка

Сколько стоит разработка мобильного приложения?

Ждет нас покупка авто или ремонт холодильника, мы всегда спрашиваем о стоимости. И хотим услышать конкретную цифру. Наши клиенты тоже ожидают конкретики: «Разработка стоит X рублей». Но возможно ли такое?

Magora Systems

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

/

Автор:

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

Не можем говорить за всех, поэтому пишем о своем опыте и процессах оценки.

Уточнение

Чем точнее требования, тем меньше шанс, что вас поймут неправильно. И тем точнее получится оценка стоимости разработки. Поэтому мы планируем звонок, чтобы обсудить:

  • Бизнес. Спрашиваем: для кого делаем приложение, каковы потребности аудитории. Уточняем ключевые функции, желаемые сроки и бюджет. Выясняем, какую проблему решит приложение, и как поможет вам зарабатывать или экономить. Даем первичную оценку – можно ли вообще реализовать проект за выделенную сумму? Например, сделать сервис такси с нуля за 200 тысяч рублей просто невозможно.
  • Техническую сторону. Это про охват (влияет на архитектуру), объемы данных, платформы (iOS, Android, Web?), устройства (смартфоны, планшеты, гаджеты?), интеграцию с другими сервисами (Google Maps и др.) и т.д. А еще узнаем о предпочтениях в дизайне.

Анализ

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

Бывает, есть только идеи или общие описания. Бывает, есть какое-то ТЗ, но почти всегда данных недостаточно для оценки. Поэтому сначала мы и уточняем детали.

Если возможно, после разговора выделяем список функций, оцениваем каждую и подбиваем итог. Эту работу мы делаем бесплатно и отправляем КП через 1-3 рабочих дня. Предупреждаем, что стоимость может измениться. Фиксирована только та цена, которая указана в контракте.

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

Оценка стоимости разработки

Изучив входные данные, мы разделим объем работ на блоки и оценим. Если функций много и проект масштабный, предложим выделить и начать с MVP (базовой версии). Так вы быстрее выпустите продукт, чтобы проверить «в бою» и собрать отзывы пользователей.

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

Чтобы ускорить оценку, у нас есть список стандартных функций с установленными трудозатратами. Это не цифры «с потолка», а результат опыта и реальных проектов.

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

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

Что-то пошло не так…

Исследование Standish Group agency показало, что только 3% крупных проектов и около половины малых проходят по плану. Как же так?!

Разработчики не умеют оценивать?

Не совсем. Зачастую оценивают идеальный сценарий.

На деле получается, что сервер упал, документация устарела, разработчик заболел и надо подключить нового к проекту. Оценка растет с X часов до X+Y, а вместе с ней и стоимость. Кому это понравится?

А потом вы решаете добавить 2 функции. Но их не оценивали, надо пересчитывать. И да, цена вырастет.

Конечно, причины бывают разные, суть в том, что непредвиденные ситуации возникают в 97% проектов.

Зачем вообще оценивать?

Несмотря на все сказанное, вы:

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

Как получить максимум от оценки

  • Узнать ставку часа. Если ставкая высокая, а общая сумма – нет, что-то могли упустить при оценке.
  • Посмотреть, есть ли в команде тестировщики, аналитики, менеджеры. Чтобы сделать продукт, мало просто написать код.
  • Подробно описать проект. Дать ТЗ, макеты, схемы… Чем четче требования, тем точнее оценка.
  • Перепроверить, что оценили все функции, которые хотите получить в приложении.
Комментарии
Продолжить чтение

Разработка

DevOps на службе разработки ПО и Open Source

Всего за несколько лет разработка ПО превратилась в стратегический сектор ИТ-индустрии и экономики в целом, особенно во Франции, если верить недавно представленным планам широкомасштабной цифровизации. Карин Браун-Энно, управляющий директор Red Hat France, рассказала нам о роли DevOps в росте индустрии.

AppTractor

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

/

Автор:

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

Именно поэтому методология DevOps приобретает все более значимую роль, а ее использование в корпоративном секторе только растет. Истоки DevOps лежат в стремлении полностью преобразовать методы и процессы создания и развертывания приложений с целью кардинально повысить их динамичность и улучшить взаимодействие участников. DevOps (акроним от англ. development и operations – разработка и эксплуатация) предлагает разработчикам и специалистам по эксплуатации ИТ-систем быстрый и не требующий лишних усилий подход к запуску новых или улучшенных приложений, позволяющий делать это быстрее и эффективнее.

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

Почему структура команды разработки может вас замедлять

Почему DevOps?

Одна из главных причин возникновения концепции DevOps – это стремление к непрерывности, причем, непрерывности не только самих ИТ-сервисов, но и их совершенствования и доработки силами разработчиков и заказчиков в лице представителей бизнеса. Очевидно, что, сводя к минимуму перебои в работе ИТ-сервисов, можно автоматически максимизировать результаты работы компании. Однако, постоянно улучшая взаимодействие с пользователем (исправляя ошибки и запуская новые функции, которые тестируются в «боевых» условиях и при необходимости очень быстро дорабатываются), ИТ-подразделение также оказывает весомую поддержку своему предприятию, предоставляя ему средства для реализации и моделирования бизнес-стратегий, ориентируясь на поведение рынка, которое отслеживается в режиме близком к реальному времени.

Компания Puppet Labs отмечает, что 63% организаций, внедряющих DevOps, делают это для повышения качества развертывания, примерно такой же процент опрошенных хотят повысить частоту доставки, а 61% респондентов прежде всего фокусируются на улучшении качества процессов.

И это еще не все. Экспоненциальный рост обмена данными в результате пришествия интернета вещей вынуждает практически полностью пересмотреть модели обработки данных и связанные с этим приложения. Умные бытовые приборы и носимая электроника, финансовые услуги, автономные автомобили, системы управления воздушным движением, промышленность нового поколения (т.н. «Индустрия 4.0»), цифровое управление цепочками поставок – уже становятся обыденностью, охватывая значительную аудиторию за счет оптимизации фундаментальных процессов. Основываясь на новых методах обработки огромных объемов данных (структурированных и неструктурированных) и включая в себя расширенное и автоматизированное управление корпоративными процессами с охватом партнеров и клиентов, и эти модели интероперабельности, гибкости, сотрудничества, совместного использования и, прежде всего, инноваций лежат в основе модели Open Source, формирующей информационные системы следующего поколения.

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

Сегодня у нас есть все, чтобы вывести эволюционировавшие процессы сотрудничества в фазу зрелости. Решения IaaS («инфраструктура как услуга») и PaaS («платформа как услуга»), лежащие в основе модели DevOps, предлагают разработчикам гораздо больше гибкости и свободы, позволяют создавать новые приложения быстрее и с меньшими усилиями, облегчают развертывание приложений, устраняя барьеры и повышая управляемость. Переходя на язык конкретики, IaaS на основе OpenStack и PaaS с открытым кодом дают возможность быстро и итеративно разрабатывать облачно-ориентированные приложения, построенные на основе микросервисов (базовых компонентов приложений), объединенных в рамках супер-обновляемой модели, предоставляя все необходимые ресурсы и полностью отвечая целям DevOps.

Android Dev Подкаст. Выпуск 54. DevOps

С учетом выше сказанного неудивительно, что DevOps все чаще находит благодатную почву в последних ИТ-разработках, как инфраструктурных, так и ориентированных на обработку операционных данных, возникающих в ответ на стремление организаций повысить конкурентоспособность в погоне за лидерами отрасли. Став синонимом инновационной и ориентированной на сотрудничество методологии, DevOps отлично вписывается в мир Open Source, который активно осваивает и развивает облачные технологии, мобильные вычисления, большие данные и другие актуальные инновации.

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

Новости

Microsoft и National Geographic выделяют гранты на разработку экологического ИИ

Microsoft и National Geographic запускают программу грантов объемом в $1 млн для разработки искусственного интеллекта в сфере экологии.

AppTractor

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

/

Автор:

Как пишет “Хайтек”, в рамках проекта от 5 до 15 разработчиков получат финансирование, доступ к облачным инструментам Microsoft и инструментам для машинного обучения, а также консультации экспертов National Geographic Labs и National Geographic Explorer.

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

Компании смогут получить гранты до 8 октября 2018 года. Для работы с Microsoft и National Geographic разработчики должны работать в сфере изменения климата, сельском хозяйстве, загрязнении водоемов или вымирании различных видов животных. Любые нейросети, разработанные на деньги с грантов, должны быть с открытым исходным кодом, чтобы любой исследователь мог использовать эти инструменты.

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

Реклама

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

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

Вакансии

Популярное

X
X

Спасибо!

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