Библиотека инструментов для интернет маркетинга

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

2026-09-22 10:31 Создание сайтов
Разработка сайта часто начинается с просьбы: «Пришлите техническое задание». Заказчик открывает пустой документ и пытается самостоятельно описать структуру, дизайн, формы, интеграции, мобильную версию и требования к системе управления.
Проблема в том, что владелец бизнеса не обязан разбираться в веб-разработке. Он лучше подрядчика знает свои услуги, клиентов, процесс продажи и ограничения компании. Перевести эту информацию в устройство будущего сайта — задача исполнителя.
Поэтому техническое задание лучше готовить совместно. Заказчик предоставляет факты о бизнесе и объясняет ожидаемый результат. Подрядчик исследует задачу, задаёт дополнительные вопросы и фиксирует, как именно будет работать сайт.
Разберём, что нужно подготовить до начала разработки, какие решения нельзя оставлять на уровне общих пожеланий и как использовать ТЗ при приёмке готового проекта.

Что такое техническое задание на сайт

Техническое задание, или ТЗ, — это документ, в котором зафиксированы требования к будущему сайту.
Оно отвечает на несколько вопросов:
  • зачем создаётся сайт;
  • для кого он предназначен;
  • какие страницы в него входят;
  • что пользователь сможет сделать;
  • какие материалы потребуется подготовить;
  • с какими сервисами будет связан сайт;
  • какие технические требования нужно соблюдать;
  • как стороны поймут, что работа выполнена.
ТЗ не должно превращаться в попытку заранее описать каждый пиксель. На раннем этапе невозможно предусмотреть все детали интерфейса. Но основные задачи, функции, ограничения и критерии готовности необходимо согласовать до разработки.
Документ особенно важен, если проект включает несколько типов страниц, каталог, формы, оплату, CRM, личный кабинет или другие интеграции. Чем больше взаимосвязанных элементов, тем опаснее полагаться на устные договорённости.

Чем техническое задание отличается от брифа

Бриф и техническое задание связаны, но решают разные задачи.
Бриф помогает собрать исходную информацию:
  • чем занимается компания;
  • кто её клиенты;
  • какие услуги приоритетны;
  • зачем нужен сайт;
  • какие сайты нравятся;
  • какие материалы уже есть;
  • какие проблемы нужно решить.
Техническое задание описывает согласованный результат:
  • структуру;
  • функциональность;
  • типы страниц;
  • формы;
  • интеграции;
  • требования к адаптивности;
  • аналитику;
  • SEO-настройки;
  • порядок тестирования и приёмки.
Бриф отвечает на вопрос «что нужно бизнесу», а ТЗ — «как это будет реализовано в рамках проекта».
Заполненный бриф ещё не является полноценным техническим заданием. Если подрядчик просит ответить на несколько общих вопросов и сразу приступает к дизайну, часть важных решений останется незафиксированной.

Кто должен составлять ТЗ

Полностью перекладывать документ на заказчика неправильно. Без знания платформы, ограничений, интеграций и процесса разработки он может пропустить критические требования или описать технически неудачное решение.
Заказчик предоставляет:
  • информацию о компании;
  • цели проекта;
  • сведения о товарах и услугах;
  • особенности клиентов;
  • географию работы;
  • процесс обработки заявок;
  • ограничения бизнеса;
  • имеющиеся материалы;
  • необходимые юридические документы;
  • требования, связанные с внутренними процессами.
Подрядчик определяет:
  • архитектуру сайта;
  • набор типов страниц;
  • техническую реализацию функций;
  • логику форм;
  • варианты интеграции;
  • требования к адаптивности;
  • базовые SEO-настройки;
  • способ подключения аналитики;
  • порядок тестирования;
  • критерии приёмки.
Итоговый документ должен быть понятен обеим сторонам. Если заказчик не может разобраться, что ему предлагают, ТЗ нельзя считать полностью согласованным.

Что подготовить заказчику

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

1. Информация о компании

Кратко опишите:
  • чем занимается компания;
  • какие товары или услуги предлагает;
  • сколько направлений нужно представить;
  • в каких городах или регионах работает;
  • обслуживает частных клиентов или организации;
  • как сейчас поступают обращения;
  • кто принимает решение о покупке;
  • есть ли сезонность;
  • какие ограничения важно учитывать.
