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

Что такое шаблон проектного брифа и когда он составляется?

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

Это документ, который люди подписывают, чтобы авторизовать работу, и спустя шесть месяцев он становится точкой отсчета, против которой все спорят. Он намеренно короткий — обычно одна-две страницы, потому что его пишут в момент, когда информации еще меньше всего.

Шаблон дает вам разделы: контекст, цели, рамки, результаты, сроки, бюджет, заинтересованные стороны, критерии успеха. Каждая версия, которую вы найдете, предлагает примерно то же самое — и в этом нет ничего плохого.

Проблема брифов почти никогда не в разделах. Проблема в том, что в них написано.

Большинство брифов описывают решение, а не проблему

Вот претензия, которую каждый delivery-команда, агентство и инженерная группа предъявляет к брифам — одинаково сформулированная в любой отрасли: нас проинструктировали по решению.

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

Это происходит по вполне разумной причине. Тот, кто заказывает проект, обычно обдумывает его неделями и приходит к выводу. Писать вывод кажется ясностью, а писать проблему — туманностью.

Цена в том, что самые дешевые решения исключаются еще до того, как кто-то на них посмотрит. Как только в брифе появляется «портал», проект становится проектом про портал, и вариант, который мог бы решить 80% проблемы за 5% бюджета, никогда не оценивается — потому что никого не попросили оценивать что-либо.

Бриф, в котором сформулирована проблема, приглашает к поиску ответов. Бриф, в котором сформулировано решение, приглашает к расчетам.

Как настроить этот шаблон в Trupeer

Шаг 1: Откройте раздел Templates

Перейдите в раздел Templates из главного меню.

Шаг 2: Выберите и откройте шаблон

Нажмите на любой шаблон, с которым хотите работать, чтобы открыть его.

Шаг 3: Разверните просмотр шаблона

При необходимости разверните просмотр шаблона, чтобы увидеть полную структуру и детали.

Шаг 4: Отредактируйте шаблон

Нажмите Edit, чтобы начать изменять выбранный шаблон.

В редакторе вы можете:

• Добавлять новые разделы

• Задавать или обновлять правила форматирования

• Добавить логотип и настроить его позицию и связанные параметры

Шаг 5: Сохраните настроенный шаблон

После того как вы внесете все необходимые изменения, нажмите Save, чтобы сохранить обновленный шаблон как свой.

Шаг 6: Предпросмотр и точная настройка шаблона

Когда вы захотите увидеть, как выглядит ваш настроенный шаблон, откройте Preview.

На экране предпросмотра при необходимости вы можете продолжить вносить правки напрямую, чтобы шаблон выглядел ровно так, как вы хотите.

С шаблоном проектного брифа вы можете:

• Экономить часы на написании: пропускайте пустую страницу с проверенной структурой брифа.

• Быстро согласовывать заинтересованные стороны: брифы на одной странице ускоряют утверждения и выравнивание позиций.

• Оставаться в фирменном стиле: применяйте логотип, шрифты и цвета с помощью brand kit от Trupeer — идеально для брифов агентства и клиента.

• Питчить с эффектом: превращайте бриф в видео-резюме — отлично для sales enablement и питчей заинтересованным сторонам.

• Стандартизировать работу в проектах: используйте один и тот же формат брифа для каждого инициативного проекта.

• Достигать глобальных команд: переводите брифы на 65+ языков одним кликом.

Тест из трех ответов для любого проектного брифа

Две минуты — и это единственный тест брифа, который действительно стоит проводить.

Прочитайте бриф и назовите три по-настоящему разные вещи, которые могли бы его удовлетворить.

Не три вариации одного и того же. Три разных подхода: построить что-то, изменить процесс, купить что-то, убрать шаг, иначе коммуницировать, сделать меньше.

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

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

Проведите этот тест по брифу до того, как его разошлют, вместе с человеком, который не участвовал в его написании. Автор брифа всегда сможет назвать три, потому что он знает, что отверг. Никто другой не сможет — потому что в брифе этого нет.

Как описать проблему вместо результата

Четыре привычки — и ни одна из них не занимает больше времени, чем написание решения.

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

