目录是接手人的问题清单, 不是你的职责范围
让人写交接文档，大多数人会先列出自己负责过的事。这份清单对写的人很自然，对读的人却没有顺序。接手的人打开这份文档的时刻永远只有一种，就是卡住的时候，而那时他要的不是前任的职责范围，是现在该点哪里。
所以目录要倒着来。先写下你走之后那一周，接手的人会在搜索框里打什么、会拿什么去问谁，再把这些问题立成小节标题。凑够六七个问题，文档的骨架就有了; 挂不到这副骨架上的内容，通常都可以不写。
交出去的是权限和对接窗口, 不是任务
工作本身怎么做，大多已经躺在内部文档和过往记录里了。真正会消失的是让这件事转起来的那些配件: 用哪个账号登录、谁来审批、卡住了打给哪个部门。按下面五个类别过一遍，空着的格子就现形了。
| 类别 | 要写什么 | 漏掉会怎样 |
|---|---|---|
| 正在运转的事 | 进度、下一步、截止日 | 接手的人在过期之后才知道有这个截止日 |
| 周期性事务 | 周期、期限、不做会出什么问题 | 月度事务一个月后整件消失 |
| 访问权限与账号 | 需要哪些权限、找谁开 | 第一周全花在申请权限上 |
| 人和对接窗口 | 什么事找谁 | 一句话的确认要走两天 |
| 决策记录 | 为什么定成现在这样 | 接手的人重试一遍已经失败过的做法 |
走两个人就停摆的项目占了三分之二
软件行业有个叫卡车系数 (truck factor) 的指标: 数一数要走掉几个人，项目就转不动了。这名字来自被卡车撞到、或者干脆辞职的情形。2016 年有研究团队提出了自动估算这个值的方法，并跑了 GitHub 上 133 个热门项目 (Avelino 等, ICPC 2016)。其中 65% 的卡车系数是 2 或更低，也就是走两个人就停。
这项调查针对的是开源项目，数字不能照搬到公司组织。但被调查的都是参与者众多的热门项目，也就是说这种集中不是因为人少，而是因为知道的人少。
交接文档是在人还没走之前降低这种集中度的最便宜的办法。等提了离职才开始写，只剩几周，而这几周里能想起来的也就是最近几个月的事。每半年花三十分钟更新一次，最后那一周基本就没什么可写了。
最先消失的是为什么会是这样
流程留在文档里，当初把流程定成这样的理由跟着人走了。于是半年后接手的人发现一条看起来很怪的规矩，合情合理地把它改掉，然后靠一次事故弄明白这条规矩当初为什么存在。
防住它并不贵: 每条加一行理由。看起来像例外的规矩、和别人做法不一样的地方、写着不要这么做的条目，一定要加。要是有条规矩你自己也想不起来为什么，那就照实写上。接手的人判断这条规矩能不能改时，没人知道原因这件事本身就是判断材料。
最后一节是还没交出去的东西
几乎没有哪次交接是干净收尾的。总会剩下没查出结果的咨询、只搬了一半的资料、想问但负责人不在的事。把这些从文档里拿掉，文档是好看了，接手的人几周后自己一脚踩进那个坑。
所以最后一节的标题就叫还没交出去的东西。每条都写上由谁在什么时候收尾，没定下由谁负责的，就写没定。有这一节，接手的人才知道自己不知道的边界在哪; 没有这一节，他会以为文档写的就是全部。最后一节空着的交接文档，通常不是写得好，只是还没写完。
常见问题
交接只有一周时间, 先写什么?
先写权限和对接窗口。工作怎么做，接手的人肯花时间读就能跟上; 但没有账号，他连要读的界面都打不开。接着是这个月内有期限的事，再接着是周期性事务。背景和决策记录留到最后，有多少时间写多少。顺序反过来，最急的那几栏就会空到最后一天。
接手的人还没定, 现在写有意义吗?
没定反而更好。心里想着某个具体的人写，你会自动跳过那些你以为他已经懂的部分，而这种猜测大多是错的。把收件人设成第一次接这份工作的人，省略就会变少。等接手的人定了，按他的情况删减，比回头补上漏掉的容易得多。
账号密码要写进文档吗?
不写。交接文档会被很多人打开、还会长期留存，密码一旦进去，那个账号基本等于公开了。文档里只写需要哪些账号、权限找谁开、去哪里申请。凭据本身通过公司在用的密钥管理工具或管理员账号交接，文档里只留这条路径。
写完了怎么知道这份文档管不管用?
最可靠的办法是: 趁你还在，让接手的人只看文档，把一件真实的工作从头做到尾。过程中冒出来的每个问题就是文档的空格，别只是口头回答，当场补进文档。要是还没有接手的人，找一位不熟这块工作的同事读一遍、标出卡住的地方，也能抓出一半。