Бриф: короткий документ от клиента о бизнесе
Бриф — это первый документ на любом проекте разработки сайта, и заполняет его клиент, а не подрядчик. По объёму это обычно несколько страниц: описание бизнеса и целей проекта, портрет целевой аудитории, список конкурентов, референсы сайтов, которые нравятся или, наоборот, категорически не нравятся, пожелания по функционалу в свободной форме и ограничения — сроки, бюджет, обязательные интеграции с уже используемыми системами.
Ценность брифа не в детализации, а в том, что он фиксирует бизнес-контекст до того, как кто-либо начал проектировать структуру или писать код. Бриф отвечает не на вопрос «что технически будет на сайте», а на вопрос «зачем этот сайт вообще нужен и кому он должен понравиться». Без этого контекста дальнейшая работа превращается в угадывание.
Техническое задание: детальная спецификация от подрядчика
Техническое задание — документ совершенно другого порядка. Его готовит подрядчик на основе брифа, и это уже не набор пожеланий, а инженерная спецификация: структура сайта по разделам, перечень функциональных блоков (каталог, корзина, личный кабинет, фильтры, форма записи), список интеграций (CRM, платёжные системы, службы доставки, 1С), а также сроки и этапы работ с конкретными датами сдачи.
Если бриф пишется свободным языком и может занимать пару страниц, то хорошее ТЗ — это структурированный документ, по которому можно однозначно проверить, сделана функция или нет. Нельзя приступать к разработке крупного сайта без ТЗ по той же причине, по которой нельзя строить дом без проекта: без спецификации любая договорённость держится на устной памяти участников, а память у заказчика и исполнителя обычно расходится уже через пару недель.
Составление грамотного технического задания — отдельная большая тема, требующая знания нюансов конкретной CMS, интеграций и юридических формулировок про приёмку работ. Мы уже разбирали подробно, как правильно составить ТЗ на разработку сайта, в отдельном материале блога — если вы готовите ТЗ впервые или хотите свериться со своим черновиком, стоит заглянуть туда перед тем, как подписывать документ с подрядчиком.
Ключевое отличие в одном предложении
Если сжать разницу до одной формулировки, она звучит так: бриф описывает «зачем и для кого» делается сайт, а техническое задание описывает «что именно и как» будет реализовано. Бриф — это про бизнес-цель и аудиторию, ТЗ — про конкретную реализацию этой цели в виде структуры, функций и сроков. Один документ без другого решает только половину задачи: бизнес-цель без реализации остаётся благим намерением, а реализация без бизнес-цели рискует оказаться технически безупречной, но никому не нужной.
Полезная аналогия — сравнить бриф с техническим заданием архитектора и инженера-строителя. Заказчик дома объясняет архитектору, для какой семьи строится дом, сколько человек будет в нём жить и какой образ жизни они ведут, — это его бриф. А инженер уже переводит эти пожелания в конкретные чертежи с размерами, материалами и расчётом нагрузок — это техническое задание на этапе реализации. Перепутать роли этих документов в разработке сайта так же странно, как просить архитектора сразу считать несущие конструкции, не выяснив предварительно, для кого и зачем строится дом.
Что бывает, если пропустить бриф
Когда подрядчик садится писать ТЗ без предварительного брифа, он вынужден додумывать бизнес-контекст самостоятельно — по интуиции, по общим представлениям о рынке заказчика, иногда просто по шаблону «как обычно делают у конкурентов». Результат предсказуем: техническое задание получается технически грамотным, но не учитывающим реальные приоритеты бизнеса. На середине разработки заказчик вдруг вспоминает, что для него критично было показать сертификаты на главной странице или что основная аудитория сайта — не молодая, а возрастная, и интерфейс нужно делать крупнее и проще. Это означает пересмотр уже утверждённого ТЗ, переделки готовых экранов и, как следствие, сдвиг сроков и рост бюджета — притом что всей этой ситуации можно было избежать одним заполненным бланком брифа в начале проекта.
Что бывает, если пропустить техническое задание
Обратная ситуация не менее болезненна. Если проект стартует сразу после брифа, без детального ТЗ, стороны опираются на общее, устное понимание того, что должно получиться. Это неизбежно приводит к спорам формата «а мы думали, что фильтр по цвету входит в стоимость» или «мы не обсуждали интеграцию с CRM отдельно, но считали её само собой разумеющейся частью проекта». Без письменной спецификации у обеих сторон нет общего документа, на который можно сослаться, поэтому подобные разногласия решаются не аргументами, а выяснением отношений. Размытыми оказываются и сроки: без разбивки на этапы с конкретными датами сдачи легко потерять ощущение прогресса и не заметить, что проект уже вышел за рамки изначального плана. В худшем случае спор доходит до попытки зафиксировать объём работ постфактум, когда часть функционала уже реализована, а часть — нет, и обе стороны по-разному помнят, что вообще обсуждалось на старте.
Как выстроить последовательность правильно
Правильный порядок всегда один: сначала бриф, потом техническое задание на его основе, и только затем — разработка. Пропуск любого из двух документов не ускоряет проект, а лишь переносит неизбежные уточнения на более поздний и более дорогой этап, когда исправить решение стоит уже не часов, а недель работы. Мы в Evaris используем эту последовательность на каждом проекте и рекомендуем начать с того же: заполнить бриф на сайте Evaris — это займёт немного времени, но избавит от большей части недопониманий, которые обычно всплывают уже в процессе разработки.