Как составить ТЗ на разработку сайта с нуля

Коротко: Чтобы составить техническое задание на сайт, необходимо описать бизнес-цели, структуру страниц, функционал, требования к интеграции с CRM и актуальные юридические нормы. Правильное ТЗ включает детальные параметры безопасности (HTTPS, TLS), требования по 152-ФЗ с отдельным согласием на обработку данных и соответствие ГОСТ Р 52872-2019 для доступности. Это минимизирует риск переделок и раздувания бюджета.

Кстати, в AmSales мы делаем внедрение и настройку Битрикс24 и разработку сайтов под ключ под ключ. Если нужна помощь - напишите нам.

Этапы подготовки ТЗ для разработки сайта

Разработка сайта начинается не с выбора дизайна, а с глубокого аудита того, зачем этот инструмент вообще нужен вашему бизнесу. Если вы просто скажете разработчикам "сделайте красиво", вы получите продукт, который выглядит современно, но не приносит денег. Грамотная структура ТЗ на разработку сайта подразумевает последовательное движение от смыслов к коду.

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

Фундамент проектирования

После понимания целей наступает этап формирования функциональной карты. Вы решаете, какие модули вам необходимы: личный кабинет, калькулятор стоимости, интерактивная карта или система фильтрации товаров. На этом же этапе закладывается информационная архитектура - то есть карта всех разделов и подразделов. Важно понимать, что структура должна быть масштабируемой. Если сегодня у вас 10 товаров, а завтра будет 10 000, архитектура не должна "посыпаться".

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

Завершается подготовка документа этапом согласования сценариев использования (User Stories). Это описание того, как конкретный пользователь решает свою задачу. Например: "Клиент заходит на страницу услуги, использует калькулятор, получает предварительную стоимость и оставляет контакты, чтобы менеджер перезвонил". Если вы не пропишете эти сценарии в техническом задании для веб-студии, разработчики могут реализовать функционал, который технически работает, но неудобен для реального человека.

Функциональные требования и архитектура проекта

Функциональные требования - это ответ на вопрос "что сайт должен делать?". Это не про цвет кнопок, а про логику процессов. Если у вас интернет-магазин, требования включают работу корзины, систему промокодов, расчет доставки через API транспортных компаний и учет остатков на складе. Если это корпоративный портал - это поиск по документам, система уведомлений и права доступа.

Архитектура проекта определяет, как данные будут храниться и передаваться. Важно разделить клиентскую часть (Frontend) и серверную (Backend). В 2026 году стандарт индустрии - это разделение на Headless-архитектуру, когда интерфейс отделен от системы управления контентом (CMS). Это позволяет менять дизайн сайта, не переписывая всю логику работы с данными, что существенно экономит бюджет при редизайне.

Типы функциональных блоков

При составлении ТЗ разделяйте требования на три категории:

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

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

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

Технические параметры и требования к хостингу

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

Критически важным параметром является протокол передачи данных. Для любого современного коммерческого сайта использование HTTPS обязательно. В ТЗ необходимо прописать: наличие действующего SSL-сертификата, поддержку протокола TLS версии 1.2 и выше, настройку принудительного редиректа с HTTP на HTTPS и полное отсутствие смешанного контента (mixed content), когда часть ресурсов (картинки, скрипты) подгружается по незащищенному протоколу.

Параметры производительности

Скорость загрузки напрямую влияет на SEO и конверсию. Рекомендуется указывать в ТЗ конкретные метрики Core Web Vitals (LCP, FID, CLS). Сайт должен проходить тесты Google PageSpeed Insights с определенным баллом. Это заставляет разработчиков оптимизировать изображения, минимизировать CSS/JS файлы и настраивать кэширование на уровне сервера.

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

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

Юридические требования по закону 152-ФЗ

Работа с данными пользователей - это зона повышенного риска. Если ваш сайт содержит хотя бы одну форму (даже просто "оставьте email для рассылки"), вы становитесь оператором персональных данных. Это накладывает на вас обязательства, прописанные в ФЗ № 152 "О персональных данных". Ошибки в этом блоке ТЗ могут привести к проверкам Роскомнадзора и огромным штрафам.

Главное требование - прозрачность. На сайте должна быть опубликована актуальная Политика обработки персональных данных. Она должна быть доступна с любой страницы сайта (обычно через ссылку в футере) и содержать исчерпывающую информацию: кто собирает данные (ваши реквизиты), зачем (цели), какие именно данные (ФИО, телефон, email) и как пользователь может отозвать свое согласие. Политика не должна быть "скачанной из интернета" - она обязана отражать реальные процессы вашего бизнеса.

В ТЗ необходимо заложить техническую реализацию защиты данных. Это касается не только шифрования (HTTPS), но и разграничения прав доступа внутри системы управления сайтом. Менеджер по продажам должен видеть контакты клиентов, но не должен иметь возможности выгрузить всю базу данных или удалить её. Контроль действий сотрудников внутри админ-панели - это тоже часть обеспечения безопасности данных согласно 152-ФЗ.

Реквизиты организации

Для подтверждения легитимности бизнеса и упрощения проверок, в футере сайта принято размещать полные юридические реквизиты. Это включает в себя: полное наименование организации (ООО или ИП), организационно-правовую форму, ОГРН/ОГРНИП и ИНН. Это не просто формальность, а способ показать регулятору и клиентам, что вы работаете в правовом поле.

