Нам предстояло создать новую версию Seller Drive взамен той, что существовала в компании последние 10 лет и никак не обновлялась 7 из них. Нужно было подстроить Seller Drive под актуальные бизнес-процессы Emex DWC и их технологическую экосистему. 

Разработку Seller Drive мы начали после проектирования системы. Этот этап длился 5 недель и стал основой для следующего за ним этапа разработки, о котором мы рассказываем в этом материале. О том, как проходил процесс проектирования, мы рассказали в отдельном кейсе. 

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

Как устроена работа в системе Seller Drive 

Стартовая страница содержит общую информацию о возможностях системы.  Это единственная индексируемая общедоступная страница Seller Drive – здесь мы настроили SEO-оптимизацию. 

Взаимодействие поставщиков с системой начинается со входа или регистрации. 

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

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

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

Товары из загруженных в Seller Drive прайс-листов попадают на маркетплейс, где покупатели могут их заказывать. Заказы после оформления отображаются в ЛК поставщика. Там их можно обрабатывать и процессить. Чем быстрее поставщик обрабатывает заказы, тем выше становится его рейтинг, который видят покупатели на маркетплейсе. 

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

Когда товары отгружены, поставка переходит в категорию исполняющихся (pending). Дойдя до склада, она проверяется складскими работниками. Они работают в одной из связанных с Seller Drive систем и отмечают приход товара, а также недочеты, выявленные на стадии приёмки. Например, пришёл товар с неверным номером. 

Как только обнаруживается, что с товаром в поставке что-то не так, поставщик в своём ЛК узнаёт об этом и может принять меры по устранению неурядицы. 

Немного о процессах

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

За проектированием следовала разработка в тандеме с бекенд-командой Emex. Мы согласовали архитектурные паттерны и сценарии взаимодействия команд и далее синхронизировались по ходу разработки еженедельно. 

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

Требования мы получали от Emex в Notion, потом переводили их в Azure DevOps, где продолжали работу с ними.

Технологический стек

Стек технологий Seller Drive согласован со стеком российского подразделения Emex, чтобы поддерживать и дорабатывать системы одной командой.

Ещё один важный момент – консистентная дизайн-система Emex. Обновлённый продукт мы подстраивали под заданные визуальные паттерны – опять же, чтобы остаться верными экосистеме, в которой продукт будет существовать. 

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

• React
• TypeScript
• State management: Redux, Redux Sagas
• Testing: Jest, React Testing Library
• Webpack
• CSS: Styled Components

Результаты

Через 6 месяцев после начала разработки новая версия Seller Drive вошла в эксплуатацию, после чего стала непрерывно совершенствоваться.

Мы продолжаем работать над Seller Drive и сейчас, дополняя функциональность системы, чтобы пользователям было ещё удобнее взаимодействовать с кабинетом поставщика.