移交一个流程

案例

移交流程之所以困难，在于移交者对流程太熟悉了。知道哪些步骤真正重要，哪些只是走个过场。知道每隔几个月会出现的那个特殊情况。知道某个依赖项不稳定，其实每次都在绕着走。这些都没有写在任何地方——本来也不需要写，因为一直是自己在处理。

于是被移交的，是文档里写的内容。对方点点头，会议结束，两周后问题来了——没有人能提前想到的那种问题，因为只有真正去执行，才会遇到。

解决方法不是写更好的文档，而是换一个顺序：先还原真实的流程，再写下来，再看着另一个人执行之后，才放手。旁观的时候，遗漏的地方会浮现出来。总会浮现的。

在另一个人能够独立运行这个流程之前，移交没有完成。在此之前的一切，都只是准备工作。

按需调整

第3步是大多数移交失败的地方。文档记录的流程版本，往往不是实际在运行的版本——总有一些针对从未修复问题的变通方法，总有一些已成惯例的捷径，总有一些因过去某次事故而留下的检查步骤。跳过这一步，就是在移交一张不完整的地图。

让对方实际运行流程、旁观的步骤（第9步），在流程有一定复杂度时不可替代。听对方说"我明白了"，和亲眼看对方操作，是两回事。对方在哪里停顿、跳过了什么，比任何问答都能说明更多问题。

对于简单的流程，第6步和第7步可以合并成一份简短文档。对于涉及客户、财务或运营等风险较高的流程，最好保持分开。"出问题时怎么办"的文档，是真正在压力下会被打开的那份。

多做几次移交之后，第1步会变得容易很多——因为你开始在执行流程的过程中同步记录，而不是事后重建。这是另一个习惯，但它能让整个移交过程快上很多。