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

Такое описание помогает составить техническое задание на интернет-магазин, сравнить предложения исполнителей и проверить готовую работу. Разберём этот подход на условном магазине товаров для дома. Все примеры здесь иллюстративные и не описывают показатели реального клиента.

Начните с процесса который уже существует

Если вы продаёте через сообщения, телефон или торговую точку, у вас уже есть процесс. Запишите, как покупатель узнаёт наличие, как уточняет варианты товара и что происходит после решения купить.

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

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

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

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

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

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

Опишите выбор товара

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

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

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

Разберите корзину и расчёт суммы

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

Отдельно опишите расчёт. Что входит в сумму? Есть ли минимальный заказ, скидка или платная упаковка? В какой момент определяется доставка? Если действуют исключения, они должны быть известны до разработки формул.

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

Определите состав данных при оформлении

Каждое поле должно иметь понятное назначение. Для отправки физического товара может понадобиться адрес, но для предварительного запроса он часто ещё не нужен. Чем раньше запрашиваются сведения, тем важнее объяснить их роль.

Составьте перечень обязательных и необязательных полей. Для каждого укажите, кто использует ответ. Если никто не может объяснить назначение поля, его необходимость стоит пересмотреть.

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

Оплата требует отдельного сценария

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

В техническом задании фиксируют состояния заказа и действия при успешной оплате, отмене, неопределённом результате и повторном открытии страницы. Эти ситуации влияют на то, что видят покупатель и сотрудник.

Если на старте оплата проходит после разговора с менеджером, это можно явно описать и оценить отдельно от полноценного платёжного сценария. Следующие интеграции добавляются после проверки технических и организационных условий. Сведения о платёжном сервисе и требованиях к расчётам уточняются у соответствующих специалистов.

Укажите получателя заказа

После отправки данные должны попасть в конкретное место. Укажите систему, состав передаваемой информации и сотрудника, который отвечает за обработку. Формулировка «уведомление менеджеру» недостаточна, если у компании несколько направлений и смен.

Для простого процесса это может быть согласованный канал получения заявок. Для более сложного — запись в CRM с назначением ответственного. Наличие интеграции сначала проверяется по возможностям выбранных систем.

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

Опишите работу сотрудника после получения

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

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

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

Разделите первый запуск и развитие

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

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

Для будущих возможностей стоит отметить направление развития, не выдавая его за готовую часть. Это особенно важно, если позже планируются приложение, учётная система или несколько складов. Разработчик должен знать о планах, но стоимость первой версии определяется её согласованным составом.

Составьте проверяемые критерии приёмки

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

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

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

Шаблон описания одного сценария

Заполните короткую заготовку связным текстом. Кто действует? Что ему доступно? Что он выбирает? Какие сведения вводит? Что получает после завершения? Где результат видит сотрудник? Какие ошибки возможны? По чему проверяется успешное выполнение?

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

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

Пример таблицы проверки заказа

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

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

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

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

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

Вопросы перед передачей задания разработчику

Нужны ли технические термины

Достаточно понятного описания бизнеса. Технические решения должен предложить исполнитель, объяснив ограничения, обслуживание и проверку результата.

Нужно ли сразу описывать все исключения

Самые вероятные и важные стоит разобрать до оценки. Редкие случаи можно вынести в обсуждение рисков и будущих изменений. Их значимость определяется последствиями для покупателя и сотрудников.

Можно ли использовать сайт конкурента

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

С чего начать если задача кажется слишком большой

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

Если планируете интернет-магазин, пришлите описание этого пути вместе с ассортиментом и примерами. На его основе обсудим структуру, необходимые функции и границы первой версии.

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

Разработка интернет-магазина ↗

Есть похожая задача?

Расскажите о своём бизнесе. Обсудим формат сайта, состав проекта и следующий шаг.

Обсудить проект ↗