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

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

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

Этап	Результат	Риск
Обследование	Реестр процессов, ролей, источников данных и границ	В проект попадают неоговорённые задачи
ТЗ и интеграции	Сценарии, правила обмена, карта систем	Системы по-разному трактуют одни данные
Прототип	Карта экранов и маршрутов заказа	Критический сценарий обнаружится после дизайна
Дизайн	Макеты согласованных состояний	Не описаны ошибки, мобильная версия и права
Разработка	Рабочий функционал в тестовом контуре	Проверка затрагивает реальные данные
Миграция	Протокол переноса и сверки	Возникают дубли, пропадают свойства или URL
Приёмка	Пройденный набор согласованных проверок	Тесты принимают за гарантию отсутствия ошибок
Запуск	План переключения, резервная копия и откат	Команда не может быстро остановить переключение
Передача	Доступы, инструкции и журнал ограничений	Поддержка получает систему без контекста

Что известно до старта разработки интернет-магазина

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

В стартовом документе указывают типы товаров, ответственных за контент, статусы заказа, сервисы, критерии приёмки и открытые вопросы. Состав зависит от масштаба, договора и архитектуры.

Работу сайта нужно отделять от работы CRM. CMS «1С-Битрикс: Управление сайтом» управляет сайтом и интернет-магазином. Битрикс24 — отдельная CRM, которую при необходимости подключают для передачи заказов, контактов и служебных данных.

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

Обследование бизнеса и границы проекта интернет-магазина

Обследование превращает задачу «нужен магазин» в модель процессов, данных и участников. Результат этапа показывает, кто обновляет каталог, принимает оплату, собирает заказ, меняет статус и разбирает исключения.

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

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

Учебный сценарий одного заказа интернет-магазина

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

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

Один сценарий не покрывает все процессы магазина, но даёт основу для прототипа, карты интеграций и приёмочных тестов.

ТЗ и карта интеграций интернет-магазина

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

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

Данные	Возможный владелец	Куда передают	Что согласовать
Товар	Учётная система или CMS	Сайт, CRM	Артикул, свойства, варианты, изображения
Цена	Учётная система или ценовой сервис	Сайт	Типы цен, округление, доступ покупателей
Остаток	Учётная система	Сайт	Частота обновления, резерв, отсутствие
Клиент	Сайт или CRM Битрикс24	CRM, учётная система	Дубли, согласие, поля контакта
Заказ	Сайт или учётная система	CRM Битрикс24, учётная система	Состав, доставка, статусы, отмена
Платёжный статус	Платёжный сервис	Сайт, учётная система	Подтверждение, повторы, сверка, возврат

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

Коротко: карта интеграций отвечает на два вопроса: откуда приходит значение и кто вправе его изменить. Владельца назначают для товара, цены, остатка, клиента, заказа и платёжного статуса. Документ описывает направление обмена, идентификаторы для сопоставления, расписание, поведение при недоступности внешнего сервиса и разбор ошибок. Карту проверяют на учебном заказе, включая отмену и возврат. Такой порядок нужен, когда сайт, учётная система, CRM Битрикс24 и сервисы оплаты работают с пересекающимися данными. Он не отменяет ограничений внешних интерфейсов и не делает обмен мгновенным. Даже принятое уведомление может прийти повторно или потребовать сверки. Для сбоя заранее определяют, кто видит ошибку, как повторяет операцию и где проверяет итоговый статус до повторного запуска. В протоколе проверки записывают исходные значения, результат обмена и ответственного за исправление расхождений. Секреты платёжного сервиса нельзя размещать в клиентском коде, макетах или открытых документах.

Прототип каталога и оформления заказа

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

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

Google рекомендует делать товарные страницы достижимыми через меню, категории и подкатегории. Sitemap может помочь обнаружению URL, но не заменяет рабочую навигацию. Ограничения и примеры приведены в руководстве Google по структуре интернет-магазина. Доступность страницы через меню сама по себе не гарантирует индексирование.

Дизайн состояний интернет-магазина

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

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

WCAG 2.2 содержит проверяемые критерии доступности для настольных и мобильных устройств. Их частичное выполнение не доказывает доступность для всех пользователей. Google также рекомендует сохранять эквивалентность основного контента и метаданных между версиями при мобильной индексации; это не обещание поисковых позиций.

Разработка интернет-магазина и тестовый контур

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

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

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

Интеграции и миграция данных интернет-магазина

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

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

Правила URL согласуют отдельно. Google рекомендует уникальные описательные адреса, минимум альтернативных URL одного содержания и единообразие адресов во внутренних ссылках, Sitemap и rel="canonical". Конкретные правила фильтров зависят от каталога; их нельзя переносить с другого сайта без проверки. См. рекомендации Google по URL интернет-магазина.

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

