软体工程师都该有的炫耀文件 (brag document)

2024年8月1日

💎 加入 E+ 成長計畫 與超過 500+ 位軟體工程師一同在社群中成長,並且獲得更多的軟體工程學習資源

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

上面谈了如何不高调地展示成果,让做这件事时不会造成他人反感。这边进一步说,如果要能展示成果,平常就要有纪录成果的习惯 (当然,更重要的前提是,要先做出成果,才有可能记录下来)。

在业界有个很流行的方式叫「炫耀文件 Brag Document」,这份炫耀文件,顾名思义是要让你记录下能炫耀的事情,但这不是要你真的去炫耀 (毕竟炫耀很可能造成别人反感)。其用意在于,当你能平时有定期记录下,在需要的时候,就能轻松地拿出来展示。

平时就记录成果的好处

炫耀文件的本质是记录自己的成果,如果你有定期做这件事,会发现长远来看,这件事的投资报酬率很高。因为这些被记录的成果,可以用在以下的场合:

  • 在跟主管的 1:1 会议时,加深主管对你的印象
  • 在年度的绩效考核时,不用花时间整理过去的成果
  • 在找下一份工作时,可以有素材直接放履历
  • 在未来的面试中,有细节足够丰富的故事可以讲

更重要的是,如果你有定期记录成果,将能更具体地检视自己的成长轨迹,而不是仅凭感觉来判断自己是否有持续成长。当有记录下来,你将能够去比较现在做的事情,比起先前做的,是否是影响力更大的? 如果不是,就能根据你的目标来进一步调整。

如何记录自己的成果?

在了解完这份文件的重要性后,相信你会有个问题,那就是「该如何写这份文件」。我们推荐的记录方式,会是以 STAR 的形式来记录。对比起流水帐式的记录工作,用这个模板会让你能更以结果导向、影响力为导向的方式来记录。

与此同时,如同在该模板提到的,就像在面试中分享完某段经历后,可能被追问「从中学到什么?未来如果要再做一次,会如何做更好? 」,会推荐要记录下学习与反思。这不仅是为了未来的面试用,而是当你去反思经验,往往会获得更多的成长。

这边特别补充,之所以在 STAR 格式记录外,还要额外写下学习,或者是写下反思,是因为这不仅能帮助自己回顾,并透过回顾来成长;还能够面对面试中分享被追问「从该次经验中学到什么?未来如果要再做一次,会如何做更好? 」

让我们透过一个具体范例,实际了解如何使用上述的形式来记录:

  • S:下一季团队预计扩招至少 5 人,然而先前的入职流程与文件,并没有系统性的整理,导致过去入职的效率不是太好
  • T:我主动跟工程经理提说,我想要有系统地重新梳理入职流程,并把文件化作好。工程经理也很同意这件事情很重要,如果现在不先做好,等到时候大量新成员加入,会有很大量的时间浪费。因此,工程经理同意让我花时间来解决这问题。
  • A:我主导整个团队的入职流程,同时找了团队其他人,除了更新流程外,也把有缺漏、不完整的文件都补上
  • R:在重整完入职流程与文件后的一季,新成员入职所需的上手时间缩短,从原本一周变成三天后即可开始贡献到专案,同时后续我带领持续优化这个部分,让我们目前的新成员入职,几乎不需用既有成员的额外时间,也能顺利完成。
  • Learning:在这次的经验中,特别有感的学习点是,要让最终的成果有效,一定要时时搜集使用者的回馈。在完成重整后的第一个新成员入职时,我才发现原本有些设想的不如预期,所以当时该成员一边入职,我一边找机会访谈他,搜集到许多有用的回馈后,再调整流程与文件,也让后面加入的成员,整体入职变得更顺畅。

上面这个形式,会是推荐在一个专案完成后做记录。但平时如果有一些相对比较小,但仍值得记录的事件,仍推荐大家要顺手记录到文件中。

举例来说,可以记录:

  • 学了什么新的技能、技术、框架,像是近期 AI 工程相关的技能,如果平常有进修,就可以特别记下来
  • 获得什么回馈,例如工作上同事、主管给的回馈,不论是好的或者坏的,都可以记下来,除了能定期检视自我,也能在面试中提到
  • 如果平常有做开源贡献,或者有在做志工 (例如当技术会议的志工) 也可以记下来,这些也能放在履历或者面试时用

阅读更多

如果你对于透过记录、适时展示自己工作成果这主题感兴趣,我们在 E+ 有写一个更完整详细的版本,额外谈到许多人不记录成果的思考误区、记录成果时要避免的事、如何不高调张扬但仍有效展示成果。

E+ 的专属介绍页面 (连结点此)。

🧵 如果你想收到最即時的內容更新,可以在 FacebookInstagram 上追蹤我們