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