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

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

Зачем нужен бриф и почему без него проект обречён

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

Вот что я наблюдал на практике. Проект без брифа: клиент описал задачу устно, на созвоне, разработчик кивнул и начал делать. Через две недели показал макет — клиент говорит: «Нет, я совсем другое имел в виду». Переделка. Ещё неделя. «А вот тут я хотел калькулятор, я же говорил». Не говорил. Или говорил, но вскользь, и это никто не зафиксировал. Итог: проект вместо двух месяцев длится четыре, бюджет вырос в полтора раза, отношения испорчены.

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

Структура рабочего брифа: что обязательно включить

За годы работы я отточил структуру брифа, которая покрывает все ключевые аспекты. Расскажу о каждом блоке подробно.

Блок 1: Компания и бизнес-контекст

Это отправная точка. Мне нужно понять, для какого бизнеса я делаю сайт, иначе результат будет оторван от реальности.

Вопросы, которые я задаю: чем занимается компания, сколько лет на рынке, в каких регионах работает, кто основные клиенты (B2B или B2C, возраст, доход, проблемы), кто главные конкуренты (ссылки на их сайты), в чём ваше ключевое отличие от конкурентов.

Последний вопрос — самый важный и самый сложный. Если клиент отвечает «у нас качественные услуги и индивидуальный подход» — это не УТП, это набор слов. Я помогаю сформулировать: «Мы единственные в городе, кто делает ремонт с гарантией 5 лет и ведёт видеоотчёт каждого этапа». Вот это уже можно положить в основу сайта.

Блок 2: Цели сайта

Один из первых вопросов в брифе, и один из самых недооценённых. «Нам нужен красивый сайт» — это не цель. Цель должна быть конкретной и измеримой.

Примеры нормальных целей: получать не менее 30 заявок в месяц через форму на сайте; увеличить долю онлайн-продаж до 40% от общего оборота; снизить нагрузку на менеджеров за счёт личного кабинета клиента; занять первую страницу Яндекса по 10 ключевым запросам в течение полугода.

Когда цель сформулирована чётко, я понимаю, какой сайт делать. Если цель — лиды, делаем лендинг с мощным оффером и формами на каждом экране. Если цель — SEO-трафик, нужна многостраничная структура с контентом. Если цель — снять нагрузку с менеджеров, приоритет — функциональный личный кабинет и автоматизация. Без понимания целей я не начинаю работу — и вам не советую.

Блок 3: Функциональные требования

Здесь фиксируется всё, что сайт должен уметь. Это самый объёмный блок, и именно в нём чаще всего возникают разночтения.

Я прошу клиента ответить на вопросы: нужен ли каталог товаров или услуг, нужна ли корзина и онлайн-оплата, нужен ли личный кабинет (для клиентов, для сотрудников), нужен ли блог или раздел с новостями, нужен ли калькулятор стоимости, нужна ли онлайн-запись или бронирование, нужна ли интеграция с CRM (какой именно — Битрикс24, amoCRM, другая), нужна ли интеграция с 1С, нужна ли интеграция с мессенджерами (WhatsApp, Telegram), какие формы обратной связи нужны.

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

Блок 4: Дизайн и визуальные предпочтения

Дизайн — самая субъективная часть проекта. Один клиент любит минимализм, другой хочет «чтобы было ярко и всё двигалось». Если не выяснить это заранее — макет придётся переделывать.

Я прошу показать 3–5 сайтов, которые нравятся, и объяснить, что именно в них нравится: цветовая гамма, стиль фотографий, компоновка, шрифты, анимации. Также спрашиваю, есть ли брендбук или фирменный стиль (логотип, цвета, шрифты), какие эмоции сайт должен вызывать у посетителя (доверие, энергию, спокойствие, престиж), есть ли элементы, которые точно не нравятся (например, «не хочу тёмный фон» или «без анимаций»).

Этот блок экономит невероятное количество времени. Когда дизайнер (или я сам) садится за макет — он уже понимает направление, а не рисует вслепую.

Блок 5: Контент — кто и что готовит

Контент — боль многих проектов. Сайт готов, а текстов и фотографий нет. Проект стоит неделями, потому что клиент «ещё не успел написать тексты».

