撰寫工作文件（Documentation, Memo）

工作時產出實際成果，如何給工作內容做紀錄、寫文件，也是很重要的能力。寫文件除了可以提升工作效率，幫助整理思路，也是內部溝通、增加個人對團隊的貢獻和刷存在感的方法。有些團隊甚至會要求每個會議重點都要以 memo 等文件檔做摘要。

Memo：先看文檔再開會

『開會前十分鐘，所有人先一起讀一遍一頁的文檔：Memo。』這個據說是亞馬遜（Amazon）內部開始的一項措施（所以又叫 Amazon Memo），又隨著公司人員的流動推行到各大科技公司。這樣可以確認『we are on the same page』在開會之前大家有一些對事情背景基礎的了解，想關的數字、背景有具體參考，溝通起來會更有效率。話雖如此，實際在每個公司每個組織的執行成果不一，我們也暫時沒有定論。

寫文件的重要性：溝通、效率、存在感

科技公司裡即使是 individual contributor (沒有擔任管裡職的員工。可以理解為底層員工，但是也根據職能不同，有些職位即使職級很高、很資深也會擔任 individual contributor)，也會常常被要求寫文件。程序員要寫文檔，寫代碼註釋，資料相關職位也要對自己做的分析、模型有所紀錄，產品經理（PM）更是要花一半的工作時間寫 PRD (product requirements document)。

擔任管理職位，甚至部門主管更要為重要計畫撰寫 white paper, POV (point of view)，為整個計畫做整理總結，讓不同部門和更高領導階層可以參考，以便為團隊計畫正取資源。

比起 slack 訊息，電子郵件和口頭報告，文件是更完整、技術上可以更深入、更長效的溝通方式。在團隊內部，好的文件系統也可以讓工作交接，互相 cover 互相配合變得更容易；以後遇到類似的任務時，也可以參考以前的文件而做的更有效率。

最後，很實際的一點，多寫文件、寫好文件可以讓你的貢獻更『具體』。到了年中、年末評考績的時候，也比較不會被忘記（不寫文件有時自己都不記得做過什麼）。如果你的文件常常被同事參考，也會自然而然的產生『ownership』，大家會認為這個業務就是你最熟悉，也更能成為團隊的重要人物。

文件怎麼寫：摘要、格式、實用性

文件怎麼寫？其實沒有一定之規，我們根據 Seaturtle 顧問團隊的實際工作經驗，綜合出幾點小提示。

1. 開頭附上摘要（Abstract、Summary 或是 TL;DR）

無論是描述計畫的綜合文檔，還是很硬核的技術文檔，比較長的文件（超過一頁），最好都附上摘要。摘要都很重要，因為可以讓需要閱讀整個文件的人先對內容有個底（知道你要講什麼，再往下看細節），對很多讀者而言（跨部門人員，管理階層），摘要可能是他們唯一會看的部分（所謂的『太長不看』，too long; don’t read，縮寫為 TL;DR）。

摘要要涵蓋描述整個文件最核心的概念。至於什麼是最核心的概念，這是要花心思好好釐清的部份；如果你覺得重要的結果有好幾個，可以試試看問自己『so what?』，那個答案可能才是核心。如果想不出來，可能要回頭思考整個計畫的重點到底是什麼。

（只要提到寫作，我們就會再推薦一次金字塔原理）

2. 格式、模組化

如果公司有現成的文件，最好可以依循類似的格式，這樣需要特定內容的讀者可以很快找到他需要的東西。類似的工作也最好用類似的格式寫，這樣無論是寫作還是閱讀都能夠事半功倍。例如用到的代碼、資料庫固定放在最後附件中，聯絡人員、更新日期固定放在開頭，或是以某種規則命名文檔。

模組化：常用的工具、方法可以另外寫一個文件，以後需要時以連結方式展現即可，不需要一直重複類似的內容。

3. 實用性

技術相關的文件，要注意實用性，光是有花裡胡哨的文字不實用也是枉然。分析類的文件要遵循 reproducibility 的原則：也就是一個稱職的同行可以基本上複製你的分析成果。實際操作包含：使用資料庫附上確切 query，下載日期（問一資料不同可能是中間有更新）；盡量附上關鍵代碼等等。

文件中提到的其他商業背景，也可以盡量附上連結（連到投影片或是其他文檔）和參考資料。寫得多了，互相連來連去的文件就可以變成一個很實用的資料庫，讓未來工作的自己和同事都可以受益。

最後，如果還有什麼秘訣，就是『寫了再說』：趁著事情剛做完（或是邊做邊寫），把重要的技術點、理由、方法、工具都記錄下來之後再慢慢整理。也可以一邊寫一邊整理思路，寫完了再慢慢修改。先養成寫東西的習慣，只要寫得多了，後面也會變成熟能生巧的事。