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