Разработка
Сайт на 1С-Битрикс: ТЗ на каталог, обмен и сопровождение
Какие требования подготовить к сайту на 1С-Битрикс: редакция и модули, каталог, обмен с 1С, статусы заказов, среда и приёмочные сценарии.
Зафиксируйте задачу сайта и выбранный продукт
ТЗ на сайт на 1С-Битрикс должно объяснять, какие рабочие задачи решает проект и что именно входит в поставку. Название платформы не определяет структуру каталога, правила заказа, обмен с учётной системой и работу редактора. Начните с основного пути посетителя: найти услугу, сравнить товары, получить расчёт, отправить заявку или оформить покупку. Опишите результат для бизнеса и пользователя без обещаний конкретного роста. Затем отделите обязательные возможности первой версии от пожеланий, которые можно рассматривать после запуска.
Уточните продукт, редакцию и состав установленных решений. «1С-Битрикс: Управление сайтом» и Битрикс24 решают разные задачи; их названия нельзя использовать как взаимозаменяемые. Зафиксируйте, создаётся новый сайт или развивается существующий, кто владеет лицензией и какие модули уже приобретены. Для стороннего решения нужны название, версия, поставщик и условия обновления. Это позволяет оценить реальный объём доработок вместо предположения, что любая функция из демонстрации доступна в текущей конфигурации проекта.
Соберите ограничения: срок, бюджетный диапазон, ответственные, обязательные интеграции и допустимые изменения существующего сайта. Если нужно сохранить адреса, структуру и оформление, внесите это в явный перечень. Приложите примеры страниц, которые нельзя менять без отдельного согласования. При переработке проекта полезно разделить исправление дефектов, обновление платформы и новые функции. Эти работы могут иметь разные риски и критерии приёмки, даже если выполняются одним подрядчиком в рамках общего календаря.
Подготовьте структуру контента и каталога
Для каждого типа страницы определите назначение, обязательные поля и владельца содержания. Главная, услуга, товар, категория, статья и контактная страница требуют разных данных. Не ограничивайтесь картинкой шаблона: редактору нужно понимать, как добавить новый материал и какие поля обязательны. Укажите ограничения длины, варианты изображений, повторно используемые блоки и порядок публикации. Если контент ещё не готов, зафиксируйте объём подготовки и ответственного, иначе задержка наполнения окажется скрытой зависимостью запуска.
Для каталога разделите товар и торговое предложение. Размер, цвет или комплектация могут влиять на остаток, цену, фотографию и возможность заказа. Приложите несколько сложных примеров, включая товар без вариантов, товар с несколькими свойствами и позицию, временно отсутствующую в продаже. Определите, какие характеристики участвуют в фильтре и сравнении, а какие только отображаются. Непоследовательные названия и единицы измерения следует исправить в исходных данных, а не компенсировать случайными правилами на каждой странице.
Зафиксируйте правила адресов и навигации до массового наполнения. У категории может быть несколько путей отображения, но индексируемый адрес товара должен оставаться согласованным. При переносе старого каталога подготовьте карту соответствия URL и перечень исключений. Не удаляйте автоматически страницы отсутствующих товаров без анализа их роли и ссылок. Для фильтров и сортировок задайте правила индексации отдельно: большое количество технических комбинаций не означает такое же количество полезных самостоятельных страниц для поиска.
Опишите обмен с 1С как контракт данных
Название «интеграция с 1С» не задаёт состав обмена. Укажите конфигурацию учётной системы, её версию, владельца доработок и фактически используемый механизм передачи. Перечислите справочники, товары, предложения, цены, остатки, заказы и статусы, которые входят в первую очередь. Для каждого поля выберите основной источник. Если цена редактируется на сайте и в учётной системе, правило разрешения конфликта должно быть согласовано заранее, иначе очередная синхронизация может отменить ручное изменение.
В официальных материалах 1С-Битрикс обмен с 1С связан с поддерживаемыми редакциями продукта. Поэтому совместимость необходимо подтверждать для конкретной связки, а не выводить из общего названия платформы. В ТЗ сохраните результат этой проверки и ограничения выбранного решения. Не обещайте работу всех свойств сторонней конфигурации без тестового обмена. Для оценки подготовьте обезличенную выгрузку с характерными товарами и заказами, чтобы разработчик видел реальные идентификаторы, связи и нестандартные значения.
Опишите повтор, частичную ошибку и задержку. Если пакет загрузился не полностью, какие данные можно показывать покупателю? Что происходит с заказом, созданным во время обмена? Как обнаружить пропущенную запись и повторить обработку без дубля? Эти сценарии должны иметь наблюдаемый результат и владельца разбора. Приложите правила сверки количества объектов и контрольных бизнес-показателей. Успешный ответ транспорта подтверждает передачу данных, но не обязательно означает, что все изменения корректно применены на принимающей стороне.
Согласуйте заказ, оплату и доставку
Для магазина опишите состав корзины и правила пересчёта. Цена, наличие, скидка и доставка могут измениться между добавлением товара и подтверждением заказа. Пользователь должен видеть актуальные условия до окончательного действия. Определите, когда резервируется остаток, кто может изменить заказ и как обрабатывается разделение на несколько отправлений. Учебный пример с двумя товарами, один из которых недоступен, помогает проверить эти решения лучше, чем демонстрационная покупка единственной позиции с идеальными данными.
Отделите создание заказа от подтверждённой оплаты. Возврат пользователя на страницу успеха не всегда является достоверным источником финансового статуса; используйте предусмотренный контрактом платёжного сервиса способ проверки. В ТЗ нужны состояния ожидания, отказа, неизвестного результата и возврата. Не повторяйте автоматически финансовое действие только потому, что браузер не получил ответ. Опишите, как сотрудник сверяет спорную операцию и что в это время видит клиент. Конкретные требования провайдера проверяются отдельно перед подключением.
Для доставки задайте поддерживаемые способы, зоны, ограничения и источник расчёта. Если внешний сервис недоступен, сайт должен предложить согласованный безопасный путь: отложить расчёт, оформить запрос сотруднику или показать понятное ограничение. Не подставляйте выдуманную стоимость ради завершения формы. Проверьте длинные адреса, изменение пункта выдачи, несколько мест в заказе и недоступность выбранного способа для конкретного товара. Уведомления клиенту должны соответствовать подтверждённым состояниям, а не промежуточной попытке получить данные.
Уточните среду и эксплуатационные требования
Официальная страница технических требований 1С-Битрикс указывает требования к серверному окружению и предоставляет средство проверки хостинга. Это исходная точка, но не готовый расчёт ресурсов под конкретный каталог и посещаемость. Перед запуском зафиксируйте совместимые версии компонентов, расширения и ограничения хостинга. Не переносите старую конфигурацию автоматически на новое окружение. Проверка должна учитывать установленные модули, обработку изображений, фоновые задания и обмен, которые могут предъявлять дополнительные требования к памяти и времени выполнения.
Нагрузку задавайте через операции: просмотр категории с фильтрами, поиск, пересчёт корзины, импорт каталога, сохранение товара редактором. Укажите объём данных и число одновременных пользователей, для которых измеряется время ответа. Проверяйте совместную работу фонового обмена и посетителей. Быстрая главная страница на пустой базе не подтверждает устойчивость магазина. Для тяжёлых операций нужны ограничения и наблюдение, чтобы одна выгрузка или неудачный запрос не делали недоступным весь рабочий сайт во время продаж.
Опишите резервное копирование и восстановление. Сохранять копию недостаточно: нужно проверить возврат базы, файлов и конфигурации в отдельной среде. Укажите допустимую потерю новых данных, время восстановления и ответственного. Перед обновлением платформы или модулей выполняйте проверку на копии. План возврата должен учитывать заказы, появившиеся после переключения версии. Простая замена файлов на старые не гарантирует совместимость с изменённой структурой данных и не должна называться полным восстановлением без проверки.
Подготовьте управление и доступы
Опишите роли редактора, контент-менеджера, оператора заказов и администратора. У каждого должна быть достаточная область работы без лишних возможностей. Редактору статьи не обязательно управлять интеграциями, а оператору заказов — менять шаблоны сайта. Проверьте ограничения через реальные действия, включая массовые операции и экспорт. Передача одного общего административного пароля всем участникам усложняет ответственность и отзыв доступа. Список учётных записей и владельцев должен входить в комплект передачи проекта заказчику.
Согласуйте редакционный сценарий от черновика до публикации. Кто проверяет цену, описание, изображения и юридически значимые сведения? Можно ли предварительно посмотреть страницу и вернуться к прошлой версии? Приложите пример самостоятельного добавления материала сотрудником без участия разработчика. Если для обычного обновления услуги требуется правка кода, это должно быть осознанным ограничением, а не неожиданностью после приёмки. Инструкция должна описывать конкретную рабочую операцию, а не только расположение пунктов административного меню.
Для файлов, форм и комментариев определите правила проверки, доступа и хранения. Не собирайте лишние поля только потому, что их легко добавить. Укажите цель каждого обязательного значения и получателя заявки. Формы должны объяснять ошибку и сохранять уже введённые данные там, где это допустимо. На мобильном устройстве проверьте клавиатуру, вложения, длинный текст и повторное нажатие отправки. Подтверждение на экране должно соответствовать реальному сохранению обращения, а не только выполнению клиентской анимации.
Соберите доказательства для приёмки
Приёмочный набор должен охватывать обычный путь и исключения. Добавьте создание и редактирование контента, поиск, фильтры, заказ, отказ оплаты, ошибку доставки, повтор обмена и ограничение доступа. Для каждого сценария укажите исходное состояние, действие, ожидаемый результат и место проверки. Не принимайте интеграцию только по факту успешного импорта одного товара. Нужны сложные примеры, на которых проявляются связи предложений, изменение остатков, удаление значения и повторная обработка уже полученного пакета данных.
Отдельно проверьте техническую публикацию: ответы страниц, canonical, robots, sitemap, перенаправления и внутренние ссылки. Сравните старые значимые URL с новыми. Посмотрите карточки и формы на телефоне и компьютере, включая состояния ошибки. Проверка разметки и сборки не заменяет визуальную оценку: обрезанный заголовок, перекрытая кнопка или недоступное закрытие окна остаются дефектами. Сохраняйте версию, дату и результаты, чтобы после исправления можно было повторить затронутые проверки на той же основе.
Разделите блокеры запуска и допустимые замечания с согласованными сроками. Потеря заказа, неверная цена или раскрытие данных не должны закрываться общей фразой «почти всё готово». Для менее критичных недочётов назначьте владельца и способ подтверждения исправления. Приёмка становится предметной, когда каждая сторона видит конкретное поведение и доказательство. Процент выполненных пунктов полезен для управления работой, но не отменяет значения одного оставшегося критического сценария, влияющего на клиентов и сотрудников.
Передайте сайт как поддерживаемый продукт
В итоговый комплект включите исходники, настройки окружения без раскрытия секретов, перечень лицензий, модулей и интеграций, инструкции обновления и восстановления. Укажите владельцев домена, хостинга, аналитики и платёжного подключения. Зафиксируйте границы поддержки: какие ошибки входят в сопровождение, как принимаются новые задачи и кто согласует обновления. Если сторонний модуль перестанет поддерживаться, команда должна понимать зависимость и возможный порядок замены, а не обнаруживать её только при аварийном обновлении платформы.
После запуска наблюдайте за основными операциями и фоновым обменом. Ошибки передачи, возраст очереди, недоступные страницы и проблемы оформления требуют отдельного внимания. Аналитику продаж сверяйте с источником подтверждённых заказов и оплат. Не считайте каждое открытие формы заявкой и не заменяйте неизвестные значения нулями. Регулярный короткий отчёт должен показывать, что произошло, на какие данные он опирается и какое действие требуется владельцу. Это полезнее общего уведомления «всё работает» без проверяемых оснований.
Заполняемый бриф в источниках статьи помогает собрать структуру, данные, обмен и приёмку в одном документе. Перед оценкой приложите несколько характерных товаров, схему заказа и перечень текущих модулей. Хорошее ТЗ не сводится к выбору платформы: оно объясняет, как сайт будет обслуживать реальный процесс и кто поддержит его после передачи. Тогда разработка и обновления опираются на согласованные правила, а результат можно проверить независимо от того, насколько убедительно выглядит демонстрационная версия магазина.
Источники
- Технические требования «1С-Битрикс: Управление сайтом»
1С-Битрикс / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Требования к интеграции с 1С
1С-Битрикс / доступ 2026-10-18
Первичный источник для соответствующих принципов и технических свойств. Структура требований и учебные примеры подготовлены редакцией; конкретная конфигурация проверяется отдельно.
- Скачать заполняемый бриф / ТЗ (.txt)
Малевич — практическое приложение / доступ 2026-10-18
Сохраните файл и заполните данные проекта, открытые решения и критерии приёмки.
FAQ
Одинаково ли ТЗ для сайта на 1С-Битрикс и CRM Битрикс24?
Нет. Это разные продукты и предметы работ. В начале документа укажите конкретную систему, редакцию и границы интеграции, чтобы не смешивать управление сайтом с процессами CRM.
Можно ли обещать обмен с любой конфигурацией 1С?
Такое обещание без проверки некорректно. Нужны точные версии и конфигурации, состав данных, поддерживаемый механизм обмена и контрольная проверка на согласованном примере.
Что проверить при повторной загрузке каталога?
Сохранение идентификаторов и связей, отсутствие дублей, поведение удалённых предложений, обновление цен и остатков, а также защиту полей, которыми управляет другая сторона.
