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

Введение. Хороший бриф сокращает цикл оценки и снижает риск «сделали не то» — это не бюрократия, а shared understanding. Материал для product- и engineering-лидеров, которые принимают решения на горизонте 12–24 месяцев, а не гонятся за хайпом в презентации.

Зачем этот гайд

Большинство срывов в теме «бриф на разработку сайта» начинается не с кода, а с размытого scope: маркетинг обещает одно, продажи фиксируют другое, а ИТ закрывает техдолг третьим приоритетом. В итоге бюджет уходит в интеграции «на скотч» и ручные сверки в Excel. Мы видим это в проектах, где не описаны границы MVP, нет владельца метрик и не зафиксированы SLA на данные между системами.

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

Подготовка

Опорный принцип: сначала поток ценности, потом стек. Нарисуйте journey от первого касания до оплаты и поддержки, отметьте ручные шаги и точки отказа. Только после этого выбирайте корпоративный сайт и модель данных. Для бриф на разработку сайта мы обычно рекомендуем цели → аудитория → scope страниц → интеграции → NFR → приёмка: она даёт предсказуемый TCO и не блокирует масштабирование команды.

Зафиксируйте ADR по ключевым решениям: хранилище, очереди, авторизация, наблюдаемость. Включите в Definition of Done контрактные тесты API, схему событий и политику миграций. веб-дизайн имеет смысл заказывать только когда есть согласованный backlog с приоритетами P0/P1 и измеримые KPI на квартал.

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

Пошаговый порядок

Кейс A (клиника). Клиент пришёл с болью: не описали запись и consent. Мы разбили релиз на три волны: стабилизация данных, автоматизация рутины, персонализация. Через 14 недель дополнение брифа интеграциями сократило переделки на 30%. Критично было не «переписать всё», а остановить утечку лидов на стыке каналов.

Кейс B (производитель). Другая ситуация: 50 страниц каталога без приоритетов. Здесь сработала обратная стратегия — сначала интеграция с CRM и нормализация справочников, затем редизайн витрины. Итог: MoSCoW в брифе зафиксировал MVP за 8 недель.

Частые ошибки

1. Описывать желаемый результат вместо цели бизнеса — «сделать сайт как у Х» вместо «поднять конверсию с 1,5% до 3%».
2. Не указывать бюджетную вилку — подрядчик либо предлагает нереалистичный минимум, либо закладывает избыточный запас на неизвестность.
3. Не называть одно лицо, утверждающее макеты и тексты — правки от трёх стейкхолдеров с разным мнением останавливают проект.
4. Присылать референсы без пояснения, что именно нравится — дизайнер угадывает по картинке, а не по смыслу.
5. Не перечислять то, что уже есть: домен, хостинг, доступы, старый контент — часть сметы уходит на выяснение очевидного.

Чеклист

• [ ] Указана измеримая бизнес-цель, а не только «сделать сайт»
• [ ] Есть бюджетная вилка или ориентир по смете
• [ ] Названо одно лицо, утверждающее макеты и тексты
• [ ] Приложены референсы с пояснением, что именно нравится
• [ ] Перечислено, что уже есть: домен, хостинг, аналитика, контент
• [ ] Указаны обязательные интеграции (CRM, оплата, 1С) и доступы к их API

Что делать дальше

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

• KPI: лиды, звонки, self-service
• Референсы «нравится/не нравится»
• Доступы к домену и аналитике

Структура брифа

Бриф на разработку сайта должен ответить на цель, аудиторию, контент, интеграции и KPI. Блоки: о компании и УТП, референсы (что нравится и почему), карта страниц, языки, формы и куда падают лиды, CMS, SEO-ожидания, сроки и бюджет-рамка. Приложите логотипы, brandbook, тексты или пометку «нужен копирайт». Без KPI («+30% заявок») подрядчик оптимизирует только «сдать в срок».

Отдельно — non-goals: что точно не делаем в v1. Укажите хостинг, домен, кто владелец аккаунтов аналитики. Шаблон брифа на странице брифа экономит 2–3 итерации созвонов. Чем точнее вход, тем точнее оценка и меньше change requests в середине спринта.

Добавьте раздел рисков: жёсткий дедлайн к выставке, неизвестный объём контента, legacy интеграции. Укажите, кто утверждает макеты и тексты — одно лицо. Приложите список доменов и почт для SSL и форм. Если нужен мультиязык — сразу объём перевода и кто legal review. Чем раньше веб-дизайн и разработка видят один бриф, тем меньше сюрпризов на приёмке.

Укажите требования к доступности (WCAG уровень) и поддерживаемым браузерам — это влияет на смету сильнее, чем «ещё одна анимация».

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