工作交接中的“交”与“接”

编辑导语：在职场中，我们免不了要经历工作交接。在这个时候，如果交接过程存在很多问题，导致交接效果很差，只会让后面的工作变得更加困难。那么，交接这个过程需要注意些什么规范呢？作者结合了自己的经验，谈谈应该如何对待交接这件事。

工作交接是无论身处任何行业、任何岗位都会遇到的事情，交接的原因也很多，因为入职、离职、岗位变动、工作重心调整、工作阶段调整等等。而在交接中也会存在很多问题导致最终交接效果很差，让原本顺利的事情变得问题百出，让原本困难的工作变得更加艰难。

所以想根据自身的经验来聊聊应该怎样对待和规范这个过程。

一、关于“交”的问题

无论因为何种原因，其他人要接手这部分工作，我们都要考虑这些问题。

怎么给对方讲能更明白，让他快速理解？

怎样能确保他的理解没问题？

怎样能避免以后他又忘了？

交出去的内容，后续对方又频繁来问，是哪里出了问题？

二、关于“接”的问题

同理如果我们是接手人，就要转换身份来考虑上述的问题。

我需要交接人怎样做，我才能更快速的掌握这些工作？

我需要怎样做才能发现哪些关键问题有遗漏？

对方短时间讲了这么多内容，过几个月我都忘了怎么办？

如果对方是要离职，那以后如果有问题不明白找谁问呢？

三、交接过程中常见的坏习惯 1. 没有可参照的文档

大家在交接的时候，直接对着系统讲，或者开发直接对着代码讲，这里是什么意思，当时为什么这么做。一个讲、一个记，也不知道讲的人准备是否充分，也不知道记的人记得是否准确。

可能会讲很久很久。稍微规范些的，可能会录屏、录音。

讲完之后问一句：明白了吗？

答：我消化消化，哪儿不理解再问你。

2. 文档内容不对

我们也许会有觉察，平时的文档和实际的应用之间存在一些（也可能很多）的差异。交接的时候依托文档内容会让双方都很懵，但是又没有人来痛下决心持续更新文档。

尤其是某些功能经过多轮演变，你、我、他三方对此功能的认知又停留在不同的版本状态下，后面再更新迭代就又很麻烦了。

不仅文档内容不对，可能开发写的代码注释也不准确，后期根据注释理解流程时，又发现注释、流程、文档三方不同。

3. 只有两方参与交接过程

可能有人会很奇怪，交接不就是两方的事情吗，两方参与有什么问题？

这里面会涉及三个问题：

• 接手人接不住，怎么办？后续有问题找谁？即便反映到领导层，领导对这些事情也不了解，那问题如何解决？
• 交出人讲不明白，或者讲的内容有误，谁来识别其中的错误？
• 双方认为交接完了，但是真的完成了吗？是否需要有第三方角色的参与来验证交接效果，或协助疑难杂症的持续推进呢？

因此我认为只有两方参与的交接过程，是不保险的。除非接手人是后续此事的直接领导者或是交出人的上级。

4. 不主动

我曾经遇到过这样的情况：

交出人提前发了一个文档和几张截图（很笼统的内容），然后说：你看完有啥问题，问吧。

接手人：你给我这么个破玩意，啥背景现状也不讲，我**知道要问什么吗？

即双方或某方没有人主动因为此事而做准备，做约定，做事前沟通，真正交接时效率低下。

5. 个人的态度问题

上一点也属于个人态度问题，但本条的态度问题是想着重强调大家对交接工作的不重视，以及后续工作中风险的预知程度不足。

尤其是此项工作的直接领导者没有识别交接工作的重要性，任由双方自由发挥。

6. 交接没有持续性

就像我在上一篇文章《小问题，折射大风险》最后提及的，A交给B可能还好，但是没多久B又交给C，C又交给D，这时候事情就很可怕了。

