Как написать проджект бриф
Проджект бриф — это документ, который помогает всем участникам проекта достичь взаимопонимания, а людям, непосредственно не задействованным в проекте (например, директору департамента или маркетинг-менеджеру), — уловить суть. В каждой компании свои стандарты написания брифа; в моей практике это лист А4, где указано:
- название проекта
- какую проблему мы решаем и почему
- цели и метрики успеха (что должно быть достигнуто, чтобы поехать в продакшн)
- кто задействован и какие сроки (релизы, тесты, интервью и тд)
- важная дополнительная информация, которую ни в коем случае нельзя потерять (какие-то ограничения, риски, открытые вопросы).
Бриф должен быть лаконичным и не превышать указанного объема. Этот документ должны прочитать ВСЕ.
Очень важно не писать простыню текста, а грамотно расставить акценты и определить структуру. Ильяхов уже отлично написал про это тут, но вот мои личные заметки:
- Один вид шрифта, максимум два цвета, 3 размера (заголовки, подзаголовки, обычный текст);
- Выделения жирным ключевых слов;
- Списки! Ненумерованные или нумерованные — не важно.
Что надо сделать до того, как писать бриф?
- Посмотреть на видение, миссию и роадмап компании: двигаем ли мы продукт в нужном направлении, вкладываясь в разработку этой фичи?
- Исследовать проблему: существует ли она? Решают ли ее конкуренты и насколько успешно? Что изменится для пользователя, если мы ее решим?
- Подробно расписать use cases и edge cases: что сейчас делает пользователь? Что он будет делать, когда фича появится в продакшн?
- Написать job story: это хороший индикатор, что у вас в руках вся нужная информация.
Что делать после того, как бриф написан?
- Подготовить мокапы. Часто этим занимаются дизайнеры. В общем, не важно, кто, главное, чтобы мокапы были.
- Собрать встречу с engineering manager или tech lead и прописать шаги разработки (tech implementation). Тоже не всегда делается продактом, но должно быть в наличии.
- Собрать встречу со всеми участниками проекта: дизайнером, разработчиком, тестировщиком, возможно, представителем техподдержки или контент-команды (если они заказчики)? Все должны понимать, что и зачем мы делаем, и согласиться с объемом и сроками.
- Завести таски в трекере задач совместно с техлидом; расписать таймлайн проекта.
После всех этих встреч ваш бриф обновится еще несколько раз, это абсолютно нормально ;)
Вот хороший пример брифа, правда, по объему он совсем уже не бриф ;) можно и объединить все в один документ. Я предпочитаю делать отдельно:
- бриф (для всех, с ссылками на более подробные документы)
- план по разработке (для разработчиков, тестировщиков и дизайнеров)
- use cases и мокапы (для разработчиков, тестировщиков и дизайнеров).
Какие инструменты использовать?
Вот мой сетап:
Для брифа — Google Docs
Для мокапов — Sketch
Для прототипов — Keynote (отличная статья на эту тему)
Для коммуникации с разработкой — Zeplin.
