避坑指南：项目如何交接才能成功避坑？

最近，我发现“复盘”对于产品经理可真太重要了，可谓是成长的一道捷径，但今天我想聊的不是复盘的重要性，而是想分享下在对今年新手新产品项目复盘后的一些感想，让大家尽量避免在接手他人项目时踩坑。

曾经我以为接手新项目就是对方把产品框架、开发团队介绍一遍，把产品文档待做事项交代好就ok的了，然而事实证明，是我太天真，里面的坑全是心酸泪。

捋了一遍交接项目的过程后，得出了以下几点建议。

一、正式交接前

和原PM初步接触，了解产品概况，初步定下交接时间。

二、列交接文档清单

根据初步沟通情况，列出需要的交接文档清单，避免正式交接时，完全按着原PM的节奏走，而遗漏了自己真实所需。

1. 产品架构介绍、需求文档、原型等资料整体了解产品结构，掌握主要功能和用户使用场景

文档、原型均需拿到源文件，以便后期迭代优化，直接在原有原型上改即可，而不用自己重新捣鼓一份

2. 原计划的产品规划建设

后续正式接手后你对该产品的规划可参考此文档。

3. 对接外部团队的联系人文档

需原PM把该产品对接的不同系统的对接人和联系方式都一一细致列清楚，等到时候真正接手的时候，你会发现，找人是个非常困难的事。

• 开发团队：需列明开发老大、项目管理、各个开发负责的模块前后端、功能模块；
• 测试团队：测试老大、测试人员；
• 运营团队、市场拓展团队等的姓名和员工ID，并需要向各个对接方都有一个简单的双方介绍，拉进沟通群，以避免后续沟通时找不到正确的对接人（同名同姓），或者对方不知道换了新产品经理而拒绝沟通。

4. 当前的版本迭代流程

本以为同在一个公司且同一个团队，版本迭代流程大体一致，也没细问，接手了发现，原来这个项目的开发可直接接需求提需求，只是在需求澄清的时候问下PM意见是否能做，而PM只能在会议上给个结果而不是对需求进行深思熟虑后再由自己来确定，且没有案例评审流程，因为当时我也同时接手几个项目，所以没注意到。

等新项目第一个迭代快上线的时候才发现，一问才知道：由于原PM特别忙，测试直接和开发完成评审，跳过了PM。那我就只能去UAT环境进行细细验证，对于与需求有出入的地方挑差异大，影响实际使用的先改，一堆小问题再放下一个迭代继续修改。

5. 近几期版本迭代内容

了解版本迭代节奏和近期迭代方向。

6. 日常管理事项

月度数据报告、产品运营情况通报等。

7. 待办问题事项

明确需要做但尚未完成的需求或是产品待优化的bug，避免因人员变动而漏掉，使得新PM在遇到时需重新捋一遍，多做一次无用功。

三、正式交接时

正式交接过程中，一边跟着原PM的交接节奏走，一边比对之前列好的交接清单查漏补缺，同时更新交接内容。

四、交接完后

尽快熟悉产品，逻辑细节，对于该产品的适用场景，都要有所了解，尽快熟悉的理由除了本身接手新任务就该熟悉产品外。

更重要的是你面对的开发同事是已经负责两年以上，对于这个产品而言，和他们相比，你是个新人，你需要让他们知道你对确实了解这个项目，并不是交接时原PM介绍你多么厉害，他们就能服你了，他们可清楚那些只是门面话。

这可是我遇到的最难受的点，第一次开这个产品的需求澄清会时，开发总能找到点怼你，并有种他强你弱的感觉，而你又不好太过强势，毕竟对于这个项目，我确实是个新人，怼的点，就记下来，会后与市场调研，用数据说话。

2) 产品规划建设会议，研究公司战略、市场情况、竞品分析，对接手的产品做一个未来一年的规划。这个会议是用来宣示产品你对这个产品的主权，并订立规则的，一定要好好把握。

拉上开发、测试同事一起，把产品的建设重点和未来的功能与大家沟通，让团队有一致的目标，并把迭代开发流程与大家一起梳理，先按自己过往经验出一个流程，再根据开发和测试同事反馈意见，进行优化，最后得出一个大家都认可的迭代流程。

对于先前遇到的问题，例如开发同事直接提需求，需在会议明确需求流程规则，需求池的内容必须由产品提。若开发同事有好的想法可以提，但需要提给先产品经理，产品经理考虑后再决定是否录入。决定权是握在产品手里的。因为该项目要是出问题，第一责任人是产品。

五、总结

新项目的坑纵然很多，但对PM来说，是拓宽产品知识面的好机会，要好好把握。产品道路上的坑，且踩且珍惜。每一个坑，都是一个成长的机会点。

希望这篇文章可以帮助到你，让我们在成为优秀产品经理的路上一起成长。

作者：张开心；微信公众号：张开心呀

本文作者 @张开心

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！