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

Мы посмотрели код и пришли к выводу, что сделать с нуля будет дешевле, чем отладить баги и переделать изначально хромающую архитектуру имеющегося решения. О чем честно и сказали заказчику.

В итоге имеющийся сайт получилось использовать только в качестве отправной точки на этапе аналитики.

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

На старте было много вопросов. Справится ли база с этой бизнес-логикой? Хватит ли Elastic Search? Придется ли писать что-то на языке PainLess — особого языка на основе урезанной JAVA, специально для поисковой машины Elastic (кстати, painless переводится как «меньше боли», но по факту ее — не меньше)? Оказалось, что придется.

В итоге начали код с автотестов. Так крайне редко делают на сайтах (дорого и долго), но на подобных, огромных и сложных проектах — подход себя полностью оправдывает.

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

Уже на этапе аналитики стало ясно, что проект — непростой: бизнес-процессы заказчика четкие, но объемные и требуют погружения. Большой плюс — сам заказчик отлично понимает все свои внутренние процессы, может рассказать, что и как работает и, главное, готов менять привычное на своей стороне для упрощения автоматизации на сайте.

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

— На этом проекте случился тот самый мэтч со специалистом 1С на стороне заказчика. Нам попался очень грамотный, думающий человек с желанием сделать всё по красоте!

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

В этом кейсе нам повезло — заказчик согласился обмениваться по HTTP-протоколу в формате JSON, что значительно упрощает задачу: большой объем данных поделен на пачки, которыми можно легко и быстро обмениваться — за счет этого процесс происходит в режиме реального времени. Стильно-модно-молодежно :)

—  По факту, конечно, каталог всегда один — разница только в доступах к товарам и SKU.

На сайте есть три типа пользователей: b2c, b2b, manager. Доступами к товарам, SKU и разделам каталога рулит 1С — их можно задавать как угодно: как отдельным типам пользователей (например, только торговому представителю), так и нескольким (например, торговому и его клиентам, но не b2c).

Доступы влияют на то, будут ли отображаться товары, SKU и разделы в каталоге, а также на фильтр: если товары недоступны пользователю, то в фильтре он не увидит значений их свойств. И конечно, типы пользователей влияют на цены товаров и доступность складов, с которых на сайте считаются остатки.

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

— Чтобы легко ориентироваться среди сотен оттенков одного и того же товара, фильтр из каталога сохраняется и при переходе на детальную страницу товара: она наследует SKU, соответствующие параметру фильтрации. При желании параметры фильтрации можно скорректировать прямо здесь, не возвращаясь в каталог.

—  Торговый представитель через свой ЛК может зайти под контрагентом и оформить заказ на этого контрагента. Благодаря этому менеджер Beecolor может видеть каталог глазами своего клиента: доступные товары и SKU, цены и остатки.
В итоге оформленный заказ появляется и в личном кабинете менеджера Beecolor, и в личном кабинете его клиента — и им обоим удобно его отслеживать.

— Вся статистическая информация приходит из 1С. Благодаря этим графикам торговые представители видят динамику своей работы за прошедший период и наглядно понимают, какой объем им необходим для закрытия плана.

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

— После заполнения решения менеджер жмет специальную кнопку «Отправить решение в 1С» — и только тогда рекламация со всеми данными улетает в 1С. Это сделано намеренно, чтобы при первичном создании рекламации лишний раз не нагружать систему.

— Часто товары B2B-сегмента приобретаются по акциям от производителей. Например, бренд N дает Beecolor акцию для реализации: «Купи 20 красителей линейки K и получи в подарок окислитель». Механизм акций очень важен в цепочке продаж. Нам важно было и продумать интерфейс, и автоматизировать приобретение товаров по акциям, и не запутать пользователей.

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

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

Главной задачей на этом этапе была скорость — чтобы клиенту при переходе в раздел «Акции» показывался актуальный список доступных акций уже после всех проверок.

—  Самая сложная часть в акциях — это проверки: там их целое дерево.

В акции есть условия и подарки. И, например, надо проверить условие типа «купи товаров на сумму 5000 руб.» для конкретного пользователя на доступность выполнения.

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

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

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

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

Также в ближайших планах — функционал маркетплейса :)