Плохой бриф обходится агентству втрое дороже самого проекта — пересогласованиями, переделками и потерей доверия клиента. Это не преувеличение. Когда digital-агентство передаёт размытые требования подрядчику, включается цепная реакция: подрядчик додумывает за клиента, агентство не контролирует результат, а клиент получает «не то, что просил». Знакомая ситуация?
Однако проблема не в том, что агентства не умеют собирать брифы. Проблема в том, что большинство брифов попадают в одну из двух ловушек: слишком расплывчатые («сделайте красиво и удобно») или слишком детальные (40-страничное ТЗ, которое никто не читает). Бриф на разработку для агентства — это не формальность, а инструмент управления рисками. В этом гайде — 12 обязательных секций, которые превращают бриф из бюрократической бумажки в фундамент успешного проекта.
Почему 80% агентских брифов не работают
По нашему опыту работы с десятками digital-агентств в Москве, бриф на разработку для агентства ломается в трёх типичных точках. Каждая из них приводит к scope creep — расползанию требований, которое убивает маржинальность проекта.
Ловушка 1: «Бриф-салфетка»
Клиент описывает задачу в двух абзацах: «Нужна CRM для отдела продаж. Бюджет — до миллиона. Сроки — вчера». Агентство передаёт это подрядчику, тот задаёт 30 уточняющих вопросов, начинается пинг-понг на две недели. В результате разработка стартует с опозданием, а клиент раздражён ещё до первого спринта.
Ловушка 2: «Бриф-диссертация»
Противоположная крайность — агентство пишет техническое задание на 40 страниц, пытаясь предусмотреть каждую кнопку. Подрядчик получает монолит, в котором бизнес-логика перемешана с дизайн-требованиями и инфраструктурными решениями. Ни один разработчик не прочитает такой документ целиком. В итоге критически важные детали теряются среди второстепенных.
Ловушка 3: «Бриф-копипаст»
Агентство берёт шаблон из интернета и заполняет его формально. Пункт «целевая аудитория» — «все предприниматели». Пункт «конкуренты» — «много». Такой бриф создаёт иллюзию системности, но не содержит ни одного инсайта, который помог бы подрядчику принять архитектурные решения.
Все три ловушки объединяет одно: агентство не управляет процессом сбора требований, а реагирует на то, что клиент сам решит рассказать. Давайте это исправим.
«Золотой» бриф: 12 обязательных секций
Мы называем это Goldilocks Brief — бриф, который «в самый раз». Не слишком короткий, не слишком длинный. Каждая из 12 секций решает конкретную задачу и предотвращает конкретный риск. Именно такой формат мы рекомендуем агентствам, которые передают разработку на субподряд.
1. Бизнес-контекст клиента
Кто клиент, чем занимается, какая отрасль, размер компании, текущие боли. Эта секция отвечает на вопрос «зачем вообще нужен этот продукт». Без неё подрядчик будет писать код в вакууме, не понимая бизнес-логику.
2. Целевые пользователи
Кто будет использовать систему? Роли, сценарии, частота использования. Если CRM — то для 5 менеджеров или для 500? Это определяет архитектуру, UX и стоимость.
3. Проблема и ожидаемый результат
Что не устраивает сейчас и как должно быть после запуска. Конкретные метрики: «сократить время обработки заявки с 2 часов до 15 минут», а не «сделать удобнее». Подрядчику нужны измеримые критерии успеха.
4. Функциональные требования
Список функций с приоритетами: must have, should have, nice to have. Именно приоритизация отличает рабочий бриф от списка желаний. Кроме того, приоритеты помогают подрядчику предложить поэтапную разработку — сначала MVP с must have, потом итерации.
5. Нефункциональные требования
Производительность, безопасность, масштабируемость, доступность. Сколько одновременных пользователей? Нужна ли сертификация? Какие данные хранятся (персональные, финансовые)? Эти требования часто «всплывают» в середине проекта и вызывают перерасход бюджета.
6. Интеграции
С какими системами нужна связь: 1С, CRM, платёжные системы, мессенджеры, внешние API. Каждая интеграция — это дополнительная сложность и сроки. Подрядчик должен знать о них до оценки, а не после.
7. Дизайн и UX
Есть ли брендбук? Нужен ли дизайн с нуля или адаптация существующего? Референсы: «нравится как у X, но проще». Эта секция предотвращает бесконечные итерации дизайна, которые задерживают разработку.
8. Технические ограничения
Хостинг клиента, предпочтения по стеку, legacy-системы, с которыми нужна совместимость. Если клиент работает на 1С-Битрикс и не готов менять — подрядчик должен знать это заранее. Также сюда входят требования к инфраструктуре: облако или собственные серверы, российский хостинг или зарубежный.
9. Бюджет и модель оплаты
Диапазон бюджета клиента, предпочтительная модель (фиксированная цена, T&M, этапная). Для агентства критично зафиксировать стоимость у подрядчика до презентации клиенту — иначе маржинальность непредсказуема.
10. Сроки и milestone’ы
Дедлайн клиента, промежуточные точки контроля, зависимости (например, «запуск привязан к выставке 15 марта»). Подрядчик должен подтвердить реальность сроков до подписания договора.
11. Критерии приёмки
Как агентство и клиент будут оценивать готовый продукт: тестовые сценарии, чек-лист приёмки, определение «готово». Без этой секции финальная сдача превращается в бесконечный спор «это баг или фича». Подробнее о структурированной оценке IT-проектов для агентств — в нашем детальном гайде.
12. Юридические условия
NDA, non-compete, передача IP, гарантийный период. Для white-label проектов обязательно: подрядчик не контактирует с клиентом агентства, вся документация под брендом агентства.
До и после: как бриф меняет проект
Теория — это одно. Давайте посмотрим, как бриф на разработку для агентства выглядит на практике — до и после трансформации.
СекцияДо (типичный бриф)После (Goldilocks Brief)
Бизнес-контекст«Компания продаёт мебель»«B2B-поставщик офисной мебели, 200 клиентов, средний чек 800К, боль — ручная обработка заказов» Пользователи«Менеджеры»«12 менеджеров по продажам + 3 логиста + руководитель, каждый — со своими сценариями» Результат«Удобная CRM»«Сократить цикл обработки заказа с 48 часов до 4 часов, автоматизировать документооборот» ФункцииСписок из 50 пунктов без приоритетов8 must have + 12 should have + 10 nice to have с описанием каждого Бюджет«Надо обсудить»«До 900 000 рублей за MVP, фиксированная цена, этапная оплата 30/30/40» Сроки«Как можно быстрее»«MVP к 1 июня (22 рабочих дня), бета-тест 2 недели, промежуточное демо каждую неделю»
Обратите внимание на разницу: во втором столбце подрядчик может оценить проект за 1-2 дня и дать точную цену. В первом — начинается недельный пинг-понг вопросов и уточнений, который раздражает всех участников.
Качество брифа определяет не объём текста, а количество решений, которые подрядчик может принять без дополнительных вопросов.
Практика: какие вопросы задавать клиенту
Главная сложность — клиент часто не знает, что именно рассказать. Поэтому задача агентства — задавать правильные вопросы. Вот список, который мы рекомендуем использовать при первом брифинге. Каждый вопрос привязан к секции Goldilocks Brief.
Бизнес и пользователи (секции 1-3)
- Какую конкретную проблему вы хотите решить этим продуктом?
- Как вы решаете эту проблему сейчас — вручную, в Excel, через другую систему?
- Кто будет пользоваться системой каждый день? Сколько таких людей?
- Как вы поймёте через 3 месяца, что проект был успешным? Назовите конкретную метрику.
- Есть ли внутренние или внешние дедлайны, к которым нужно успеть?
Технические детали (секции 4-8)
- С какими системами нужна интеграция? Есть ли у них API или документация?
- Где сейчас хранятся данные? Нужна ли миграция?
- Есть ли требования к хостингу — российские серверы, облако, собственная инфраструктура?
- Какие данные будут в системе — персональные, финансовые, коммерческая тайна?
- Есть ли брендбук или UI-гайдлайны? Нужен дизайн с нуля?
Коммерческие условия (секции 9-12)
- Какой бюджет вы закладываете на первую версию (MVP)?
- Как вам удобнее платить — фиксированная сумма за весь проект или этапами?
- Кто со стороны вашей компании будет принимать решения и участвовать в демо?
- Есть ли требования по NDA или конфиденциальности данных?
Этот список — не допрос, а структурированная беседа. Опытный аккаунт-менеджер агентства проходит эти вопросы за 45-60 минут в формате Zoom-колла. После встречи — оформляет ответы в формат Goldilocks Brief и согласовывает с клиентом письменно.
Когда клиент не может сформулировать, что ему нужно
Самая сложная ситуация: клиент говорит «я не знаю, что мне нужно — вы же эксперты, предложите». Это не тупик, а возможность для агентства проявить экспертизу. Тем не менее здесь нужен особый подход.
Техника «от проблемы, а не от решения»
Не спрашивайте «какие функции вам нужны?». Спрашивайте «что вас бесит в текущем процессе?». Клиент может не знать, что ему нужен Kanban-board, но точно знает, что «заявки теряются между отделами». Задача агентства — перевести боли в функциональные требования. Именно этот навык — выявление реальных потребностей клиента — отличает сильное агентство от посредника.
Техника «покажи, а не расскажи»
Покажите клиенту 3-4 аналога и спросите: «Что нравится? Что категорически не подходит?». Визуальные референсы работают лучше абстрактных вопросов. Подрядчик, получив список референсов с комментариями, оценит проект точнее, чем по текстовому описанию.
Техника «MVP-фильтр»
Предложите клиенту мысленный эксперимент: «Если бы у вас было только 3 недели и 900 000 рублей — какие 5 функций вы бы включили?». Это заставляет расставить приоритеты и выделить ядро продукта. Всё остальное — в backlog для следующих итераций.
FAQ о брифе на разработку для агентства
Сколько времени занимает сбор качественного брифа?
От 2 до 5 рабочих дней: один Zoom-колл с клиентом (45-60 минут), оформление в документ (2-3 часа), согласование с клиентом (1-2 раунда правок). Это инвестиция, которая экономит 2-4 недели на этапе разработки. При white-label модели с фиксированным сроком 22 рабочих дня качество брифа напрямую определяет, уложитесь вы в дедлайн или нет.
Должен ли бриф содержать технические детали стека?
Только если у клиента есть жёсткие ограничения: legacy-система на конкретном фреймворке, корпоративный стандарт на базу данных, требование российского хостинга. В остальных случаях выбор стека — задача подрядчика. Агентству достаточно зафиксировать нефункциональные требования: производительность, безопасность, масштабируемость.
Можно ли передать подрядчику сбор брифа напрямую?
Нет, если вы работаете в white-label формате. Клиент не должен знать о субподрядчике. Однако подрядчик может подготовить список уточняющих вопросов, которые агентство задаст клиенту от своего имени. Это обычная практика — она сочетает экспертизу подрядчика с контролем агентства над коммуникацией.
Что делать, если клиент меняет требования после утверждения брифа?
Именно для этого в Goldilocks Brief есть секция «модель оплаты». Фиксированная цена покрывает scope из утверждённого брифа. Любые изменения — через Change Request с отдельной оценкой сроков и стоимости. Это защищает и агентство, и подрядчика от бесконечного scope creep.
Бриф — это не документ, а процесс
Главный инсайт этого гайда: бриф на разработку для агентства — это не бумажка, которую нужно заполнить для галочки. Это управляемый процесс извлечения требований из клиента и трансляции их подрядчику в понятном формате. 12 секций Goldilocks Brief — ваш чек-лист, который предотвращает самые дорогие ошибки: scope creep, срыв сроков и конфликты при приёмке.
Три правила, которые стоит запомнить: фиксируйте приоритеты (must/should/nice to have), требуйте измеримые критерии успеха и согласовывайте бриф письменно до начала разработки. Эти три шага снижают вероятность конфликтов на 70% — по нашему опыту работы с десятками агентств.
Хотите протестировать формат Goldilocks Brief на реальном проекте? Запишитесь на 30-минутный Zoom-колл — разберём ваш текущий бриф и покажем, как модель white-label MVP с совместной проработкой ТЗ помогает агентствам сдавать проекты в срок и в бюджет.