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

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

Что решает бриф на разработку сайта и где его границы

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

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

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

Бриф и техническое задание — разные документы

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

Когда бриф не нужен

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

Кто заполняет бриф и кто отвечает за результат

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

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

Роли на стороне заказчика

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

Роль подрядчика

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

Какие входные данные нужны для оценки проекта

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

Бизнес-контекст

Что компания продаёт, какие направления важны, кто принимает решения, есть ли сезонность, какие каналы привлечения уже используются. Эти данные помогают понять, какие сценарии на сайте действительно нужны. Например, если основной поток клиентов приходит по рекомендациям, сайт может выполнять роль витрины и точки контакта, а не сложного магазина.

Пользователи и сценарии

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

Технические ограничения и интеграции

Какие системы уже используются: учётная система, CRM, склад, платёжные сервисы, рассылки, аналитика. Какие из них должны быть связаны с сайтом. Есть ли ограничения по хостингу, домену, доступам. Если сайт планируется на 1С-Битрикс, стоит заранее обсудить разработка сайтов на Битрикс и уточнить, какие модули и настройки потребуются. Это не техническое задание, а рамка для оценки.

Как устроен шаблон брифа на разработку сайта

Шаблон брифа на разработку сайта удобно делить на две части. В источнике 1С-Битрикс рекомендуется именно такой подход: первая часть — разъяснение терминов, вторая — анкета. Словарь помогает участникам говорить на одном языке, а анкета собирает ответы в структурированном виде. Если пропустить словарь, на встрече могут возникнуть споры о значениях слов, которые каждый понимает по-своему.

Две части: словарь и анкета

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

Блоки анкеты

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

Как формулировать цели и критерии успешности

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

Список целей с отметками

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

Приоритеты и порог успешности

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

Критерии успешности по инструментам

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

Поиск неизвестных интеграций и владельцев контента

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

Карта систем и интеграций

Составьте список систем, которые уже используются или планируются. Для каждой укажите: назначение, кто отвечает, есть ли API, кто может дать доступы. Не нужно вставлять в бриф пароли и ключи — достаточно указать ответственных и способ передачи доступов. Если речь идёт о Битрикс, полезно заранее обсудить Администрирование сайта на Битрикс — доступы, данные и настройки, чтобы понять, какие данные и настройки потребуются.

Владельцы контента и данных

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

Что делать, если владелец не найден

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

Таблица принятия решения: что уточнять на разных этапах

Таблица помогает не потерять вопросы. Но она не заменяет обсуждение: по каждому пункту нужен человек, который подтвердит ответ. Если таблица заполнена формально, она не снижает риски.

Учебный пример брифа на условных данных

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

Входные условия

У компании есть три направления услуг, два офиса, отдел продаж из пяти человек. Сайт нужен, чтобы клиенты оставляли заявки и находили информацию об услугах. Контент: тексты об услугах, фотографии, список филиалов. Интеграции: заявки должны попадать в CRM, которая уже используется. Ответственный за контент — маркетолог. Ответственный за CRM — ИТ-специалист. Бюджетный коридор и сроки в примере не указаны, чтобы не создавать ложных ориентиров.

Заполненный фрагмент

Цели: получать заявки с сайта; показывать услуги и филиалы; снижать количество повторных вопросов по телефону. Приоритет: сначала заявки, затем услуги, затем филиалы. Критерии успешности: форма заявки работает, заявка поступает в CRM и ответственному менеджеру; страницы услуг содержат актуальные описания; контакты филиалов совпадают с данными компании. Владельцы: маркетолог — тексты и фото; ИТ-специалист — доступы к CRM; руководитель проекта — согласование. Ограничения: нельзя публиковать персональные данные клиентов; юридические формулировки согласуются с юристом.

Проверка примера

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

Как проверить бриф и принять работу

Проверка брифа — это не формальность. Она помогает избежать разночтений. Ниже чек-лист, который можно применить перед передачей брифа в работу.

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

Если пункт не применим, это отмечается явно. Пустые места — источник неопределённости. Лучше написать «не применимо» и объяснить почему, чем оставить поле без ответа.

Типичные ошибки и ограничения

Ошибки повторяются из проекта в проект. Вот основные.

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

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

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

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

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