В итоге всё вылилось в перенос запуска и несколько человеко-недель работы сверх плана.

Клиент приходит с «простой» задачей: в каталоге меньше сотни позиций.

Опасаюсь, что будут варианты. Уточняю у клиента и выясняю, что — да, будут.

Ну ок, начинаем работать.

Получаем от клиента прайс, загружаем в магазин.

Выясняется, что есть ещё и дополнительные варианты: наличники, фурнитура и прочее.

Вносим около десяти новых свойств товара, на основании которых движок автоматически создаёт варианты.

Появляется предчувствие проблемы, но продолжаем разбираться.

Создаём варианты дверей с несколькими видами наличников, каждый с несколькими видами фурнитуры и так далее.

Получаем больше ста вариантов каждой двери — и упираемся в ограничение движка на количество вариантов товара.

Каждый вариант является составным товаром — это комплект из собственно двери и фурнитуры.

Возникает вопрос, как работать с ценами всех этих вариантов.

Тогда комплектов в движке не было предусмотрено, да и решение с ними выходило слишком неповоротливым.

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

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


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

Наши потери — несколько человеко-недель.
Потери клиента — время старта и капитальные издержки на разработку.
И всё это — из-за неверной постановки задачи.