Новые правила согласия на обработку данных

С 1 сентября 2025 года правила игры в вопросах согласия на обработку персональных данных (ПДн) радикально изменились. Если раньше многие компании пытались "спрятать" согласие внутри текста пользовательского соглашения или оферты, то теперь такой подход считается незаконным. Согласие должно быть оформлено как отдельный, самостоятельный документ.

Это означает, что в ТЗ на разработку форм обратной связи нужно прописать следующую логику: пользователь видит пустой чекбокс (он не должен быть отмечен по умолчанию!), рядом с которым размещается прямая ссылка на полный текст документа "Согласие на обработку персональных данных". В самом документе должны быть четко указаны: ФИО субъекта (пользователя) и данные оператора (вашей компании), конкретная цель сбора данных (например, "для связи по поводу заказа"), перечень собираемых данных и перечень действий, которые вы с ними совершаете.

Технически важно не просто получить галочку, а зафиксировать факт этого действия. Рекомендуется внедрить логирование согласий. Система должна записывать в базу данных: IP-адрес пользователя, время и дату нажатия на чекбокс, а также версию документа, с которой он согласился. В случае претензии со стороны Роскомнадзора, только такие логи будут являться доказательством того, что вы соблюдаете закон.

Также важно учитывать cookie-файлы. Скрипты аналитики, чат-боты и счетчики также могут собирать данные, которые классифицируются как ПДн. Поэтому на сайте должно быть реализовано cookie-уведомление, которое дает пользователю возможность не только принять, но и отклонить определенные типы файлов. Нельзя активировать маркетинговые скрипты до того, как пользователь выразил свое согласие.

Требования к доступности и ГОСТ Р 52872-2019

С 1 марта 2026 года требования к доступности сайтов (web accessibility) стали обязательными в полном объеме согласно ГОСТ Р 52872-2019. Это касается не только государственных структур, но и коммерческих компаний, если они хотят соответствовать современным стандартам качества и избегать юридических рисков. Доступность - это возможность пользоваться сайтом людьми с ограниченными возможностями здоровья (например, слабовидящими).

В техническом задании должны быть четко прописаны следующие параметры:

• Контрастность: соотношение контраста текста к фону должно быть не менее 4.5:1. Это критично для читаемости.
• Атрибуты alt: все значимые изображения должны иметь заполненные alt-атрибуты, чтобы скринридеры (программы, читающие текст с экрана) могли объяснить пользователю, что изображено на картинке.
• Навигация с клавиатуры: пользователь должен иметь возможность перемещаться по всем элементам сайта (ссылки, кнопки, формы) с помощью клавиши Tab без использования мыши.
• Масштабирование: сайт должен поддерживать увеличение шрифта и элементов до 200% без появления горизонтальной полосы прокрутки.

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

Интеграция с CRM и системами автоматизации

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

При описании интеграций важно избегать общих фраз вроде "интегрировать с CRM". Нужно прописывать конкретные сценарии передачи данных. Например: "При заполнении формы 'Заказать звонок' в CRM должен создаваться новый Лид, в котором поля 'Имя', 'Телефон' и 'Тип услуги' заполняются автоматически на основе данных из формы. Также должна передаваться метка источника (UTM-метки)".

Сложности автоматизации

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

Также стоит рассмотреть интеграцию с системами сквозной аналитики. Чтобы маркетолог понимал, какая рекламная кампания принесла деньги, а какая просто "сожгла" бюджет, сайт должен передавать в системы аналитики (например, Google Analytics или Яндекс.Метрика) не только факт визита, но и события: нажатие на кнопку, успешная отправка формы, завершение заказа. Все эти события должны быть зафиксированы в ТЗ как обязательные элементы аналитического трекинга.

Типичные ошибки при постановке задач разработчикам

Опыт показывает, что большинство проблем при разработке сайтов проистекает не из-за плохой работы программистов, а из-за некачественного технического задания. Самая распространенная ошибка - избыточная абстрактность. Фразы типа "нужен современный дизайн" или "сайт должен быть быстрым" не имеют технического смысла. Для дизайнера "современный" может значить минимализм, а для вас - неоновый киберпанк. Для разработчика "быстрый" - это 0.5 секунды загрузки, а для вас - "ну, чтобы не зависал".

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

Третья ошибка - игнорирование этапа тестирования. Часто в ТЗ пишут только про разработку, но забывают про процесс приемки. В ТЗ обязательно должен быть раздел "Порядок приемки работ", где указано, по каким критериям вы будете проверять результат. Например: соответствие макетам, прохождение тестов скорости, отсутствие ошибок в консоли браузера и корректная передача данных в CRM.

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

Что запомнить:

• Согласие на обработку ПДн теперь должно быть отдельным документом с пустым чекбоксом.
• Используйте HTTPS с TLS 1.2+ и храните данные граждан РФ на серверах в России.
• Соблюдайте ГОСТ Р 52872-2019: контрастность, alt-атрибуты и навигация с клавиатуры обязательны.
• Интеграция с CRM должна включать четкое описание передачи полей и форматов данных.
• Всегда прописывайте требования к скорости загрузки через метрики Core Web Vitals.