Не копируйте длинное описание из презентации. Подрядчику необходимо понять модель бизнеса и путь клиента.
Например, для локального фитнес-клуба важны адрес, расписание, направления тренировок, тренеры и возможность записаться. Для B2B-компании — отрасли клиентов, длительность сделки, техническая документация и способ получения расчёта.
Если нужно сначала разобраться в спросе, конкурентах и подходящих каналах продвижения, можно провести базовый анализ бизнеса.

2. Цель создания сайта

Фраза «нужен современный сайт» не описывает цель проекта.
Сайт может быть нужен, чтобы:
  • получать обращения;
  • продавать товары;
  • принимать оплату;
  • показывать каталог;
  • презентовать компанию;
  • привлекать дилеров;
  • публиковать документы;
  • собирать заявки на мероприятия;
  • поддерживать клиентов;
  • привлекать посетителей из поиска;
  • принимать рекламный трафик.
У одного проекта может быть несколько целей, но среди них нужно определить основные.
Например:
Посетитель должен выбрать подходящую услугу, изучить примеры работ и отправить заявку на предварительный расчёт.
Такая формулировка помогает понять, какие страницы, доказательства и формы нужны сайту.

3. Ожидаемое действие посетителя

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

4. Целевая аудитория

Не ограничивайтесь формулировкой «мужчины и женщины от 25 до 55 лет».
Для проектирования сайта полезнее знать:
  • кто ищет товар или услугу;
  • какую задачу хочет решить;
  • что уже пробовал;
  • чего опасается;
  • что сравнивает;
  • какая информация влияет на решение;
  • кто согласовывает покупку;
  • какие вопросы задаёт перед обращением;
  • что может остановить покупку.
У бизнеса может быть несколько групп клиентов.
Например, корпоративный сайт производственной компании могут посещать:
  • потенциальные заказчики;
  • существующие клиенты;
  • дилеры;
  • поставщики;
  • соискатели;
  • представители контролирующих организаций.
Этим людям нужны разные разделы и разные пути по сайту.
Подробнее работа с такими группами раскрыта в статье «Анализ целевой аудитории: ключ к успешной стратегии».

5. Товары и услуги

Подготовьте полный список направлений, которые должны быть представлены на сайте.
Для каждой услуги полезно указать:
  • название;
  • кому она подходит;
  • какую задачу решает;
  • что входит в работу;
  • от чего зависит стоимость;
  • как проходит процесс;
  • какие материалы нужны от клиента;
  • какие ограничения существуют;
  • какие примеры можно показать;
  • какие вопросы задают покупатели.
Если услуг несколько, не объединяйте их автоматически на одной странице. По разным направлениям могут отличаться аудитория, спрос, аргументы и порядок заказа.
Как оформить отдельное предложение, разобрано в статье «Что должно быть на странице услуги».

6. География работы

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

7. Конкуренты

Соберите несколько компаний, с которыми вас действительно сравнивают клиенты.
По каждому конкуренту можно отметить:
  • что у него сделано хорошо;
  • что выглядит неудобно;
  • какие услуги он выделяет;
  • как объясняет стоимость;
  • какие доказательства использует;
  • какие страницы получает пользователь;
  • чем ваше предложение отличается.
Не нужно просить подрядчика скопировать чужой сайт. Конкуренты помогают понять сложившиеся ожидания аудитории и найти информацию, которой не хватает в других предложениях.
Подробнее о процессе можно прочитать в статье «Анализ конкурентов для маркетинговой стратегии».

8. Материалы для сайта

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

9. Требования к содержанию

До начала работы определите, кто:
  • собирает фактуру;
  • пишет тексты;
  • проверяет сведения;
  • предоставляет фотографии;
  • согласовывает материалы;
  • размещает содержание на сайте;
  • обновляет его после запуска.
Текст нельзя оставлять «на потом». Его объём и структура влияют на прототип и дизайн.
Если разработчик использует условные абзацы, готовый материал может не поместиться в блоки. В результате либо текст приходится сокращать без учёта смысла, либо уже согласованный дизайн нужно переделывать.

10. Предварительная структура

Заказчику необязательно самостоятельно создавать окончательную карту сайта. Достаточно перечислить направления и информацию, которую необходимо разместить.
Например:
  • главная;
  • услуги;
  • отдельные страницы услуг;
  • о компании;
  • проекты или кейсы;
  • цены;
  • блог;
  • контакты;
  • юридические документы.
