28 сентября

В середине 2020 года к нам обратился представитель инвестора - визионер проекта “Гараж”. На встрече, на которой присутствовали технические специалисты и консультанты, мы обсудили основную концепцию проекта. Это было в рамках бесплатной консультации. Если кратко, в приложении Гараж мы помогаем водителю найти нужное СТО, а собственники станций или сетей технического обслуживания получают трафик клиентов. В этой статье мы поделимся секретом - как можно сэкономить заказчику приложения порядка 60 000 долларов благодаря грамотному проектированию архитектуры и использованию специальной технологии для разработки мобильного приложения. Также будут освещены некоторые детали, которые нам позволено раскрывать. Эти детали помогут Вам лучше понять - что такое разработка приложений и как создать собственное приложение для бизнеса.

Итак, “Гараж” - это 2 приложения для двух типов пользователей - для водителей и для сотрудников станции технического обслуживания или сети таких станций.

С одной стороны приложение для водителей - на нём отображается карта, на которой отмечены все СТО в городе. Собственник авто может быстро найти подходящие услуги для своего авто. Для этого он добавляет свои автомобили, выбирает некоторые характеристики и интересующие его услуги, после чего записывается в календаре на удобное доступное время. Ему будут высланы уведомления, чтобы он не пропустил визит на обслуживание. На карте будет построен ближайший маршрут до СТО с учетом трафика.

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


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

Дизайн

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

Мобильные приложения

Мобильное приложение планировалось как на iOS, так и на Android. Важно понимать, что классический способ разработки мобильных приложений - так называемый “нейтивный” или “родной”. Он подразумевает, что Вы будете использовать отдельного специалиста по языку Java на андроид и языку Swift или Objective C для iOS. Это надёжный и проверенный способ, однако он достаточно дорогой, особенно если у Вас сложное клиент-серверное приложение со множеством экранов, не типовой схемой данных и сложными операциями поиска данных.

Нами был предложен альтернативный метод разработки - гибридный. Это когда Вы разрабатываете одно приложение сразу для платформы iOS и Android. ПО сути, Вы создаёте веб приложение, которое запускается в таком же виде, как родное. Внешне отличить эти приложения практически невозможно, они одинаково загружаются в сторы и маркеты, одинаково устанавливаются на рабочий стол с иконкой.

Но, конечно, есть нюансы. Во первых, есть некоторые функции, которые достаточно сложно портировать на гибридное приложение. А если приложение делает не опытный специалист и без поддержки опытного проектировщика - приложение будет глючить. Могут быть не сильно заметные “тормоза”, задержки при касании интерфейса - от 300мс до 1000. А могут быть полные отказы в функционировании некоторых виртуальных элементов. Нашей команде удалось портировать все необходимые встроенные функции для обеих операционных систем, обойти все трудности и создать интерфейсы, которые работают ровно на такой же скорости, как и классические мобильные приложения, никто не отличит его от нейтивного. При этом, благодаря грамотной архитектуре и принятию ключевых технических решений, мы смогли не просто сделать полностью функционирующее приложение, но и сделать его кратно-дешевле, чем разработка отдельных аппов. ПО нашим подсчётам мы сэкономили клиенту от 60 до 80 тысяч долларов (в зависимости от того по какому рейту считать).

Не будем лукавить, всё это получилось не на легке. Это был серьезный вызов, сложная работа, иногда - бессонные ночи. Было множество нюансов и проблем. И первые версии приложения имели различные не очень приятные грубости. Однако, проект разрабатывался в течении 4.5 месяцев (для такого приложения это очень короткий срок) и уже на 3-й месяц было отшлифовано 90% самых грубых “углов”.

К моменту сдачи приложения всё работало строго по ТЗ и у нас даже нашлось время выполнить дополнительные оплачиваемые работы а также добавить в проект приятные и удобные функции - бонусы, о которых на этапе составления ТЗ никто не подумал.

Подробно про функциональность приложений

Регистрация - пользователь мог получить доступ к картам после выбора языка, верификации телефонного номера и согласия с правилами сервиса.

Карта - была выбрана и интегрироана карта Google Maps. Не самое дешевое решение, в статье про приложение Интернет-город мы рассказывали про нюансы выбора карт. Но мы нуждались в некоторых функциях гугл карт, которые было легче купить и оплатить по тарифу, чем писать заново на основе бесплатных карт.

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

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

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

Запись по календарю - после выбора определенного СТО, производится бронирование. Логика бронирования - это всегда непростой алгоритм в почти любом приложении. Не будем и не можем вдаваться в детали.

Добавление авто - водители могут добавлять фото и базовые данные совего авто (ВИН, модель и т.д.). Всё это необходимо как для поиска актуальных СТО, так и для рекомендации самого подходящего.

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

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

Интеграция платёжных систем - для оплаты услуг мы рассматривали различные сервисы платежей. Для задач данного проекта подходящим оказался сервис Fondy. Мы внедрили его по схеме Б - это расширенная и не тривиальная схема, которая подразумевает внедрение через АПИ, а не стандартные простые формы\кнопки.

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

Административная панель

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

Проектирование архитектуры

Все детали под НДА

Написание ТЗ

Для проекта было разработано профессиональное техническое задание нашим бизнес-аналитиком. Все детали под НДА.

Организация командной работы

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

Сложности и вызовы

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

Было выделено достаточно мало времени на ТЗ, да и вообще на весь проект. Сроки проекта были ограничены некоторыми маркетинговыми стратегиями и дедлайнами.

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

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

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

Был ряд сложностей с тонкостями настройки интегрируемых сервисов. В частности на уровне технической поддержки сервисов (извечная проблема)

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

Отдельная история - это прохождение гайдлайнов. Другими словами, прохождение проверки при регистрации приложения в сторах. Для андроида эти гайдлайны были выполнены достаточно просто. А для iOS было множество проблем. Начиная с того, что платформа не хотела принимать наши средства за оплату аккаунта разработчика (без него невозможно залить приложение). И заканчивая огромным списком требований, которые необходимо внести в приложение для того, чтобы его одобрили. Это тянулось долгое время и потребовалась консультация и помощь iOS специалиста.


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

Развивай навык, формализуй опыт, создавай продукт, автоматизируй труд