👨‍💻 Как это работает? Делаем курьера на карте в мобильном приложении Додо
Вот уже третью неделю тусуюсь в новой команде. Делаем клиентские штуки. Для меня это в новинку, так как до этого я разрабатывал в основном для нашей кухни.

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

Тут я вкратце запишу все это, так сказать от первого лица.

😑 Как принималось решение?
Вышел на одном из корпоративов Федор и сказал: "Ребяты, наше приложение в пицце — говно. Все переделываем!" (ну он не так сказал, но, вы понимаете)

Все зашевелились и впали в неистовство (охуели). Я тоже не остался в стороне (охуел и зашевелился). Потому что наряду с этим Федор еще сказал, что разработку моих любимых кухонных сервисов мы немного замедляем. Тут я подумал "Куда уж медленнее?!"

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

Тут нужно оговориться, что в общении с ребятами в компании, я выяснил, что переработка приложения уже давно в планах, а Федор просто дал волшебного пенделя. Но я, как увидел, так и пишу 🤷‍♀️

Вот в этот бэклог быстрых побед и попала задача "показывать курьера на карте".

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

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

👨‍🎨 Как разрабатывается дизайн?
У нас есть крутейшая design lead Яна Мишко и она провела крутейшее исследование конкурентов. Его результат представляет из себя дерево User Flow, где расписаны все крайние случаи использования фичи у всех остальных доставок. Что будет если сделают два заказа? Как ведет себя экран, когда заказ отменяют? И так далее.

На таком дереве легко видеть узлы, в которых можно придумать что-то новенькое. Короче, это прям красиво и математично. А еще говорят, что дизайн -- гуманитарная дисциплина!

Дальше мы определили контуры нашей будущей фичи и перешли к технической проработке. И тут мы переходим к части:

Как такие вещи устроены технически?
Я угрюмый бэкендер и у меня были сомнения в том, что такую фичу можно сделать быстро. Но в целом, оказалось, что все не настолько сложно. Принципиальная схема оказалась легкой (пояснительный дикпик выше):
1️⃣ Курьерское приложение отправляет координаты курьера в Azure IoT Hub
2️⃣ У хаба есть настройка, которая позволяет перенаправлять события в Kafka. Как оказалось это делает одной кнопкой
3️⃣ Из кафки событие попадает в сервис Recent-Orders и прикапывается в базку. Это специальный сервис, который оперативно отдает данные по заказу.
4️⃣ При запросе от мобильного приложения или сайта Mobile API и Site API получают данные о координатах из Recent-orders и отдают их обратно клиентам.

По итогу получается, что со стороны бэка выглядит, как действительно быстрая победа (классическое приключение на 20 минут). Посмотрим, что из этого выйдет, но пока вот так. Я все еще скептически смотрю на эту фичу, с точки зрения произведения ВАУ на пользователя или какой-то видимой пользы. Но попробуем и посмотрим, как оно пойдет. Мне то, что? Будет чем повыебываться на пьянках))) А то всё "ну я для кухни делал в основном фичи 😕"
#опыт