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