Опишите, что происходит сейчас. Как проблема решается в текущем виде — плохо, включая обходные пути, которые люди уже придумали. Описание текущего состояния позволяет кому-то предложить более дешевый ответ.

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

Определяйте успех как изменение числа, а не как наличие результата. Сократить эти обращения вдвое в течение шести месяцев — критерий успеха. Запуск портала — это веха.

Если у вас действительно есть решение в голове, поместите его в явно помеченный раздел, где вы прямо говорите об этом, как один из кандидатов — а не как сам бриф.

Бесплатный шаблон проектного брифа: структура для копирования

Скопируйте отсюда. Одна-две страницы — и не расширяйте.

Заголовок. Название проекта, спонсор, автор, дата, версия и запрашиваемое решение.

Проблема. Наблюдение с числом, как часто это происходит и во сколько это обходится. Два-три предложения.

Как это решается сейчас. Текущий процесс, включая обходной путь, и почему этого недостаточно.

Почему сейчас. Что изменилось и делает это актуальным именно в этом квартале, а не в следующем году.

Кто затронут. Люди или клиенты, которых это касается, и примерно сколько их.

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

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

Вне рамок. Что этот проект не будет затрагивать — достаточно конкретно, чтобы это было спорным.

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

Какое решение запрашивается и кем. Что именно вы просите утвердить и кто дает авторизацию.

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

Ритейлер, который построил портал, на который никто не зарегистрировался

Ashfold Group — специализированный ритейлер с примерно девяноста магазинами и существенным онлайн-бизнесом.

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

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

Через шесть месяцев после запуска было три тысячи сто зарегистрированных аккаунтов при примерно сорока шести тысячах активных клиентов — то есть меньше семи процентов. Объем обращений в сервисный центр не изменился.

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

И тогда кто-то нашел проблему. Сервисный центр обрабатывал около одиннадцати тысяч обращений в месяц. Выборка из пятисот показала, что 61% — это разные версии «где мой заказ», что составляет примерно шесть тысяч семьсот обращений в месяц.

У этих клиентов 84% уже получали email о отправке с ссылкой для отслеживания. Либо они ее не видели, либо возвращались к ней после того, как ссылка истекла через четырнадцать дней.

Главная проблема, таким образом, была не в том, что у клиентов не было способа проверить. Проблема была в том, что тот способ, который у них уже был, не работал.

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

Портал был легитимным решением реальной проблемы. Он не был самой большой проблемой, и он требовал регистрации, которую 93% клиентов никогда не делали.

Бриф для последующего проекта был написан иначе. Клиенты обращаются к нам шесть тысяч семьсот раз в месяц, чтобы узнать, где их заказ. 84% из них уже получали ссылку для отслеживания. Сократить эти обращения вдвое в течение шести месяцев. Ограничения: без изменений интеграции с перевозчиком, бюджет — сто пятьдесят тысяч фунтов, и это должно работать без необходимости регистрировать клиентов.

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

Разница между двумя брифами в том, что второй можно было решить тремя способами. Первый можно было решить одним способом — и этот способ уже был выбран.

Ключевые элементы, которые должен содержать любой проектный бриф

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

Как написать проектный бриф за пять шагов

Один. Опишите проблему с числом. Если вы не можете получить число, потратьте полдня, чтобы его найти. Бриф без числа — это предпочтение.

Два. Опишите текущее состояние, включая то, как люди обходят это сегодня.

Три. Зафиксируйте успех как изменение этого числа — с датой.

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

Пять. Проведите тест из трех ответов с человеком, который не писал бриф. Если тест не проходит, либо откройте бриф, либо честно переименуйте документ.

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

Ограничения и как их незаметно превращают в требования

Вот где большинство брифов тихо превращаются в спецификации — и это происходит без чьего-либо намерения.

Настоящее ограничение — это то, что находится вне контроля проекта. Бюджет — это то, что есть. Регуляторный дедлайн фиксирован. Систему складского учета в этом году не заменяют. В команде четыре человека.

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

