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

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

Документація проєктів на 1С-Бітрікс

Розробник звільнився. Новий відкриває init.php на 2000 рядків — бачить 47 обробників подій через AddEventHandler, ланцюжок агентів у b_agent і кастомний модуль без жодного коментаря. На вникання йде місяць. Документація цей місяць перетворює на три дні. Ми створюємо документацію 1С-Бітрікс для проєктів будь-якої складності: від архітектурних схем до покрокових інструкцій для контент-менеджера.

Наявність документації скорочує час адаптації нового розробника втричі — з трьох тижнів до одного. Проєкт без неї вимагає в 3 рази більше часу на введення новачка; даунтайми при оновленні ядра трапляються на 60% частіше. Понад 10 років досвіду розробки на Бітрікс і 50+ задокументованих проєктів — це наш стандарт. Економія на онбордингу одного розробника може сягати 90 000 грн — саме стільки коштує місяць простою без документації. Зв’яжіться з нами для оцінки вашого проєкту за один день.

Чому документація критична?

Конкретні ситуації, які бачимо на кожному другому проєкті:

• Оновлення ядра — розробник запускає bitrix/tools/upgrade.php. Оновлення перезаписує модифіковані файли в /bitrix/components/bitrix/. Ніхто не знає, які компоненти були змінені. Сайт зламався. Відкат — з бекапу. Даунтайм — 4 години.
• Обмін з 1С — агент обміну CCatalogImport::PreGenerateXML падає з помилкою. Налаштування нестандартне. Хто змінював маппінг властивостей? Без документації — реверс-інжиніринг на пів дня.
• Новий підрядник — команда отримує проєкт з 12 highload-блоками без опису призначення, кастомними таблицями b_custom_order_log і b_product_sync_history. Призначення та зв’язки з інфоблоками ніде не зафіксовані. Це затягує введення нового розробника на два тижні.
• Зростання команди — кожен новий розробник три тижні ходить за «тим, хто знає», замість того щоб відкрити документацію і працювати.

Статистика наших проєктів: при наявності повної документації кількість інцидентів при оновленні модулів знижується на 50%, а середній час виправлення помилки в продакшні скорочується вдвічі.

Один із кейсів — інтернет-магазин з 500 000 товарів, обмін з 1С, три платіжні системи, інтеграція з СДЕК. Без документації новий розробник розбирався 4 тижні. Ми задокументували архітектуру даних (інфоблоки, HR-блоки, кастомні таблиці), REST API, регламенти деплою та бекапів. Після цього введення новачка зайняло 1 тиждень, а вартість підтримки зменшилася на 35% за рахунок зниження часу на налагодження. За стандартом CommerceML (описано у Вікіпедії) обмін з 1С — одна з найчастіших точок збою. Документація знімає цю проблему.

Як структурувати документацію для розробників?

Технічна документація

Для розробників і DevOps — внутрішній устрій проєкту:

Архітектура:

• Використовувані модулі Бітрікс (sale, catalog, iblock, main, кастомні)
• Шлях запиту: HTTP → nginx → urlrewrite.php → компонент → шаблон → відповідь
• Серверна інфраструктура: конфігурація, топологія, балансування

Структура даних — найкритичніша частина:

• Інфоблоки: типи (IBlock::TYPE_ID), розділи, властивості (PROPERTY_CODE), зв’язки між інфоблоками через властивість типу «Прив’язка до елементів»
• Highload-блоки: таблиця b_hlblock_entity, призначення кожного блоку, структура полів, користувацькі поля (UF_*), індекси
• Кастомні таблиці в БД — навіщо створювались, DDL, зв’язки з b_iblock_element, b_sale_order та іншими штатними таблицями
• Торговий каталог: типи цін (b_catalog_group), склади (b_catalog_store), правила кошика (b_sale_discount)

Кастомні розробки:

• Компоненти в /local/components/ — призначення, class.php, вхідні параметри (.parameters.php), шаблони, залежності
• Модулі в /local/modules/ — API, події, встановлювальні скрипти
• Обробники подій — список усіх AddEventHandler/registerEventHandler з описом: яка подія, що робить, критичність
• Агенти (b_agent) — розклад, функціонал, які не можна зупиняти (обмін з 1С, розсилки, очищення кошиків)
• Змінені файли ядра — повний список. При оновленні bitrix/ ці файли будуть перезаписані

Інтеграції:

• Обмін з 1С: налаштування модуля catalog → «Обмін з 1С», формат CommerceML, розклад CCatalogImport, маппінг властивостей, підводні камені (кодування, таймаути, розмір import.xml)
• Платіжні системи: обробники в sale.handlers, режими роботи (тест/бій), URL для callback
• Служби доставки: профілі в sale.delivery, алгоритми розрахунку, API-ключі
• CRM, маркетплейси, зовнішні API: ендпоїнти, механізми аутентифікації, частота синхронізації

Користувацькі інструкції

Для контент-менеджерів і адміністраторів:

Керівництво контент-менеджера:

• Управління каталогом: створення елементів інфоблоку, заповнення властивостей, робота з розділами. Які поля обов’язкові, які впливають на відображення на сайті
• Зображення: допустимі розміри (авторесайз налаштований чи ні?), формати, процес завантаження в DETAIL_PICTURE і PROPERTY_GALLERY
• Акції та знижки — як налаштувати правило кошика в «Маркетинг» → «Правила роботи з кошиком», не зламавши ціноутворення. Перевірка через тестове замовлення

Керівництво адміністратора:

• Користувачі: групи (b_group), права доступу до модулів та інфоблоків
• Обробка замовлень: статуси (b_sale_status), оплата, повернення
• Бекап через «Налаштування» → «Резервне копіювання» — з застереженням, що для великих проєктів штатний бекап не справляється

Формат:

• Покроково з нумерацією
• Скріншоти з анотаціями — стрілки, виділення, підписи
• FAQ з реальних питань, зібраних при навчанні
• Відеоінструкції для нетривіальних операцій (за запитом)

API-документація

Для проєктів з кастомним REST API — ми описуємо всі ендпоїнти: метод, URL, призначення, параметри (обов’язкові/опціональні), формат відповіді. Аутентифікація: механізм отримання токена, TTL, оновлення. Rate limiting: ліміти, HTTP-коди при перевищенні. Приклади — робочі cURL-команди, не теоретичні. Інструменти: Swagger/OpenAPI та Postman Collection для тестування.

Архітектурні схеми

Одна схема замінює 10 сторінок тексту. Формати: Draw.io, Mermaid (версіонується в Git), PlantUML.

• Інфраструктура — сервери, мережі, балансувальник, БД (master-slave?), Redis, CDN. Фізична та логічна топологія
• Компоненти — модулі Бітрікс, кастомні компоненти в /local/, зовнішні сервіси, зв’язки
• ER-діаграма — таблиці b_iblock_element, b_sale_order, highload-блоки, кастомні таблиці. Поля, зв’язки, індекси. Особливо критично для кастомних таблиць, яких немає в документації Бітрікс
• Потоки даних — як інформація рухається між Бітрікс, 1С, маркетплейсами, CRM, платіжними системами
• Мапа сайту — що інфоблок, що статична сторінка, що кастомний розділ на компоненті

Регламенти експлуатації

Деплой:

• Покрокова інструкція для staging і production
• Чек-лист після деплою: перевірка головної, каталогу, чекауту, обміну з 1С
• Процедура відкату — який symlink переключити, який бекап БД відновити

Бекапи:

• Розклад: БД, upload/, конфігурації
• Де зберігаються і скільки
• Процедура відновлення — перевірена, не теоретична
• Тестове відновлення раз на місяць

Оновлення ядра:

• Staging → тестування → production. Строго в такому порядку
• Перевірка сумісності кастомних компонентів і змінених файлів ядра
• bitrix/updates/ — що було оновлено

Інциденти:

• Класифікація: сайт недоступний / помилки 500 / зламався обмін з 1С / гальмує
• Контактні особи та зони відповідальності
• Шаблони дій для кожного типу

Як відбувається створення документації?

1. Аналіз проєкту (1–2 дні) — вивчаємо код, БД, конфігурації, спілкуємося з командою.
2. Збір інформації (2–5 днів) — фіксуємо архітектуру, інтеграції, бізнес-процеси.
3. Написання та валідація — формуємо технічну документацію, інструкції, схеми. Кожен текст перевіряє розробник, який брав участь у проєкті.
4. Розміщення — Confluence, GitBook, Notion або Wiki з розмежуванням доступу.
5. Гарантія актуальності — оновлюємо документацію при кожній значущій зміні (новий модуль, зміна обміну, оновлення ядра).

Створення документації 1С-Бітрікс за цим алгоритмом забезпечує точність і повноту — жоден кастомний агент або змінений файл ядра не залишиться незадокументованим. Замовте попередню оцінку документації — ми проаналізуємо ваш проєкт і назвемо строки та обсяг робіт.

Що входить в роботу

Ми готуємо повний комплект документації для вашого проєкту:

• Технічна документація з описом архітектури, структури даних, кастомних розробок та інтеграцій
• Користувацькі інструкції для контент-менеджерів і адміністраторів
• API-документація у форматі Swagger/OpenAPI з Postman-колекцією
• Архітектурні схеми (інфраструктура, ER-діаграми, потоки даних)
• Регламенти експлуатації (деплой, бекапи, оновлення ядра, інциденти)
• Розміщення в Confluence, GitBook, Notion або Wiki з розмежуванням доступу
• Гарантія актуальності — оновлюємо документацію при кожній значущій зміні

Джерело: власна методологія, апробована на 50+ проєктах на 1С-Бітрікс.

Строки

Замовте документацію під ключ — зв’яжіться з нами для безкоштовної оцінки вашого проєкту за 1 день. Застаріла документація гірша за її відсутність: вона створює хибну впевненість. Ми оновлюємо матеріали при кожній суттєвій зміні, щоб інформація залишалася точною. Отримайте консультацію прямо зараз.