ТЗ на разработку сайта: как составить и что включить

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

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

По данным агентских исследований рунета, более 70% конфликтов между клиентами и веб-студиями возникают из-за разного понимания итогового результата. Причина почти всегда кроется в размытых формулировках на старте. Если в требованиях записано «создать современный удобный каталог», разработчик сделает стандартную сетку товаров, а собственник бизнеса будет ждать встроенного калькулятора и мгновенной синхронизации с 1С.

Мнение эксперта: «Главная проблема стандартных ТЗ в том, что их пишут либо сухим техническим языком, либо набором абстрактных пожеланий вроде "сделайте красиво и быструю загрузку". В результате получается ресурс, который идеально работает технически, но абсолютно не продаёт. В Zveno мы начинаем проектирование с реестра смыслов — исследовательской анкеты на 100–200 вопросов о продукте, клиентах и барьерах покупки. Только после этого сформированные смыслы превращаются в технические требования к блокам и функционалу», — Григорий Блаер, основатель Zveno.

---

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

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

Разберём основные функции, которые выполняет профессиональное ТЗ в процессе веб-разработки:

• Фиксация объёма работ и стоимости: документ защищает обе стороны от неконтролируемого разрастания задач (scope creep), когда в процессе верстки заказчик просит бесплатно добавить личный кабинет или квиз;
• Защита от срыва сроков: чёткое описание каждого модуля позволяет программистам и дизайнерам точно оценить трудозатраты в часах;
• Критерий приёмки результатов: при сдаче проекта проверяется соответствие готового сайта каждому пункту ТЗ, что исключает субъективные оценки в духе «мне не нравится этот цвет»;
• Единый контекст для команды: копирайтер, designer, верстальщик и SEO-специалист работают по одной логике, не создавая противоречащих друг другу решений.

Кто должен составлять техзадание: заказчик или исполнитель?

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

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

Оптимальный процесс распределения ролей при подготовке ТЗ выглядит следующим образом:

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

1. Общие сведения о проекте и бизнес-целях

Раздел задаёт рамку для всей команды разработки. Без понимания сферы деятельности и задач бизнеса программисты и дизайнеры будут принимать решения на свой вкус.

В этот блок входят следующие данные:

• Информация о компании: ниша, регион работы, основные продукты и ключевое позиционирование;
• Цели создания сайта: получение прямых заявок (лидогенерация), презентация сложного оборудования, автоматизация расчётов или первичный отсев нецелевых клиентов;
• Портрет целевой аудитории: кто принимают решение о покупке (РОМ, генеральный директор, частный заказчик) и какие главные страхи их останавливают;
• Источники трафика: контекстная реклама Яндекс Директ, органическое SEO-продвижение, холодные рассылки или таргетированная реклама.

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

Запросить бесплатный аудит сайта

2. Требования к структуре и навигации

Каждая страница и блок сайта должны занимать своё строго отведенное место в общей цепочке продаж. В ТЗ прописывается полная карта сайта (Sitemap), иерархия вложенности и логика перехода между разделами.

При проектировании структуры важно учитывать тип ресурса и особенности поведения целевой аудитории:

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

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

3. Функциональные требования и интерактивные элементы

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

Обязательному детальному описанию подлежат следующие интерактивные модули:

• Формы обратной связи: количество полей, автоматическое определение региона, валидация номеров телефонов по маске +7 (X-X-X) XXX-XX-XX, всплывающие окна благодарности (Thank You Page) и политика обработки персональных данных в соответствии с 152-ФЗ;
• Калькуляторы и квизы: полная математическая формула расчёта параметров, алгоритм ветвления вопросов, зависимости между переключателями и условия выдачи итоговой цифры или скидочного купона. Для каждого шага квиза прописываются варианты ответов, маски полей и логика передачи результатов менеджеру;
• Интерактивные фильтры и поиск: параметры сортировки товаров или услуг по характеристикам, цена, наличие, а также работа фильтрации без перезагрузки страницы (AJAX) для ускорения отклика;
• Интеграции со сторонними сервисами: передача контактов в CRM-систему (Битрикс24, amoCRM) с сохранением источников трафика (UTM-метки, Client ID), отправка мгновенных уведомлений в Telegram-бот компании, подключение эквайринга и сервисов сквозной аналитики;
• Личные кабинеты и закрытые разделы: если проектом предусмотрена регистрация клиентов, в ТЗ описывается матрица прав доступа, восстановление пароля по SMS или email, а также история заказов и просмотров.

