Складання технічного завдання на сайт 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С-Бітрікс).

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