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


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

Создание технического задания

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


Мы потратили примерно неделю для написания ТЗ. Раза три переделывая и дополняя описание действий для реализации поставленной задачи. Клиент принимал активное участие в корректировке задания, задавая вопросы, уточняя детали и важные для себя особенности. Надо отдать должное вовлеченности заказчика, ведь это в итоге сильно повлияло на полученный результат.

Интерфейс пользователя

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

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


Среди яркой ошибки прошлого разработчика, было необоснованное умножение кода для каждой вкладки отдельно. К примеру, в конфигураторе есть стрелка «назад» позволяющая вернуться на шаг раньше. По логике достаточно одной функции для этого действия, однако была сделана кнопка «Назад» на каждой вкладке и для каждой своя функция. Итого 6 шагов конфигуратор это было 6 функций, вместо одной. Конечно, так делать недопустимо, ведь это не только усложняет доработку в будущем но и формирует лишние объемы сайту, которые в итоге влияют на скорость его загрузки, ранжирование поисковиков и удовлетворённость клиента от работы с сайтом.

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

  • Выбор направления деятельности (медицинские, пожарные и другие спецавтомобили)
  • Класс автомобиля (по сути, выбор марки)
  • Модель автомобиля
  • Выбор размерности (колесной базы автомобиля)
  • Технические параметры – двигатель + привод + коробка передач
  • Специальное оборудование (особое оборудование, например, дефибриллятор для медицинского автомобиля)
  • Дополнительное оборудование (магнитола, регистратор и т.д.)
  • Тюннинг (тонировка, антикоррозийное покрытие и подобные улучшения)
  • Финальный шаг – таблица расчета и форма заявки

Интерфейс администратора

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

Главная сложность в работе старой версии конфигуратора

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

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

Новая проблема в виде новой логики формирования цены

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


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

Решение задачи и разработка индивидуального модуля для 1С-Битрикс

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

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

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

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

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

Резюме

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