ТЗ на разработку сайта: образец и чек-лист для заказчика

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

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

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

Чем ТЗ отличается от брифа и дизайна

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

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

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

Начните с бизнес-задачи и границ проекта

Опишите услугу и основное действие посетителя. «Узнать условия монтажа и отправить заявку на расчёт» полезнее, чем «повысить узнаваемость компании»: первый сценарий можно проверить на готовом сайте.

Зафиксируйте пять исходных условий:

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

Раздел «Не входит в проект» особенно полезен. Например: личный кабинет, онлайн-оплата, перенос старого каталога и мультиязычность не включены в первую версию. Это не запрет на развитие, а способ согласовать одинаковые ожидания.

Если формат ещё не выбран, сначала сравните, какой сайт нужен бизнесу: лендинг, корпоративный сайт или web-сервис.

Составьте список страниц и материалов

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

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

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

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

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

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

Опишите функции через сценарии, а не названия

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

Условный пример требования к форме заявки:

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

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

Для интеграций укажите конкретную систему, направление передачи, список полей и ответственного за доступы. «Интеграция с CRM» без этих деталей не даёт сопоставимой оценки трудозатрат.

Включите SEO-требования до начала разработки

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

Включите в документ проверяемые пункты:

У коммерческих страниц есть согласованные постоянные URL и ссылки из подходящих разделов сайта.
Для каждой индексируемой страницы предусмотрены собственные title, description и понятный основной заголовок H1.
Основное содержание доступно поисковому роботу; описание услуги не существует только внутри изображения или после отправки формы.
На рабочих страницах нет случайного запрета индексирования, а canonical указывает на согласованный основной адрес.
В XML Sitemap включены предназначенные для поиска канонические страницы; технические адреса обрабатываются по отдельно согласованным правилам.
Несуществующие страницы возвращают корректный ответ 404, а не маскируются под рабочие страницы с ответом 200.

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

Яндекс также рекомендует связывать документы обычными HTML-ссылками и продумывать структуру адресов. Поэтому пункт «сделать SEO» лучше заменить перечнем конкретных проверок. См. рекомендации Яндекса по структуре сайта.

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

Образец ТЗ для сайта компании по монтажу кондиционеров

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

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

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

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

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

Управление: сотрудник может менять цены и описания услуг без редактирования кода. Для обновления структуры обращается к разработчику. Если самостоятельное редактирование не требуется, вместо CMS можно согласовать регламент обновлений — это другой объём работ.

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

Шаблон технического задания для заполнения

Скопируйте пункты в документ и заполните до запроса окончательной сметы. Неизвестные решения помечайте «нужно определить», а не оставляйте на неявное усмотрение подрядчика.

Компания и предложение: [что продаём, кому, в каких регионах].
Цель сайта: [какое действие должен совершить посетитель].
Первая версия: [что включено; что явно не входит].
Страницы: [список, назначение, основные блоки, шаблоны].
Материалы: [кто готовит тексты, фотографии, цены; сроки передачи].
Дизайн: [примеры с пояснениями; брендовые материалы; макеты мобильной версии].
Функции: [сценарии, поля, проверки, успешные действия и ошибки].
Интеграции: [системы, передаваемые данные, обработка сбоев, доступы].
SEO и аналитика: [адреса, метаданные, индексация, счётчики и измеряемые события].
Эксплуатация: [кто обновляет сайт; домен, хостинг, резервные копии и восстановление].
Проверка и передача: [устройства и браузеры, тестовые сценарии, инструкция, исходники и доступы].
Этапы и изменения: [что сдаётся на каждом этапе, кто согласует, как оцениваются новые пожелания].

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

Как проверить готовность и избежать спорных требований

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

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

Вместо «всё под ключ» перечислите результаты передачи: рабочая версия на домене, исходники, доступы, инструкция по обновлению, настройка резервного копирования и проверка восстановления — в том объёме, который согласован для проекта.

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

Частые вопросы о техническом задании

Можно ли заказать сайт без готового ТЗ?

Да. Для первого разговора достаточно описания бизнеса и задачи. Затем заказчик и исполнитель уточняют требования и фиксируют объём работ. Подготовка подробного ТЗ может быть отдельным этапом; его результат и стоимость стоит обсудить заранее.

Нужно ли техническое задание для лендинга?

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

Кто должен составлять ТЗ — заказчик или разработчик?

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

Можно ли по этому шаблону сразу получить точную цену?

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

Если вы готовите проект, соберите по шаблону список страниц и задач. Его можно использовать при обращении за разработкой сайта в SEOLIFT: так проще обсудить объём первой версии и требования к дальнейшему продвижению.