Обложка статьи 
Хорошее ТЗ на разработку сайта — это не формальность и не бюрократия
ради бюрократии. Это документ, который помогает бизнесу и подрядчику одинаково
понимать задачи проекта, состав работ, критерии результата, сроки, ограничения
и точки контроля. Чем лучше подготовлено ТЗ, тем меньше вероятность, что сайт
получится красивым, но не тем, а бюджет уйдет на переделки.

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

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

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

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

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

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

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

·      
название компании и проекта;

·      
контакты ответственных лиц;

·      
тип сайта: лендинг,
корпоративный сайт, каталог, интернет-магазин;

·      
текущий статус: новый проект,
редизайн, перенос или развитие существующего сайта.

·      
какие результаты должен давать
сайт: заявки, звонки, записи, продажи, лиды по конкретным услугам;

·      
какие услуги или продукты
являются приоритетными;

·      
какие каналы трафика
планируются: SEO, контекст, таргет, прямой трафик, email, карты, ретаргетинг;

·      
какие KPI считаются успехом:
количество заявок, конверсия, CPL, глубина просмотра, индексируемость.

·      
кто основные клиенты;

·      
какие сегменты аудитории есть у
бизнеса;

·      
что важно для каждого сегмента:
цена, скорость, кейсы, гарантии, доверие, экспертиза;

·      
какое действие должен совершить
пользователь: оставить заявку, позвонить, записаться, скачать материал,
заказать консультацию.

·      
список разделов и страниц;

·      
иерархия меню;

·      
отдельные посадочные страницы
под услуги, регионы, направления, категории;

·      
служебные страницы: политика,
оферта, контакты, карта сайта, 404, спасибо-страница.

·      
какой контент предоставляет
заказчик, а какой делает подрядчик;

·      
нужны ли тексты, фото,
инфографика, иллюстрации, иконки;

·      
нужны ли страницы под SEO и
блог;

·      
нужны ли кейсы, отзывы, FAQ,
отраслевые страницы, страницы по городам.

·      
формы заявок и их поля;

·      
кнопки связи, обратный звонок,
чат, мессенджеры;

·      
каталог, фильтры, поиск,
калькулятор, квиз, онлайн-оплата;

·      
интеграции с CRM,
коллтрекингом, аналитикой, email-сервисами, картами и онлайн-записью.

·      
общая стилистика и желаемое
позиционирование;

·      
референсы: что нравится и что
не нравится;

·      
требования к адаптиву;

·      
какие блоки обязательны на
первом экране и на ключевых страницах;

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

·      
ЧПУ-адреса страниц;

·      
возможность редактирования
title, description, H1 и alt;

·      
настройка sitemap.xml и
robots.txt;

·      
корректные редиректы, canonical
и 404;

·      
скорость загрузки, чистота
кода, отсутствие дублей, корректная мобильная версия;

·      
готовность сайта к индексации и
аналитике.

·      
установка Яндекс Метрики и
Google Analytics / GA4 при необходимости;

·      
настройка целей, событий, форм,
кликов и звонков;

·      
UTM-метки, сквозная аналитика,
коллтрекинг;

·      
отдельная thank-you page или
триггеры успешной отправки форм.

·      
этапы проекта: прототип,
дизайн, верстка, программирование, наполнение, тестирование, запуск;

·      
сроки по каждому этапу;

·      
кто и за сколько времени
согласовывает промежуточные результаты;

·      
по каким критериям проект
считается выполненным.

Хорошее ТЗ не обязано быть документом на сорок страниц. Для лендинга
под рекламу иногда хватает 5–7 плотных страниц, если там четко описаны задачи,
структура, контент, функционал, аналитика и критерии приемки. Для
многостраничного сайта, B2B-проекта, SEO-сайта или сложной интеграции документ
может быть значительно больше. Смысл не в объеме, а в том, чтобы после прочтения
не оставалось ключевых вопросов.

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

·      
Нет целей проекта. Формулировка
«нужен современный сайт» ничего не дает ни бизнесу, ни подрядчику.

·      
Не описана целевая аудитория. В
результате сайт получается для всех, а значит — ни для кого.

·      
Структура не зафиксирована.
Позже страницы и блоки начинают расти хаотично.

·      
Не указаны обязательные
интеграции. Потом вспоминается CRM, коллтрекинг, онлайн-оплата, API и
начинается веселье.

·      
Не прописаны требования к SEO.
В итоге получается сайт, который надо переделывать уже после запуска.

·      
Нет критериев приемки. Самый
дорогой вид недосказанности — тот, который обнаруживается на финальном этапе.

·      
Все завязано на референсах.
Референсы полезны, но они не заменяют логику проекта и задачу бизнеса.

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

·      
Цель сайта: какие заявки или
действия он должен приносить.

·      
Тип сайта: лендинг,
корпоративный, каталог, интернет-магазин, сайт услуги.

·      
Целевая аудитория: кто клиент и
почему он должен выбрать Вас.

·      
Структура: список страниц и
обязательных блоков на каждой из них.

·      
Функции: формы, калькуляторы,
интеграции, оплата, чат, CRM, аналитика.

·      
Контент: что уже есть, что
нужно создать, кто отвечает за материалы.

·      
SEO: какие страницы
приоритетны, нужен ли блог, регионы, мета-теги, индексация.

·      
Дизайн: позиционирование,
стилистика, референсы, ограничения.

·      
Сроки и этапы: когда и что
должно быть готово.

·      
Приемка: по каким критериям Вы
примете проект.

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

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

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

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

Грамотное ТЗ на разработку сайта — это документ, который экономит
деньги, сроки и нервные клетки. Оно помогает сразу увязать цели бизнеса,
структуру сайта, функционал, маркетинг, SEO, аналитику и приемку в одну
систему. Хорошее ТЗ не обязано быть гигантским, но обязано быть конкретным.
Если в документе не видно, зачем делается сайт, для кого он делается, как он
будет зарабатывать и по каким критериям приниматься, значит проект стартует на
зыбкой почве.

Правильный подход простой: сначала зафиксировать бизнес-задачу,
потом структуру и сценарии пользователя, затем функционал, контент, SEO,
интеграции и критерии результата. Все остальное — уже упаковка. И да, красивый
сайт без нормального ТЗ иногда получается. Проблема только в том, что потом он
живет как дорогой памятник импровизации.

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

Оптимально — совместно. Заказчик формулирует бизнес-задачи и
ограничения, подрядчик помогает перевести их в понятную проектную структуру.

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

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

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