Бриф и техническое задание на сайт: чем отличаются и что подготовить

В чем разница между брифом и ТЗ

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

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

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

Что собрать в брифе

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

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

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

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

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

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

Как бриф, прототип и ТЗ связаны

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

После прототипа многие вопросы становятся видимыми: не хватает контента, один экран пытается решить две задачи, форма слишком длинная, а кейс не содержит доказательств. Исправить это на черно-белой схеме дешевле, чем после финального дизайна.

Хороший документ не превращает проект в бюрократию. Он освобождает время для решений и помогает спокойно обсуждать изменения, потому что понятно, к какой части результата они относятся.