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