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