Бриф на разработку сайта: шаблон и пример заполнения

1. Как заполнять бриф без технических знаний

Заполняйте документ своими словами. Если решение ещё не принято, пишите «нужно обсудить», а не выбирайте случайную CMS или интеграцию. Отдельно отмечайте обязательное для первого запуска и пожелания на будущее: иначе разные исполнители посчитают разный объём работ, а сравнить предложения будет трудно.

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

2. Шаблон брифа на разработку сайта

Скопируйте весь список ниже и заполните пустые поля. Важнее конкретные ответы, чем объём документа. Ссылки на материалы размещайте в закрытой рабочей папке; пароли и персональные данные клиентов в этот шаблон не добавляйте. Если сайт уже существует, приложите перечень важных страниц до обсуждения новой структуры.

• Компания, вид деятельности, контакт согласующего: ______.
• Что продаём и какие услуги доступны сейчас: ______.
• Кто покупатель, с каким вопросом приходит и что мешает выбрать: ______.
• Страны, языки и реально обслуживаемая территория: ______.
• Главная задача сайта и основное действие посетителя: ______.
• Состав первого запуска и то, что пока не входит: ______.
• Страницы: название, вопрос посетителя, нужное действие на каждой: ______.
• Подтверждённые преимущества, ограничения и условия работы: ______.
• Материалы: тексты, фотографии, документы; кто готовит и к какой дате: ______.
• Примеры оформления: ссылки и что конкретно нравится или не подходит: ______.
• Форма заявки: необходимые поля, вложения, сообщение после отправки: ______.
• Куда поступает обращение, кто отвечает и кто его заменяет: ______.
• CRM, почта, запись, оплата или другие интеграции; обязательные поля: ______.
• Старый сайт: важные URL, формы и данные, которые нужно сохранить: ______.
• Планируемые источники посетителей и какие действия нужно измерять: ______.
• Бюджетный ориентир заказчика, желательная дата и причина срока: ______.
• Мобильные и компьютерные сценарии для приёмки: ______.
• Кто владеет доменом и хостингом; какие роли нужны исполнителю: ______.
• Резервные копии, передача результата, поддержка и ответственный после запуска: ______.
• Неясные вопросы, зависимости и решения до начала работ: ______.

3. Пример заполнения: условная мебельная мастерская

Это вымышленный учебный пример, не кейс AI PILOT и не описание реального заказчика. Все решения ниже придуманы, чтобы показать нужную степень конкретности. Суммы, реальные контакты и обещания коммерческого результата намеренно отсутствуют. Для своего проекта замените пример фактическими условиями компании.

• Компания и согласующий: условная мебельная мастерская; решения подтверждает руководитель. Реальные контакты добавляются только в рабочий документ.
• Предложение: изготовление кухонь по индивидуальному проекту, без продажи готовой мебели со склада.
• Покупатель: человек перед ремонтом; сравнивает исполнителей, хочет понять порядок расчёта и увидеть изделия.
• Территория и язык: один согласованный город, русский язык. Другие регионы пока не заявляем.
• Задача: получить запрос на обсуждение кухни. Заявка не считается автоматически продажей.
• Первый запуск: главная, кухни, порядок работы, примеры изделий и контакты. Интернет-магазин и личный кабинет не входят.
• Вопросы страниц: главная объясняет предложение; кухни — варианты исполнения; порядок работы — этапы; контакты — способ обращения.
• Условия: окончательная стоимость после размеров и комплектации. Подтверждённые преимущества согласует руководитель; гарантий цены по фотографии нет.
• Материалы: руководитель проверяет описания; мастер передаёт разрешённые фотографии до согласования макетов. Отсутствующие снимки отмечаются в списке.
• Оформление: спокойная светлая подача, крупные реальные фотографии. Чужие изделия не выдаём за собственные.
• Форма: имя, один способ связи, комментарий; план помещения необязателен. После сохранения показываем номер обращения.
• Ответственность: менеджер получает уведомление и разбирает обращения в объявленные часы; руководитель заменяет его при отсутствии.
• Интеграции: журнал заявок и уведомление менеджеру. В записи нужны запрос, дата и исходная страница; CRM пока не входит.
• Старый сайт: в этом примере его нет, переносить страницы и данные не требуется.
• Привлечение и измерение: поиск и рекомендации; отдельно считаем отправленные обращения и переходы к контактам. Рост не обещаем.
• Бюджет и срок: диапазон задаёт заказчик, дату утверждаем после проверки материалов и сметы; неподтверждённую оценку не публикуем.
• Приёмка: с телефона и компьютера отправить тестовую заявку, найти её в журнале, проверить уведомление, ошибку формы и повторную попытку.
• Владение: домен и хостинг оформляет компания; исполнителю выдаётся отдельная рабочая роль.
• Передача: исходные материалы и резервная копия с проверкой восстановления. После запуска руководитель назначает поддержку и отзывает временные доступы.
• Открытые вопросы: сервис уведомлений и допустимые вложения. Решить до начала реализации формы.

4. Что приложить к заполненному брифу

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

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

Источник: Google: руководство по поисковой оптимизации для начинающих.

5. Опишите путь заявки и поведение при ошибке

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

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

Источник: MDN: отправка и серверная обработка данных формы.

6. Превратите пожелания в критерии приёмки

Вместо «удобно на телефоне» запишите действия: открыть меню, прочитать услугу без увеличения, нажать контакт, заполнить форму, исправить ошибку и увидеть подтверждение. MDN описывает адаптивность как работу страницы на разных размерах экранов; она не доказывается одним уменьшенным скриншотом.

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

Источник: MDN: адаптивный веб-дизайн.

7. Доступы передавайте отдельно от брифа

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

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