Эту страницу открывают, когда проект нужно быстро собрать в понятную стартовую рамку: объяснить, зачем он запускается, кто участвует, какой результат ожидается и по каким правилам команда начинает движение.
Project brief — это короткий стартовый документ, который соединяет цель, результат, scope, ключевые ограничения и стартовые роли в одном месте. Он нужен не вместо глубокой проработки, а как её опорная входная точка.
Когда открывать
- проект только стартует;
- нужно быстро ввести новых участников в контекст;
- инициатива обсуждается на уровне «что-то делаем», но общей рамки ещё нет;
- требуется собрать стартовый документ до появления детального ТЗ или полноценного плана;
- заказчик, команда и руководство по-разному понимают, зачем существует проект.
Что это за артефакт
Project brief — это управленческая выжимка стартового контура проекта. Хороший brief отвечает на базовые вопросы:
- какую проблему или задачу решаем;
- какой результат хотим получить;
- что входит и не входит в рамку;
- кто ключевые участники;
- какие есть ограничения и риски старта;
- какие следующие шаги по детализации.
В маленьком проекте brief может быть главным стартовым документом. В более сложном контуре он становится входом в ТЗ, roadmap и stakeholder map.
Зачем нужен
- выравнивает стартовое понимание между участниками;
- помогает быстро проверить, не едет ли проект в разные стороны ещё до начала работ;
- сокращает число повторных объяснений на стартовых встречах;
- создаёт базу для дальнейшей детализации требований, плана и коммуникации;
- помогает PM не потерять управленческий смысл проекта под валом деталей.
Что должно быть внутри
Минимальный состав сильного brief:
- контекст и причина запуска;
- цель проекта;
- ожидаемый результат;
- границы scope;
- ключевые ограничения;
- основные стейкхолдеры и роли;
- стартовые допущения и риски;
- ближайшие шаги по проработке.
Как собрать
1. Поднимите исходную инициативу, переписку, заметки с продажи или внутреннего запроса. 2. Зафиксируйте, что именно запускает проект: проблема, обязательство, возможность, срок, внешний фактор. 3. Отдельно сформулируйте цель и результат, не смешивая их. 4. Уточните, что уже точно входит в контур, а что пока под вопросом. 5. Соберите минимальный список ключевых участников и владельцев решений. 6. Отметьте ограничения, которые нельзя игнорировать на старте. 7. Завершите brief списком ближайших шагов: что уточняем, кем и в каком документе дальше.
Рабочий шаблон
Подходит такая структура:
1. Контекст и причина запуска. 2. Цель проекта. 3. Ожидаемый результат. 4. Scope in / scope out. 5. Ограничения и допущения. 6. Ключевые участники. 7. Риски старта. 8. Ближайшие шаги.
Типовые ошибки
- превращать brief в перегруженное мини-ТЗ;
- писать общие слова без проверяемой рамки;
- не отделять цель от списка работ;
- забывать зафиксировать ограничения и исключения;
- не обновлять brief после первых ключевых уточнений;
- не использовать brief как опору в стартовой коммуникации.
Как понять, что brief слабый
- по нему нельзя ввести нового человека в проект за 10 минут;
- после чтения всё ещё непонятно, зачем проект существует;
- разные участники трактуют scope по-разному;
- документ либо слишком пустой, либо перегружен техническими деталями;
- следующие шаги не обозначены.