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

Разработка интернет-магазина на Битрикс — это последовательность этапов, у каждого из которых есть входные данные, результат и способ проверки. Заказчику этапность нужна не для красоты отчёта: она позволяет принимать работу частями, понимать, за что именно заплачено, и замечать расхождения с задачей до того, как они превратятся в переделку. Ниже — что происходит на каждом этапе, какие решения принимает заказчик, где чаще всего возникают ошибки и как проверить результат до запуска.

Что считается этапом и какой у него результат

Этап — это не отрезок календаря, а законченный результат. Формулировка «идёт разработка» ничего не говорит ни заказчику, ни руководителю проекта. Рабочая единица выглядит иначе: есть входные данные, есть действия, есть артефакт на выходе, есть критерий приёмки и есть человек, отвечающий за результат.

Полезно заранее договориться о трёх вещах.

• Что считается готовым. Не «сделали каталог», а «каталог наполнен, фильтр работает, карточка товара отдаёт цену и остаток, менеджер видит товар в административной части».
• Кто принимает. Обычно это заказчик или выделенный представитель с правом решения. Если принимающих несколько, решения затягиваются, и это главный источник простоев на согласованиях.
• Что происходит с новыми пожеланиями. Любая новая идея, появившаяся в середине этапа, либо меняет объём и оценку, либо уходит в отдельный список и рассматривается после приёмки текущего шага.

В Битрикс значительная часть работы — это не написание кода с нуля, а настройка существующих модулей и связывание их между собой. Поэтому этапы часто идут не строго друг за другом, а с перекрытием: пока согласуется дизайн, уже можно готовить структуру каталога. Но приёмка всё равно идёт по результатам, а не по времени.

Отдельно стоит сказать про артефакты. У каждого этапа должен оставаться документ или настроенный объект, к которому можно вернуться: ТЗ, прототип, описание правил обмена, инструкция для сотрудника. Если результат существует только в переписке, при смене исполнителя или после паузы его придётся восстанавливать заново.

Этап 1. Аналитика и техническое задание

Первый этап отвечает на вопрос «что именно мы строим». В типовом порядке работы с магазином техническое задание стоит в самом начале — до настройки модулей и наполнения каталога. Это не формальность: ТЗ превращает «хочу магазин» в список проверяемых требований.

Что уточняют на этом этапе.

• Модель продаж. Розница, опт, гибрид, продажа услуг, подписки, продажа контента — от этого зависит структура каталога и логика оформления заказа.
• Ассортимент. Сколько товаров, есть ли варианты одного товара (размер, цвет, комплектация), нужны ли торговые предложения, как устроены разделы и свойства.
• Учёт. Какая система ведёт остатки и цены, сколько складов, нужно ли резервирование товаров, кто и когда выгружает данные.
• Деньги. Какие способы оплаты нужны, есть ли оплата по счёту для юридических лиц, нужны ли частичные оплаты и возвраты.
• Логистика. География доставки, самовывоз, расчёт стоимости, кто отвечает за передачу заказов в службу доставки.
• Права. Кто из сотрудников что видит и может менять: менеджер, контент-редактор, бухгалтер, администратор.
• Ограничения. Требования к обработке персональных данных, к фискализации, к маркировке товаров, к срокам хранения документов.

Развилка: типовые настройки или доработка

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

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

Типичные ошибки этапа

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

Проверка ТЗ на однозначность

Хороший критерий простой: передайте ТЗ исполнителю, который не участвовал в обсуждении, и попросите оценить объём. Если он задаёт те же вопросы, что и первый подрядчик, — в документе есть пробелы. Если оценка сопоставима, значит требования описаны достаточно однозначно. Из чего складывается стоимость такой работы, разбирается отдельно в материале Сколько стоит разработка интернет-магазина: из чего складывается цена.

Этап 2. Прототип и дизайн

Здесь задачу переводят в структуру страниц и внешний вид. Порядок важен: сначала согласуют логику и расположение блоков, потом оформление. Менять прототип дёшево, менять готовую вёрстку — дорого.

Что входит в этап.

• Карта страниц. Главная, каталог, раздел, карточка товара, корзина, оформление заказа, личный кабинет, информационные страницы.
• Прототипы ключевых сценариев. Путь от списка товаров до подтверждённого заказа, включая состояния «товара нет», «ошибка оплаты», «пустая корзина».
• Дизайн-макет. Визуальный стиль, типографика, поведение на разных размерах экрана.
• Мобильный сценарий. Отдельно проверяют, как выглядит и работает оформление заказа на небольшом экране.

Что решает заказчик на этом этапе

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

Проверка прототипа покупательским маршрутом

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

Этап 3. Каталог, торговые предложения и цены

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

Товары и торговые предложения

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

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

Фильтр и поиск

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

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

Цены, валюты и округление

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

Скидки и правила корзины

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

Проверка каталога на выборке товаров

Возьмите пять-семь реальных товаров разных типов — простой, с вариантами, со скидкой, отсутствующий на складе — и пройдите по ним весь путь до корзины. Проверьте, что цена, остаток и доступность совпадают с тем, что видит менеджер в административной части.

Этап 4. Оформление заказа, оплата и доставка

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

Сценарии оформления

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

Оплата и возвраты

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

Доставка и местоположения

