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