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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10. Что must-have в первой версии, а что можно отложить?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

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

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

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

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

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

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

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

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

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

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