Что такое brag document, с примером

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

Разрозненные куски законченной работы, собранные в одну упорядоченную опись

Brag document — это ведущийся список того, что вы сделали на работе: ваш, вашими словами, пополняемый, пока детали свежие. Это не резюме и не статус: резюме пишут для незнакомых людей и сжимают всё, статус пишут про эту неделю. Brag document нужен, чтобы на вопрос «что вы сделали за последние полгода-год» ответ доставался из архива, а не восстанавливался.

Откуда взялся термин

Формулировку ввела в оборот программистка Джулия Эванс постом 2019 года «Get your work recognized: write a brag document», где был простой тезис: ваш руководитель не может помнить вашу работу в тех подробностях, в которых её помните вы, и требовать этого неразумно. Документ — способ закрыть разрыв, не полагаясь на чужую память.

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

Что туда входит

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

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

Разобранный пример

Разница между полезной и бесполезной записью целиком в конкретности. Две версии одного полугодия:

  • Слабо: «Улучшил конвейер импорта. Помогал с онбордингом новичков. Участвовал в роадмапе».
  • Сильно: «Переписал обработку повторов при импорте (январь–февраль). Тихие сбои были примерно раз в неделю, за два месяца после — ни одного; сбои теперь видны на дашборде очереди, и ops перестали узнавать о них из обращений. PR 2214».
  • Сильно: «Ввёл в работу двух инженеров в марте и апреле — написал инструкцию по настройке окружения, которой оба пользовались; время до первого коммита сократилось примерно с недели до двух дней».
  • Сильно: «В февральском ревью дизайна возражал против мультирегионального раската; отложили и выпустили вместо этого исправление очереди. В июне раскат урезали по тем же причинам».

Почему сроки ревью играют против вас

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

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

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

Как наполнять его без ещё одного еженедельного ритуала

Второй документ никто не тянет. Реалистичный вариант — не писать ничего дополнительно и собирать brag document из того, что вы и так производите: датированных записей о том, что изменилось за день, сообщений, где вы объясняли решение, и заметок после инцидента.

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

Чего brag document не сделает

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

Он ещё и зависит от культуры. Где-то прийти с письменной описью читается как подготовленность, где-то — как лоббирование. Версия, которая везде проходит одинаково хорошо, — это доказательства, а не прилагательные: числа, даты и имена, а оценку оставьте читателю. И числа без базы — шум: «снизил ошибки на 60 %» ничего не значит без того, сколько было, за какой период и чем мерили. Наконец, ничего из этого не двигает вилку зарплат и не отменяет заморозку найма. Brag document выигрывает споры, которые действительно про доказательства, — а таких меньше, чем кажется, но не ноль.

Практический вывод

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

Reloggly

Сделайте свою память доступной для поиска.

Сохраняйте текст, голос и фото. Reloggly удержит контекст и поможет найти его снова.

Скачать Reloggly