关注并将「人人都是产品经理」设为星标
每天早 07 : 45 按时送达
作者:不想延期了
微信公众号:不想延期了
编辑:范佳璐,人人都是产品经理实习生
题图来自Unsplash,基于CC0协议
全文共 2984 字,阅读需要 6 分钟
——————/ BEGIN /——————
工作交接是无论身处任何行业、任何岗位都会遇到的事情,交接的原因也有很多,比如入职、离职、岗位变动、工作重心调整、工作阶段调整等等。
而在交接中也会存在很多问题,导致最终交接效果很差,让原本顺利的事情变得问题百出,让原本困难的工作变得更加艰难。
所以我想根据自身的经验,来聊聊应该怎样对待和规范这个过程。
无论因为何种原因,其他人要接手这部分工作,我们都要考虑这些问题:
怎么给对方讲能更明白,让他快速理解?
怎样能确保他的理解没问题?
怎样能避免以后他又忘了?
交出去的内容,后续对方又频繁来问,是哪里出了问题?
同理,如果我们是接手人,就要转换身份来考虑上述的问题:
我需要交接人怎样做,我才能更快速的掌握这些工作?
我需要怎样做才能发现哪些关键问题有遗漏?
对方短时间讲了这么多内容,过几个月我都忘了怎么办?
如果对方是要离职,那以后如果有问题不明白找谁问呢?
大家在交接的时候,可能会直接对着系统讲,或者开发直接对着代码讲“这里是什么意思,当时为什么这么做”。
一个讲、一个记,不知道讲的人的准备是否充分,也不知道记的人记得是否准确。
可能会讲很久很久。稍微规范些的,可能会录屏、录音。
讲完之后问一句:明白了吗?
答:我消化消化,哪儿不理解再问你。
我们也许会有觉察,平时的文档和实际的应用之间存在一些(也可能很多)差异。交接的时候依托文档内容会让双方都很懵,但是又没有人来痛下决心持续更新文档。
尤其是某些功能经过多轮演变,你、我、他三方对此功能的认知停留在不同的版本状态下,后面再更新迭代就很麻烦了。
不仅文档内容不对,可能开发写的代码注释也不准确,后期根据注释理解流程时,又发现注释、流程、文档三方不同。
可能有人会很奇怪,交接不就是两方的事情吗,两方参与有什么问题?
这里面会涉及三个问题:
接手人接不住,怎么办?后续有问题找谁?即便反映到领导层,领导对这些事情也不了解,那问题如何解决?
交出人讲不明白,或者讲的内容有误,谁来识别其中的错误?
双方认为交接完了,但是真的完成了吗?是否需要有第三方角色的参与来验证交接效果,或协助疑难杂症的持续推进呢?
因此我认为只有两方参与的交接过程,是不保险的。除非接手人是后续此事的直接领导者或是交出人的上级。
我曾经遇到过这样的情况:
交出人提前发了一个文档和几张截图(很笼统的内容),然后说:你看完有啥问题,问吧。
接手人:你给我这么个破玩意,啥背景现状也不讲,我**知道要问什么吗?
即双方或某方没有人主动因为此事而做准备,做约定,做事前沟通,真正交接时效率低下。
上一点也属于个人态度问题,但本条的态度问题是想着重强调大家对交接工作的不重视,以及后续工作中风险的预知程度不足。
尤其是此项工作的直接领导者没有识别交接工作的重要性,任由双方自由发挥。
A交给B可能还好,但是没多久B又交给C,C又交给D,这时候事情就很可怕了。
如果A没离职,那A还会经常接到D、E的咨询电话。而且这个电话是D打给C、再打给B、最后打给A,问题才搞清楚。这时就更加彰显了交接流程、交接质量、交接持续性的重要。(嗯,没错,我就是那个没有做好交接坑了很多人的A)
说了这么多问题,其实大家也会有很多做好交接工作的想法和成功实践,下面我来总结我的方法论。
首先要准备丰富的交接文档,根据工作类型、工作内容不同,文档组成会有很多不同,在此不一一列举。
但更重要的是,要有一个对所交事项的整体描述。
这个描述是需要重新编写的,包含工作现状以及现状的背景、原因、关键事项或关键流程、遗留问题及针对这些问题的规划、后续的可预知风险和工作重点等等。
尤其是涉及到对外的关联方、对接人,一定要介绍相关人员为人处世的风格特点、关联方的实际情况及配合度等等。这些均要作为“交接目录”进行逐一整理。
当然,工作过程中所产生的各类物料(文档、设计图、代码等等)不标准、不完整、与实际不匹配等相关问题,属于日常工作管理的问题,在此不做展开讨论。
交接时若能够完善,则需要尽量修改完善。但这一定是一项很庞大的工程,用功在平时,临时抱佛脚的办法一定不会太好。
交接物料准备完整后,在真正执行过程中,还要有的放矢,按照合理的顺序和优先级逐一讲解、逐一交接,切勿一个大压缩包发过去拍屁股走人。
就像我们在接触一个新的业务、新的项目时,一定是要先搞清楚背景、关联关系、整体流程,有了宏观概念之后,再深入了解细节。
交接也是如此,因为接手人就是要通过这种思维模式来快速上手,所以交出人按照这样的逻辑讲,最终的效果也会更好。
如何确认交接完成了?一定不是大家说完成就是完成。需求有评审,设计有评审,代码有走查,交接是否需要增加核验流程呢?
我个人的观点是,针对重点、中大型工作的交接,一定要有核验流程。其他情况的交接可不做固定要求。
核验形式多种多样,既能不让大家觉得形式化,又能简单直接地达成目的即可。
比如由领导进行关键问题提问(有点类似代码走查);由接手人进行整体讲解;设置一周的“试行期”等等,结合自身团队的实际情况,制定相应的核验规则。
为了防止交接过程中讲不明白、讲不全面等问题,需要更有经验的人(或pmo等角色)参与到此过程中作为协助者,并且此人可以执行后续的核验任务,同时针对工作中后续的风险、待解决问题等关键事项,也可以协助解决。
其实直属领导参与关键工作的交接是非常有必要的。
工作交接的质量能够反映出一个团队的整体执行质量和管理质量,交接不明白的团队,执行中一定会存在各种各样其他类型的管理风险。
但是大多数人,或大多数团队对于工作交接并没有引起足够的重视,没有为之付出足够的精力。
交接不完整引起的后续工作问题,会极大增加团队工作负荷度,进而花费更多的代价来弥补,因此今天特意以此为题进行整理,希望我们的工作能更好地推进,更好地流转。
规则的设立和执行是非常困难的,如若因为困难而迟迟不肯改变,那后续的压力也会越积越多,问题越攒越满,直到大家不堪重负。
因此“重要但不紧急”的任务,应该是我们日常工作的重中之重。提升意识、强化管理、点滴执行、长期见效,才是团队良性成长的模式。
其中提到的很多方法我也在实践,也在不断探索,有对有错,有适合与不适合,希望大家也能辩证性地看待这些问题。到最后不都是为了更顺利地工作,更健康地成长嘛。
—————— / END / ——————
产品经理培训|产品运营培训|企业内训服务
请在公众号后台回复「培训」了解更多
▼ 喜欢请分享&收藏,满意点个赞,最后点「在看」 ▼