
Техническое задание на интернет-магазин описывает, что должен уметь сайт и как стороны проверят результат. Полезное ТЗ связывает задачу бизнеса, поведение системы и критерий приёмки. Фразы «современный дизайн», «полная интеграция» и «быстрый сайт» без условий проверки оставляют слишком много вариантов трактовки.
Ниже — рабочая структура для небольшого магазина физических товаров. Её можно скопировать и заполнить перед обсуждением с исполнителем. Это шаблон требований к продукту, а не договор и не универсальная спецификация для любого бизнеса.
Скачайте шаблон и заполните исходные условия
Скачать редактируемый шаблон ТЗ в Markdown. Файл открывается текстовым редактором; его содержимое можно перенести в Word или общий документ команды. В нём есть структура требований, таблица приёмки и журнал изменений.
Начните с ассортимента, географии, способов получения и роли сайта. Например: «Магазин продаёт посуду по России, отправляет заказы со своего склада; цены и остатки обновляет сотрудник». Укажите, какие задачи должны решаться автоматически, а какие в первой версии остаются ручными.
Опишите участников: покупатель, менеджер, редактор каталога и администратор. Для каждой роли перечислите действия и ограничения. Отдельно определите владельца домена, хостинга и учётных записей внешних сервисов: эти ресурсы не должны теряться при смене исполнителя.
Опишите границы первой версии
Составьте два списка: «входит в запуск» и «рассматриваем позже». Для первого запуска в него могут входить каталог, поиск, карточка, корзина, оформление заказа, один платёжный сценарий и выбранные способы доставки. Сложная программа лояльности или несколько складов не становятся обязательными только потому, что встречаются у крупных магазинов.
Не используйте слово «стандартный» вместо описания. Даже обычная корзина может включать разные правила: покупка гостем, ограничение количества, резервирование последней единицы, применение скидок. Зафиксируйте правила, от которых зависит исполнение заказа.
Свяжите требования со сценариями покупателя
Для каждого сценария укажите исходное состояние, действия, результат и исключения. В учебном примере ниже товары и условия вымышлены; для своего магазина замените их реальными данными.
| Требование | Как проверить | Ожидаемый результат |
|---|---|---|
| Выбор варианта товара | Выбрать кружку объёмом 350 мл и добавить её в корзину | В корзине и заказе сохранён выбранный вариант |
| Изменение количества | Увеличить количество с одной до двух штук | Сумма пересчитана, количество не превышает доступное по принятому правилу |
| Доставка по адресу | Ввести адрес внутри и вне зоны обслуживания | Показаны доступные способы либо понятное сообщение об ограничении |
| Отмена тестовой оплаты | Выполнить сценарий отказа у провайдера | Магазин не показывает ложное подтверждение оплаты |
| Доступ менеджера | Открыть панель под отдельной учётной записью | Доступны согласованные действия с заказами, отсутствуют лишние права |
Такую таблицу удобнее обсуждать, чем длинный список пожеланий без примеров. Если стороны по-разному понимают ожидаемый результат, уточните его до оценки работы.
Зафиксируйте данные каталога и обмен
Перечислите поля товара: название, артикул, варианты, цена, наличие, изображения, характеристики и параметры для доставки. Укажите обязательные поля, единицы измерения и ответственную сторону за наполнение. Отдельно опишите перенос старых товаров, если он входит в проект.
Для каждого обмена данными нужны источник истины, направление и частота обновления. Например, остаток поступает из учётной системы на сайт, а заказ передаётся обратно. Опишите, что происходит при недоступности одной из сторон и кто разбирает ошибку. Слова «интеграция с учётом» без состава данных и сценариев восстановления недостаточны для согласованной приёмки.
Не добавляйте в общий документ рабочие пароли и платёжные ключи. Запишите, какие доступы потребуются и как их передадут ответственным людям по согласованному каналу.
Определите проверяемые требования к интерфейсу
Перечислите основные страницы и состояния: каталог, пустая выдача поиска, карточка без остатка, корзина, ошибка формы и подтверждение заказа. Укажите согласованные устройства и браузеры для проверки. На телефоне человек должен видеть выбранный вариант, понимать итоговую сумму и завершать ввод данных без потери уже заполненных полей.
Вместо требования «оценка скорости 100» опишите условия измерения: какие страницы, какие данные, среда, инструмент и допустимый результат. Не обещайте одинаковый результат на любой сети и любом устройстве. Уточните, кто готовит изображения и как проверяются страницы с реальным наполнением.
Согласуйте образцы макетов и число раундов корректировок. Замечание «не нравится» полезно перевести в конкретную проблему: непонятен выбор размера, плохо читается цена или кнопка перекрывает информацию.
Запишите порядок приёмки и передачи
Для каждого требования назначьте идентификатор и проверку. Удобный формат: «CAT-01 — выбор варианта», «PAY-01 — успешная тестовая оплата», «SHIP-01 — расчёт доставки». Сохраните ожидаемый и фактический результат, дату, проверяющего и ссылку на замечание. Повторная проверка после исправления закрывает конкретный пункт, а не весь проект одной общей отметкой.
Договоритесь, какие дефекты препятствуют запуску, как фиксируются остальные замечания и кто принимает решение о выпуске. Не считайте новую функцию исправлением ошибки, если она меняет согласованный сценарий. Такие изменения должны получать отдельную оценку сроков и стоимости до выполнения.
При передаче проверьте доступы владельца, исходные материалы, инструкции сотруднику, резервное копирование и порядок обновлений. Отдельно согласуйте сопровождение после запуска: что входит в него, куда обращаться и кто отвечает за внешние интеграции.
Контроль готовности ТЗ к оценке
- Понятны цель магазина, ассортимент и география первой версии.
- У каждой обязательной функции есть сценарий и критерий проверки.
- Назначены источники цен, остатков и данных заказов.
- Описаны ошибки оплаты, недоступная доставка и отсутствие товара.
- Зафиксированы обязанности по контенту, изображениям и доступам.
- Известны порядок приёмки, передачи и согласования изменений.
ТЗ можно уточнять по мере работы, но изменения должны оставаться видимыми всем участникам. Хороший документ помогает одинаково понять результат, сравнить предложения исполнителей и принять магазин по фактам.
Читайте также
- Как открыть интернет-магазин: план от идеи до первого заказа
- Как выбрать платформу: бесплатный запуск и пределы готовых решений
- Интернет-магазин на WordPress: установка и базовая настройка WooCommerce
Редакционный материал «Практики магазина». Подготовлен: 2026-10-24. Учебные примеры обозначены в тексте.