Приёмочное и нагрузочное тестирование интернет-магазина

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

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

В k6 пороги — заранее заданные критерии успешности для метрик; при нарушении порога тест получает статус failed. Значения из чужого проекта нельзя считать универсальной нормой: их выбирают по сценарию, инфраструктуре и ожидаемой нагрузке. См. документацию Grafana k6.

Чек-лист приёмки интернет-магазина

• Каталог показывает согласованную структуру категорий.
• Фильтр возвращает ожидаемые товары и корректно сбрасывается.
• Карточка показывает цену, наличие и выбранный вариант по согласованным правилам.
• Корзина позволяет добавлять, удалять товар и менять количество.
• Оформление проходит по основному сценарию с доступной доставкой и оплатой.
• Ошибочные поля формы получают понятные сообщения.
• Неуспешная оплата не создаёт ложного подтверждения заказа.
• Повторное уведомление платёжного сервиса не создаёт дубликат операции.
• Заказ передаётся в учётную систему или CRM Битрикс24 с согласованными полями.
• Отмена и возврат проходят по описанным веткам.
• Мобильная версия проверена на согласованных устройствах и разрешениях.
• Права ограничивают цены, заказы и административные действия по ролям.
• Тестовый контур закрыт от индексации согласованным способом.
• Проверены URL, перенаправления, canonical, Sitemap и метаданные.
• Разметка Product совпадает с видимыми данными карточки.
• Интерфейс проверен по согласованным критериям доступности.
• Нагрузочный тест выполнен с утверждёнными порогами.
• Резервная копия доступна для восстановления, а процедура отката назначает ответственных и точки решения.
• Известные ограничения занесены в журнал до запуска.

robots.txt управляет обходом, но закрытый в нём URL всё ещё может участвовать в поиске Яндекса. Для удаления страницы Яндекс указывает на noindex в HTML или HTTP-заголовке при доступности страницы роботу. См. справку о robots.txt. Директива Sitemap в robots.txt задаёт путь к файлам Sitemap, но не подтверждает корректность URL и не гарантирует индексирование: документация Яндекса.

Запуск интернет-магазина и план отката

Запуск требует заранее описанного переключения: что меняется, кто принимает решение, как проверяют результат и при каких условиях останавливают работы. Результат этапа — рабочая версия на целевом контуре и зафиксированный итог контрольных проверок.

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

После переключения повторяют критические проверки каталога, корзины, тестового заказа, платёжного статуса, передачи заказа, перенаправлений и административных функций. LCP, CLS и INP входят в Core Web Vitals по документации web.dev, но эти показатели не заменяют функциональные и бизнес-проверки.

Передача интернет-магазина и поддержка

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

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

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

Матрица ответственности проекта интернет-магазина

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

Обозначения: R — выполняет; A — принимает итоговое решение; C — консультирует; I — получает информацию.

Работа	Заказчик	Аналитик	Дизайнер	Разработчик	Тестировщик
Цели, границы, критерии приёмки	A	R	I	I	C
Обследование процессов	C	A/R	I	C	C
ТЗ и карта интеграций	A	R	I	C	C
Прототип каталога и заказа	A	R	C	C	C
Дизайн экранов и состояний	A	C	R	C	C
Разработка и тестовый контур	I	C	C	A/R	C
Миграция и сверка данных	A	R	I	R	C
Приёмочное тестирование	A	C	C	C	R
Решение о запуске и откате	A	R	I	R	C
Передача и поддержка	A	R	I	C	C

FAQ по этапам разработки интернет-магазина

Можно ли написать ТЗ без полного списка товаров?

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

Когда подключать CRM Битрикс24?

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

Нужен ли прототип, если дизайн понятен по референсам?

Да, если референсы не описывают маршруты, ошибки, роли и состояния магазина. Прототип фиксирует эти правила до подготовки финальных макетов.

Можно ли проверять магазин на рабочем сайте?

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

Гарантирует ли Sitemap появление страниц в поиске?

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

Что считать результатом запуска интернет-магазина?

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

Официальные источники статьи

Факты подтверждены ссылками на документацию W3C, OWASP, Google, Яндекса, Grafana, ЮKassa и web.dev. Методика S-WEBS24 — проектный порядок, а не отраслевой стандарт.

Заключение по этапам разработки интернет-магазина

Управляемая разработка строится вокруг сценариев, карты данных, макетов, тестов, решения о запуске и переданного комплекта документов. Изменения становятся видны до спора о границах проекта.

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

Фактическая проверка: 21 августа 2026 года
Автор: S-WEBS24
Проверяющий: редакция S-WEBS24