Техническое задание на B2B-сайт: что подготовить заказчику

Техническое задание не должно заранее описывать цвет каждой кнопки. Его задача — зафиксировать бизнес-цель, границы проекта, обязательные сценарии и критерии приёмки. Тогда заказчик и разработчик одинаково понимают результат, а важные решения не принимаются случайно в середине работы.

Ниже — структура ТЗ для корпоративного сайта, производителя или B2B-сервиса.

1. Контекст и цель проекта

Начните с короткого описания бизнеса:

• что продаёт компания;
• кому и в каких регионах;
• как устроен цикл сделки;
• откуда сейчас приходят обращения;
• какую роль должен выполнять сайт.

Цель «сделать современно» невозможно проверить. Лучше сформулировать наблюдаемое изменение: упростить запрос коммерческого предложения, объяснить линейку продуктов, подготовить SEO-структуру или сократить ручные консультации по типовым вопросам.

Выберите одну главную цель и несколько вспомогательных. Если сайт одновременно должен продавать, обучать партнёров, обслуживать клиентов и заменять внутреннюю систему, проект следует разделить на этапы.

2. Аудитории и участники решения

В B2B страницу часто изучают несколько ролей. Собственника интересуют риски и экономика, инженера — характеристики, закупщика — условия, пользователя — эксплуатация.

Для каждой роли зафиксируйте:

| Роль | Главный вопрос | Нужный материал | Целевое действие | |---|---|---|---| | Руководитель | Почему этому поставщику можно доверять? | Кейсы, цифры, этапы | Запросить обсуждение | | Инженер | Подходит ли решение по параметрам? | Характеристики, чертежи | Отправить ТЗ | | Закупщик | Как получить цену и документы? | Условия, сертификаты | Запросить КП | | Пользователь | Как решение работает? | Инструкции, FAQ | Получить консультацию |

Такой список помогает не сводить сайт к одной универсальной странице.

3. Карта страниц и сценарии

Для каждого раздела укажите задачу и переход. Например, карточка оборудования помогает оценить параметры и ведёт к запросу цены, а отраслевая страница объясняет применимость и ведёт к подбору решения.

Отдельно опишите ключевые сценарии:

1. Посетитель находит продукт через поиск.
2. Сравнивает характеристики.
3. Проверяет документы и опыт.
4. Отправляет запрос.
5. Получает подтверждение и следующий шаг.

Не ограничивайтесь меню. Важны также фильтры, поиск, связанные материалы, формы и состояния после отправки.

4. Функциональные требования

Разделите требования на обязательные и желательные. Это упростит оценку и поможет сохранить бюджет.

Примеры функций:

• каталог и фильтры;
• поиск по сайту;
• загрузка файлов к заявке;
• калькулятор или конфигуратор;
• личный кабинет;
• несколько языков;
• управление контентом;
• интеграция с CRM;
• уведомления в Telegram или email;
• передача UTM-меток;
• карта объектов или дилеров.

Для каждой интеграции укажите систему, доступность API, владельца доступа и ожидаемый обмен данными. Формулировка «интегрировать с 1С» слишком широкая: нужно перечислить конкретные сущности и направление синхронизации.

5. Контент и ответственность

Большая часть задержек возникает не из-за кода, а из-за материалов. Составьте таблицу контента заранее:

| Материал | Формат | Кто предоставляет | Срок | |---|---|---|---| | Описания продуктов | Документ или таблица | Продуктовый специалист | До прототипа | | Характеристики | Структурированная таблица | Инженер | До разработки каталога | | Фотографии | Оригиналы | Маркетинг | До дизайна | | Сертификаты | PDF | Отдел качества | До наполнения | | Кейсы | Факты и разрешения | Продажи | До подготовки текстов |

Если тексты создаёт подрядчик, заказчик всё равно должен предоставить факты и согласовать техническую точность.

6. SEO до разработки

SEO-требования нельзя добавлять после готового дизайна. До прототипа определите:

• основные группы поисковых запросов;
• посадочные страницы;
• правила URL;
• требования к title, description и заголовкам;
• перелинковку;
• индексируемые и служебные страницы;
• правила переноса старых адресов.

При замене существующего сайта подготовьте карту редиректов и сохраните страницы, которые уже получают трафик. Для этого используйте чек-лист технического SEO при переносе.

7. Нефункциональные требования

Зафиксируйте требования, которые определяют качество системы:

• поддерживаемые устройства и браузеры;
• доступность с клавиатуры;
• ожидаемая скорость;
• защита форм от спама;
• резервное копирование;
• журналирование ошибок;
• права пользователей;
• правила хранения персональных данных.

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

8. Критерии приёмки

Приёмка должна проверять результат, а не личное ощущение. Примеры критериев:

• все страницы из утверждённой карты созданы;
• формы доставляют заявки в согласованные каналы;
• обязательные поля и ошибки работают;
• данные передаются в CRM по заданной схеме;
• редиректы соответствуют карте;
• контент корректно отображается на согласованных разрешениях;
• подключена аналитика событий;
• заказчику переданы доступы и инструкция.

Определите количество циклов правок и порядок фиксации новых требований. Новая функция после согласования прототипа — это изменение объёма, а не обычная правка.

9. Этапы и точки согласования

Практичная последовательность:

1. Исследование и сбор требований.
2. Карта сайта.
3. Прототип ключевых страниц.
4. Дизайн-концепция.
5. Полный дизайн.
6. Разработка и интеграции.
7. Наполнение.
8. Тестирование и перенос.
9. Запуск и наблюдение.

На каждом этапе укажите ответственного и срок обратной связи. Без этого даже подробное ТЗ не защитит график.

Что отправить подрядчику для первой оценки

Для начального расчёта достаточно пяти материалов:

• ссылка на текущий сайт;
• краткое описание продукта и клиента;
• желаемый список разделов;
• обязательные функции и интеграции;
• ориентир по сроку.

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