目錄是接手人的問題清單, 不是你的職責範圍
讓人寫交接文件，大多數人會先列出自己負責過的事。這份清單對寫的人很自然，對讀的人卻沒有順序。接手的人打開這份文件的時刻永遠只有一種，就是卡住的時候，而那時他要的不是前任的職責範圍，是現在該點哪裡。
所以目錄要倒著來。先寫下你走之後那一週，接手的人會在搜尋框裡打什麼、會拿什麼去問誰，再把這些問題立成小節標題。湊夠六七個問題，文件的骨架就有了; 掛不到這副骨架上的內容，通常都可以不寫。
交出去的是權限和對接窗口, 不是任務
工作本身怎麼做，大多已經躺在內部文件和過往記錄裡了。真正會消失的是讓這件事轉起來的那些配件: 用哪個帳號登入、誰來審批、卡住了打給哪個部門。按下面五個類別過一遍，空著的格子就現形了。
| 類別 | 要寫什麼 | 漏掉會怎樣 |
|---|---|---|
| 正在運轉的事 | 進度、下一步、截止日 | 接手的人在過期之後才知道有這個截止日 |
| 週期性事務 | 週期、期限、不做會出什麼問題 | 月度事務一個月後整件消失 |
| 存取權限與帳號 | 需要哪些權限、找誰開 | 第一週全花在申請權限上 |
| 人和對接窗口 | 什麼事找誰 | 一句話的確認要走兩天 |
| 決策記錄 | 為什麼定成現在這樣 | 接手的人重試一遍已經失敗過的做法 |
走兩個人就停擺的專案佔了三分之二
軟體業有個叫卡車係數 (truck factor) 的指標: 數一數要走掉幾個人，專案就轉不動了。這名字來自被卡車撞到、或者乾脆辭職的情形。2016 年有研究團隊提出了自動估算這個值的方法，並跑了 GitHub 上 133 個熱門專案 (Avelino 等, ICPC 2016)。其中 65% 的卡車係數是 2 或更低，也就是走兩個人就停。
這項調查針對的是開源專案，數字不能照搬到公司組織。但被調查的都是參與者眾多的熱門專案，也就是說這種集中不是因為人少，而是因為知道的人少。
交接文件是在人還沒走之前降低這種集中度的最便宜的辦法。等提了離職才開始寫，只剩幾週，而這幾週裡能想起來的也就是最近幾個月的事。每半年花三十分鐘更新一次，最後那一週基本就沒什麼可寫了。
最先消失的是為什麼會是這樣
流程留在文件裡，當初把流程定成這樣的理由跟著人走了。於是半年後接手的人發現一條看起來很怪的規矩，合情合理地把它改掉，然後靠一次事故弄明白這條規矩當初為什麼存在。
防住它並不貴: 每條加一行理由。看起來像例外的規矩、和別人做法不一樣的地方、寫著不要這麼做的條目，一定要加。要是有條規矩你自己也想不起來為什麼，那就照實寫上。接手的人判斷這條規矩能不能改時，沒人知道原因這件事本身就是判斷材料。
最後一節是還沒交出去的東西
幾乎沒有哪次交接是乾淨收尾的。總會剩下沒查出結果的諮詢、只搬了一半的資料、想問但負責人不在的事。把這些從文件裡拿掉，文件是好看了，接手的人幾週後自己一腳踩進那個坑。
所以最後一節的標題就叫還沒交出去的東西。每條都寫上由誰在什麼時候收尾，沒定下由誰負責的，就寫沒定。有這一節，接手的人才知道自己不知道的邊界在哪; 沒有這一節，他會以為文件寫的就是全部。最後一節空著的交接文件，通常不是寫得好，只是還沒寫完。
常見問題
交接只有一週時間, 先寫什麼?
先寫權限和對接窗口。工作怎麼做，接手的人肯花時間讀就能跟上; 但沒有帳號，他連要讀的介面都打不開。接著是這個月內有期限的事，再接著是週期性事務。背景和決策記錄留到最後，有多少時間寫多少。順序反過來，最急的那幾欄就會空到最後一天。
接手的人還沒定, 現在寫有意義嗎?
沒定反而更好。心裡想著某個具體的人寫，你會自動跳過那些你以為他已經懂的部分，而這種猜測大多是錯的。把收件人設成第一次接這份工作的人，省略就會變少。等接手的人定了，按他的情況刪減，比回頭補上漏掉的容易得多。
帳號密碼要寫進文件嗎?
不寫。交接文件會被很多人打開、還會長期留存，密碼一旦進去，那個帳號基本等於公開了。文件裡只寫需要哪些帳號、權限找誰開、去哪裡申請。憑證本身透過公司在用的密鑰管理工具或管理員帳號交接，文件裡只留這條路徑。
寫完了怎麼知道這份文件管不管用?
最可靠的辦法是: 趁你還在，讓接手的人只看文件，把一件真實的工作從頭做到尾。過程中冒出來的每個問題就是文件的空格，別只是口頭回答，當場補進文件。要是還沒有接手的人，找一位不熟這塊工作的同事讀一遍、標出卡住的地方，也能抓出一半。