Вернуться к списку Вернуться к статьям
Статьи

Договор на разработку интернет-магазина: что зафиксировать

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

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

Предмет договора на разработку интернет-магазина

Фраза «разработка интернет-магазина» не раскрывает состав работ. В одном проекте это публичные страницы и каталог, в другом — личный кабинет, несколько типов товаров, правила получения заказа, обмен данными с внутренними системами.

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

Конкретные сценарии отделяют согласованный объём от формулировок вроде «стандартный каталог» или «оформление заказа». Если какой-либо сценарий не входит в проект, его также указывают в документах.

Техническое задание и состав результата

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

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

Если для сайта выбрана «1С-Битрикс: Управление сайтом», в документах её описывают как CMS публичной части и администрирования контента в рамках конкретной реализации. Задачи внутреннего учёта и других корпоративных систем не подменяют описание сайта.

Каталог товаров и исходные данные заказчика

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

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

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

Интеграции интернет-магазина: что описать заранее

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

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

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

Порядок согласования изменений в проекте

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

Договор на разработку интернет-магазина отделяет уточнение согласованного решения от нового требования. В порядке согласования указывают, кто инициирует изменение, в каком виде передаёт его, кто подтверждает влияние на состав работ и после какого согласования задача поступает в разработку.

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

Приёмка интернет-магазина и передача проекта

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

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

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

Часто задаваемые вопросы

Можно ли подписать договор, если каталог ещё не собран?

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

Что считать изменением, а что уточнением технического задания?

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

Нужно ли включать в договор проверку на мобильных устройствах?

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

Как описать интеграцию, если технические детали ещё неизвестны?

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

Что передать заказчику после завершения разработки?

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