軟體工程師都該有的炫耀文件 (brag document)

什麼是炫耀文件 (Brag Document)?

上面談了如何不高調地展示成果，讓做這件事時不會造成他人反感。這邊進一步說，如果要能展示成果，平常就要有紀錄成果的習慣 (當然，更重要的前提是，要先做出成果，才有可能記錄下來)。

在業界有個很流行的方式叫「炫耀文件 Brag Document」，這份炫耀文件，顧名思義是要讓你記錄下能炫耀的事情，但這不是要你真的去炫耀 (畢竟炫耀很可能造成別人反感)。其用意在於，當你能平時有定期記錄下，在需要的時候，就能輕鬆地拿出來展示。

平時就記錄成果的好處

炫耀文件的本質是記錄自己的成果，如果你有定期做這件事，會發現長遠來看，這件事的投資報酬率很高。因為這些被記錄的成果，可以用在以下的場合：

• 在跟主管的 1:1 會議時，加深主管對你的印象
• 在年度的績效考核時，不用花時間整理過去的成果
• 在找下一份工作時，可以有素材直接放履歷
• 在未來的面試中，有細節足夠豐富的故事可以講

更重要的是，如果你有定期記錄成果，將能更具體地檢視自己的成長軌跡，而不是僅憑感覺來判斷自己是否有持續成長。當有記錄下來，你將能夠去比較現在做的事情，比起先前做的，是否是影響力更大的? 如果不是，就能根據你的目標來進一步調整。

如何記錄自己的成果?

在了解完這份文件的重要性後，相信你會有個問題，那就是「該如何寫這份文件」。我們推薦的記錄方式，會是以 STAR 的形式來記錄。對比起流水帳式的記錄工作，用這個模板會讓你能更以結果導向、影響力為導向的方式來記錄。

與此同時，如同在該模板提到的，就像在面試中分享完某段經歷後，可能被追問「從中學到什麼?未來如果要再做一次，會如何做更好? 」，會推薦要記錄下學習與反思。這不僅是為了未來的面試用，而是當你去反思經驗，往往會獲得更多的成長。

這邊特別補充，之所以在 STAR 格式記錄外，還要額外寫下學習，或者是寫下反思，是因為這不僅能幫助自己回顧，並透過回顧來成長；還能夠面對面試中分享被追問「從該次經驗中學到什麼?未來如果要再做一次，會如何做更好? 」

讓我們透過一個具體範例，實際了解如何使用上述的形式來記錄：

• S：下一季團隊預計擴招至少 5 人，然而先前的入職流程與文件，並沒有系統性的整理，導致過去入職的效率不是太好
• T：我主動跟工程經理提說，我想要有系統地重新梳理入職流程，並把文件化作好。工程經理也很同意這件事情很重要，如果現在不先做好，等到時候大量新成員加入，會有很大量的時間浪費。因此，工程經理同意讓我花時間來解決這問題。
• A：我主導整個團隊的入職流程，同時找了團隊其他人，除了更新流程外，也把有缺漏、不完整的文件都補上
• R：在重整完入職流程與文件後的一季，新成員入職所需的上手時間縮短，從原本一週變成三天後即可開始貢獻到專案，同時後續我帶領持續優化這個部分，讓我們目前的新成員入職，幾乎不需用既有成員的額外時間，也能順利完成。
• Learning：在這次的經驗中，特別有感的學習點是，要讓最終的成果有效，一定要時時蒐集使用者的回饋。在完成重整後的第一個新成員入職時，我才發現原本有些設想的不如預期，所以當時該成員一邊入職，我一邊找機會訪談他，蒐集到許多有用的回饋後，再調整流程與文件，也讓後面加入的成員，整體入職變得更順暢。

上面這個形式，會是推薦在一個專案完成後做記錄。但平時如果有一些相對比較小，但仍值得記錄的事件，仍推薦大家要順手記錄到文件中。

舉例來說，可以記錄：

• 學了什麼新的技能、技術、框架，像是近期 AI 工程相關的技能，如果平常有進修，就可以特別記下來
• 獲得什麼回饋，例如工作上同事、主管給的回饋，不論是好的或者壞的，都可以記下來，除了能定期檢視自我，也能在面試中提到
• 如果平常有做開源貢獻，或者有在做志工 (例如當技術會議的志工) 也可以記下來，這些也能放在履歷或者面試時用

閱讀更多

如果你對於透過記錄、適時展示自己工作成果這主題感興趣，我們在 E+ 有寫一個更完整詳細的版本，額外談到許多人不記錄成果的思考誤區、記錄成果時要避免的事、如何不高調張揚但仍有效展示成果。

E+ 的專屬介紹頁面 (連結點此)。