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

1. Задача и бизнес-цель

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

2. Аудитория и сценарии

Кто будет пользоваться результатом и что у него должно получиться сделать. Полезно перечислить два-три главных сценария от лица пользователя: «менеджер загружает прайс и видит, кто его открыл», «посетитель сравнивает тарифы и оставляет заявку». Если аудиторий несколько — скажите, какая главная: интерфейс нельзя одинаково хорошо настроить на всех сразу.

3. Состав и ограничения

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

4. Срок и бюджетные рамки

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

5. Критерии готовности

По каким признакам вы поймёте, что проект удался? «Заявки приходят в CRM», «менеджеры перестали вести учёт в таблицах», «страница загружается быстро, и её находят в поиске по названию продукта». Критерии превращают приёмку из спора о вкусах в проверку по списку.

Чего в брифе писать не нужно

  • Технических решений — «нужен React и микросервисы». Выбор технологий — ответственность исполнителя, и он делается под задачу, а не наоборот.
  • Описаний всех страниц и кнопок. Это работа этапа проектирования — в брифе она преждевременна и связывает руки.
  • Красивых формулировок. Бриф — рабочий документ; «хотим как у конкурента X, но проще» — нормальная и полезная фраза.

Что происходит с брифом дальше

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

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