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