Бриф на разработку сайта: как объяснить задачу и получить нужный результат

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

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

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

Что решает бриф, а что остаётся за техническим заданием

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

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

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

Что собрать до заполнения: факты вместо догадок

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

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

Поговорите не только с руководителем, но и с людьми, которые принимают звонки, рассчитывают заказы и обновляют каталог. Они знают, почему приходится переспрашивать клиента и где действующие процессы расходятся с красивым описанием. Сам принцип изучения пользователей и действующего пути до проектирования отражён в руководстве GOV.UK по исследованию на этапе discovery. Для коммерческого сайта это полезный подход, а не обязательный государственный стандарт.

Как описать цель сайта и не обещать невозможное

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

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

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

Аудитория: опишите ситуацию, а не вымышленный портрет

«Мужчины и женщины от 25 до 55 лет со средним доходом» редко помогает выбрать структуру сайта. Полезнее знать, что один посетитель срочно ищет замену детали и знает модель, а другой впервые собирает комплект и боится ошибиться. Их действия различаются, даже если возраст и доход одинаковы. Для каждой важной группы запишите причину визита, уже известную информацию, тревогу и ожидаемый результат.

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

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

Как определить страницы и границы первой версии

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

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

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

Кто подготовит тексты, фотографии и данные

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

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

Заложите процесс обновления после запуска. Кто меняет часы работы? Кто снимает недоступную услугу? Как редактор узнаёт, что характеристика устарела? Попросите показать обновление одной типичной записи без участия программиста. Сайт, который легко наполнить один раз и трудно поддерживать, быстро расходится с реальностью. Особенно это важно для цен и тарифов, где старая информация влияет на ожидания покупателей.

Интеграции: описывайте передачу данных до конца

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

Разберите сбои ещё в брифе. Что увидит посетитель, если внешняя система недоступна? Где сохранится принятая заявка? Кто получит уведомление об ошибке? Повторная отправка не должна незаметно создавать несколько заказов, а отсутствие ответа — выглядеть подтверждённым успехом. Не нужно самостоятельно придумывать технический механизм; достаточно потребовать объяснение сценариев и критерий проверки. Это существенная часть функции, а не мелочь для финального теста.

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

Что включить в бриф по SEO и переносу старого сайта

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

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

Не ставьте приёмку разработки в зависимость от гарантированного места в выдаче. Проверяемы доступность страниц, корректные ответы сервера, отсутствие случайного запрета индексации, согласованные canonical и внутренняя навигация. Решение поисковой системы и коммерческий эффект оцениваются позже. Подробный план есть в руководстве по SEO при переезде, а контроль ошибок выпуска — в статье о регрессионном тестировании.

Как описать приёмку, чтобы не спорить о «готово»

Критерий приёмки связывает действие, условия и наблюдаемый результат. «Форма работает» не объясняет ничего. «С телефона отправляем допустимые тестовые данные, видим подтверждение, а ответственному приходит ровно одна запись с верными полями» уже позволяет проверить цепочку. Рядом должен быть отрицательный пример: обязательное поле не заполнено, сеть оборвалась, вложение неподходящего формата. Без него команда проверит только счастливый путь.

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

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

Условный пример: сайт компании по обслуживанию оборудования

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

Цель. Помочь организациям проверить соответствие услуги своей задаче и передать данные для первичной оценки. Аудитория. Ответственный за оборудование знает модель и симптомы, но не обязательно разбирается в ремонте. Основной сценарий. Найти направление, проверить ограничения, описать проблему и оставить контакт. Содержимое. Описание направлений, список обслуживаемого оборудования, порядок работы, контакты и подтверждённые примеры. В публикацию не идут закрытые данные заказчиков.

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

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

Как по одному брифу сравнить предложения подрядчиков

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

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

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

Короткий шаблон брифа и что делать после заполнения

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

1. Компания и предложение: что делаем, для кого, где работаем.
2. Проблема: что сейчас мешает клиенту или сотруднику.
3. Главная задача посетителя: действие и ожидаемый итог.
4. Основные сценарии: новый клиент, повторный клиент, редактор.
5. Первая версия: нужные разделы и типы страниц.
6. Не входит: отложенные функции и условие возврата к ним.
7. Контент: что готово, кто допишет, кто согласует.
8. Интеграции: какие данные передаём и что считаем успехом.
9. Старый сайт: адреса, материалы и настройки, которые сохраняем.
10. Ограничения: сроки, ресурсы команды, обязательные условия.
11. Приёмка: сценарии, устройства, ошибки и подтверждения.
12. Ответственные: решение, материалы, проверка и поддержка.
13. Открытые вопросы: владелец и момент уточнения.

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

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