БОЛЬШАЯ ТЕХНИЧЕСКАЯ РЕТРОСПЕКТИВА

ИНТЕРФЕЙС ЛОГИСТА ДЛЯ СБОРКИ ЗАКАЗОВ

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

В этот раз всё тех демо было посвящено подведению итогов большой истории упрощения рабочих процессов для логистов на наших предприятиях, которой занималась команда Onyx три месяца. Ведущий программист команды — Олег Стрекаловский, рассказал о том, как команда дорабатывала модуль «Логист». Это ключевой модуль всей нашей Единой системы автоматизации, благодаря которому заказы доставляются в срок. В нём был реализован интерфейс, который помогает логистам комплектовать заказы. 

Полное видео доклада можно посмотреть <тут>. Мы сделали запись этого доклада. А конспект будет разбит на две статьи.

В первой мы расскажем о продуктовой стороне этой доработки:

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

Во второй дадим больше технического хардкора о финальной версии, к которой пришли в итоге:

• Как определялись к ней нефункциональные требования.
• На какие грабли распределённых систем наступила команда на раннем этапе и как это учла в дизайне API.
• Какие выводы мы сделали.

От задачи до решения

А чеки были нужны не только клиентам…

В начале марта наши рестораны и кафе столкнулись с дефицитом бумаги для чеков. Было решено как можно быстрее перейти на электронные чеки: они не расходуют бумагу, а клиент получает ссылку на него по sms или на email. Это не выглядело как большая проблема: достаточно кассовому аппарату через API передать нужную информацию и вместо печати чека его данные отправляются клиенту. 

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

Как только повара приготовят блюда из заказа, логисты приступают к сборке заказа по печатному чеку, в котором печатались все позиции. После перехода на электронные чеки остро встал вопрос: а как теперь логистам собирать заказы?

Сбор функциональных требований

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

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

Нужно больше логистов!

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

Именно из-за ситуаций, когда на смене несколько логистов, было важно проработать процесс «перехвата сборки заказа».  Если первый логист по каким-либо причинам больше не может собирать заказ, другой логист должен продолжить начатую сборку, а первый получить уведомление, что он больше не должен собирать этот заказ. Также логисты хотели видеть в режиме реального времени: кто собирает/собрал заказ сейчас, проверен ли чек-лист заказа полностью, чтобы отдать сумку с ним курьеру.

Вишенки на торте

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

При отмене заказа, логистам нужно сразу видеть уведомление об этом.

Для разбора полётов и аналитики к заказу необходимо добавить информацию о сборке: кто и когда собирал заказ.

MVP aka «блокнотик»

Сначала команда решила сделать MVP проекта, названные внутри команды «блокнотиком».

MVP — Minimum Viable Product — ранняя версия будущего проекта, которая позволяет при минимальных затратах собрать максимум практических данных о том, как будет происходить взаимодействие с будущим продуктом.

Работал он достаточно просто. Чек-лист строит наш фронт сам по данным из заказа. Отметки сборщика хранятся в Local Storage браузера, чтобы переживать обновления страниц, закрытие браузера. 

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

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

Сборка маршрута

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

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

Белый цвет — сборка не начата

Красный цвет —  заказ отменён

Жёлтый цвет — заказ собирается

Зелёный цвет — заказ собран, можно отдавать курьеру

Финальная версия

Следующий фидбек — всё классно, но логисты хотят, чтобы данные о сборке заказов на одном предприятии обновлялись на всех девайсах в режиме реального времени. Чтобы данные не разъехались, нам нужна была общая точка синхронизации: бэкенд, который бы принимал команды от браузера, проверял возможность выполнения операции, обновлял состояние сборки и рассылал уведомления другим подключенным к этому филиалу браузерам. Перенеся всё управление состоянием из браузера на бэкенд, мы смогли реализовать и механизм «перехвата сборки». Команда потратила 1 спринт на проработку архитектуры и 3 спринта на реализацию.

Проследили за % сборки заказа. Предприятия пока привыкают к новому инструменту.

ЛЕГЕНДА

Рост относительно предыдущего значения

Красный цвет — падение

Зелёный цвет — после падения превысили максимум

Оранжевый цвет — после падения стало незначительно лучше

Фиолетовый цвет — после падения упало ещё ниже

Продолжение следует. Во второй статье вас ждёт больше технического части про финальную версию.