Интернет-супермаркет стройматериалов — «Аквилон»

Когда «Аквилон» пришёл за разработкой нового интернет-магазина в panfilov.digital в 2020 году, у клиента было три строительных магазина в двух городах. За время пандемии интерес к онлайн-продажам в Казахстане вырос и собственник «Аквилона» увидел перспективную нишу на рынке страны.

На тот момент у «Аквилона» уже был сайт на Битриксе. Задача новой версии — решить проблемы старого сайта и добавить больше полезных фичей.

Проблемы

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

Так работают реляционные базы данных, в том числе в Битриксе. Из-за неудачной структуры данных сайт медленно работал.

Но это не единственная проблема. Реляционные БД не только замедляют сайт, но и делают невозможной фильтрацию поисковых результатов по категориям. Типов товаров много, и пользователь устаёт прочёсывать дерево каталога вручную. Поиск и сложные фильтры поисковой выдачи — это важный элемент хорошего UX строительного интернет-магазина. Поэтому одной из главных задач разработки стало решение проблемы с реляционными БД.

Наше решение

После аудита стало понятно, что просто докручивать сайт бессмысленно — и мы предложили разработать интернет-магазин с нуля на базе Symfony. Это PHP-фреймворк, который, в отличие от Битрикса, даёт больше возможностей для интеграций и работает не только с реляционными базами данных. Для каталога с нечёткой структурой использовали документоориентированную СУБД — MongoDB. В таких базах данных можно хранить только нужную информацию по каждому товару без длинного списка категорий с пустыми значениями.

Для фронтенда выбрали архитектуру Single Page Application на основе Vue.js и Nuxt.js. Такой стек позволяет выдавать готовую страницу сразу вместо того, чтобы сначала подгружать пустой шаблон, а потом наполнять его контентом. Это помогает с SEO — поисковые системы часто не ждут загрузки контента. Ещё один плюс этого решения — менее тесная связь бэкенда и фронтенда, что позволяет привязывать один и тот же бэкенд к нескольким приложениям.

Подробнее об архитектуре SPA — в блоге panfilov.online

Готовь сани летом, а сайт зимой

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

Чтобы понять, какие фичи надо выкатить раньше, мы обратились к пользователям — провели 10 интервью с постоянными покупателями.

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

Domain-Driven Design

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

В работе мы ориентировались на подход DDD — Domain-Driven Design. Суть подхода в том, что команда разработки учитывает «домен» — сферу бизнеса, для которой она делает приложение. В рамках DDD клиент постоянно в контакте с разработчиками и даёт им экспертизу в своей сфере, чтобы продукт в первую очередь выполнял бизнес-задачи. Поэтому мы тщательно уточняли бизнес-требования и «переводили» их на «язык» разработчиков.

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

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

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

Интеграция с 1С

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

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

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

Нестандартная функциональность

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

Адаптивная форма заказа

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

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

Поиск с машинным обучением

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

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

Комплекты

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

Правила сборки комплектов составлены вручную в 1С, а оттуда эти данные попадают на сайт.

Калькулятор

Допустим, покупатель заказывает напольное покрытие, но не знает, сколько паркетных досок ему нужно для комнаты. Считать вручную сложно. Если есть выбор из нескольких вариантов покрытия, придётся вычислять по новой для каждой опции — доски бывают разных размеров.

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

Запуск

Мы уложились в сроки и запустили MVP с базовой функциональностью в марте. Релиз проходил в три этапа, которые заняли месяц:

— Сначала протестировали новый сайт на небольшой группе постоянных покупателей и собрали фидбек
— Когда сайт был готов к запуску, открыли его на отдельном поддомене и поделились ссылкой с более широкой аудиторией
— Когда мы увидели, что большинство пользователей остаются на новой версии сайта, заменили старую версию на основном домене

В чём польза MVP?

Если долго запускать продукт, клиент в ожидании релиза потеряет время и деньги, а пользователь уйдёт к конкурентам, у которых лучше UX. В случае с Аквилоном ещё и было важно запустить новый сайт быстрее, чтобы маркетологи начали привлекать трафик в начале строительного сезона. Но ценность MVP не только в сокращении time-to-market.

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