Большинство провальных проектов проваливаются не на этапе кодинга, а до него — когда команда бросается «делать сайт», не выяснив, что именно и зачем строится. Через месяц всплывает, что каталог устроен не так, обмен с 1С работает иначе, а нагрузку никто не считал. Начинаются переделки, сроки плывут, бюджет растёт, а отношения между заказчиком и исполнителем портятся.
Всего этого можно избежать, потратив время на discovery — этап исследования и проектирования до старта разработки. Разберём, что именно нужно выяснить перед тем, как писать первую строчку кода интернет-магазина на 1С-Битрикс, и почему этот этап окупается многократно. Если вы планируете сложный проект с интеграцией, начать стоит с аудита и оптимизации 1С — понять, с чем предстоит работать.
Коротко
- Discovery — этап исследования до кодинга: цели, сценарии, интеграции, модель данных и риски.
- Ошибки архитектуры и данных дороже всего исправлять, поэтому их выясняют до старта, а не в процессе.
- Интеграцию с 1С и модель каталога/цен обсуждают в первую очередь — они определяют весь проект.
- Результат discovery — осязаемые документы: ТЗ, архитектура, карта интеграций, риски, оценка сроков и бюджета.
Что такое discovery и зачем он нужен
Discovery (от англ. «исследование, обнаружение») — этап, на котором команда до начала разработки выясняет, что и зачем строится: цели бизнеса, сценарии пользователей, требования к интеграциям, модель данных, нагрузку и риски. Это не «разговоры», а предметная работа с конкретным результатом в виде документов.
Смысл прост: ошибки, найденные на discovery, стоят копейки, а те же ошибки, найденные в разработке или после запуска, — дорого. Изменить строчку в документе легко, переделать спроектированный не так каталог с тысячами товаров — мучительно. Discovery переносит выяснение вопросов на самый дешёвый этап и делает проект предсказуемым.
Цели бизнеса и метрики успеха
Discovery начинается не с функций, а с целей. «Хочу интернет-магазин» — не цель, а средство. Настоящие цели звучат иначе: увеличить онлайн-продажи, снять нагрузку с менеджеров, выйти в новый сегмент, автоматизировать опт. От целей зависит, что вообще стоит строить.
- Бизнес-цель. Зачем проект и какую проблему он решает в деньгах или процессах.
- Метрики успеха. Как поймём, что проект удался: рост продаж, снижение доли ручной работы, скорость обработки заказов.
- Приоритеты. Что важнее — быстрый запуск, максимум функций или интеграция с учётом.
- Ограничения. Бюджет, сроки, имеющиеся системы, с которыми надо жить.
Без чётких целей проект скатывается в бесконечный список «хотелок», где невозможно расставить приоритеты. Цели — это фильтр, через который проходит каждое решение.
Сценарии пользователей и роли
Дальше выясняют, кто и как будет пользоваться системой. У магазина не один пользователь: розничный покупатель, оптовый закупщик, менеджер, контент-редактор, бухгалтер. У каждого свои сценарии, и их надо описать до проектирования интерфейсов.
- Роли пользователей. Кто взаимодействует с системой и с какими правами.
- Ключевые сценарии. Как покупатель находит товар и оформляет заказ, как менеджер его обрабатывает.
- Особые случаи. Опт, повторные заказы, работа по спецификации, согласования.
- Точки боли. Что раздражает пользователей сейчас и что надо исправить.
Сценарии — мост между целями бизнеса и конкретными функциями. Именно из них потом рождаются требования и дизайн, а не наоборот.
Интеграция с 1С и модель обмена
Для магазина на 1С-Битрикс интеграция с учётной системой — не деталь, а фундамент. Обмен с 1С определяет, как приходят товары, цены, остатки и заказы, какие свойства и единицы измерения есть в учёте. Если это выяснить в конце, окажется, что каталог спроектирован не под реальный обмен.
- Конфигурация 1С. Какая версия и конфигурация, как устроена номенклатура, цены, склады.
- Формат обмена. Обмен CommerceML, состав выгружаемых данных, что и как приходит на сайт.
- Частота синхронизации. Как часто обновляются остатки и цены, насколько критична актуальность.
- Обратный обмен. Как заказы уходят в 1С, какие статусы и документы возвращаются.
Разобраться в обмене надо до проектирования каталога, потому что модель данных сайта должна лечь на модель данных 1С. Технические тонкости интеграции — отдельная большая тема; надёжность обратного обмена и приёма уведомлений мы разбирали в статье про безопасность REST и вебхуков в 1С-Битрикс.
Модель каталога, цен и остатков
На основе понимания 1С проектируют модель каталога. Здесь всплывает специфика бизнеса, которую нельзя угадать: разные единицы измерения, кратность упаковок, торговые предложения, типы цен для разных групп клиентов, наличие по складам.
- Структура товаров. Простые товары или с вариантами (торговые предложения), какие свойства и характеристики.
- Единицы и кратность. В чём продаётся товар, есть ли фасовки и упаковки с кратностью.
- Модель цен. Одна цена или разные для групп клиентов, скидки, оптовые условия.
- Остатки и склады. Один склад или несколько, нужен ли разрез наличия по складам.
Ошибка в модели каталога — одна из самых дорогих: она пронизывает фильтр, карточку, корзину и обмен. Поэтому её проектируют тщательно и до старта разработки, а не по ходу. Если товарный учёт, цены и остатки в 1С требуют предварительной чистки, это закрывает автоматизация продаж и склада на 1С ещё на подготовительном этапе.
Нагрузка, инфраструктура и производительность
Магазин на 10 тысяч товаров и на 500 тысяч — разные проекты с разными требованиями к архитектуре. На discovery выясняют масштаб и нагрузку, чтобы не построить систему, которая ляжет в первую распродажу.
| Что выясняем | На что влияет |
|---|---|
| Размер каталога | Индексы, фасетный индекс, скорость фильтра |
| Посетители и заказы в пик | Мощность сервера, кэширование |
| Сезонные всплески | Запас производительности, композитный сайт |
| Размещение проекта | Выбор хостинга и инфраструктуры |
От ответов зависят решения по кэшированию, композитному сайту и серверу. Требования к инфраструктуре лучше заложить сразу — как её выстраивать, мы разбирали в материале про хостинг и инфраструктуру для 1С-Битрикс на BitrixVM. А чтобы разработка и выкладка шли предсказуемо, полезно заранее продумать процесс деплоя, описанный в статье про CI/CD и деплой для 1С-Битрикс.
Внешние интеграции и сервисы
Магазин редко живёт в вакууме. Кроме 1С, к нему подключаются платёжные системы, службы доставки, CRM, аналитика, маркетинговые сервисы, фискализация. Каждая интеграция — это работа и риск, поэтому их выясняют заранее.
- Платежи и фискализация. Какие платёжные системы, как устроен чек по 54-ФЗ.
- Доставка. Какие службы, расчёт стоимости и сроков, пункты выдачи.
- CRM и маркетинг. Куда уходят заявки и заказы, какие рассылки и триггеры.
- Прочие сервисы. Аналитика, чаты, отзывы, внешние каталоги и маркетплейсы.
Составленная на discovery карта интеграций показывает реальный объём работ. Часто именно интеграции, а не сам магазин, оказываются самой трудоёмкой частью проекта.
Требования закона и безопасности
Отдельный блок discovery — юридические и охранные требования, которые проще заложить сразу, чем прикручивать потом. Для интернет-магазина это работа с персональными данными (152-ФЗ), согласия на cookie, хранение данных в РФ, чек по 54-ФЗ, защита от несанкционированного доступа.
- Персональные данные. Что собирается, на каком основании, где хранится.
- Согласия. Cookie-баннер, политика конфиденциальности, журнал согласий.
- Фискализация. Порядок чека по 54-ФЗ для ваших товаров.
- Безопасность. Требования к доступам, защите данных, устойчивости к атакам.
Риски и как их снизить
Зрелый discovery не прячет риски, а выявляет их. Риск — это то, что может пойти не так: сложный обмен с нестандартной 1С, неопределённость с нагрузкой, зависимость от внешнего сервиса, нехватка данных о процессах.
По каждому существенному риску команда предлагает способ его снизить: сделать прототип интеграции заранее, заложить запас производительности, разбить проект на этапы, уточнить процессы с операционными сотрудниками. Открыто названный риск управляем, а замолчанный — превращается в сюрприз в разгар разработки. Именно честная работа с рисками отличает продуманный проект от авантюры.
Приоритеты и объём первого релиза
Discovery почти всегда показывает, что хочется больше, чем разумно делать сразу. Поэтому его важная часть — расстановка приоритетов и определение объёма первого релиза (MVP). Не «всё и сразу», а то, что даёт бизнес-ценность быстрее всего.
- Разделите обязательное и желаемое. Что нужно для запуска, а что можно добавить потом.
- Оцените ценность и стоимость. Приоритет — тому, что даёт максимум пользы при разумных затратах.
- Спланируйте этапы. Первый релиз, затем итерации развития по приоритетам.
- Зафиксируйте объём. Чёткие границы первого релиза защищают сроки и бюджет.
Частые ошибки на старте проекта
- Пропуск discovery. «Начнём делать, по ходу разберёмся» — прямой путь к переделкам.
- Функции вместо целей. Составляют список «хотелок», не понимая, зачем проект.
- Интеграцию с 1С оставляют на потом. Каталог проектируют, не зная реального обмена.
- Не считают нагрузку. Строят систему, которая ляжет в первую распродажу.
- Не зовут операционных сотрудников. Критичные детали процессов остаются неизвестны.
- Молчат о рисках. Сложности замалчиваются и всплывают в разгар работы.
- Пытаются сделать всё сразу. Нет приоритетов и границ первого релиза — сроки плывут.
Чек-лист discovery-этапа
- Цели и метрики определены. Понятно, зачем проект и как измерим успех.
- Сценарии описаны. Роли пользователей и их ключевые пути ясны.
- Интеграция с 1С разобрана. Конфигурация, обмен, состав данных, частота, обратный обмен.
- Модель каталога спроектирована. Товары, единицы, кратность, цены по группам, остатки.
- Нагрузка оценена. Размер каталога, пики, инфраструктура и требования к скорости.
- Карта интеграций готова. Платежи, доставка, CRM, аналитика, прочие сервисы.
- Закон и безопасность учтены. Персональные данные, согласия, 54-ФЗ, защита.
- Риски и приоритеты зафиксированы. Способы снижения рисков и объём первого релиза.
Вывод
Discovery — это не бюрократия и не задержка старта, а самая выгодная инвестиция в проект. За относительно небольшие деньги вы выясняете то, что иначе всплывёт в разгар разработки и обойдётся в разы дороже: как устроен обмен с 1С, какова модель каталога и цен, какая нагрузка, какие интеграции и риски. Ошибка на бумаге стоит копейки, ошибка в коде — дорого, ошибка после запуска — очень дорого.
Для магазина на 1С-Битрикс с реальной интеграцией и нестандартным каталогом discovery особенно важен: именно данные и обмен определяют весь проект. Потратьте время на исследование до старта, соберите осязаемые артефакты — ТЗ, архитектуру, карту интеграций, оценку — и разработка пойдёт предсказуемо, в срок и без болезненных переделок. Хороший старт стоит того, чтобы не спешить.
