Бриф на разработку сайта помогает передать исполнителю то, что вы знаете о своём бизнесе: зачем нужен сайт, кому он поможет, что вы предлагаете и как обрабатываете обращения. Для первого разговора достаточно собрать эти сведения, доступные материалы и список вопросов. Выбирать язык программирования, рисовать меню и заранее проектировать каждую страницу не требуется.
Хороший бриф позволяет понять задачу и увидеть, каких данных пока не хватает. Ниже разберём, что подготовить, как уточнять расплывчатые ответы и какой пакет отправить разработчику. Все примеры относятся к учебной компании по ремонту промышленного насосного оборудования; это не описание клиента или проекта Студии Вебирус.
Где заканчивается бриф и начинается ТЗ
В рамках этой статьи бриф — исходное описание бизнеса и ожиданий заказчика. Он может быть документом, ответами в форме или записью разговора, которую стороны затем проверят. Ценность определяется содержанием, а не форматом анкеты.
Допустим, предприниматель пишет: «Клиент должен понять, обслуживаем ли мы его оборудование, и передать сведения о поломке». Это полезная вводная для брифа. Какие страницы понадобятся, как будет устроена форма и куда поступят данные — решения, которые ещё предстоит проработать.
В техническом задании на сайт согласованное решение описывают подробно: функции, данные, условия работы и критерии приёмки. Смета показывает состав и стоимость работ с учётом принятого объёма. А этапы разработки объясняют, как команда проходит путь от исходной задачи к запуску. Бриф даёт материал для этих документов, но сам по себе не подтверждает согласование функций, цены или сроков.
Начните с изменения, которое нужно бизнесу
Фраза «хотим современный сайт» описывает впечатление. Она не объясняет, почему компания берётся за проект именно сейчас. Назовите проблему в текущей работе и полезное действие, которое посетитель должен совершить.
Слабый ответ: «Нужен красивый сайт, чтобы было больше клиентов».
Полезный учебный ответ: «Сейчас диспетчер сначала выясняет по телефону тип насоса и место установки. Часть обращений касается оборудования, которое мы не ремонтируем. Хотим заранее показать условия обслуживания и получать запросы, в которых понятны модель, неисправность и место объекта».
Такой ответ задаёт направление: помочь посетителю проверить, подходит ли услуга, и передать сведения для первичной оценки. Он ещё не определяет, нужна ли одна страница, каталог оборудования или другой формат.
Чтобы уточнить свою формулировку, вспомните последнее неудобное обращение: чего человек не знал, что сотрудник выяснял повторно и где возникла задержка. Добавьте обезличенный пример вопроса клиента или заметку сотрудника. Это полезнее общего пожелания «повысить конверсию».
Сразу договоритесь, какое наблюдение поможет оценить изменение. В учебной компании можно учитывать, по скольким обращениям хватает сведений для первичного ответа и почему остальные приходится уточнять. Если такого учёта ещё нет, так и напишите: «Исходные данные не собирали; способ измерения нужно согласовать». Не назначайте произвольный процент роста только ради заполнения поля.
Связь цели, ожидаемого эффекта и измерения описана в руководстве GOV.UK по выбору показателей. В коммерческом проекте этот подход помогает связать оценку сайта с задачей бизнеса. При этом число обращений зависит и от источников посетителей, предложения, сезона и работы сотрудников: бриф не даёт оснований обещать результат одной только разработкой.
Объясните предложение и тех, кто его выбирает
Что именно клиент может получить
Соберите описание основных услуг или товаров, границ предложения и условий обращения. Особенно полезны сведения, которые менеджер обычно объясняет устно: география работы, исключения, порядок расчёта стоимости, необходимость диагностики, документы и способ получения результата.
Слабый ответ: «Ремонтируем всё, качество высокое, цены выгодные».
Полезный учебный ответ: «Занимаемся промышленным насосным оборудованием. По модели и описанию неисправности инженер проверяет, можем ли принять работу. Зону выезда укажем отдельным списком населённых пунктов. Окончательную стоимость определяем после диагностики; бытовую сантехнику не обслуживаем».
Уточняйте каждое преимущество через подтверждение. Если хотите написать об опыте, подготовьте сведения о выполненных работах, которые разрешено раскрывать. Если важна квалификация, найдите действующие документы. Для слов «быстро» и «гарантия» нужны реальные условия, одобренные ответственным сотрудником. Непроверенную формулировку лучше пометить как вопрос, чем передать её в работу как готовый факт.
Кто обращается и на каком основании принимает решение
Для брифа полезнее роль человека и его задача, чем портрет «мужчины и женщины от 25 до 60 лет». В одной покупке могут участвовать несколько людей, которым нужна разная информация.
Слабый ответ: «Наша аудитория — все предприятия».
Полезный учебный ответ: «Инженер предприятия ищет, кто работает с его моделью насоса, и хочет описать поломку. Сотрудник закупок проверяет реквизиты, порядок договора и документы. Оба могут обратиться к нам, но первый оценивает техническую применимость услуги, а второй — условия сотрудничества».
Проверьте этот ответ с тем, кто принимает звонки и ведёт продажи. Посмотрите реальные вопросы в переписке, убрав имена, телефоны и другие сведения, которые не нужны исполнителю. Если часть аудитории пока предполагается, обозначьте это прямо.
Руководство GOV.UK по потребностям пользователей рекомендует опираться на наблюдения и описывать проблему человека без преждевременного выбора решения. Для брифа это означает: «нужно передать сведения о поломке» полезнее неподтверждённого требования «обязательно нужен личный кабинет».
Опишите путь клиента до ответа сотрудника
Выберите основные ситуации обращения и расскажите их обычными словами. Для каждой достаточно объяснить, что случилось у клиента, какую информацию он ищет, что хочет сделать и кто продолжит работу после его действия.
Слабый ответ: «Нужны форма, чат, калькулятор и онлайн-запись».
Полезный учебный сценарий:
- На предприятии обнаружили неисправность насоса. Инженер ищет подрядчика и открывает сайт с телефона.
- Он проверяет, работает ли компания с таким оборудованием и выезжает ли к нему на объект.
- Он хочет передать модель, описание проблемы и фотографию, если она есть. Если модель неизвестна, ему нужен понятный способ обратиться за уточнением.
- Запрос получает диспетчер, направляет его инженеру и организует ответ. Заказчику нужно понимать, что обращение принято и что произойдёт дальше.
Здесь видна роль сайта и работа компании после обращения. Разработчик сможет обсудить подходящий способ передачи информации и ограничения. Наличие формы с фотографией пока остаётся вариантом решения; возможность безопасно принимать файлы и обрабатывать заявки ещё нужно проверить.
Отдельно укажите важные исключения: клиент не знает модель, у него нет фотографии, он находится за пределами зоны выезда, сотрудник не может ответить сразу. Не нужно проектировать все экраны ошибок. Достаточно описать, как бизнес поступает в таких случаях сегодня и что должен понять клиент.
Для существующих систем сообщите название и назначение. Например: «Заявки учитываем в CRM; её поддерживает внешний специалист. Автоматическая передача обращений пока не согласована». Исполнитель уточнит возможности интеграции. Требование «подключить CRM» без описания процесса не объясняет, какие сведения и кому нужны.
Подготовьте материалы с понятным состоянием
Не откладывайте разговор до готовности всех текстов и фотографий. Составьте перечень того, что есть, что требует проверки и кто может помочь с недостающим. Отсутствие материала — тоже важная вводная, если оно названо явно.
Слабый ответ: «Всё возьмите с нашего старого сайта».
Полезный учебный ответ: «На старом сайте верны описания видов ремонта, но зона выезда устарела. Логотип приложен в исходном формате. В папке есть фотографии мастерской; перед использованием их проверит руководитель. Новое описание диагностики подготовит инженер, дату передачи ещё согласуем».
Для удобства приложите короткий реестр:
| Материал | Что отметить рядом с файлом или ссылкой |
|---|---|
| Услуги, товары, условия | Какие сведения актуальны и кто подтверждает спорные формулировки |
| Логотип, фирменные цвета, правила оформления | Где лежат исходники и какие правила действительно действуют |
| Фотографии и видео | Что изображено, качество исходника и подтверждена ли возможность использования |
| Кейсы, отзывы, документы | Что разрешено показывать публично и какие данные нужно исключить |
| Старый сайт и аналитика | Что полезно сохранить, какие проблемы известны и за какой период есть данные |
Не отправляйте неподготовленный архив всех документов компании. Отберите материалы, которые объясняют предложение, подтверждают его или помогают понять текущую проблему. Клиентские переписки и документы передавайте с удалёнными лишними данными; закрытые материалы заранее пометьте как непубличные.
Ссылки на понравившиеся сайты тоже могут быть полезны. К каждой добавьте конкретное объяснение: «понятно показана зона обслуживания» или «легко найти документы». Фраза «сделайте как здесь» не показывает, какая особенность вам нужна и подходит ли она вашему бизнесу.
Назовите ограничения и людей, которые принимают решения
Бюджет, дата, доступность сотрудников и порядок согласования влияют на возможный объём. В брифе достаточно сообщить известные рамки и основание каждой из них.
Слабый ответ: «Нужно всё, срочно, бюджет скажите сами».
Полезный учебный ответ: «Сайт нужен к отраслевому мероприятию; его дату сообщим отдельно. Для первого выпуска главное — объяснить услуги и принимать обращения. Кабинет постоянного клиента обсуждается как дальнейшее развитие. Верхнюю границу бюджета утвердит директор после предложения по составу работ. Тексты проверяет инженер, дизайн и итоговый объём согласует директор».
Если бюджет уже определён, укажите сумму или рабочий диапазон и поясните, что в него планируете включить: разработку, подготовку контента, внешние сервисы, обслуживание. Если рамка не установлена, попросите предложить состав первой версии и отдельно оценить необязательные возможности. Это позволит обсуждать выбор, а не угадывать скрытый предел расходов.
Для даты объясните причину и приоритет: обязательна ли готовность всего сайта или к событию нужен определённый сценарий. Какие факторы затем влияют на календарный план, разобраны в статье о сроках разработки сайта.
Назначьте одного человека, который собирает обратную связь компании и передаёт согласованный ответ. При этом назовите владельцев отдельных сведений: кто отвечает за услуги, материалы, договорные формулировки и доступы. Если руководитель проекта не вправе утверждать расходы или содержание, это нужно знать до работы.
Добавьте, кто будет обновлять сайт после запуска и какие сведения меняются чаще всего. Ответ «сотрудник меняет условия обслуживания по мере необходимости» помогает обсудить управление контентом. Название конкретной системы управления можно выбрать позже, когда понятны эти задачи и ограничения.
Перечислите доступы, не записывая пароли в бриф
На этапе подготовки нужен список существующих ресурсов и ответственных людей. Для нового сайта часть строк может отсутствовать; для переделки действующего важно понимать, у кого находятся домен, хостинг, система управления, аналитика и связанные сервисы.
Слабый ответ: «Всё у прежнего разработчика; вот его общий логин и пароль».
Полезный учебный ответ: «Домен оформлен на компанию, продлением занимается администратор. Хостинг и старую систему управления обслуживает прежний подрядчик. Доступ к аналитике может выдать маркетолог. Список необходимых прав согласуем после определения работ; полный доступ к CRM на первой встрече не выдаём».
Для каждого ресурса запишите название, назначение, владельца учётной записи или ответственного, возможность пригласить исполнителя и известные ограничения. Если доступ утрачен или права владельца неясны, отметьте это как отдельный вопрос. Не обещайте передачу того, что ещё не проверили.
Когда доступ действительно понадобится, согласуйте его цель и срок. Используйте отдельную учётную запись или приглашение с нужной ролью, если сервис это поддерживает. Не включайте в бриф пароли, ключи API, коды восстановления и данные платёжных средств. Способ передачи необходимых секретов согласуйте отдельно.
Принцип выдачи только тех прав, которые нужны для задачи, описан в рекомендациях OWASP по авторизации. Применительно к подготовке проекта это повод разделить просмотр сведений, изменение настроек и управление аккаунтом, а после завершения работ пересмотреть выданные права.
Как поступить с ответом «пока не знаем»
Неизвестное полезно сохранить в брифе вместе со способом уточнения. Оно становится проблемой, когда выглядит как уже принятое решение.
Например, «нужен калькулятор ремонта» может быть пожеланием руководителя. Чтобы понять его смысл, выясните, какую цену компания способна рассчитать без диагностики, какие данные для этого нужны и кто подтвердит правила. До ответа корректная запись звучит так: «Хотим помочь клиенту оценить расходы; возможность предварительного расчёта проверит инженер». Разработчик затем предложит подходящее решение.
Можно использовать три короткие пометки:
- Подтверждено: сведения проверены ответственным сотрудником; например, список обслуживаемого оборудования.
- Предположение: ожидаемая польза пока не проверена; например, клиентам будет удобно отправлять фотографии.
- Нужно выяснить: данных не хватает; например, кто может предоставить документацию по CRM.
Рядом с открытым вопросом укажите человека или источник, к которому можно обратиться. Если вопрос влияет на объём работ, его нужно закрыть до согласования соответствующего решения. Выбор технологии и подробную структуру страниц оставьте для обсуждения с исполнителем на основе собранных вводных.
Что отправить для первого обсуждения
Соберите один короткий документ с вводными и папку отобранных материалов. Учебный пример краткого описания может выглядеть так:
Компания ремонтирует промышленное насосное оборудование. Главная задача сайта — помочь предприятию проверить применимость услуги и передать сведения для первичного ответа. Инженеру нужны данные об оборудовании и условиях выезда; закупкам — условия сотрудничества и документы. После обращения диспетчер подключает инженера. Первая версия должна объяснять услуги и поддерживать этот сценарий. Кабинет клиента пока обсуждается. Краткие сведения об ограничениях и ответственных приложены; материалы и их состояние перечислены в реестре. Владельцы домена, хостинга и аналитики известны. Открытые вопросы — обработка фотографий и возможность передачи заявки в CRM.
Это описание сопровождают конкретные сведения: список услуг и исключений, зона работы, выбранные материалы, известные бюджетные рамки, дата с её основанием и контакты ответственных. Если чего-то пока нет, оставьте явную пометку и способ уточнения.
Перед отправкой проверьте три вещи: может ли исполнитель объяснить вашу задачу своими словами; понятно ли, что подтверждено, а что обсуждается; найден ли человек, который ответит на каждый существенный открытый вопрос. Количество заполненных полей само по себе не определяет готовность брифа.
Этот пакет можно использовать при выборе веб-студии, чтобы обсуждать с кандидатами одни и те же вводные. Если рассматриваете разработку сайта под ключ, сведения о материалах, согласованиях и обработке обращений помогут уточнить границы работ. С подготовленным описанием можно обсудить проект: сначала разобрать задачу и пробелы, затем согласовать решение, ТЗ и состав сметы.
