Этапы разработки интернет-магазина: от ТЗ до запуска

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

Читать полностью на S-WEBS24