Техническое задание на сайт: как зафиксировать объём, смету и ответственность

ТЗ на сайт — это договорённость о результате, а не список экранов

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

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

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

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

Что должно быть в ТЗ, чтобы смета была сопоставимой

Смета становится управляемой не тогда, когда в ней больше строк, а когда у каждой строки есть понятный объём и граница. «Каталог», «личный кабинет», «интеграция с CRM» и «SEO-оптимизация» — это названия крупных областей, а не постановка задачи. Два подрядчика могут вложить в одинаковую формулировку совершенно разный набор работ.

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

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

Переведите бизнес-задачу в пользовательские сценарии

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

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

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

Функции, контент и интеграции: где прячется дополнительный объём

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

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

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

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

Как зафиксировать приёмку и изменения без конфликта

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

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

Скорость сайта также должна быть частью проверяемого контура, а не обещанием «быстро». Google относит LCP, INP и CLS к текущему набору Core Web Vitals; эти метрики описывают загрузку, отзывчивость и визуальную стабильность. В документе полезно указывать не абстрактную скорость, а страницы, среду и способ оценки. Практический разбор метрик и технических приоритетов есть в статье «Скорость сайта и Core Web Vitals: что чинить, а что косметика».

Опасные формулировки, которые потом стоят денег

Главная проблема плохого ТЗ — не краткость, а невозможность доказать, что именно было обещано. Слова «современный», «интуитивный», «премиальный», «с высокой конверсией», «под SEO» и «быстрый» могут быть направлением для обсуждения, но не критерием сдачи. Они не содержат пользователя, действие, условия и способ проверки.

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

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

ТЗ — старт управляемой разработки, а не финальная бумага

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

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

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