В большинстве студий и интернет-агентств бриф — это опросник на несколько листов, где клиенту нужно дать стопицот ответов. Но из которого затем, при разработке прототипа, ТЗ или дизайна, нифига непонятно. Зато на него обязательно есть отсылка из договора, так что без заполнения брифа не обходится ни один проект.

Откуда взялись такие брифы? Понятно — из интернета (копипаст никто не отменял, так зачем голову ломать и изобретать велосипед). Создавалась новая студия, ребята выясняли, что для работы нужен бриф. А вот с какой целью — не совсем понимали, так что брали попользоваться один из доступных в сети. Потом им, естественно, было не до того, чтобы его переделать (да и осознание такой необходимости возникает редко). Поэтому брифы большей частью очень похожи.

Самое интересное в этой истории — самый распространенный в интернете бриф дает на выходе крайне однородный результат в виде сайтов с типичной структурой и текстами, предложенными клиентом. Понятно, качество исполнения отличается, но все равно определить сайты, сделанные по такому брифу и рожденному из него ТЗ, довольно просто (отгадайте, почему так происходит?). Потом к ним также любят прикладывать руку SEO-оптимизаторы. И когда клиенту в итоге становится совсем грустно — специалисты по юзабилити. Это решает проблему, но к сожалению только отчасти.

Отгадка: В 90% брифов на разработку сайтов встречаются вопросы типа «Требуемые разделы сайта», «Предполагаемая структура сайта», «Предполагает ли сайт наличие каталога? В каком разделе сайта он должен находиться». Заказчик об этом имеет весьма смутное представление. Поэтому идет на сайт конкурентов и аккуратно переписывает меню.

Итак, длинный и непонятный бриф, отправленный клиенту, порождает следующие проблемы:

1. Он раздражает клиентов. Результат — большой процент отказов на этапе заполнения брифа.
2. Он не отражает ожиданий клиента от сайта, так как обилие вопросов привлекает внимание к деталям но отвлекает от сути. Кроме того, сама анкетная форма побуждает отвечать на вопросы поверхностно. Как следствие — сайты плохо сдаются, с кучей придирок типа «не нравится картинка», или «давайте добавим еще один уровень меню». Сделанные по таким брифам сайты не решают задач клиентов, и поэтому многократно переделываются, чтобы хоть как-то улучшить конверсию.

Кстати, на этапе заполнения брифа процент отказов по входящим заявкам даже больше, чем на этапе отправки коммерческого предложения. Почему? С точки зрения клиента получение такого документа в большинстве случаев выглядит как «отстаньте, не мешайте работать». А если он отправил запрос на разработку сайта не в одну студию, а в десяток? Самые сметливые в итоге заполняют один бриф, предварительно убрав из него опознавательные знаки, и отправляют в ответ всем потенциальным разработчикам.

Отсюда вывод: брифы клиентам не нужны. Заказчику нужен сайт, очень дешево и желательно вчера который бы решал его задачи. Даже не так. Сайт не нужен, нужно решение его конкретной задачи. Поэтому не загружайте заказчиков заполнением брифов.

Разработчику же бриф однозначно нужен. Это инструмент, который позволяет как-то формализовать традиционно расплывчатые представления и требования заказчиков. Так как же на елку влезть и жопу не ободрать получить необходимую для работы информацию в достаточном объеме, не потеряв по пути клиента?

Мы пробовали сделать возможность заполнения брифа онлайн — не работает. Не заполняют. Хотя заявки с сайта идут исправно. Пробовали писать в сопроводительном письме, что заполнять надо только понятные пункты, что заполнять можно кратко и т.п. Все равно — тянут неделями.

В итоге пришли к следующему. Не только бриф, но и вся работа по проекту должны быть нацелены на создание сайта, который бы решал задачи клиента. Отсюда нехитрые правила:

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

Во-вторых, бриф должен быть ненапряжным для клиентов (вопросов мало, и все по существу), но включать то основное, что надо для разработки клевого сайта. Вот главные вопросы:

• Какую бизнес-задачу должен решать сайт?
• Кто должен посещать этот сайт?
• Что посетитель должен сделать на сайте?
• Какой ориентировочный бюджет проекта?
• Примеры, что вам нравится по стилю. Если у вашей компании есть фирменный стиль — покажите. Кстати, при разработке промо-сайтов этот вопрос не актуален.

Этой информации вполне достаточно. Если для организации процесса разработки у вас в компании нужна дополнительная детализация — добавляйте вопросы, но во-первых, по существу, а во-вторых, незаметно для клиентов. Расписать проект по полочкам должен в ходе (или после) беседы менеджер проекта.

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