如果A没离职，那A还会经常接到D、E的咨询电话。而且这个电话是D打给C、再打给B、最后打给A，问题才搞清楚。这时就更加彰显了交接流程、交接质量、交接持续性的重要。（嗯，没错，我就是那个没有做好交接坑了很多人的A）

说了这么多问题，其实大家也会有很多做好交接工作的想法和成功实践，下面我来总结我的方法论。

四、我设想的交接流程 1. 有清晰准确的参照物

首先要准备丰富的交接文档，根据工作类型、工作内容不同，文档组成会有很多不同，在此不一一列举。

但更重要的是，要有一个对所交事项的整体描述，这个描述是需要重新编写的，包含工作现状以及现状的背景、原因，关键事项或关键流程，遗留问题及针对这些问题的规划，后续的可预知风险，后续工作重点等等。

尤其是涉及到对外的关联方、对接人，一定要介绍相关人员为人处世的风格特点，关联方的实际情况及配合度等等。这些均要作为“交接目录”进行逐一整理。

当然，工作过程中所产生的各类物料（文档、设计图、代码等等）不标准、不完整、与实际不匹配等相关问题，属于日常工作管理的问题，在此不做展开讨论。交接时若能够完善则需要尽量修改完善。但这一定是一项很庞大的工程，用功在平时，临时抱佛脚的办法一定不会太好。

2. 分批分阶段按优先级依次交接

交接物料准备完整后，在真正执行过程中，还要有的放矢，按照合理的顺序和优先级逐一讲解、逐一交接，切勿一个大压缩包发过去拍屁股走人。

就像我们在接触一个新的业务、新的项目时，一定是要先搞清楚背景、关联关系、整体流程，有了宏观概念之后，再深入了解细节。交接也是如此，因为接手人就是要通过这种思维模式来快速上手，所以交出人按照这样的逻辑讲，最终的效果也会更好。

3. 有核验流程

如何确认交接完成了？一定不是大家说完成就是完成。需求有评审、设计有评审、代码有走查，交接是否需要增加核验流程呢？

我个人的观点是，针对重点、中大型工作的交接，一定要有核验流程。其他情况的交接可不做固定要求。

核验形式多种多样，既要不让大家觉得形式化，又能简单直接地达成目的即可。比如由领导进行关键问题提问（有点类似代码走查）；比如由接手人进行整体讲解；再比如有一周的“试行期”等等，结合自身团队的实际情况，制定相应的核验规则。

4. 有领导或其他辅助岗位参与并协助

为了防止交接过程中讲不明白、讲不全面等问题，需要更有经验的人（或pmo等角色）参与到此过程中作为协助者，并且此人可以执行后续的核验任务，同时针对工作中后续的风险、待解决问题等关键事项，也可以协助解决。

其实直属领导参与关键工作的交接是非常有必要的。

5. 从意识上加强，从流程上规范

工作交接的质量能够反映出一个团队的整体执行质量和管理质量，交接不明白的团队，执行中一定会存在各种各样其他类型的管理风险。但是大多数人，或大多数团队对于工作交接并没有引起足够的重视，没有为之付出足够的精力。

因为交接不完整引起的后续工作问题，却会极大增加团队工作负荷度，进而花费更多的代价来弥补，因此今天特意以此为题进行整理，希望我们的工作能更好的推进，更好的流转。

五、写在最后

规则的设立和执行是非常困难的，如若因为困难而迟迟不肯改变，那后续的压力也会越积越多，问题越攒越满，直到大家不堪重负。

因此“重要但不紧急”的任务，应该是我们日常工作的重中之重，提升意识，强化管理，点滴执行，长期见效，才是团队良性成长的模式。

其中提到的很多方法我也在实践，也在不断探索，有对有错，有适合与不适合，希望大家也能辩证性的看待这些问题。到最后不都是为了更顺利的工作，更健康的成长嘛。

作者：不想延期了，公众号：不想延期了

本文由 @不想延期了 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议。