Бриф від маркетолога розробнику: що прикласти обов’язково

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

Бриф, з якого можна працювати, — це коротка тека, а не довша переписка. У ній результат, поточна система, як виглядає «готово» і чиї це доступи. Назв класів там немає. Зберіть теку до старту і тримайте ту саму форму, коли наступного місяця того самого клієнта візьме інший розробник. Сенс у релізі, який клієнт упізнає, без несподіванки на живому сайті в обіцяний день.

1. Звідки береться несподіванка

Несподіванка вилазить на показі, не на старті. Сторінка є. Кампанія на неї веде. Клієнт усе одно відхиляє, бо крок, який для нього важливий, ніхто не записав. Стан оплати. Філія, яка не повинна бачити іншу. Поле, без якого відділ продажів сказав, що форма не працює.

Ви тримаєте, чого хоче клієнт. Розробник тримає репозиторій. Кожна сторона думає, що дірку закрив хтось інший. У чаті здається швидко, тож дірка там і лишається. За тиждень ніхто не знайде повідомлення, у якому вирішили, як це має працювати. Успадковані проєкти ламаються там само. Команда забирає продукт, який інша лишила в кепському стані, і перший тиждень іде на те, щоб зрозуміти, що взагалі запущено. Бриф, який не вийшов із голови однієї людини, приходить у тому самому вигляді: наступний не відрізнить задуману поведінку від випадкової.

До файлів напишіть три рядки:

• Результат для клієнта одним реченням, під яким він підписався б: що він зможе робити після релізу і не може зараз.
• Що вже обіцяно, разом із датами, і що з цього ще можна зрушити.
• Хто з вашого боку приймає роботу і хто з боку клієнта того самого дня відповість, як це має поводитися.

2. Що прикладати щоразу

Тека «матеріали» і фраза «зробіть як у дизайні» брифом не є. Теку відкриють. Усе одно неясно, який файл актуальний, який екран у задачі і що робити, якщо макет і живий сайт розходяться.

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

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

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

Якщо в клієнта інтернет-магазин, назвіть платформу, на якій він уже працює, і крок покупки, який має змінитися. «Підняти конверсію» не каже, правка в каталозі, у кошику чи в поверненні з оплати. Підкрутити живий магазин і зібрати новий — різні роботи. У брифі має бути видно, яка з двох ця.

3. Опишіть, як це працює, а не як виглядає

Бриф, у якому задані кольори, а правило не сказане, перевірятимуть за правилом. Клієнт спробує, хто бачить запис, що буває, коли оплата не проходить, і що має опинитися у звіті після оцінки дзвінка.

Як виглядає — видно у файлі. Як працює — видно, лише коли пробують. Якщо ви продаєте інтеграцію, CRM, телефонію, пошту чи облік, клієнт дивитиметься на результат там, де вже працює, а не в pull request. На одній CRM оцінка дзвінків зв’язувала телефонію, повідомлення й облік, а підсумок показувала у звіті. Повтор не мав права створити другу оцінку, і одна філія не могла читати записи іншої. Цей набір систем у бриф класти не треба. Потрібні такі самі за змістом фрази: які системи в задачі, що людина має побачити, коли обробка скінчилася, і що лишається вірним, якщо задача виконається двічі. «Додати AI» такою фразою не є.

На кожен сценарій у задачі запишіть:

• Основний шлях і один збій: оплату відхилено, файла немає, у користувача немає доступу.
• Якщо продуктом користуються кілька клієнтів, хто чиї дані бачити не повинен.
• Якщо роботу можна запустити двічі — форма, імпорт, вебхук — чи має другий запуск щось змінювати.
• Екран, на якому клієнт шукатиме результат. На показі дивляться саме на нього.

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

Пароль із продакшену в повідомленні — одна поломка. Інша — рядок «доступи надішлемо пізніше», після якого пізніше не настає. Розробник або не починає, або починає на живому сайті, бо лише туди зміг увійти.

Доступ здається дрібницею поруч із креативом. Від цієї дрібниці залежить, чи безпечний перший викат. Проєкт, який можна змінювати лише на живому сайті, здивує клієнта: перша справжня перевірка і є реліз. Чек-лист приймання — довша версія того самого для успадкованого Laravel. Для маркетингового брифа вистачає короткої: доступи на акаунтах компанії, окреме середовище, жодних вивантажень клієнтів у відкриту тестову копію.

До обіцянки дати підтвердьте:

• Репозиторій, хостинг і сторонні сервіси відкриваються через акаунти, які контролює клієнт або агенція. Секрети з продакшену не йдуть поштою і не йдуть у чат.
• Яким середовищем розробник може користуватися. Якщо другого середовища немає, скажіть про це як про ризик до обіцянки дати.
• Справжні дані клієнтів не потрапляють у незахищене тестове середовище. Просіть урізану або знеособлену копію.
• Яка гілка викатана. Це записують окремо від коментарів до брифа, коли перший реліз уже є.

5. Приймайте за тими перевірками, які приклали

Приймання, яке починається зі смаку, знайде заголовок і пропустить повернення з оплати. Смак допустимий. Ним погано виявляти, що кроку в задачі не було. Рядки приймання з брифа і є приймання. Пройдіть їх із клієнтом на тому середовищі, яке назвали, до того як хтось скаже «готово».

Дата настала, клієнт на зустрічі, і хтось просить швидко глянути. Швидкий погляд бачить перший екран і не бачить, що буде при помилці. Потім це знаходить покупець. Письмова перевірка забирає ті самі десять хвилин і дає список, який можна надіслати назад без нової суперечки про те, що обіцяли.

Користуйтеся списком, який уже написаний:

• Кожен рядок приймання пройдіть самі, до того як збірку побачить клієнт.
• Клієнту надішліть той самий список, а не новий опис роботи, вигаданий наприкінці.
• Зауваги про вигляд, яких немає в списку, відкладіть. Це наступний бриф. Якщо перевірки пройшли, цей через них не вважається незакритим.
• Якщо перевірка не пройшла, назвіть рядок. «Якось не те» — не рядок, під який можна зробити наступну збірку.

В окремого проєкту мають бути зрозумілий обсяг і погоджений план здачі. У постійної роботи та сама тека, тільки коротша, на кожен новий запит: результат, приймання, що не входить. В обох випадках розробник має зуміти сказати, чого він не робить.

Коли звати розробника раніше

Теку можна зібрати до того, як розробник відкриє репозиторій. Кличте його до обіцянки дати, якщо правка стосується оплати, спільної бази клієнтів або системи, яку ви не можете описати, або якщо сайт успадкований і окреме середовище ніхто не підтвердив. Розробник, який бачить бриф уже після фрази клієнту «майже готово», дізнається про несподіванку разом із вами.

Я беру обмежену роботу від маркетологів, дизайнерів і агенцій і розробку після письмової передачі. Послуги — окремий проєкт або постійна співпраця: швидкодія, SaaS і backend, інтеграції з AI. Проєкти — системи, на які такі брифи лягають: успадкований продукт, інтернет-магазин, CRM, у якої вже є клієнти. Кожен в обсязі своєї роботи. Якщо у вас реліз клієнта і потрібен розробник, який працюватиме за письмовою текою, напишіть мені в LinkedIn. Прикладіть результат, рядки приймання і назву платформи. Паролі залиште в себе.