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