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

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

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

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

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

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

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

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

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

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

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

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

举例来说，可以记录：