4. Требования к дизайну и UI/UX интерфейсу

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

В ТЗ фиксируются:

• Фирменный стиль и типографика: ссылки на брендбук, утверждённая цветовая палитра (основной, акцентный и фоновый цвета в формате HEX/RGB), шрифтовые пары для заголовков и основного текста, размер кегля для мобильной и десктопной версий;
• Адаптивность и сетка: список поддерживаемых разрешений экранов (мобильные устройства 360px–480px, планшеты 768px–1024px, десктопы от 1280px до 1920px);
• Состояния элементов: визуальный отклик кнопок при наведении курсора (hover), клике (active), заблокированном состоянии (disabled) и фокусировке для ввода (focus);
• Анимация и микро-взаимодействия: допустимые параметры анимации появления блоков (fade-in, slide-up), скорость плавного скролла и строгий запрет на отвлекающие всплывающие элементы;
• Графические материалы: формат и качество предоставляемых фотографий, иконок (SVG) и видеороликов, требования к оптимизации веса файлов.

5. Технические требования и стек технологий

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

В разделе указываются:

• Система управления контентом (CMS) или конструктор: Tilda, WordPress, 1C-Битрикс или кастомный стек (Astro, React, Node.js) в зависимости от сложности логики и планов по масштабированию;
• Скорость загрузки и производительность: целевые показатели Google PageSpeed Insights (не менее 80/100 для мобильных устройств и 90/100 для десктопов), сжатие изображений в формат WebP и минификация скриптов;
• Безопасность и отказоустойчивость: наличие SSL-сертификата (HTTPS), защита от спама (reCAPTCHA v3 или SmartCaptcha), протоколы ежедневного резервного копирования баз данных на изолированный сервер;
• Кроссбраузерность: корректное отображение и идентичное поведение всех модулей во всех актуальных браузерах (Яндекс Браузер, Chrome, Safari, Edge, Firefox);
• Хостинг и доменное имя: требования к параметрам сервера (объём RAM, версия PHP/Node.js, дисковое пространство SSD/NVMe) и правам доступа к доменной панели.

6. Требования к контенту и SEO-оптимизации

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

Раздел содержит:

• Порядок подготовки материалов: кто предоставляет тексты, фотографии, видеообзоры и сертификаты качества (заказчик или веб-студия), а также график подачи материалов;
• Базовая SEO-разметка: поддержка редактирования тегов Title, Meta Description, заголовочной структуры H1–H3, чистота кода и автогенерация карты сайта sitemap.xml;
• ЧПУ-ссылки и редиректы: человекопонятные URL-адреса страниц на транслите без лишних динамических параметров и настройка 301-редиректов при переезде со старого сайта;
• Микроразметка данных: внедрение стандартов Schema.org (Organization, Product, Article, FAQPage) для корректного формирования расширенных сниппетов в выдаче Яндекса и Google.

7. Порядок сдачи, тестирования и гарантийные обязательства

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

Здесь прописываются:

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

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

Рассчитать стоимость и сроки проекта

---

ТЗ на лендинг vs ТЗ на многостраничный сайт: разница в требованиях

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

Разберём ключевые отличия в требованиях к этим типам веб-ресурсов.

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

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

Специфика ТЗ для различных рыночных сегментов

Требования в техзадании также зависят от специфики вашей целевой аудитории:

