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