移交一个流程
从只有你熟悉的流程，到另一个人能够独立运行的流程。
The case
移交流程之所以困难，在于移交者对流程太熟悉了。知道哪些步骤真正重要，哪些只是走个过场。知道每隔几个月会出现的那个特殊情况。知道某个依赖项不稳定，其实每次都在绕着走。这些都没有写在任何地方——本来也不需要写，因为一直是自己在处理。
于是被移交的，是文档里写的内容。对方点点头，会议结束，两周后问题来了——没有人能提前想到的那种问题，因为只有真正去执行，才会遇到。
解决方法不是写更好的文档，而是换一个顺序：先还原真实的流程，再写下来，再看着另一个人执行之后，才放手。旁观的时候，遗漏的地方会浮现出来。总会浮现的。
在另一个人能够独立运行这个流程之前，移交没有完成。在此之前的一切，都只是准备工作。
流程移交
- 凭记忆写出流程的每个步骤。 先不要查阅文档。能不借助任何资料回忆起来的内容，大致就是对方需要掌握的内容。
- 将列表与现有文档进行核对。 记录缺漏和不一致之处。文档通常已经过时。
- 补充未被文档记录的细节。 特殊情况、例外处理、第4步失效时的应对方法。这里是只有你掌握的部分。
- 梳理依赖关系。 工具、权限、账号信息、相关人员。流程涉及的所有内容。
- 确认对方已具备运行流程所需的一切。 在交接会议前确认权限，而不是在会议中发现问题。
- 撰写交接文档。 步骤按顺序排列，依赖关系和例外情况均有说明。内容应足以让对方在没有你的情况下运行流程。
- 列出两到三个最容易出问题的环节。 会在哪里卡住、如何处理、处理不了时联系谁。
- 完整走一遍流程。 逐步讲解。对方这时还不需要自己操作。
- 让对方实际运行流程，旁观。 除非出现真正的问题，否则不要介入。记录对方遗漏了什么。
- 补充对方遗漏的内容。 简洁，具体。
- 如果存在明显遗漏，重新来过。@9 如有必要。
- 确定移交完成后出现问题时的处理方式。 一个联系人、一份文档、一个沟通渠道。不能只说"有问题就联系我"。
- 确认对方已准备好独立运行流程。 由对方来判断，而不是你。
按需调整
第3步是大多数移交失败的地方。文档记录的流程版本，往往不是实际在运行的版本——总有一些针对从未修复问题的变通方法，总有一些已成惯例的捷径，总有一些因过去某次事故而留下的检查步骤。跳过这一步，就是在移交一张不完整的地图。
让对方实际运行流程、旁观的步骤（第9步），在流程有一定复杂度时不可替代。听对方说"我明白了"，和亲眼看对方操作，是两回事。对方在哪里停顿、跳过了什么，比任何问答都能说明更多问题。
对于简单的流程，第6步和第7步可以合并成一份简短文档。对于涉及客户、财务或运营等风险较高的流程，最好保持分开。"出问题时怎么办"的文档，是真正在压力下会被打开的那份。
多做几次移交之后，第1步会变得容易很多——因为你开始在执行流程的过程中同步记录，而不是事后重建。这是另一个习惯，但它能让整个移交过程快上很多。