Тест простой: для каждого пункта спросите, кто это решил и что произойдет, если это изменится. Реальное ограничение имеет владельца вне проекта и последствия, если его нарушить. Предпочтение не имеет ни того, ни другого, и обычно автор с радостью откажется от него, если спросить напрямую.

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

Проектный бриф, бизнес-кейс или план проекта?

Три документа в начале проекта, по порядку, с разными задачами.

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

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

В плане проекта описано, как будет реализован выбранный подход: рамки, график, ресурсы, зависимости и риски. Наш шаблон плана IT-проекта покрывает этот слой.

Порядок важен: бриф, затем варианты, затем бизнес-кейс, затем план. Написание плана до брифа — что случается чаще, чем кто-либо признает — означает, что подход был выбран еще до того, как сформулировали проблему.

Как только план существует, бриф должен быть явно заменен, а не оставлен в файле как второй источник согласованных рамок. Два документа, претендующие на авторитет, — вот как споры о рамке становятся неразрешимыми.

Варианты проектного брифа: креатив, дизайн, ПО и строительство

Структура сохраняется для разных типов, а акценты смещаются.

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

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

Брифы по проектам разработки ПО прежде всего требуют проблему и текущий обходной путь, и их нужно держать полностью свободными от функций. Как только функции попадают в рамки, вы пишете документ требований — это описано в нашем шаблоне lean PRD.

Брифы для строительства и дизайна несут ограничения, которые действительно являются ограничениями: площадка, планирование, регулирование, бюджет. Здесь раздел ограничений — это содержание, а не риск.

Проекты с сильным уклоном в закупки требуют, чтобы бриф описывал, что именно покупается как результат, а не как спецификация, поскольку решение о зрелости спецификации принимается позже — и это описано в нашем шаблоне плана управления закупками.

Могу ли я получить шаблон проектного брифа в Word или Excel?

Word или Google Docs. Бриф — это текст, одна-две страницы, и его комментируют до утверждения. В нем нет ничего, что «просит» таблицу.

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

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

PowerPoint — плохой контейнер. Бриф, представленный как слайды, обычно теряет формулировку проблемы и сохраняет решение — по той же причине, которая описана на этой странице.

Как показать проблему, а не просто описать ее

Самая сложная часть хорошего брифа — сделать так, чтобы проблема казалась реальной людям, которые с ней не сталкивались. Число помогает. Параграф редко помогает.

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

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

Trupeer AI делает это простым: запись экрана превращается и в видео, и в письменный пошаговый разбор текущего процесса — ровно то, что нужно разделу «текущее состояние» в брифе. Также это дает delivery-команде материал, к которому можно вернуться при выборе подхода, вместо того чтобы полагаться на формулировки брифа спустя месяцы.

Запишите. Оформите в бренд. Переведите. Trupeer it.

Та же запись полезна и позже как «до» при измерении того, сработал ли проект. Материалы хранятся в вашем knowledge base в едином брендинге, а инструкции по настройке — в руководстве по настройке шаблона документа.

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

Есть ли бесплатный шаблон проектного брифа в Word?

Структура выше вставляется прямо в Word или Google Docs. Нет «закрытой» загрузки и нет формы. Два раздела, которые нужно написать первыми, — это проблема с числом и ограничения, потому что все остальное следует из них, и это два самых слабых места, которые шаблоны обычно закрывают хуже всего.

Есть ли бесплатный шаблон проектного брифа в Excel?

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

Где найти пример проектного брифа в PDF?

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

Какой длины должен быть проектный бриф?

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

Кто должен писать проектный бриф?

Спонсор или человек, который отвечает за проблему, вместе с кем-то из delivery, кто прочитает его до рассылки. Этот второй читатель и ловит «брифование решения», потому что именно он иначе потратит девять месяцев на создание неправильного ответа.

В чем разница между проектным брифом и креативным брифом?

В основном — в предметной области, а не в структуре. Креативный бриф добавляет аудиторию, сообщение, тон и канал, и обычно его пишет клиент для агентства. Оба страдают от «брифования решения» одинаково, и тест из трех ответов применим к обоим без изменений.

Когда нужно согласовать проектный бриф?

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

Что происходит с брифом, когда появляется план проекта?

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