После анализа подрядчик может изменить эту структуру: объединить разделы, добавить недостающие страницы или предложить другой порядок.
Для небольшого проекта иногда достаточно лендинга. Если направлений много или планируется SEO, чаще требуется многостраничная структура. Выбор формата подробно разобран в статье «Какой сайт нужен бизнесу: лендинг или многостраничный».

11. Необходимые функции

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

12. Формы и заявки

Для каждой формы нужно определить:
  • где она находится;
  • какие поля содержит;
  • какие поля обязательны;
  • куда отправляются данные;
  • кто получает уведомление;
  • что видит человек после отправки;
  • нужно ли создавать сделку в CRM;
  • какие данные об источнике сохраняются;
  • требуется ли согласие на обработку персональных данных;
  • как предотвращаются повторные отправки.
Название кнопки должно объяснять действие. Формулировки «Отправить», «Подробнее» или «Оставить» без контекста часто не позволяют понять, что произойдёт после нажатия.
После запуска формы необходимо протестировать. В документации Яндекс Метрики отдельно указано, что стандартная цель может в некоторых реализациях фиксироваться уже при попытке отправки, даже если данные не прошли проверку. Поэтому в ТЗ желательно указать не только установку счётчика, но и проверку фактической отправки заявки. Документация Яндекс Метрики.

13. Интеграции

Составьте список сервисов, которые уже используются или должны быть подключены:
  • CRM;
  • телефония;
  • платёжная система;
  • служба доставки;
  • онлайн-касса;
  • сервис рассылок;
  • система бронирования;
  • бухгалтерская программа;
  • складской учёт;
  • мессенджеры;
  • карты;
  • виджеты;
  • система аналитики.
Укажите название сервиса и желаемый сценарий.
Недостаточно написать «подключить CRM». Нужно определить:
  • когда создаётся сделка;
  • в какую воронку она попадает;
  • какие поля заполняются;
  • как передаётся источник;
  • кто назначается ответственным;
  • что происходит при ошибке;
  • как обрабатываются повторные обращения.
Если заявки передаются между несколькими системами, полезно заранее нарисовать простой маршрут:
форма сайта → CRM → уведомление менеджеру → изменение статуса → отчёт.

14. Требования к дизайну

Подготовьте не список любимых цветов, а ориентиры.
Полезно указать:
  • есть ли фирменный стиль;
  • какие элементы нельзя менять;
  • каким должен быть характер сайта;
  • какие сайты нравятся и почему;
  • какие решения не подходят;
  • используются ли реальные фотографии;
  • есть ли требования к доступности;
  • кто согласовывает дизайн.
Фраза «хочу дорого и современно» допускает слишком много трактовок.
Лучше объяснить:
На сайте должно быть легко изучать техническую информацию. Мы хотим использовать реальные фотографии производства, спокойные цвета и крупную типографику. Сложная анимация не нужна, потому что значительная часть клиентов открывает сайт со смартфона при нестабильном интернете.
Такое описание помогает принять осмысленное решение.

15. Мобильная версия

Адаптивность нельзя оставлять в виде общей фразы «сайт должен работать на всех устройствах».
В ТЗ стоит закрепить проверку:
  • меню;
  • заголовков;
  • изображений;
  • таблиц;
  • карточек;
  • форм;
  • кнопок;
  • всплывающих окон;
  • виджетов;
  • длинных адресов и реквизитов;
  • горизонтальной прокрутки.
Google использует мобильную версию содержания при индексировании и рекомендует адаптивный дизайн как удобный для реализации и поддержки подход. При этом важное содержание и метаданные должны быть доступны на мобильной версии. Рекомендации Google по mobile-first indexing.

16. SEO-требования

Если сайт планируется продвигать, SEO нужно учитывать до дизайна и разработки.
В техническом задании можно зафиксировать:
  • логичную структуру H1–H3;
  • редактируемые Title и Description;
  • понятные URL;
  • canonical;
  • robots.txt;
  • sitemap;
  • страницу 404;
  • редиректы;
  • alt у изображений;
  • внутреннюю перелинковку;
  • отсутствие технических дублей;
  • возможность добавлять новые страницы;
  • микроразметку там, где она соответствует содержанию;
  • подключение Google Search Console и Яндекс Вебмастера;
  • сохранение действующих URL при переработке сайта.