В брифе я чётко фиксирую: есть ли готовые тексты для сайта, есть ли профессиональные фотографии (не стоковые), есть ли видеоматериалы, кто будет готовить контент — клиент, его маркетолог или я. Если контент готовлю я — это отдельная строка в смете и отдельные сроки. И клиент знает об этом до старта, а не когда проект уже горит.

Блок 6: Технические требования

Этот блок важен для тех, кто уже имеет IT-инфраструктуру или специфические требования: предпочтения по технологии или CMS (Next.js, WordPress, Tilda, 1С-Битрикс), требования к хостингу (российский, облачный, выделенный сервер), существующий домен или нужен новый, требования к безопасности (SSL, защита персональных данных по 152-ФЗ), нагрузочные требования (ожидаемое количество посетителей).

Для многих малых бизнесов этот блок минимален — они доверяют выбор технологий мне. Но для компаний с IT-отделом он принципиально важен.

Блок 7: Бюджет и сроки

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

Я формулирую это так: «Мне не нужна точная цифра. Мне нужно понимать порядок: мы говорим о 50 000, 150 000 или 500 000 рублей? От этого зависит, что я могу предложить. Если бюджет 50 000 — это будет лендинг на конструкторе. Если 150 000 — полноценный многостраничный сайт. Если 500 000 — платформа с интеграциями и автоматизацией».

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

По срокам: я всегда уточняю, есть ли жёсткий дедлайн (привязка к мероприятию, сезону, запуску рекламной кампании) и какой запас по времени. Это влияет на приоритизацию задач.

Как проводить бриф-сессию: мой формат

Не все клиенты готовы заполнять бриф самостоятельно. Кому-то некогда, кому-то сложно сформулировать ответы в текстовом виде. Для таких случаев я провожу бриф-сессию — созвон на 40–60 минут, на котором задаю вопросы и фиксирую ответы.

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

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

Инструменты для ведения брифов

Я перепробовал разные форматы и остановился на комбинации. Google Forms — для первичного сбора информации. Удобно, бесплатно, ответы автоматически собираются в таблицу. Notion — для ведения проекта после бриф-сессии. Здесь бриф превращается в рабочий документ с чек-листами, комментариями и статусами. Google Docs — для финального согласования. Клиент может оставить комментарии прямо в тексте.

PDF-версия тоже уместна, если клиент привык к классическому документообороту. Главное — не формат, а полнота и чёткость зафиксированной информации.

Что делать, когда клиент не знает, чего хочет

Это нормальная ситуация, и я не раздражаюсь, когда с ней сталкиваюсь. Предприниматель — специалист в своём деле, не в веб-разработке. Моя задача — помочь ему сформулировать потребность.

В таких случаях я начинаю с бизнес-задач: «Откуда сейчас приходят клиенты? Что вы хотите изменить? Что вас не устраивает в текущей ситуации?». Потом показываю примеры из его ниши: «Вот сайт вашего конкурента — нравится? А вот другой подход — что скажете?». И постепенно складывается картина.

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

Типичные ошибки при составлении брифа

Первая — слишком общие вопросы. «Опишите ваш бизнес» — это не вопрос, это домашнее сочинение. Лучше: «Перечислите 5 основных услуг в порядке приоритетности» или «Назовите 3 главных конкурента и укажите, чем вы от них отличаетесь».

Вторая — бриф слишком длинный. Если в нём 80 вопросов на 10 страницах — клиент бросит на третьей. Оптимально: 20–30 ключевых вопросов, которые можно заполнить за 20–30 минут.

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

Четвёртая — бриф не обновляется. Если по ходу проекта меняются требования — обновите бриф. Иначе к концу проекта будет два документа: бриф, который уже не актуален, и хаотичная переписка в мессенджере.

Бриф — это инвестиция, а не бюрократия

30–60 минут на бриф в начале проекта — это сэкономленные 30–50 часов работы и нервов в процессе. Если ваш разработчик не просит бриф — это повод задуматься, насколько системно он подходит к работе. А если вы заказчик и вам предлагают заполнить бриф — отнеситесь к этому серьёзно. Это не формальность. Это фундамент, на котором строится ваш будущий сайт. И чем он прочнее — тем надёжнее результат.