Практическое руководство

Техническое задание на интернет-магазин: шаблон с критериями приёмки

24.10.2026 · 7 мин чтения
Бумажное техническое задание с отметками проверки, карандашом и моделью магазина

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

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

Скачайте шаблон и заполните исходные условия

Скачать редактируемый шаблон ТЗ в Markdown. Файл открывается текстовым редактором; его содержимое можно перенести в Word или общий документ команды. В нём есть структура требований, таблица приёмки и журнал изменений.

Начните с ассортимента, географии, способов получения и роли сайта. Например: «Магазин продаёт посуду по России, отправляет заказы со своего склада; цены и остатки обновляет сотрудник». Укажите, какие задачи должны решаться автоматически, а какие в первой версии остаются ручными.

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

Опишите границы первой версии

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

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

Свяжите требования со сценариями покупателя

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

ТребованиеКак проверитьОжидаемый результат
Выбор варианта товараВыбрать кружку объёмом 350 мл и добавить её в корзинуВ корзине и заказе сохранён выбранный вариант
Изменение количестваУвеличить количество с одной до двух штукСумма пересчитана, количество не превышает доступное по принятому правилу
Доставка по адресуВвести адрес внутри и вне зоны обслуживанияПоказаны доступные способы либо понятное сообщение об ограничении
Отмена тестовой оплатыВыполнить сценарий отказа у провайдераМагазин не показывает ложное подтверждение оплаты
Доступ менеджераОткрыть панель под отдельной учётной записьюДоступны согласованные действия с заказами, отсутствуют лишние права

Такую таблицу удобнее обсуждать, чем длинный список пожеланий без примеров. Если стороны по-разному понимают ожидаемый результат, уточните его до оценки работы.

Зафиксируйте данные каталога и обмен

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

Для каждого обмена данными нужны источник истины, направление и частота обновления. Например, остаток поступает из учётной системы на сайт, а заказ передаётся обратно. Опишите, что происходит при недоступности одной из сторон и кто разбирает ошибку. Слова «интеграция с учётом» без состава данных и сценариев восстановления недостаточны для согласованной приёмки.

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

Определите проверяемые требования к интерфейсу

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

Вместо требования «оценка скорости 100» опишите условия измерения: какие страницы, какие данные, среда, инструмент и допустимый результат. Не обещайте одинаковый результат на любой сети и любом устройстве. Уточните, кто готовит изображения и как проверяются страницы с реальным наполнением.

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

Запишите порядок приёмки и передачи

Для каждого требования назначьте идентификатор и проверку. Удобный формат: «CAT-01 — выбор варианта», «PAY-01 — успешная тестовая оплата», «SHIP-01 — расчёт доставки». Сохраните ожидаемый и фактический результат, дату, проверяющего и ссылку на замечание. Повторная проверка после исправления закрывает конкретный пункт, а не весь проект одной общей отметкой.

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

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

Контроль готовности ТЗ к оценке

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

ТЗ можно уточнять по мере работы, но изменения должны оставаться видимыми всем участникам. Хороший документ помогает одинаково понять результат, сравнить предложения исполнителей и принять магазин по фактам.

Читайте также

Редакционный материал «Практики магазина». Подготовлен: 2026-10-24. Учебные примеры обозначены в тексте.