Для сайта на Tilda возможности и ограничения поисковой оптимизации собраны на странице «SEO на Tilda».
Если сайт уже существует, перед изменением структуры нужно проверить, какие страницы получают трафик. Полезные URL нельзя удалять без анализа и подготовки переноса. Об этом подробнее рассказано в статье «Редизайн или новый сайт».

17. Аналитика

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

18. Производительность

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

19. Управление сайтом после запуска

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

Что должно входить в итоговое ТЗ

После сбора исходной информации подрядчик может оформить документ со следующей структурой.

1. Общие сведения

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

2. Аудитория и сценарии

  • основные группы пользователей;
  • их задачи;
  • способы перехода на сайт;
  • целевые действия.

3. Структура

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

4. Содержание

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

5. Функциональность

  • формы;
  • каталог;
  • фильтры;
  • поиск;
  • личный кабинет;
  • оплата;
  • другие интерактивные элементы.

6. Интеграции

  • CRM;
  • аналитика;
  • телефония;
  • рассылки;
  • платёжные и другие сервисы;
  • сценарии передачи данных.

7. Дизайн и адаптивность

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

8. SEO

  • URL;
  • метатеги;
  • заголовки;
  • индексирование;
  • sitemap;
  • robots.txt;
  • canonical;
  • редиректы;
  • структурированные данные;
  • внутренняя перелинковка.

9. Тестирование и приёмка

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

10. Передача проекта

  • домен;
  • хостинг;
  • CMS;
  • исходные материалы;
  • инструкции;
  • доступы;
  • права;
  • поддержка после запуска.

Как описывать требования, чтобы их можно было проверить

Плохое требование:
Сайт должен быть удобным.
Проверяемая формулировка:
На мобильной версии пользователь может открыть меню, выбрать услугу и перейти к форме. Контент не выходит за границы экрана, элементы интерфейса не перекрывают друг друга.
Плохое требование:
Сделать красивую форму.
Проверяемая формулировка:
Форма содержит поля имени и телефона, проверяет заполнение обязательных полей, показывает понятное сообщение об ошибке, после успешной отправки выводит подтверждение и создаёт сделку в CRM.
Плохое требование:
Настроить SEO.
Проверяемая формулировка:
Для индексируемых страниц можно отдельно изменять Title, Description, H1, URL и alt изображений. Созданы sitemap.xml, robots.txt и страница 404. Сайт добавлен в Яндекс Вебмастер и Google Search Console.
Чем легче проверить требование, тем меньше споров возникнет при приёмке.

Что часто забывают включить

Наполнение

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

Перенос со старого сайта

Нужно определить, какие страницы, статьи, изображения, метатеги и URL сохраняются.

Страницу благодарности

После отправки формы пользователь должен понимать, что заявка принята и что произойдёт дальше.

Ошибки формы

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

Уведомления

Следует определить, кто и где получает информацию о новой заявке.

Передачу доступов

Домен, сайт, аналитика и интеграции не должны остаться под контролем одного исполнителя.

Поддержку после публикации

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

Юридические страницы

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

Можно ли использовать готовый шаблон ТЗ

Шаблон помогает не забыть основные разделы, но его нельзя заполнять механически.
Для лендинга локальной услуги и интернет-магазина нужны разные требования. В небольшом проекте часть разделов не понадобится. В сложном — потребуются дополнительные документы: схема интеграций, описание ролей, прототипы, модель данных или отдельная спецификация API.
Хороший шаблон задаёт вопросы. Он не принимает решения вместо заказчика и подрядчика.

Чек-лист заказчика перед началом разработки

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

Как Вайтиру готовит проект к разработке

Работу над сайтом мы рассматриваем не как сборку отдельных блоков, а как последовательный процесс:
  1. Изучение бизнеса, клиентов и конкурентов.
  2. Определение задач сайта.
  3. Проектирование структуры.
  4. Подготовка прототипов.
  5. Работа с содержанием.
  6. Разработка визуального решения.
  7. Сборка страниц.
  8. Настройка форм и интеграций.
  9. Базовая SEO-подготовка.
  10. Подключение аналитики.
  11. Тестирование и публикация.
Конкретный состав зависит от проекта. Если часть материалов уже подготовлена, используем их после проверки. Если сайт уже существует, сначала определяем, что стоит сохранить.
Перед выбором исполнителя также можно использовать статью «Как выбрать подрядчика на создание сайта и не потерять деньги».
Чтобы обсудить будущий сайт и определить необходимый объём подготовки, оставьте заявку на главной странице Вайтиру.