ТЗ и бриф: в чём разница и что готовить первым

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

Что такое бриф

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

Что такое техническое задание

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

Основные различия

• Назначение: бриф — для понимания задачи и оценки, ТЗ — для разработки и приёмки
• Автор: бриф заполняет заказчик, ТЗ составляет исполнитель вместе с заказчиком
• Детализация: бриф — несколько страниц, ТЗ — столько, сколько нужно для однозначного понимания
• Язык: бриф — бизнес-термины, ТЗ — точные формулировки функций и требований
• Юридический вес: бриф обычно не входит в договор, ТЗ часто становится его приложением

Что готовить первым

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

Что включить в бриф

• Описание компании и продукта
• Проблема, которую нужно решить, и цель проекта
• Кто будет пользоваться результатом
• Основные функции своими словами
• Существующие системы, с которыми нужна связь
• Примеры решений, которые нравятся и не нравятся, с объяснением почему
• Желаемые сроки и ограничения
• Кто со стороны заказчика принимает решения

Как бриф превращается в ТЗ

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

Можно ли обойтись без одного из них

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

Типичные ошибки

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