Техническое задание на корпоративный сайт: шаблон и чек-лист
Техническое задание на корпоративный сайт должно описывать не цвет кнопок, а границы проекта и способ проверки результата. Хорошее ТЗ фиксирует цели, аудитории, карту страниц, функциональные сценарии, интеграции, требования к контенту, SEO, скорости, безопасности и приемке.
Ниже — шаблон, по которому можно подготовить запрос подрядчикам и сравнить их предложения на одинаковой основе. Если проект только формируется, сначала скачайте бриф NBM-IT, а после первой встречи превратите ответы в ТЗ.
Чем бриф отличается от технического задания
Бриф собирает исходную информацию: о компании, продукте, аудитории, конкурентах, сроках и бюджете. Он помогает подрядчику задать правильные вопросы.
Техническое задание фиксирует согласованное решение: какие страницы и сценарии разрабатываются, какие системы участвуют, что передается заказчику и по каким критериям принимается результат.
Не стоит просить заказчика самостоятельно описывать будущую архитектуру или выбирать стек. Это зона ответственности команды, которая выполняет разработку корпоративного сайта под ключ. Заказчик лучше всех знает бизнес-процессы и ограничения, а подрядчик переводит их в проектные требования.
Шаблон ТЗ на корпоративный сайт
Скопируйте структуру ниже в рабочий документ. Каждый пункт должен содержать конкретное решение, вопрос для уточнения или пометку «не входит в текущий этап».
1. Общая информация о проекте
- Название компании и проекта.
- Ответственные со стороны заказчика и подрядчика.
- Причина разработки или редизайна.
- Целевой срок запуска и события, к которым он привязан.
- Ограничения: брендбук, CMS, инфраструктура, законодательство, договоры с поставщиками.
- Ссылки на текущий сайт, аналитику, CRM, каталоги и документацию.
Плохая формулировка: «Нужен современный продающий сайт».
Рабочая формулировка: «Нужно объединить пять направлений услуг, вести пользователей на отдельные посадочные, передавать заявки в Битрикс24 и сохранить поисковый трафик старого сайта».
2. Цели и измеримые действия
ТЗ не должно обещать позицию в поиске или произвольный рост продаж. Зафиксируйте действия, которые сайт обязан поддерживать:
- отправка заявки по конкретной услуге;
- запрос коммерческого предложения;
- скачивание технической документации;
- запись на консультацию или демонстрацию;
- поиск товара или решения;
- переход к контакту менеджера;
- подписка на обновления;
- просмотр кейса перед обращением.
Для каждого действия укажите событие аналитики и страницу, на которой оно доступно.
| Целевое действие | Где происходит | Что передаем в аналитику или CRM |
|---|---|---|
| Заявка на услугу | Страница услуги, кейс, контакты | URL, услуга, источник, UTM, контакты |
| Скачать презентацию | Страница решения | Название файла, страница, источник |
| Запросить расчет | Калькулятор или форма | Выбранные параметры, бюджетный диапазон, контакты |
3. Аудитории и пользовательские сценарии
Опишите не абстрактный возраст клиента, а его задачу и критерии выбора.
Пример для B2B-сайта:
- руководитель ищет подрядчика и сравнивает опыт, сроки и ответственность;
- специалист проверяет техническую совместимость и документацию;
- закупщик запрашивает смету и реквизиты;
- кандидат оценивает команду и вакансии;
- действующий клиент ищет поддержку и контакты.
Для каждой роли укажите начальную страницу, необходимую информацию, целевое действие и возможное возражение.
4. Карта страниц
Карта должна содержать будущий URL, назначение страницы, основной интент и источник контента.
| URL | Назначение | Основной вопрос пользователя | Владелец контента |
|---|---|---|---|
/ |
Позиционирование компании | Чем вы полезны и куда перейти дальше? | Маркетинг |
/services/... |
Коммерческая посадочная | Что входит, сколько стоит, какие есть кейсы? | Руководитель направления |
/cases/... |
Доказательство опыта | Как решали похожую задачу? | Аккаунт + эксперт |
/about |
Доверие | Кто отвечает за проект и как устроена компания? | Руководитель |
Готовую логику разделов можно сверить с нашим руководством по структуре корпоративного сайта.
5. Требования к прототипам и дизайну
Зафиксируйте:
- список уникальных шаблонов страниц;
- разрешения и состояния адаптивной версии;
- обязательные компоненты: таблицы, формы, фильтры, карточки, документы;
- состояния загрузки, ошибки, пустые результаты и успешную отправку;
- использование брендбука, шрифтов, фото и иллюстраций;
- правила согласования и число итераций;
- требования к доступности: контраст, клавиатурная навигация, подписи полей и альтернативный текст.
Не нужно перечислять координаты каждого элемента. ТЗ определяет систему и сценарии, а макеты фиксируют визуальное решение.
6. CMS и управление контентом
Перечислите сущности, которые редактор должен менять без разработчика:
- страницы и блоки;
- услуги и отрасли;
- кейсы;
- сотрудники;
- статьи и категории;
- документы;
- SEO-поля;
- меню, контакты и формы;
- редиректы.
Для каждой сущности укажите обязательные поля, права ролей, черновики, предпросмотр и историю изменений. Если контент приходит из 1С, PIM или CRM, определите, какая система является источником истины.
7. Формы и интеграции
Для каждой формы зафиксируйте поля, валидацию, согласие на обработку данных, сообщение об успехе и маршрут заявки.
Для интеграции опишите:
- направление обмена;
- состав данных;
- событие запуска;
- способ авторизации;
- допустимую задержку;
- повтор при ошибке;
- журналирование;
- ответственного за доступы;
- тестовую среду.
Фраза «интегрировать с CRM» недостаточна. Рабочее требование выглядит так: «После успешной отправки создать лид в воронке X, передать услугу, URL, UTM и контакты; при ошибке сохранить заявку и уведомить ответственного».
8. SEO-требования до запуска
SEO нельзя добавлять после готового дизайна одной строкой «установить плагин». В ТЗ включите:
- карту интентов и посадочных страниц;
- правила формирования title, description и H1;
- человекопонятные URL;
- canonical;
- robots.txt и sitemap.xml;
- хлебные крошки;
- редактируемые Open Graph-поля;
- структурированные данные, соответствующие видимому контенту;
- внутренние ссылки между услугами, кейсами и статьями;
- HTML-текст для важной информации;
- 301-редиректы со старых URL;
- контроль ответов 200, 301, 404 и 410;
- подключение Яндекс Вебмастера и Google Search Console.
Для редизайна приложите таблицу «старый URL → новый URL → действие». Страницы с трафиком нельзя удалять только потому, что их нет в новом меню.
9. Скорость, мобильная версия и качество страницы
Вместо требования «100 баллов PageSpeed» зафиксируйте пользовательские показатели и условия измерения. В качестве ориентира для Core Web Vitals Google использует LCP до 2,5 секунды, INP до 200 мс и CLS до 0,1 для не менее чем 75% посещений.
В ТЗ укажите:
- приоритетные устройства и браузеры;
- допустимый вес ключевых изображений;
- адаптивную загрузку изображений;
- правила подключения шрифтов и сторонних скриптов;
- среду тестирования;
- сбор реальных полевых данных после запуска.
Один лабораторный тест не гарантирует одинаковую скорость у всех посетителей. Поэтому после релиза нужен мониторинг реального опыта, а не только скриншот отчета.
10. Безопасность и персональные данные
Минимальный список:
- HTTPS;
- разграничение прав в CMS;
- двухфакторная аутентификация для администраторов, если поддерживается;
- резервные копии и проверка восстановления;
- обновление CMS и зависимостей;
- защита форм от спама и злоупотреблений;
- хранение секретов вне репозитория;
- журналирование ошибок;
- политика обработки персональных данных;
- перечень внешних сервисов, получающих данные.
Требования зависят от страны, отрасли и типа данных. Юридические формулировки должен проверять профильный специалист, а техническая команда — реализовать согласованные ограничения.
11. Контент и миграция
Для каждой страницы определите:
- кто предоставляет фактуру;
- кто пишет и согласует текст;
- кто готовит фотографии и графику;
- какие документы переносятся;
- какой контент архивируется;
- кто отвечает за финальную проверку.
При миграции отдельно сохраните метаданные, URL, изображения, документы, даты публикаций и авторство. Автоматический перенос без редакторской проверки часто переносит дубли, старую разметку и битые ссылки.
12. Аналитика
Составьте таблицу событий до разработки интерфейса:
- отправка каждой формы;
- ошибка формы;
- клик по телефону, почте и мессенджеру;
- скачивание документа;
- использование фильтра или калькулятора;
- переход в кейс;
- просмотр ключевого блока;
- источник и UTM-параметры.
Укажите системы аналитики, контейнер тегов, правила доступа и срок хранения данных. Событие должно иметь понятное имя и параметры, чтобы через полгода отчет можно было прочитать без автора настройки.
13. Приемка и передача проекта
Приемка должна опираться на проверяемые критерии:
- страницы соответствуют утвержденной карте;
- формы создают заявки в нужной системе;
- роли CMS имеют согласованные права;
- мобильные сценарии работают на целевых разрешениях;
- нет критичных ошибок в консоли и журнале сервера;
- настроены редиректы, canonical, sitemap и robots.txt;
- события приходят в аналитику;
- переданы доступы, репозиторий, инструкции и резервная копия;
- согласован период гарантийных исправлений и формат поддержки.
Формулировка «сайт должен нравиться заказчику» не является критерием приемки. Визуальная часть принимается по утвержденным макетам, функциональная — по сценариям и тестам.
Что часто забывают включить в ТЗ
- Пустые состояния каталога и поиска.
- Ошибки внешних интеграций.
- Страницу 404 и правила удаленных материалов.
- Веб-формы после блокировки cookies.
- Перенос старых URL.
- Владельца контента после запуска.
- Лицензии шрифтов, изображений, CMS и плагинов.
- Тестовые данные и тестовую среду.
- Мониторинг доступности и ошибок.
- Границы гарантийной поддержки.
Короткий чек-лист для запроса коммерческого предложения
Перед отправкой подрядчику приложите:
- описание компании и продуктов;
- причины запуска нового сайта;
- список аудиторий и целевых действий;
- предварительную карту разделов;
- обязательный функционал;
- список интеграций и контакт технического специалиста;
- ссылку на брендбук и исходные материалы;
- требования к CMS;
- старую аналитику и список важных URL;
- желаемый срок и бюджетный диапазон;
- порядок согласования;
- критерии выбора подрядчика.
Одинаковый пакет исходных данных помогает сравнивать не случайные итоговые суммы, а состав работ, риски и ответственность. Перед выбором команды также полезен разбор как выбрать подрядчика для разработки сайта.
FAQ
Кто должен писать техническое задание на сайт?
ТЗ лучше готовить совместно. Заказчик предоставляет цели, процессы, ограничения и фактуру, а подрядчик проектирует сценарии, архитектуру, интеграции и критерии приемки. Если исполнитель просит заказчика самостоятельно выбрать технологии и описать API, риск ошибки перекладывается не на ту сторону.
Можно ли оценить сайт без готового ТЗ?
Можно дать диапазон после брифа и короткой встречи. Фиксированная смета возможна только после согласования границ: количества шаблонов, функций, интеграций, контента и требований к переносу.
Насколько подробным должно быть ТЗ?
Настолько, чтобы две стороны одинаково понимали результат и способ его проверки. Для небольшого корпоративного сайта это может быть 15–30 страниц вместе с картой и прототипами, а для портала потребуется отдельная документация по ролям, данным и интеграциям.
Нужно ли указывать CMS в техническом задании?
Если CMS уже обязательна из-за инфраструктуры или компетенций команды заказчика, это нужно зафиксировать. В остальных случаях лучше описать требования к управлению контентом, безопасности и интеграциям, а выбор платформы обосновать после анализа.
Является ли прототип частью ТЗ?
Да, прототип уточняет расположение блоков, сценарии и состояния интерфейса. Текстовая часть фиксирует правила и границы, которые невозможно однозначно показать на экране.
Что делать, если требования меняются во время разработки?
Использовать согласованный процесс change request: описать изменение, оценить влияние на сроки и бюджет, принять решение и обновить документацию. Это безопаснее устных договоренностей в переписке.