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

Это очень интересный кейс, он про комплексную разработку двух мобильных приложений, учётно-административной системы и системы эфира для службы такси и доставки. Я сначала расскажу про само приложение, про процесс разработки, а в конце статьи опишу некоторые вызовы, особенности и нетипичные задачи в процессе уточнения требований проектирования архитектуры. Конечно, многие крайне интересные моменты вынужден опустить в виду NDA. Данный проект крайне не шаблонный, такой проект не сделать ни по готовому руководству, ни по стандартному учебнику аля "Вигерс Битт. Разработка требований к ПО". Нет, это сотрудничество имело массу особенностей, достойных одного из самых сложных наших кейс-проектов. Но как и всегда, мы этих сложностей ожидали и готовы были как к сложным стратегическим решениям, так и к оперативным и тактическим импровизациям.

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

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

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

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

С точки зрения менеджмента это предполагало формирование текстовых задач дизайнеру, созвоны с ним, тестирование отрисованных макетов и внесение правок:

1. Так, был составлен документ с 38 правками

2. И было написано задание на Дизайн второго приложения включавшее около 40 уникальных страниц!

Дизайн второго приложения оказался сложнее, ведь дизайнер не знала деталей и пришлось рисовать прототипы, которые следом переделывались в готовые макеты.

Весь дизайн был сделан в программе Figma - самое современное приложение для веб дизайна.

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

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

В ходе проектирования архитектор документировал основные технические решения с использованием стандартного подхода документирования. Схемы “сущность-связь” с использованием четырёх основных поинта - точек зрения:

1. Логика. Описание основных сценариев и изменений в интерфейсах при связи с объектами предметной области доставки пассажиров и лёгких грузов.
2. Физика. Были задокументированы некоторые ключевые особенности проекта с точки зрения необходимых объёмов памяти, особенностей развертывания, особенностей масштабирования, требований к скорости доставки новых версий и так далее.
3. Статика. Описание диаграммы связей и типов состояний. Описание модели предметной области в виде взаимозависимых классов в безвременном срезе, описание возможных состояний и формата данных и списка возможных действий со множествами. Создание базы данных и моделей данных.
4. Динамика. Это описание алгоритма главных процессов и событий, которые возникают во времени и их прямая связь с моделью предметной области., Представьте себе город, в котором множество дорог, адресов, автомобилей и мото-техники. Люди по определенному адресу нуждаются в транспорте для поездок и доставки. И всё это происходит в реальном времени и связано с массой тонкостей при коммуникации, особенно когда не используется живой оператор. Все эти сущности - это экземпляры статических моделей, имеющие свой жизненный цикл. Описание поведения и изменения объектов во времени, описание последовательности алгоритма, вызова динамических методов модели предметной области - вот, что было описано в данном поинте.

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

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

Xтобы оценить размер проекта и полноту требований - его Техническое задание было более 150 страниц (77 страниц, чистого текста без картинок!)