Службы доставки настраиваются с привязкой к местоположениям: от этого зависит, какие варианты увидит покупатель из конкретного города. Самовывоз настраивается как отдельная служба со своими условиями. Если расчёт стоимости сложный, его описывают в ТЗ отдельным пунктом.

Статусы и уведомления

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

Проверка заказа по сценариям

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

Этап 5. Интеграции: 1С, CRM, кассы и маркировка

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

Обмен с учётной системой

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

Интеграция с CRM

Если продажи сопровождает отдел, заказы имеет смысл передавать в CRM, чтобы менеджер работал с ними в привычной среде. Настройка включает сопоставление сущностей и правила, по которым заказ попадает в воронку.

Кассы и маркировка

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

Проверка обмена с учётной системой

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

Этап 6. Контент, права доступа и тестирование

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

Права доступа

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

Тестирование

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

Проверка тестовых сценариев

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

Этап 7. Запуск, передача и поддержка

Запуск — это перенос на рабочий контур, финальная проверка и открытие доступа покупателям. Перед этим делают резервную копию, фиксируют текущее состояние и готовят план возврата на случай, если что-то пойдёт не так.

Что должно быть передано заказчику.

• Доступы к административной части и к панели управления хостингом.
• Исходные материалы: макеты, ТЗ, инструкции для сотрудников.
• Описание того, как выполняются регулярные операции: обмен с учётом, обработка заказа, изменение цен.
• Контакты ответственных и порядок обращения при сбое.

После запуска магазин не заканчивается. Меняются цены, добавляются товары, обновляются правила доставки, появляются новые требования. Без сопровождения магазин постепенно расходится с процессами компании. Что входит в такую работу и как её планировать, разбирается в материале Поддержка интернет-магазина после запуска: зачем и сколько стоит.

Проверка передачи и самостоятельных операций

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

Сравнительная таблица этапов

Как этапность защищает от долгостроя

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

Этапность лечит это тремя вещами.

• Границы объёма. Новое пожелание не растворяется в текущей работе, а становится отдельной задачей с собственной оценкой.
• Точки приёмки. Заказчик видит результат регулярно, а не один раз в конце, когда менять что-либо дорого.
• Понятная ответственность. У каждого этапа есть владелец со стороны подрядчика и со стороны заказчика.

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

Учебный пример: магазин с двумя складами

Учебный пример. Данные условные и приведены для иллюстрации порядка работы, а не как статистика.

Исходные условия. Компания продаёт инструмент и расходные материалы, около 1200 позиций, часть товаров имеет варианты по размеру. Два склада в разных городах, учёт ведётся во внешней системе. Нужны самовывоз, доставка в регионы, оплата картой и по счёту для юридических лиц. В компании три роли: менеджер по продажам, контент-редактор, руководитель.

Как разворачивается работа по этапам.

1. Аналитика. Выясняется, что часть товаров продаётся наборами, а часть — поштучно, и что остатки по двум складам нужно показывать раздельно. Эти два факта меняют структуру каталога и правила резервирования, поэтому они попадают в ТЗ до начала настройки. 2. Прототип. На прототипе видно, что выбор склада в карточке товара сбивает покупателя. Решение: склад выбирается автоматически по адресу доставки, а покупатель видит только итоговую доступность. Правка на прототипе занимает минуты, в готовой вёрстке — дни. 3. Каталог. Товары с вариантами переводятся в торговые предложения, остальные остаются простыми. Свойства, по которым покупатели ищут, выводятся в умный фильтр; остальные остаются в карточке. 4. Заказ и оплата. Настраиваются два типа плательщика: физическое и юридическое лицо. Для юридического лица добавляется оплата по счёту и свои поля в заказе. 5. Интеграции. Определяется источник истины: цены и остатки приходят из учётной системы, описания и фотографии редактируются на сайте. Это правило фиксируется, чтобы правки не затирались при обмене. 6. Тестирование. Прогоняются сценарии: заказ с самовывозом, заказ в другой регион, заказ с товаром, которого нет на одном складе, но есть на другом, оплата картой и оплата по счёту. 7. Запуск. Перед открытием делается копия, проверяется обмен, сотрудники проходят короткое обучение по обработке заказа.

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

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

Чек-лист приёмки этапов

• ТЗ описывает не только основной сценарий, но и исключения: нет товара, не прошла оплата, адрес вне зоны доставки.
• В ТЗ указан источник истины по каждому полю: цена, остаток, описание, характеристики.
• Прототип пройден как покупатель, включая мобильный экран.
• Определено, какие товары становятся торговыми предложениями, а какие остаются простыми.
• Свойства для фильтра отобраны осознанно, пустая выдача после выбора двух характеристик исключена.
• Правила скидок и купонов описаны с приоритетами: что суммируется, что отменяет друг друга.
• Типы цен и правила округления зафиксированы письменно.
• Тестовые заказы сделаны по каждому сценарию оплаты и доставки.
• Уведомления о заказе приходят покупателю и сотрудникам.
• Обмен с учётной системой проверен на выборке товаров и на изменении цены.
• Права доступа разграничены: редактор не меняет цены, подрядчик не работает с боевыми заказами.
• Перед запуском сделана резервная копия и описан план возврата.
• Заказчику переданы доступы, исходные материалы и инструкции по регулярным операциям.
• Сотрудник заказчика самостоятельно выполнил базовые операции без подсказок подрядчика.

Частые вопросы

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