Что должно решать техническое задание
Техническое задание нужно не для того, чтобы заранее описать каждый пиксель будущего сайта. Его основная функция - убрать разночтения между бизнесом, дизайнером, разработчиком, SEO-специалистом и теми, кто будет принимать работу. Если документ не помогает ответить на вопросы что делаем, для кого, в каком объеме и как проверяем результат, он превращается в формальность.
Для сайта ТЗ особенно важно в трех точках. Первая - оценка: без зафиксированного объема невозможно сравнить предложения подрядчиков. Вторая - производство: структура, тексты, дизайн, сборка и интеграции должны идти из одной логики. Третья - приемка: замечание должно опираться на согласованное требование, а не на впечатление после публикации.
Какие исходные данные собрать до написания ТЗ
Начинайте не с перечня экранов, а с бизнеса. Подрядчику нужны факты, которые влияют на архитектуру сайта: что продает компания, кому, в каких регионах, как клиент выбирает поставщика, какие услуги приоритетны, чем отличается предложение и какое действие на сайте считается целевым.
- список услуг, продуктов и направлений с приоритетами;
- география работы и ограничения по регионам;
- основные типы клиентов и сценарии выбора;
- действующий сайт, если он есть, и данные аналитики;
- конкуренты, которых бизнес реально встречает в сделках;
- готовые материалы: тексты, фотографии, презентации, каталоги, кейсы;
- CRM, телефония, почта, платежи и другие системы, с которыми сайт должен обмениваться данными.
Если часть информации неизвестна, это тоже нужно отметить. Плохая практика - молча закладывать неизвестное как готовое. Например, фраза нужна интеграция с CRM бесполезна, если не указана система и направление передачи данных.
Рабочая структура ТЗ на сайт
| Раздел | Что фиксируем | Зачем это нужно |
|---|---|---|
| Цель проекта | Заявки, продажи, презентация продукта, поддержка дилеров, SEO | Определяет архитектуру и приоритеты |
| Аудитория | Кто принимает решение и что проверяет до обращения | Влияет на содержание страниц |
| Структура | Список типов страниц и их назначение | Фиксирует объем разработки |
| Контент | Кто готовит тексты, фото, таблицы, документы | Убирает задержки на наполнении |
| Функционал | Формы, каталог, фильтры, оплаты, личные кабинеты, интеграции | Позволяет оценить техническую часть |
| SEO | URL, метаданные, структура, редиректы, индексирование | Сохраняет и развивает поисковый трафик |
| Аналитика | Метрика, цели, события, рекламные системы | Позволяет измерять результат |
| Приемка | Устройства, браузеры, формы, ошибки, доступы | Делает сдачу проекта проверяемой |
Как описывать структуру сайта
Не ограничивайтесь формулировкой главная плюс десять внутренних страниц. У страницы должно быть назначение. Для корпоративного сайта это могут быть шаблон услуги, отраслевое решение, кейс, статья, контактная страница. Если пять услуг строятся по одному шаблону, в ТЗ важно разделить уникальный дизайн шаблона и последующее наполнение.
Для проекта с SEO структуру лучше связывать с поисковым спросом до дизайна. Иначе после запуска выясняется, что разные группы запросов собраны на одной странице или, наоборот, несколько URL конкурируют за один запрос. Для многостраничных проектов мы сначала проектируем карту страниц и только затем переходим к макетам. Такой подход подробнее описан в услуге разработки многостраничных сайтов.
Как описывать функциональные требования
Функцию нужно описывать через сценарий, а не названием элемента. Вместо нужен калькулятор лучше указать, какие данные вводит человек, что рассчитывается, что он получает после расчета и куда уходит результат. Для формы нужно перечислить поля, обязательность, согласие на обработку данных, получателей, запись в CRM, страницу после отправки и события аналитики.
Тот же принцип работает с каталогом: число товаров, варианты, категории, фильтры, поиск, карточка, корзина, оплата, остатки и источник данных. Чем ближе описание к реальному сценарию, тем меньше скрытых допущений в смете.
Контент и зона ответственности
В ТЗ стоит отдельно указать, кто предоставляет фактуру и кто превращает ее в текст. Фраза заказчик предоставляет контент часто трактуется по-разному: один имеет в виду готовые тексты, другой - презентацию на 80 страниц и устный созвон с экспертом.
Для каждого типа страницы полезно определить минимальный набор материалов. Например, для кейса - задача, исходная ситуация, выполненные работы, измеримый результат, изображения и разрешение на публикацию названия клиента. Для услуги - условия, процесс, ограничения, сроки, доказательства опыта, ответы на вопросы. Это ускоряет производство сильнее, чем попытка писать все после готового дизайна.
SEO-требования нужно фиксировать до запуска
Если сайт уже получает поисковый трафик, в ТЗ должен быть отдельный раздел по сохранению URL и сигналов. Нужна карта старых и новых адресов, правила 301-редиректов, перенос метаданных, контроль индексации и проверка внутренних ссылок. Для нового сайта фиксируют человекопонятные URL, один основной H1, редактируемые Title и Description, sitemap, robots.txt, canonical и возможность развивать структуру.
SEO не стоит сводить к полю добавьте ключевые слова. На этапе проектирования важнее, чтобы каждая страница имела понятное назначение и не дублировала соседнюю. Если продвижение планируется после запуска, требования лучше согласовать заранее с теми, кто будет отвечать за SEO-продвижение.
Что написать про адаптив и техническое качество
Фраза сайт должен корректно работать на всех устройствах слишком размыта. В приемке лучше зафиксировать диапазоны ширины, актуальные версии основных браузеров и критичные сценарии: меню, формы, таблицы, попапы, слайдеры, оплату, ввод данных с телефона. Не обязательно перечислять десятки моделей смартфонов, но должно быть понятно, что именно проверяется.
Отдельно укажите требования к изображениям, собственным шрифтам, сторонним скриптам и анимациям. Если проект использует тяжелое видео на первом экране или несколько виджетов, это нужно согласовать до разработки, а не пытаться исправить скорость в день запуска.
Критерии приемки
- Все согласованные страницы опубликованы по утвержденным адресам.
- Навигация и внутренние ссылки ведут на актуальные URL.
- Формы отправляют данные нужным получателям и фиксируют события аналитики.
- Нет горизонтального скролла, обрезанного текста и недоступных элементов на контрольных разрешениях.
- Метаданные, H1 и индексирование настроены по карте страниц.
- Для переноса сайта проверены редиректы и ответы старых URL.
- Заказчику переданы доступы, инструкция и исходные материалы, предусмотренные договором.
Критерий должен проверяться действием. Формулировка современный дизайн не проверяется. Формулировка кнопка формы на ширине 390 пикселей остается полностью видимой и открывает форму - проверяется.
Минимум, которого достаточно для старта
Если проект небольшой, не нужно писать документ на сто страниц. Для лендинга достаточно зафиксировать цель, аудиторию, структуру, источники контента, формы и интеграции, адаптив, SEO-настройки и приемку. Для корпоративного сайта или каталога детализация должна быть выше, потому что число шаблонов, данных и связей растет.
Хорошее ТЗ не делает разработку бюрократической. Оно позволяет быстро принимать решения, потому что команда понимает рамки проекта и не возвращается к базовым вопросам после каждого нового макета.
