Техническое задание на создание сайта: пример ТЗ

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

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

Зачем нужно техническое задание

Без письменной спецификации фраза «сделать современный сайт» для каждого означает своё. Один ожидает пять страниц, другой — личный кабинет, интеграцию с CRM и автоматические письма. Разница обнаруживается поздно и превращается в спор о сроках и бюджете.

ТЗ помогает:

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

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

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

Заказчик лучше знает бизнес, аудиторию, процессы и ограничения. Разработчик — технические варианты, риски и зависимости. Поэтому рабочее ТЗ создаётся совместно.

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

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

Раздел 1. Цели и показатели результата

Начните с проблемы, а не с технологии. «Нужен сайт на Next.js» — техническое пожелание. «Нужно получать заявки на три услуги и понимать источник каждого обращения» — задача.

Зафиксируйте:

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

Пример: «Сайт должен представить услуги промышленного оборудования, собирать заявки с указанием направления и передавать источник в CRM. Основная аудитория — технические директора предприятий России. Успех через три месяца оценивается по корректной индексации страниц и количеству квалифицированных обращений».

Не гарантируйте в ТЗ конкретное число продаж, если разработчик не управляет спросом, ценой и отделом продаж. Фиксируйте измеряемую работу сайта.

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

Список «мужчины и женщины 25–55» почти бесполезен. Опишите ситуацию, мотивацию, сомнения и контекст устройства.

Для каждого сегмента создайте сценарий:

Откуда пользователь приходит.
Какую задачу решает.
Какие данные ему нужны.
Что мешает принять решение.
Какое действие считается успехом.
Что происходит после действия.

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

Раздел 3. Структура сайта

Приложите карту URL с назначением каждой страницы. Для SEO важно определить структуру до дизайна: коммерческий спрос должен получить отдельные посадочные, а информационные материалы — поддержать их.

Раздел	Назначение	Основное действие
Главная	Объяснить направления и доверие	Перейти к услуге
Страница услуги	Закрыть коммерческий интент	Отправить заявку
Кейсы	Подтвердить опыт	Обсудить похожую задачу
Блог	Ответить на информационный спрос	Перейти к услуге
Контакты	Дать способы связи и реквизиты	Связаться

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

Раздел 4. Состав страниц и контент

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

Пример страницы услуги:

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

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

Для медиа определите форматы, максимальный вес, авторские права и alt-тексты. Реальные фотографии нужно подготовить заранее; временные изображения не должны случайно попасть в продакшен.

Раздел 5. Функциональные требования

Описывайте функцию через сценарий и результат.

Плохо: «Сделать удобную форму».

Лучше: «Форма содержит имя, контакт, направление, сайт и описание. После успешной отправки данные уходят на email и в CRM, пользователь видит подтверждение. При ошибке введённые данные сохраняются. Событие успеха передаётся в Метрику».

Для каждой функции укажите:

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

Для магазина дополнительно описываются каталог, фильтры, остатки, цены, корзина, оплата, доставка, возврат и статусы заказа. Для личного кабинета — регистрация, восстановление доступа, роли и работа с персональными данными.

Раздел 6. Интеграции

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

Полезная таблица:

Интеграция	Данные	Триггер	Ошибка
CRM	Контакт, услуга, источник	Успешная форма	Письмо администратору и повтор
Email	Полный бриф	Создание лида	Запись в журнал
Метрика	Цель и направление	Ответ сервера 200	Не блокировать форму
Оплата	Заказ и сумма	Подтверждение оплаты	Статус «ожидает проверки»

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

Раздел 7. SEO-требования

Минимальная спецификация включает:

редактируемые title и description;
один H1 на шаблон;
canonical;
robots.txt и sitemap.xml;
человекопонятные URL;
коды 200, 301 и 404;
Open Graph;
хлебные крошки;
структурированные данные, где они уместны;
редиректы со старых адресов;
отсутствие тестового noindex после запуска.

Контент должен быть доступен в исходном HTML или корректно рендериться для поисковика. Фильтры и параметры требуют правил индексации. Для большого проекта привлеките специалиста до программирования шаблонов, а не после. Это входит в SEO для нового сайта.

Раздел 8. Нефункциональные требования

Нефункциональные требования описывают качество работы:

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

Используйте проверяемые формулировки. «Сайт должен быть быстрым» замените на набор целевых метрик, условия теста и список ключевых шаблонов. Не требуйте абсолютный балл любого сервиса на каждом устройстве: это может конфликтовать с функциональностью. Web Vitals дают подходящие ориентиры для пользовательского опыта.

Раздел 9. Дизайн и адаптивность

Вместо «нравится как у конкурента» приложите бренд-материалы, примеры атмосферы и ограничения. Определите обязательные компоненты, состояния и точки адаптации. Результат фиксируется утверждёнными макетами или прототипом.

Нужно предусмотреть:

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

Если существующий интерфейс уже мешает конверсии, редизайн сайта должен включать аудит и сохранение поисковых URL.

Раздел 10. Приёмка

Каждое важное требование превратите в сценарий проверки. Формат «дано — когда — тогда» делает результат однозначным.

