Бриф на разработку - 15 вопросов заказчику

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

• Зачем бриф - зафиксировать цель, рамки и критерии успеха
• Когда задавать - до коммерческого предложения и до старта проекта
• Кто отвечает - ЛПР (лицо, принимающее решения) и владелец продукта, не «все понемногу»
• Что получите - ясные рамки, реалистичный срок и прозрачный бюджет
• Правило - нет ответа = риск переделок и скрытых затрат

Зачем собирать бриф до старта

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

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

15 вопросов заказчику

1. Какую бизнес-проблему решаем?

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

2. Кто целевая аудитория и какой у неё сценарий?

Кто пользователь: B2B-закупщик, розничный клиент, сотрудник, партнёр. Один главный сценарий важнее десяти второстепенных.

3. Как поймём, что проект успешен?

Нужны измеримые критерии: число заявок, конверсия, время обработки заказа, снижение ошибок, скорость публикации контента. Без KPI «готово» остаётся субъективным.

4. Какой срок и есть ли жёсткий дедлайн?

Запуск к выставке, сезону или релизу продукта меняет план: MVP сейчас или полный объём позже. Дедлайн без приоритетов обычно означает переделки.

5. Какой бюджетный коридор реалистичен?

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

6. Что уже есть: сайт, CRM, ERP, API, контент?

Инвентаризация экономит деньги. Интеграция с живой CRM и перенос каталога - это отдельные объёмы, а не «мелочь в конце».

7. Какие интеграции обязательны на старте?

Платежи, склад, 1C/ERP, почта, аналитика, мессенджеры. Список интеграций сильнее влияет на срок, чем выбор фреймворка.

8. Есть ли ограничения по стеку, хостингу и безопасности?

Корпоративные стандарты, на своей инфраструктуре, требования ИБ, запрет облаков - всё это должно быть в брифе до оценки, а не после выбора подрядчика.

9. Кто принимает решения и кто согласует этапы?

Один ЛПР ускоряет проект. Если согласование идёт через пять отделов без владельца - закладывайте буфер на ожидание и смену мнения.

10. Что обязательное в первой версии, а что можно отложить?

Разделите «нужно для запуска» и «хочется потом». MVP с ясным ядром быстрее даёт результат и дешевле полного «всё сразу».

11. Есть ли референсы «как надо» и антипримеры «как не надо»?

Ссылки на сайты и продукты экономят часы споров о UX и тоне. Антипримеры тоже полезны: они показывают границы вкуса и ожиданий.

12. Кто готовит контент, тексты, фото и доступы?

Контент часто становится узким местом. Если тексты и доступы к сервисам появятся поздно - дизайн и разработка встанут в простой.

13. Какие роли пользователей и уровни доступа нужны?

Гость, клиент, менеджер, админ, партнёр - разные кабинеты и права. Модель ролей лучше описать до проектирования экранов.

14. Есть ли требования по закону, персональным данным и отрасли?

152-ФЗ / GDPR, медицина, финансы, публичный сектор - меняют архитектуру хранения, согласия, логи и договор. Их нельзя «добавить потом».

15. Кто поддерживает продукт после запуска?

Обновления, мониторинг, правки контента, реакция на инциденты. Если поддержки нет в плане - риск, что рабочий продукт быстро устареет.

Как использовать ответы на практике

Сведите ответы в одну страницу:

По этой таблице легко собрать коммерческое предложение и дорожную карту. Если по пункту пусто - это не «деталь на потом», а открытый риск.

Типичные ошибки в брифе

• Путать желание («сделайте красиво») с результатом («вырастить заявки на 30%»).
• Считать интеграции «кнопкой», а не отдельным проектом.
• Не назначать владельца продукта со стороны заказчика.
• Собирать обязательное из всего бэклог без приоритизации.
• Игнорировать поддержку: запуск без владельца поддержки = долг с первого дня.

Когда полный бриф не нужен

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

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

Итог

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

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

Часто задаваемые вопросы

Сколько времени занимает заполнение брифа?

Обычно 1-2 рабочих дня, если есть ЛПР и доступ к базовым данным. Сложнее, когда решения размазаны по отделам: тогда лучше короткий воркшоп на 1-2 часа, чем недели переписки.

Можно ли оценить проект без брифа?

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

Бриф заменяет техническое задание?

Нет, бриф - вход в ТЗ. Он фиксирует смысл и рамки. ТЗ уже описывает экраны, данные, API, роли и критерии приёмки. Без брифа ТЗ часто раздувается и меняется на ходу.

Что делать, если заказчик не знает бюджет?

Задайте коридор и варианты объёма: MVP / стандарт / расширенный. Так проще выбрать реалистичные рамки. «Бюджет не ограничен» на практике почти всегда означает, что приоритеты ещё не согласованы.

Нужно ли обновлять бриф в процессе разработки?

Да, при смене цели, дедлайна или состава обязательного. Бриф - живой документ рамок. Любое расширение рамок должно явно менять срок или бюджет, иначе команда работает в долг.

Термины в статье

B2B — Business to Business — продажи между компаниями

KPI — Key Performance Indicator — ключевой показатель эффективности

MVP — Minimum Viable Product — минимально жизнеспособный продукт

CRM — Customer Relationship Management — управление взаимоотношениями с клиентами

ERP — Enterprise Resource Planning — планирование ресурсов предприятия

на своей инфраструктуре — on-premise — на своей инфраструктуре (on-premise)

152-фз — Russian personal data protection law (152-FZ) — закон РФ о персональных данных

GDPR — General Data Protection Regulation — Общий регламент по защите данных

must-have — required capability or requirement — обязательное требование или возможность