Ошибки при создании интернет-магазина: 7 промахов заказчика и как их избежать

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

Почему ошибки при создании интернет-магазина обходятся дороже, чем кажется

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

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

Ниже разобраны семь ошибок в том порядке, в котором они обычно и возникают: от постановки задачи до первых недель работы.

Ошибка 1: заказ без технического задания

«Хочу магазин как у конкурента» — это пожелание, а не задача. Без описания функций каждый участник понимает проект по-своему: заказчик представляет один сценарий покупки, менеджер — другой, разработчик — третий. На выходе получается магазин, который формально работает, но не совпадает с ожиданиями. Споры о том, «что имелось в виду», съедают время и бюджет.

Что должно быть в техническом задании

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

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

Хорошее ТЗ отвечает не только на вопрос «что должно быть», но и на вопрос «что не нужно». Явно вычеркнутые функции защищают от лишней работы и помогают уложиться в бюджет. Если функция кажется сомнительной, её лучше отложить во вторую очередь, чем включать в первый запуск. Если на часть вопросов ответа нет, это нормально — их фиксируют как открытые и закрывают до старта разработки, а не по ходу. Открытый вопрос, оставленный без ответа, почти всегда превращается в переделку.

Ошибка 2: выбор подрядчика только по цене

Самая низкая цена в смете почти всегда означает, что часть работ в неё не вошла. Это не обязательно обман: подрядчик мог решить, что интеграция с учётной системой — «отдельная задача», а наполнение каталога — «забота заказчика». В результате итоговая стоимость оказывается выше, чем у исполнителя, который сразу посчитал весь объём.

Сравнивать нужно не цифру, а состав работ. Задайте один и тот же список вопросов всем участникам и посмотрите, кто что включил, а кто обошёл молчанием. Разбор состава работ помогает читать сметы предметно: Сколько стоит разработка интернет-магазина.

Как сравнивать предложения

• Попросите разбить смету по блокам: каталог, оформление заказа, интеграции, контент, аналитика, поддержка.
• Уточните, что входит в каждый блок и что считается дополнительной работой.
• Спросите, как будет выглядеть приёмка: по каким критериям вы поймёте, что блок готов.
• Проверьте, есть ли в предложении план возврата на случай сбоя.

Ошибка 3: интеграция с учётной системой «на потом»

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

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

Что уточнить до старта

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

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

Ошибка 4: недооценённый контент каталога

Разработка заканчивается, а магазин не запускается: каталог пустой. Фотографии не сняты, описания не написаны, характеристики не заполнены. Это не вина разработчика — это работа, которую часто забывают включить в план.

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

Как не утонуть в наполнении

• Составьте список характеристик, обязательных для каждого товара.
• Определите, какие поля заполняются автоматически из учётной системы, а какие — вручную.
• Назначьте ответственного за контент и сроки по разделам.
• Проверьте на небольшой выборке, что фильтр находит товары по заполненным характеристикам.

Отдельно стоит продумать, что делать с товарами, которые временно недоступны. Оставлять их в каталоге с пометкой «нет в наличии» или скрывать — решение зависит от спроса. Но правило должно быть единым, иначе каталог превращается в свалку.

Ошибка 5: поддержка после запуска не заложена

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

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

Что зафиксировать в договоре на поддержку

• состав работ: обновления, резервное копирование, мониторинг, консультации;
• время реакции на сбои разного уровня;
• порядок доработок и оценка новых задач;
• кто отвечает за сохранность данных и как часто снимаются копии.

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

Ошибка 6: права на исходники и доступы остались у подрядчика

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

Права на сайт, исходный код и все учётные записи должны принадлежать заказчику. Это фиксируют в договоре и передают по акту. Отдельно стоит проверить, что доступы не привязаны к личным почтам сотрудников подрядчика — иначе после смены команды могут возникнуть сложности с доступом к сервисам.

Что проверить при передаче

• домен зарегистрирован на заказчика;
• хостинг и панель управления оформлены на заказчика;
• исходный код передан и хранится в доступном заказчику месте;
• доступы к админке, аналитике, платёжным сервисам выданы заказчику;
• есть акт передачи с перечнем.

Ошибка 7: запуск без аналитики и проверки сценариев

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

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

Что проверить до запуска

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

Сравнительная таблица: ошибка, признак и что делать

Учебный пример: заказ магазина с проверкой результата

Ниже — условный пример. Данные о компании и количестве товаров вымышлены и приведены только для иллюстрации.

Учебный пример. Компания «Северный склад» продаёт инструмент, около 4 000 позиций, часть — с вариантами по размеру. Учёт ведётся в 1С, заказы сейчас принимают по телефону и почте. Задача — интернет-магазин с самостоятельным оформлением заказа.

Условия проекта, которые зафиксировали до старта:

• типы товаров: простой и с вариантами;
• цены: базовая и скидка по накопительной программе;
• остатки: обмен с 1С раз в сутки, при расхождении приоритет у учётной системы;
• оплата: онлайн и счёт для юридических лиц;
• доставка: самовывоз и служба доставки;
• роли: покупатель, менеджер, администратор;
• контент: фотографии и описания готовит заказчик по согласованному шаблону;
• поддержка: плановые обновления и реакция на сбои по договору;
• права: исходники и доступы передаются заказчику.

Проверка результата до запуска:

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

Если хотя бы один пункт не проходит, запуск откладывают до устранения. Это снижает риски и затраты на последующие доработки.

Чек-лист перед подписанием договора

• Есть техническое задание или бриф с ответами по товарам, ценам, остаткам, оплате, доставке и ролям.
• Состав работ у подрядчиков сравнивается по единому списку вопросов, а не только по цене.
• Интеграция с учётной системой описана: формат, частота, ответственный за сопоставление.
• Понятно, кто и по какому шаблону наполняет каталог и в какие сроки.
• Условия поддержки после запуска зафиксированы в договоре.
• Права на исходники, домен, хостинг и доступы переходят заказчику.
• Аналитика и проверка ключевых сценариев включены в план до запуска.
• Описан план возврата: резервная копия, тестовый контур, порядок отката.

Ограничения и что проверить отдельно

Ни один чек-лист не заменяет разбор конкретного проекта. Решения зависят от отрасли, объёма ассортимента и учётной системы, поэтому универсальных ответов нет.

Отдельной проверки требуют:

• юридические вопросы: обработка персональных данных, оферта, правила возврата — их стоит сверить с профильным специалистом;
• требования платёжных систем и фискализации — актуальные условия уточняют у провайдера;
• производительность при большом каталоге и сложных скидках — нагрузку проверяют на тестовом контуре;
• права доступа к файлам и папкам — часть ошибок при редактировании связана с тем, что веб-сервер и FTP работают под разными пользователями; это проверяют на тестовой копии, а не на рабочем сайте.

Если сомневаетесь в состоянии уже существующего магазина, полезно начать с диагностики: Аудит интернет-магазина — что проверяют и что будет в отчёте. Для нового проекта отправной точкой становится описание процессов, после которого можно оценивать разработку интернет-магазина.