Техническое задание на сайт: что в нём должно быть, чтобы подрядчик сделал то, что вы ждали

Зачем нужно ТЗ и когда без него можно обойтись

ТЗ превращает фразу «хочу красивый сайт, чтобы заявки шли» в список проверяемых вещей. Без него спор «мы это не обсуждали» неизбежен: у заказчика в голове один сайт, у студии другой, а на макетах третий.

Полное ТЗ нужно, если у сайта есть сложная логика: каталог, личный кабинет, калькулятор, интеграции с CRM и 1С, несколько языков. Для лендинга на один экран хватит краткого брифа на две-три страницы: цель, предложение, блоки, контакты, ссылки на примеры. Но даже в брифе три раздела обязательны: цель, аудитория и критерий приёмки.

Хорошее ТЗ не обязано быть толстым. Объём определяется количеством решений, которые иначе пришлось бы принимать на ходу. Каждое такое решение стоит времени, а при фиксированной цене проекта ещё и нервов.

Раздел 1. Цели и контекст проекта

Начните с бизнеса, а не с экранов. Подрядчику важно понимать:

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

Последний пункт влияет на структуру. Сайт под контекстную рекламу строится вокруг посадочных страниц под запросы, а сайт под SEO нуждается в иерархии разделов и шаблонах для массовых страниц.

Здесь же укажите конкурентов и два-три сайта, которые вам нравятся, с пояснением, что именно нравится: подача цены, фильтр, структура страницы услуги. Фраза «как у них» без пояснения ничего не даёт.

Раздел 2. Структура и функции

Это ядро документа. Опишите:

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

Удобный приём: для каждой функции писать пользовательский сценарий в одну строку. «Посетитель выбирает размер в карточке, нажимает “Заказать”, заполняет имя и телефон, видит подтверждение, менеджер получает сделку в Битрикс24». Такая строка сразу выявляет, чего не хватает: например, кто будет менять статус сделки.

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

Раздел 3. Дизайн и интерфейс

Здесь фиксируют не вкус, а ограничения и обязательные элементы:

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

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

Раздел 4. Техническая часть

Эти пункты читает разработчик, но решение по ним касается и вас:

• платформа и причина выбора: WordPress, Битрикс, конструктор или самописное решение (если вы ещё выбираете, начните с сравнения WordPress и Битрикса);
• хостинг и домен: кто покупает, на чьё имя оформляются, кто обеспечивает бэкапы;
• интеграции: CRM, 1С, телефония и коллтрекинг, платёжные системы, службы доставки, рассылки, Яндекс Метрика;
• требования к SEO: человекопонятные адреса, заголовки и мета-теги по шаблонам, карта сайта, файл robots, редиректы со старых адресов при переезде, микроразметка;
• безопасность: HTTPS, защита форм от спама, права доступа, соответствие закону о персональных данных, хранение данных на серверах в России, где этого требует закон;
• производительность и нагрузка, если ожидаются пики трафика после рекламных запусков.

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

Раздел 5. Контент и данные

Самая частая причина срыва сроков не вёрстка, а отсутствие текстов и фотографий. В ТЗ пропишите:

• кто готовит тексты, фото, видео, прайс, каталог и в каком формате;
• кто переносит товары и статьи: подрядчик импортом или вы вручную;
• сроки передачи материалов: если контент приходит с опозданием, срок проекта сдвигается, и это должно быть записано;
• нужны ли SEO-тексты и по какой семантике.

Если каталог большой, договоритесь о формате выгрузки заранее: таблица с обязательными полями, названия, артикулы, характеристики, фото по правилу имени файла. Это экономит недели.

Раздел 6. Этапы, сроки и приёмка

Разбейте проект на этапы с результатом на выходе: прототип, дизайн-макеты, вёрстка, программирование, наполнение, тестирование, запуск. После каждого этапа происходит согласование, и без него следующий не стартует.

Критерии приёмки пишите проверяемыми фразами:

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

Отдельно запишите, что входит в гарантийный период и что считается новой задачей. Исправление ошибки реализации по ТЗ и «добавьте ещё один раздел» это разные вещи, и граница должна быть описана заранее.

Типичные ошибки при составлении ТЗ

• Описывать дизайн словами «современный, лаконичный, премиальный». Для разработчика это пустые слова. Дайте примеры и референсы.
• Копировать шаблон из интернета с пунктами про технологии, которые вашему проекту не нужны, и пропускать то, что нужно.
• Не указывать владельца решений. Когда правки приходят от пяти человек, проект стоит. Назначьте одного человека, который согласует за компанию.
• Забывать про после запуска: поддержка, обновления, мониторинг, продвижение. Сайт без трафика не работает, и это тоже стоит учесть в планировании.
• Не оставлять места для изменений. Хорошее ТЗ предусматривает порядок внесения изменений: письменный запрос, оценка влияния на срок и стоимость, согласование.

Когда стоит передать составление ТЗ специалистам

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