Бриф больше не маст-хэв. Да и ТЗ тоже
Но! Моя студия реально все больше уходит даже от таких анкет. Не потому, что мы такие отважные или ультра дипломатичные. И не из-за какого-то поветрия. Просто мы пришли к тому, что не каждому проекту это несет пользу.
Бриф нужен не всегда. Иногда он, конечно, помогает. Но иногда тормозит. А иногда ну совсем сильно тормозит, если клиент просто по наитию накидал что-то в не понятные для себя поля.
Почему мы сократили брифование
Главная причина — скорость.
Если нужно быстро сделать простой лендинг, небольшую посадочную страницу или доработку на сайте, классический бриф избыточен. Проще созвониться на 30–40 минут, чтобы пройтись по ключевым вопросам: что делаем, зачем, как должно стать, кто согласует, сроки.
Это на порядок быстрее, чем ждать, пока нам заполнят документ. Особенно если какую-то часть вопросов сочтут необязательными к заполнению, а нам именно они и нужны — все равно будет созвон.
Например, в брифе можно спросить про целевую аудиторию. Клиент напишет: «Мужчины, женщины, 25–55 лет». Формально ответ есть. Практической пользы — нет.
Когда я показывала черновик знакомому, он не понял, что не так в пункте про ЦА. Так что раскрою подробнее: указанные характеристики — это не портрет, а демография. Она полезна, скажем, для медийки и таргетинга. Но для разработки сайта нам нужно понимать, с какими болями приходит человек, где он в воронке и тому подобное.
На созвоне подобные ситуации сразу разъясняются. Собственно, поэтому для простых проектов мы чаще используем не бриф, а синки. Потом уже сами фиксируем выводы, превращаем их в структуру, смету или основу для ТЗ.
Когда бриф не нужен
Первый случай — простой, быстрый проект.
Если задача понятная, объем небольшой, нет сложной логики, интеграций, личных кабинетов и десяти согласующих, бриф только замедляет разработку. Эффективнее — быстро выяснить задачу и ограничения.
Второй случай — действующий клиент.
Если мы давно работаем с компанией, ведем, например, SEO, поддержку или регулярные доработки, то часто сами понимаем продукт, аудиторию, сайт, ограничения, стиль коммуникации.
Например, мы сами видим в аналитике, что нужно доработать раздел, посадочную страницу или структуру. Проще созвониться, обсудить гипотезу, уточнить детали, зафиксировать решение.
Третий случай — заказчик не в терминологии.
Такое бывает часто. Да и зачем, скажем, владельцу ветеринарной клиники понимать, что такое пользовательские сценарии, СТА, УТП и другие страшные слова? Он для того нас и нанял, чтобы не погружаться в этот дивный новый мир.
Если человеку непонятен вопрос, он либо пишет что-то общее, либо копирует формулировки у условной Алисы, либо просто пропускает пункт. В итоге мы получаем заполненный, но все еще сырой документ.
Созвон во всех таких случаях работает лучше. Мы задаем вопросы на языке клиента, уточняем ответы, переспрашиваем, если слышим противоречия. Затем сами переводим это в свой рабочий формат. 
И когда бриф все-таки нужен
Бриф нужен для решения вполне конкретных задач.
Первый случай — большой поток заявок.
Если студия получает много обращений на разработку сайтов, бриф может быть частью воронки продаж. Он помогает отсеять нерелевантные заявки: тех, кто не понимает задачу, не готов обсуждать бюджет, хочет сайт «как у конкурентов, только вчера плюс недорого» или пока просто присматривается.
В этом случае бриф работает как фильтр. Нормальный клиент ответит по делу. Случайный — отвалится сам.
Второй случай — крупная разработка.
Если проект большой, многоступенчатый, с личным кабинетом, интеграциями, ролями пользователей, сложной структурой, разными сценариями и несколькими этапами — без нормального сбора требований легко уйти в тупик.
Тут бриф нужен как первый слой. Он помогает собрать вводные, понять масштаб, подготовиться к более подробному обсуждению.
Третий случай — корпорации, бренды.
То есть если заказчик — это крупная компания, у которой есть брендбук, TOV, юридические ограничения, требования безопасности, несколько подразделений, согласование с маркетингом, юристами, кем-нибудь еще.
В такой работе нельзя держать все на созвоне. Нужно фиксировать вводные письменно. И здесь я уже заранее понимаю, что мы будет еще не раз ссылаться на данные из брифа.
Четвертый случай — тендеры.
Здесь бриф почти всегда нужен. Потому что документальная часть здесь как бы унифицирует общее понимание проекта: задача, объем, критерии, ограничения, сроки, формат оценки, требования. Заказчику проще сравнить подходы подрядчиков.
А что с техническим заданием
С ТЗ похожая история.
Оно нужно не всегда в классическом полновесном формате. Для небольшой доработки, лендинга или понятного этапа иногда достаточно структуры, прототипа, списка задач, зафиксированных договоренностей.
Но если проект сложный, технически связанный с другими системами, с большим количеством сценариев и ответственных, без ТЗ выйдет дорого. Не сразу, а потом: на правках, переделках, спорных трактовках и подобном.
Я не говорю, что ТЗ вообще не нужно. Скорее так: не каждому проекту нужен большой документ на десятки страниц. Но каждому проекту нужны понятные договоренности. Просто формат может быть разным.
Иногда это полноценное ТЗ.
Иногда — прототип и комментарии к нему.
Иногда — список задач в таск-трекере.
Иногда — расшифровка созвона, из которой потом собирается рабочее описание.
Главное, чтобы после обсуждения все понимали одно и то же.
Вывод
Брифы с ТЗ не нужно использовать по умолчанию в каждом проекте:
- Если задача маленькая и понятная — достаточно созвона.
- Если погружены в контекст клиента — достаточно созвона.
- Если проект большой, клиент новый, заявок много, участвует корпорация или идет тендер — нужен бриф. И ТЗ не помешает.
Вопрос даже не в том, работать с брифом или без. Вопрос в том, помогает он реально понять или выполнить задачу. Если помогает — используем. Если только генерирует лишние синки и уточнения, лучше сразу заменить его живым разговором с фиксацией договоренностей.