Бриф от маркетолога разработчику: что приложить обязательно

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

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

1. Откуда берётся сюрприз

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

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

До файлов напишите три строки:

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

2. Что прикладывать каждый раз

Папка «материалы» и фраза «сделайте как в дизайне» брифом не являются. Папку откроют. Всё равно неясно, какой файл актуальный, какой экран в задаче и что делать, если макет и живой сайт расходятся.

Файлы приезжают из того инструмента, в котором вы работаете. Дизайнер шлёт макет. Специалист по рекламе шлёт ссылку на лендинг. Аккаунт-менеджер кидает пароль в личку, потому что в прошлый раз так кого-то разблокировали. Брифа в этом нет. Разработчик додумывает недостающий кусок, и догадка становится тем, за что клиент не платил.

Прикладывайте в таком порядке:

• Текущая система: живой адрес, платформа и где лежит код. Напишите WordPress, Shopify, Magento, Laravel или то, что реально работает. Слова «сайт» мало.
• Что входит и что не входит. Экраны или сценарии, которые меняются, и одна строка о том, чего этот релиз не тронет.
• Приёмка: от трёх до семи проверок, которые пройдёт человек без разработки. «Постоянный покупатель может оплатить» — проверка. «Чистый код» — нет.
• Актуальный макет или текст, с датой. Если файлов два, напишите, какой брать.
• Ограничения, которые клиент уже поставил: языки, дата, система, которая должна продолжить работать, данные, которые нельзя переносить.
• Доступы, которые надо выдать, по системам: репозиторий, хостинг, аналитика, оплата, почта. Секретов в документе нет.

Если у клиента интернет-магазин, назовите платформу, на которой он уже работает, и шаг покупки, который должен измениться. «Поднять конверсию» не говорит, правка в каталоге, в корзине или в возврате из оплаты. Подкрутить живой магазин и собрать новый — разные работы. В брифе должно быть видно, какая из двух эта.

3. Опишите, как это работает, а не как выглядит

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

Как выглядит — видно в файле. Как работает — видно, только когда пробуют. Если вы продаёте интеграцию, CRM, телефонию, почту или учёт, клиент будет смотреть результат там, где уже работает, а не в pull request. На одной CRM оценка звонков связывала телефонию, сообщения и учёт, а итог показывала в отчёте. Повтор не имел права создать вторую оценку, и один филиал не мог читать записи другого. Этот набор систем в бриф класть не нужно. Нужны такие же по смыслу фразы: какие системы в задаче, что человек должен увидеть, когда обработка кончилась, и что остаётся верным, если задача выполнится дважды. «Добавить AI» такой фразой не является.

На каждый сценарий в задаче запишите:

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

4. Доступ без секрета в чате

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

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

До обещания даты подтвердите:

• Репозиторий, хостинг и сторонние сервисы открываются через аккаунты, которые контролирует клиент или агентство. Боевые секреты не уходят почтой и не уходят в чат.
• Какой средой разработчик может пользоваться. Если второй среды нет, скажите об этом как о риске до обещания даты.
• Настоящие данные клиентов не попадают в незащищённую тестовую среду. Просите урезанную или обезличенную копию.
• Какая ветка выкатана. Это записывают отдельно от комментариев к брифу, когда первый релиз уже есть.

5. Принимайте по тем проверкам, которые приложили

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

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

Пользуйтесь списком, который уже написан:

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

У отдельного проекта должны быть понятный объём и согласованный план сдачи. У постоянной работы та же папка, только короче, на каждый новый запрос: результат, приёмка, что не входит. В обоих случаях разработчик должен суметь сказать, чего он не делает.

Когда звать разработчика раньше

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

Я беру ограниченную работу от маркетологов, дизайнеров и агентств и разработку после письменной передачи. Услуги — отдельный проект или постоянное сотрудничество: скорость, SaaS и backend, интеграции с ИИ. Проекты — системы, на которые такие брифы ложатся: унаследованный продукт, интернет-магазин, CRM, у которой уже есть клиенты. Каждый в объёме своей работы. Если у вас релиз клиента и нужен разработчик, который будет работать по письменной папке, напишите мне в LinkedIn. Приложите результат, строки приёмки и название платформы. Пароли оставьте у себя.