Вернуться к статьям После запуска интернет-магазина иногда выясняется, что каталог нельзя загрузить в согласованном виде, оформление заказа не учитывает часть рабочих сценариев, а сотрудникам непонятно, кто и как будет обновлять данные. Формально сайт готов, но процесс работы с ним остаётся за границами договорённостей.
Проблема часто возникает на этапе выбора исполнителя. Под словами «разработка интернет-магазина» разные команды могут понимать разный состав работ. Поэтому подрядчика стоит выбирать не только по портфолио и общему впечатлению от предложения, а по тому, насколько точно он разбирает задачу и фиксирует её границы.
Как выбрать подрядчика для разработки интернет-магазина по содержанию предложения
Предложения полезно сравнивать не по названиям блоков, а по содержанию каждого из них. Формулировки «каталог», «дизайн», «интеграция» или «запуск» без расшифровки не показывают состав работ.
Для каталога важны ответы на конкретные вопросы: какие бывают типы товаров, есть ли варианты, какие характеристики участвуют в фильтрах, откуда берутся изображения и документы, как обрабатываются позиции без остатка или с неполными данными. Для оформления заказа — какие способы получения товара нужны, какие статусы используют сотрудники, какие действия предусмотрены при отмене или частичной отгрузке.
Если предложение состоит только из общего перечня разделов, без вопросов о товарах, данных и обработке заказов, в нём могут остаться незафиксированные предположения. Их лучше выявить до подписания договора, а не после появления первой версии сайта.
Вопросы подрядчику по каталогу и данным интернет-магазина
Каталог редко сводится к набору карточек. В одном ассортименте достаточно названия и фотографии. В другом есть варианты товара, технические параметры, совместимые позиции, комплекты, файлы, ограничения на заказ и несколько источников данных.
До начала работ полезно показать исполнителю примеры: простой товар, товар с большим числом характеристик, товар с вариантами и позицию с неполными данными. По реакции на эти примеры можно оценить, задаёт ли команда предметные вопросы или оставляет детали на потом.
Отдельно фиксируют источник данных: учётная система, таблицы, материалы производителей или ручная редактура. Настройка загрузки, первичное наполнение и последующая обработка карточек — разные задачи. Наличие дизайна также не означает, что в состав работ входят фотографии, описания позиций или проверка каждого атрибута.
На что смотреть в портфолио разработчика интернет-магазинов
Портфолио помогает оценить визуальный уровень и опыт в близкой тематике, но не показывает, как была устроена работа над конкретным проектом. Скриншот главной страницы не раскрывает поведение фильтров, карточек с длинными названиями, пустой выдачи поиска, недоступного товара или корзины на телефоне.
Полезнее уточнить, с какими ограничениями команда сталкивалась в похожих задачах и как учитывала их при проектировании. Например: как обрабатывали отсутствие изображения, разные наборы характеристик, изменение условий заказа после добавления товара в корзину, отменённый заказ или повторную передачу данных.
Необязательно запрашивать закрытые материалы других клиентов. Достаточно обсудить подход к описанию сценариев и результатам работ: структуру требований, прототипы, перечень проверок, правила передачи данных. Это помогает оценить процесс без доступа к чужой внутренней информации.
Как обсудить CMS и интеграции до разработки магазина
Технологию выбирают исходя из сценариев проекта, а не только из привычного для подрядчика инструмента. Если для публичной части магазина рассматривается «1С-Битрикс: Управление сайтом», её стоит обсуждать как CMS сайта: где будут управляться страницы, каталог и контент в конкретной реализации. CMS не заменяет учётную систему и сама по себе не определяет правила обмена данными.
Слово «интеграция» также требует расшифровки. Разовая выгрузка файла и постоянный обмен данными — разные сценарии. Для каждого внешнего источника следует определить, какие сущности передаются, в каком направлении, когда обновляются данные, кто проверяет результат и что происходит при ошибке.
Полезно спросить, какие исключения учитываются в обмене. Ответ должен касаться ситуаций с отсутствием товара, изменением условий заказа, отменой заказа, возвратом, неполными данными или повторной передачей. Общая формулировка о подключении интеграции не описывает будущую работу.
Критерии выбора подрядчика по проектированию интерфейса
Макет стоит проверять не только на демонстрационных товарах. В интернет-магазине встречаются длинные названия, изображения разного качества, характеристики разной длины, пустые категории, неполные данные каталога и товары, которые нельзя заказать.
До согласования дизайна нужно определить, какие страницы и состояния будут проработаны: категории, подкатегории, поиск, фильтры, сортировка, карточки разных типов товаров, корзина, оформление заказа, личный кабинет, уведомления, ошибки и пустые результаты. Для мобильной версии проверяют те же маршруты, а не только главную страницу.
Показательно, когда подрядчик обсуждает действия посетителя, а не ограничивается списком экранов. Пользователь должен найти товар, сравнить параметры, понять условия получения, изменить состав корзины и завершить заказ без неочевидных препятствий.
Как зафиксировать границы работ с разработчиком интернет-магазина
Фраза «под ключ» не описывает глубину проработки и не распределяет ответственность. В договорённостях важно отделить готовые результаты, данные со стороны заказчика и действия, которые остаются после запуска.
Например, необходимо различать создание механизма загрузки, передачу исходного файла, проверку загрузки и ручную доработку карточек. То же относится к текстам, изображениям, классификации товаров и правилам формирования названий. Если эти элементы не описаны, их не стоит считать включёнными автоматически.
Со стороны подрядчика фиксируют состав страниц, сценарии заказа, правила передачи данных, условия тестирования и материалы, передаваемые по завершении. Со стороны заказчика — источники информации, ответственных за согласование и порядок приёмки результата.
Как принять результат разработки интернет-магазина
Открытие сайта в браузере не подтверждает готовность магазина к работе. Проверка строится вокруг согласованных сценариев: поиск товара, работа фильтров, добавление в корзину, оформление заказа с разными способами получения, отображение данных на мобильном устройстве, уведомления и передача сведений во внешние системы.
Сценарии лучше согласовать заранее. Тогда у обеих сторон появляется единый критерий: не впечатление от первой страницы, а прохождение конкретных действий в рабочей среде.
При передаче проекта полезно получить доступы в согласованном объёме, инструкцию по обновлению каталога, перечень известных ограничений и порядок сообщения об ошибках. Такой набор не отменяет возможные доработки, но делает исходное состояние магазина понятным для команды, которая будет с ним работать.
Часто задаваемые вопросы
- Какие вопросы задать подрядчику до подписания договора?
Спросите, как будут описаны типы товаров, источники данных, сценарии оформления заказа, правила обмена с внешними системами, мобильные состояния и условия приёмки. Ответы должны быть привязаны к ассортименту и рабочим процессам, а не состоять из общего перечня услуг.
- Можно ли выбрать разработчика только по портфолио?
Одного портфолио обычно недостаточно. Оно показывает визуальный уровень и тематику проектов, но не раскрывает состав работ, качество интеграций и порядок передачи результата. Его стоит использовать как дополнительный материал при разборе задачи.
- Что предоставить подрядчику для оценки интернет-магазина?
Подготовьте примеры товаров, структуру каталога, перечень характеристик, источники данных о наличии товаров, варианты получения заказа, материалы для карточек и описание того, как сотрудники будут работать с заказами и данными.
- Как понять, что в предложении есть скрытые допущения?
Проверьте, расшифрованы ли пункты про каталог, контент, дизайн, обмен данными, тестирование и запуск. Если не указано, какие сценарии и результаты входят в каждый пункт, часть договорённостей может остаться незафиксированной.
- Что считать результатом работы подрядчика?
Результатом могут быть согласованные страницы и сценарии, каталог в оговорённом составе, настроенный обмен данными, прохождение тестовых проверок и переданные материалы для дальнейшей работы. Полный состав зависит от требований проекта и фиксируется отдельно.