Складання технічного завдання на розробку сайту 1С-Бітрікс
Проєкт без ТЗ — це проєкт з ТЗ, написаним постфактум у листуванні. Розробник пам'ятає одне, замовник очікував інше, а підсумкова суперечка про те, «чи входило це до scope», з'їдає бюджет і відносини. Специфіка 1С-Бітрікс погіршує проблему: платформа має власну архітектуру (інфоблоки, компоненти, модулі, обмін з 1С), і якщо в ТЗ написано «каталог товарів з фільтрацією», не уточнивши тип властивостей і фасетний індекс, — розробник реалізує мінімальний варіант, а замовник отримає фільтр, що працює 8 секунд на 20 000 SKU.
Структура ТЗ для Бітрікс-проєкту
ТЗ на Бітрікс-проєкт не рівнозначне ТЗ на довільний сайт. Крім стандартних розділів (цілі, аудиторія, функціональні вимоги), необхідні Бітрікс-специфічні секції.
Розділ: Редакція та ліцензування
Вказується редакція Бітрікс («Старт», «Стандарт», «Малий бізнес», «Бізнес», «Ентерпрайз»), обґрунтування вибору. Для інтернет-магазину мінімум — «Малий бізнес» (модуль catalog, торгові пропозиції, 1 прайс-лист). Якщо потрібен розширений каталог з кількома типами цін, знижки за правилами (sale.discount), агрегація залишків за складами — «Бізнес» або «Ентерпрайз».
Розділ: Структура інфоблоків
Перелічуються всі інфоблоки з типами властивостей. Саме тут приймається рішення, яке потім неможливо безболісно змінити: тип властивості «Рядок» vs «Довідник» (HL-блок). Для кожного інфоблоку — таблиця:
| Властивість | Тип | Множинне | Бере участь у фільтрі |
|---|---|---|---|
| Бренд | Довідник (HL) | Ні | Так |
| Колір | Список | Так | Так |
| Опис | HTML/текст | Ні | Ні |
Розділ: Інтеграції
Обмін з 1С описується окремо: напрямок синхронізації (двосторонній або лише вивантаження з 1С), periodичність, що синхронізується (залишки, ціни, зображення, властивості). Помилка — написати просто «інтеграція з 1С». Потрібно: яка конфігурація 1С, стандартний обмін через CommerceML або кастомна інтеграція через API, маппінг полів.
Розділ: Продуктивність
SLA за часом відповіді сторінок: розділ каталогу ≤ N секунд при M одночасних користувачах. Це єдиний спосіб формалізувати вимоги до продуктивності — без цього розділу претензії щодо швидкості неможливо пред'явити.
Проектування користувацьких сценаріїв
ТЗ без користувацьких сценаріїв описує систему, але не те, як у ній працюють люди. Для Бітрікс-проєктів сценарії особливо важливі для:
- Оформлення замовлення: скільки кроків, авторизація обов'язкова чи ні, способи доставки/оплати, поведінка кошика для незалогіненого користувача
- Особистий кабінет: історія замовлень з
b_sale_order, статуси, можливість повторного замовлення - Адміністративний сценарій: як менеджер додає товар, редагує ціну, обробляє замовлення
Кожен сценарій описується у вигляді послідовності кроків із зазначенням компонентів Бітрікс, які задіяні, або з позначкою «кастомна розробка».
Що часто упускають
Ролі користувачів та права. Бітрікс має групи користувачів та систему прав на інфоблоки, розділи, компоненти. Якщо на сайті є B2B-кабінет або дилерський розділ — структура груп і матриця доступу мають бути прописані в ТЗ.
SEO-технічні вимоги. ЧПУ (людиночитані URL), формат мета-тегів, robots.txt, sitemap.xml — все це налаштовується в Бітрікс через модуль seo та параметри компонентів. Без явних вимог у ТЗ розробник поставить дефолт.
Багатомовність. Якщо сайт планується кількома мовами — у ТЗ прописується структура мовних сайтів у рамках одного ядра Бітрікс, маппінг контенту, локалі для дат і валют.
Кейс: як відсутність ТЗ коштувала трьох місяців роботи
Замовник — оптовий постачальник, хотів «каталог з фільтром та особистим кабінетом для дилерів». ТЗ на 2 сторінки, написане всередині команди замовника. Після запуску виявилося:
- Дилерам потрібні індивідуальні ціни (три типи цін за групами), а розробник реалізував один прайс
- Фільтр не враховував залишки на складі — товари без залишку з'являлися в результатах
- Особистий кабінет показував лише замовлення через сайт, тоді як дилери очікували історію з 1С
Доробка зайняла 3 місяці при бюджеті вихідної розробки в 6 тижнів. Якби ці вимоги були формалізовані в ТЗ до початку робіт — обсяг і вартість були б оцінені коректно.
Склад роботи з написання ТЗ
- Інтерв'ю із замовником: бізнес-процеси, користувачі, інтеграції
- Аналіз наявних систем (1С, CRM, склад)
- Проектування структури інфоблоків та властивостей
- Опис користувацьких сценаріїв для всіх ролей
- Функціональні вимоги з прив'язкою до компонентів і модулів Бітрікс
- Нефункціональні вимоги: продуктивність, безпека, масштабування
- Прототипування ключових екранів (wireframes)
- Узгодження та фіналізація документа
Обсяг ТЗ для типового інтернет-магазину — 40–80 сторінок. Строки підготовки: від 2 тижнів для невеликого проєкту до 6–8 тижнів для складного багатофункціонального порталу з кількома інтеграціями.