Пример: «Дано: пользователь заполнил обязательные поля и согласие. Когда: сервер успешно принял заявку. Тогда: письмо отправлено, форма очищена, показано сообщение, в Метрику передана цель один раз».

Согласуйте:

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

Не принимайте проект только по скриншотам. Проверьте реальные формы, ссылки, метаданные, адаптивность и аналитику.

Что приложить к ТЗ

карту сайта;
прототипы;
дизайн-макеты;
контент-матрицу;
таблицу редиректов;
модель данных;
описание API;
доступы и владельцев сервисов;
тестовые сценарии;
план запуска;
список работ вне текущего этапа.

Документ должен иметь версию и историю решений. Устные изменения после встречи фиксируйте письменно.

Короткий шаблон ТЗ

О проекте и бизнес-цели.
Аудитории и сценарии.
Структура и URL.
Состав шаблонов.
Контент и ответственные.
Функции и состояния.
Интеграции.
SEO и аналитика.
Производительность, доступность, безопасность.
Дизайн и адаптивность.
Приёмка и запуск.
Поддержка и развитие.

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

Роли и ответственность сторон

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

Пример:

Результат	Готовит	Согласует	Срок
Карта сайта	Аналитик и SEO	Заказчик	3 дня
Прототип	UX-дизайнер	Владелец продукта	5 дней
Тексты	Редактор	Эксперт заказчика	До дизайна
Интеграция CRM	Разработчик	Администратор CRM	До тестирования
Политика данных	Юрист заказчика	Руководитель	До запуска

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

В ТЗ также укажите срок ответа. Когда согласование задерживается на неделю, общий календарь должен сдвигаться, а не превращаться в обязанность разработчика «догнать» время.

Миграция со старого сайта

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

План миграции включает:

выгрузку страниц и файлов;
резервную копию;
таблицу 301-редиректов без цепочек;
сохранение важных title, H1 и контента;
перенос аналитики и целей;
проверку robots и sitemap;
обновление canonical и внутренних ссылок;
тест кодов ответа до переключения домена;
мониторинг Вебмастера после запуска.

Не перенаправляйте все удалённые URL на главную. Если эквивалента нет, иногда корректнее вернуть 404 или 410. Решение принимается по содержанию, трафику и ссылкам.

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

Безопасность и персональные данные

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

Технические требования могут включать:

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

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

Чек-лист запуска

Перед публикацией пройдите единый список:

домен и SSL работают;
тестовые заглушки и noindex удалены;
все приоритетные URL возвращают 200;
редиректы одноступенчатые;
формы доставляют заявку и показывают подтверждение;
цели аналитики срабатывают один раз;
контакты кликабельны;
страницы проверены на телефоне;
политика и реквизиты опубликованы;
robots и sitemap доступны;
есть резервная копия;
ответственные знают порядок обращения при ошибке.

Результаты проверки приложите к акту приёмки. Так запуск становится контролируемой процедурой, а не нажатием кнопки поздно вечером.

Как поддерживать ТЗ актуальным

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

Статусы удобно разделить на «обязательно к запуску», «следующий этап» и «идея». Тогда полезное пожелание не теряется, но не расширяет текущий объём без оценки.

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

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

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

Признак готовности документа

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

Не стремитесь удалить все вопросы. Важно явно отметить открытые решения, владельца и срок. Скрытая неопределённость опаснее честного пункта «будет уточнено после прототипа».

Такой подход экономит время обеих сторон.

Проверяемый лист приёмки сайта

Это образец приложения к ТЗ, не обещание одинакового состава для любого проекта. Для каждой строки сохраните URL, среду, дату, результат и ссылку на подтверждение. Ответственного и допустимые отклонения согласуйте до разработки.

Объект	Проверка	Критерий результата
Страницы и контент	Сверить согласованный реестр URL с сайтом	Все предусмотренные страницы и материалы присутствуют; нет случайных заглушек
Заявка	В тестовой среде проверить успешную отправку, ошибку сети и повторный клик	Обращение поступает получателю; ошибка понятна; повторный клик не создаёт дубль
Мобильная версия	Пройти меню, форму и длинные таблицы на согласованных ширинах	Текст и кнопки доступны; страница не уезжает горизонтально; таблица прокручивается внутри блока
Поиск и адреса	Проверить коды ответов, canonical, sitemap и согласованные перенаправления	Рабочие URL открываются; несуществующий URL даёт 404; нет случайного запрета индексации
Доступность	Пройти основные действия клавиатурой	Фокус виден, поля подписаны, нет ловушки клавиатуры
Передача	Проверить доступы владельца, исходники, инструкции и восстановление бэкапа в отдельной среде	Заказчик получает согласованный комплект и может проверить восстановление

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

FAQ

Обязательно ли ТЗ для небольшого сайта?

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

Может ли заказчик составить ТЗ сам?

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

Чем ТЗ отличается от прототипа?

Прототип показывает расположение и логику экранов. ТЗ описывает цели, данные, функции, интеграции, ограничения и правила проверки. Они дополняют друг друга.

Можно ли менять ТЗ во время разработки?

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

Кто готовит контент?

Это заранее назначается в ТЗ. Нужно указать владельца текстов, фото, цен, документов и срок передачи, иначе контент легко задержит запуск.