Про документ с достижениями, aka «Brag-doc» 

Про документ с достижениями, aka «Brag-doc» 

Alexey Bykov

Несколько лет назад я активно начал вести Brag-doc: документ, в котором отображаются результат вашей работы. В этом посте, рассмотрим основные причины и главное, как данный документ вести.

Зачем?

Перформанс ревью и повышения

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

Процесс может отличаться от компании к компании, но везде, где я работал, были одни и те же паттерны:

  • Вы оцениваете себя или же проводите самоанализ.
  • Ваш менеджер и коллеги оценивают вас.
  • Результаты калибруются "людьми свыше".

Так вот. Каждый день мы исправляем какие-то баги, добавляем различные функциональности, запускаем A/B тесты и пр. Особенно, если вы работаете в кросс-функциональной команде или и часто меняете фокус, вы можете просто забыть некоторые вещи (я часто на это попадался), которые добавляют неплохой импакт в продукт.

При этом, если вы можете что-то забыть, будьте уверены, что ваш менеджер, которому репортят много людей (иногда больше 10 чк), тоже может не знать или не помнить все важные детали.

Данный документ помогает не только вам, но и вашему менеджеру.

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

Ваш менеджер может сменить работу

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

Буквально недавно, мой менеджер и Principle инженер, которые были знакомы с основными достижениями, ушли из компании. Причём случилось это в промежутке двух недель. Такое так же может случиться в момент перформанс ревью. Конечно, данный документ не поможет новому менеджеру оценить вас на 100% правильно, но как минимум будут доступны основные хайлайты и будет то, от чего можно отталкиваться.

К слову, за последние 7 лет, в 3-х компаниях у меня сменилось 7 менеджеров. С каждым менеджером я работал не более года.

Вы можете сменить работу

Вы также можете находиться в процессе подготовки к собеседованиям. Данный документ отлично покрывает behavioral интервью (интервью с менеджером), где в основном задают вопросы, связанные с вашими прошлыми достижениями, ошибками и опытом. (Вопросы в стиле "расскажите последний случай, когда...")

Так же, основные хайлайты (главное кратко) можно включить в рассказ «о себе», в любой интервью секции.

Подача на визы талантов / GDE / прочее

Тут скорее полностью опциональная секция, но может кому-то быть актуально. Данный документ сильно помог мне в процессе оформления Global Talent Visa в UK, где нужно было рассказать про импакт за последние 5 лет в 3-х компаниях, желательно в цифрах.

Это также помогло в процессе рассмотрения моей заявки на Google Developer Expert, где нужно было заполнить детальную информацию про каждый доклад, статью и импакт. На последнем этапе (интервью с инженером из Google) меня также много спрашивали про достижения.

Как вести

Что включать

Я включаю всё, на что трачу время и что хоть как-то связанно с работой:

  • Фичи и их импакт. Так же, включая ваши собственные идеи, которые реализовали другие инженеры
  • Фиксы багов и их импакт, так же трекинг их количества
  • Долгосрочные метрики и их тренды, на которые вы повлияли
  • Дизайн-документы
  • Проведение собеседований. Очень часто это чисто волонтерская работа. Она не должна быть невидимой, так как требует довольно много сил и отдачи от вас. В прошлой компании я провёл около 200 собеседований, в среднем потратив на это около 400+ часов.
  • Менторинг других людей
  • Ваши ошибки и чему вы с них научились
  • Количество фиксов и хитфиксов (желательно держать эти цифры на нуле)
  • Количество пр-ов / LoC. Я автоматизировал эту статистику, т.к. она была нужна для оформления UK Global Talent Visa и её было весьма проблематично достать из мест, где я уже не работал. Сейчас, я веду её на всякий случай.
  • Рекогнишн других людей. Например, в слак-каналах / pull requests
  • Волонтерский опыт за пределами компании: публичные выступления, статьи, подкасты, организации курсов. Всё это улучшает не только ваш публичный бренд, но и компании в том числе!

Формат

Тут точно нет каких-либо строгих правил: чем проще, тем лучше. Мне очень зашёл формат change-log, где новые апдейты всегда вписываются сверху по каждому разделу и каждый half of year (H1/H2) выделен отдельным цветом.

  • Project/Impact
  • Design documents & Documentation
  • Process improvements
  • Mentoring
  • Statistics
  • Publicity & Recognitions

На последок

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

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

Делитесь с этим документом как можно с большим количеством людей, с кем вы работаете. Включите не только ваших пиров, но и по возможности, скип-менеджера.

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

Я продолжу описывать свой опыт вот тут: @invalidate_cache

Report Page