Мульча.рф

Было два сайта. Нужен был один

мульча.рф — розничная и оптовая торговля товарами для сада: органическая и кокосовая мульча, агрохимия, агротекстиль, грунты, декоративные отсыпки, инструменты. Клиент — «Наш Кедр», на рынке 15 лет, с аудиторией от дачников до оптовых перекупщиков и ландшафтных дизайнеров, которые закупают мульчу для клиентских проектов.

К моменту обращения в MWI у клиента было два сайта — мульча.рф и nashkedr.ru — на устаревшем движке WebAsyst Shop Script 3.0. Контент и структура частично были готовы, но бизнес-процессы жили в основном офлайн, бренд-бука не существовало — только логотип и природная зелено-коричневая палитра.

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

Казалось, что нужен интернет-магазин

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

Проект в цифрах — 28 месяцев разработки — 2475 часов — 83 задачи — 16+ специалистов — 5 служб доставки — 2 сценария работы: B2B и B2C

Почему оформление заказа стало самым сложным местом проекта

Казалось бы, оформление заказа — четыре экрана: местоположение → доставка → оплата → контакты. На практике именно эта задача заняла 297 часов и 397 комментариев в трекере — больше, чем весь дизайн проекта целиком.

Причина не в интерфейсе, а в том, что за ним стоит. Пять служб доставки — СДЭК, ПЭК, КИТ, «Деловые линии», самовывоз — плюс собственный «Курьер Мульча РФ» с расчетом стоимости по километражу от МКАД через API Яндекс.Карт и с учетом габаритов товара. У каждой службы свой капризный API: интеграция с «Деловыми линиями» потребовала прямой правки файлов модуля доставки, а на типовые ошибки вроде «упаковки недоступны» или «межтерминальная доставка» заложили отдельную обработку.

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

Выяснилось и другое: тарифы доставки на стороне клиента уже отличались от тех, что были заложены в ТЗ.

Еще одна проблема обнаружилась в интеграции с Яндекс.Картами: карта заново инициализировалась при каждом действии пользователя. Десятки лишних запросов быстро упирались в лимит API и возвращали ошибку 403 прямо в процессе оформления заказа. Проблему решили двумя изменениями: маршрут стали запрашивать один раз — после отправки формы адреса, а не при каждом взаимодействии с картой, — и перешли на клиентские API-ключи.

Следующий сложный участок — авторизация

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

На практике проблема затрагивала и оформление заказа: пользователь мог дойти до оплаты с двумя разными учетными записями и некорректно объединенной корзиной гостя и авторизованного пользователя. Решение — проверять, есть ли в системе телефон и email, до создания пользователя и перейти на сессионную модель регистрации: аккаунт не появляется в базе, пока все шаги не пройдены.

Личный кабинет физ. лица:

Личный кабинет юр. лица:

Почему интеграция с 1С никогда не бывает «просто обменом»

Обмен между сайтом и 1С работал по CommerceML 2: каталог, остатки, цены, торговые предложения и характеристики передавались на сайт, заказы и подписки — обратно в 1С. Большинство сложностей возникло не в самом протоколе, а в особенностях его реализации.

Выгрузка периодически падала с ошибкой 504 — решили десятикратным увеличением размера одновременно загружаемой части файла. Большие HTML-описания товаров обрезались, потому что 1С писала их в свойство типа «Строка» с ограничением длины — а после того как тип поменяли на «Текст/HTML», 1С при следующей синхронизации сама возвращала его обратно. В итоге поменяли не настройки, а саму логику обмена — иначе при каждой следующей синхронизации проблема возникала бы снова.

Что мы сделали сверх ТЗ

Некоторые доработки появились не потому, что были прописаны в ТЗ, а потому, что команда заранее видела риски и предлагала способы их устранить. Например:

• диагностировали и объяснили клиенту корневую причину расхождений в расчете доставки — не «баг на сайте», а несовпадение единиц измерения на стороне 1С;
• провели отдельный аудит производительности оформления заказа, выявили лишние запросы и некэшируемые операции и предложили рекомендации по оптимизации;
• заранее предупредили клиента о рисках самостоятельного развертывания сайта в Docker; когда клиент все равно развернул сайт так и сервер начал падать из-за забитого на 99% диска — каталог кэша Битрикса разросся до ~30 ГБ, — предложили и внедрили агент автоматической очистки кэша;
• адаптировали решение под ограничения Docker-окружения заказчика: все, что было возможно, автоматизировали, а для остальных сценариев задокументировали технические ограничения.

Что получилось

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