• B2B и производственные предприятия: ключевой акцент делается на детальных спецификациях, возможности скачивания прайс-листов в PDF, форме запроса коммерческого предложения и блоке со стандартами ГОСТ/ISO и сертификатами;
• B2C и сфера услуг: приоритет отдается эмоциям, прозрачности цен, социальным доказательствам (живые фото, отзывы, видео), интерактивной карте проезда и мгновенной записи в 1-2 клика.

Ниже приведена сравнительная таблица параметров, которые фиксируются в ТЗ для разных форматов веб-сайтов:

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

---

5 главных ошибок в ТЗ, из-за которых сайт не даёт заявок

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

Рассмотрим самые частые просчеты, с которыми сталкиваются предприниматели при заказе веб-сайтов.

1. Отсутствие маркетинговой аналитики до начала написания ТЗ

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

В Zveno любые технические формулировки базируются на маркетинговых фактах. Например, при создании сайта для компании AutoBIT24 (внедрение корпоративных систем Битрикс24) мы отказались от шаблонных фраз про «индивидуальный подход». На основе двух 1,5-часовых глубоких интервью был спроектирован калькулятор внедрения и выстроено позиционирование вокруг оптимизации реальных бизнес-процессов. Результат — сайт создавался с нуля, а за первые 3 месяца работы без рекламного бюджета получил более 6 000 органических посетителей и окупил разработку с первых заключенных сделок.

2. Использование оценочных и субъективных формулировок

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

Каждое требование должно быть измеримым:

Неправильно: «Сайт должен быстро загружаться на смартфонах.» Правильно: «Скорость загрузки главной страницы по метрике Google PageSpeed Insights на мобильных устройствах должна составлять не менее 80 баллов, а время до первого отображения контента (FCP) — не более 1,8 секунды.»

3. Перегруженность лишним функционалом на старте

Желание внедрить на новый сайт личные кабинеты, сложные программы лояльности, голосовой поиск и интерактивные 3D-модели на первом этапе приводит к затягиванию сроков на полгода и раздуванию сметы в 3 раза.

Для проверки коммерческих гипотез оптимально запустить MVP-версию (минимально жизнеспособный продукт) с фокусировкой на главном оффере, квизе или калькуляторе. Внедрять сложные модули стоит только после того, как сайт начнёт стабильно генерировать заявки и окупать рекламный трафик.

4. Игнорирование адаптивности под мобильный трафик

В большинстве B2B и B2C ниш доля мобильного трафика превышает 65–80%. Однако в традиционных ТЗ до сих пор 90% объема уделяется десктопной версии, а про мобильные устройства вспоминают в самом конце одной строчкой «сделать адаптив».

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

5. Отсутствие требований к сквозной аналитике и UTM-меткам

Сайт может выглядеть безупречно, но если в ТЗ не прописана корректная передача динамических UTM-меток в CRM-систему, маркетолог не сможет определить, из каких конкретно рекламных объявлений приходят платящие клиенты.

В ТЗ обязательно фиксируются требования к установке Яндекс Метрики, настройке целей на отправку каждой формы, интеграции с коллтрекингом и передаче технической информации (Client ID, источник, тип устройства) вместе с контактами лида.

Пример качественной работы сайта — это не просто отсутствие ошибок в коде, а стабильный поток целевых обращений в ваш отдел продаж. Если вы планируете запуск нового проекта или хотите кардинально повысить показатели действующего ресурса, обратитесь к команде Zveno. Мы поможем сформировать точную структуру и разработаем сайт, адаптированный под ваши бизнес-задачи.

Запросить разбор вашей ситуации

---

Часто задаваемые вопросы (FAQ)

Сколько времени занимает составление грамотного ТЗ на сайт?

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

Можно ли обойтись без ТЗ при заказе сайта на Tilda или другом конструкторе?

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

Что делать, если в процессе разработки возникла необходимость изменить ТЗ?

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

Кто несёт ответственность, если сайт сделан строго по ТЗ, но не приносит заявок?

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

Входит ли стоимость составления ТЗ в общий бюджет разработки сайта?

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

Можно ли использовать чужое ТЗ из интернета в качестве образца для своего проекта?

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