Составление технического задания на разработку сайта 1С-Битрикс

Представьте: вы запускаете интернет-магазин на 1С-Битрикс. Каталог на 15 000 товаров, интеграция с 1С, B2B-кабинет для дилеров. Разработчик спрашивает: «а как фильтровать по остаткам?» — и выясняется, что нигде не прописано, что цены должны быть индивидуальными для каждой группы дилеров. Итог: переделка фильтра и личного кабинета добавляет 40% к смете. По нашей статистике, 80% проблем с производительностью возникают из-за нечёткого описания инфоблоков, а доработки на этапе разработки обходятся в 3-5 раз дороже, чем исправление в ТЗ. Именно поэтому мы составляем техническое задание, которое фиксирует все требования до старта разработки. Закажите составление ТЗ — мы подготовим документ, который сэкономит вам до 50% бюджета и устранит разночтения между вами и разработчиком.

Какие разделы обязательно должны быть в ТЗ для Битрикс?

ТЗ на Битрикс-проект отличается от ТЗ на произвольный сайт. Помимо стандартных разделов (цели, аудитория, функциональные требования), необходимы специфичные секции.

Редакция и лицензирование

Указывается редакция Битрикс (Старт, Стандарт, Малый бизнес, Бизнес, Энтерпрайз), обоснование выбора. Для интернет-магазина минимум — Малый бизнес (модуль catalog, торговые предложения, один прайс-лист). Если нужен расширенный каталог с несколькими типами цен, скидки по правилам (sale.discount), агрегация остатков по складам — Бизнес или Энтерпрайз.

Структура инфоблоков

Перечисляются все инфоблоки с типами свойств. Именно здесь принимается решение, которое потом нельзя безболезненно изменить: тип свойства «Строка» vs «Справочник» (HL-блок). Для каждого инфоблока — таблица:

Интеграции

Обмен с 1С описывается отдельно: направление синхронизации (двусторонний или только выгрузка из 1С), периодичность, что синхронизируется (остатки, цены, изображения, свойства). Ошибка — написать просто «интеграция с 1С». Нужно: какая конфигурация 1С, стандартный обмен через CommerceML или кастомная интеграция через API, маппинг полей.

Производительность

SLA по времени ответа страниц: раздел каталога ≤ N секунд при M одновременных пользователях. Это единственный способ формализовать требования к производительности — без этого раздела претензии по скорости невозможно предъявить.

Как избежать ошибок при проектировании ТЗ?

Структурированное ТЗ сокращает доработки в 3-5 раз по сравнению с устными договорённостями. Формальное ТЗ эффективнее: доработки возникают только в 10% проектов против 70% при устных договорённостях, что экономит 30–50% бюджета. Мы рекомендуем включать пользовательские сценарии и технические требования, которые часто упускают.

Проектирование пользовательских сценариев

ТЗ без сценариев описывает систему, но не работу людей. Для Битрикс-проекта важны:

• Оформление заказа: количество шагов, авторизация, способы доставки/оплаты, поведение корзины для незалогиненных пользователей.
• Личный кабинет: история заказов из b_sale_order, статусы, возможность повторного заказа.
• Административный сценарий: как менеджер добавляет товар, редактирует цену, обрабатывает заказ.

Каждый сценарий описывается последовательно с указанием компонентов Битрикс или отметкой «кастомная разработка».

Типичные упущения в ТЗ

• Роли пользователей и права: Битрикс использует группы и систему прав на инфоблоки, разделы, компоненты. Для B2B-кабинета или дилерского раздела матрица доступа должна быть в ТЗ.
• SEO-технические требования: ЧПУ, мета-теги, robots.txt, sitemap.xml — настраиваются через модуль seo. Без явных требований ставятся дефолтные.
• Многоязычность: для нескольких языков прописывается структура языковых сайтов в одном ядре, маппинг контента, локали для дат и валют.

Почему без ТЗ растёт бюджет?

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

• Дилерам нужны индивидуальные цены (три типа цен по группам), а разработчик реализовал один прайс.
• Фильтр не учитывал остатки на складе — товары без остатка появлялись в результатах.
• Личный кабинет показывал только заказы через сайт, а дилеры ожидали историю из 1С.

Доработка заняла 3 месяца при бюджете исходной разработки в 6 недель. Если бы требования были формализованы в ТЗ до начала работ — объём и стоимость были бы оценены корректно. Формальное ТЗ в 3-5 раз эффективнее устных договорённостей: доработки возникают только в 10% проектов вместо 70%.

Как мы составляем ТЗ: пошаговый процесс

1. Интервью с заказчиком: выявляем бизнес-процессы, пользователей, интеграции.
2. Анализ существующих систем (1С, CRM, склад).
3. Проектирование структуры инфоблоков и свойств.
4. Описание пользовательских сценариев для всех ролей.
5. Формирование функциональных требований с привязкой к компонентам и модулям Битрикс.
6. Определение нефункциональных требований: производительность, безопасность, масштабирование.
7. Прототипирование ключевых экранов (wireframes).
8. Согласование и финализация документа.

Объём ТЗ для типичного интернет-магазина — 40–80 страниц. Сроки подготовки: от 2 недель для небольшого проекта до 6–8 недель для сложного многофункционального портала с несколькими интеграциями.

Что входит в работу

Правильно составленное ТЗ — это гарантия прозрачного бюджета и предсказуемого результата. Наш опыт более 10 лет в разработке на Битрикс обеспечивает качество документации. Дополнительную информацию можно найти в соответствующих статьях на Wikipedia и Wikipedia (1С-Битрикс).

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