如何快速接手一个新系统
背景回顾
受今年疫情影响，公司之前负责××产品的人员准备离职了，然后领导安排你来与他做工作交接，后面产品的工作就交给你来负责了。系统的地址和资料某某一会发给你，可以去看看。
那么产品经理如何交接工作，尽量最大程度的接收信息，以便快速接手一个新系统？
此时，我们可以撸起袖子就开干么？此时我们面对的是一个全新的系统，在还没有了解这个系统的情况下，很难安排后面的工作计划。在正式开展工作之前，我们还需要做一些准备工作来迎接这个新系统。
如何接手一个新系统
做产品经理，时刻要有主人翁心态，即使是接手一个现有的系统，也不要等着别人来带领我们，记住是产品经理带领他们做产品。
此时，你需要列一份交接清单，需要经过以下5步阶段，来全面需要了解系统。
内容包括：背景了解、系统资料、经办工作，其他需交接事宜，每项需注明具体交接内容及说明。
主动了解系统的建设背景、干系人，获取系统资料信息。基于现有资料，进行结构化梳理，从产品经理角度还原产品全貌。经办工作：需要对产品情况进一步摸底，包括项目衔接，未完事宜等。了解目前进展，了解现在存在的问题及历史未解决的问题。其他需交接事宜：产品工作流程，接了新系统，需要了解该系统的发布流程，团队日程工作等情况。前面做了这些功课之后，我们就可以正式接手产品后续的工作了。
1. 主动了解系统情况
我们可以通过系统的背景、涉及到的干系人、目前的建设工作3个方面建立对系统的认知，整体掌握系统情况
（1）背景了解
由于这个系统已经存在了，我们在接手一个新系统的时候，往往还不了解这个系统的建设背景、设计思路，现在既然要接手了，就得了解他的过去，才能决定他的未来！
首先系统了解这个系统的建设背景：站在公司的角度，为啥公司要做这个项目，业务核心是什么，最大的盈利点是什么；如果是工具类，就站在用户的角度，用户最想解决什么。
比如之前接手TMS同类题管理平台，这个平台已经使用多年。刚看到这个系统的时候，发现系统非常的臃肿，逻辑耦合性强。第一反应就是这个系统如果继续维护，那么研发和测试的代价很高。但是如果把这个系统全部重构，成本也是非常大的。后来去调研了这个系统的建设背景，发现里面有2条业务线，一个是同类题资源的管理，另一个是锚题资源的管理。锚题资源的管理，目前已经很少使用了，只是给之前的老客户提供支撑。最后我们决定把同类题资源的管理，单独剥离出来进行维护。而锚题资源就在老系统中使用。
新来的产品经理要对每一个老产品抱有敬畏之心。老的版本不管你觉得多不合理，都有他存在的理由。
可以找该项目涉及到的部门负责人进行讨论和请教，从头到尾全面了解业务，请教时可以选择去公司附近的咖啡店请对方喝咖啡。从心理学角度来说，让对方会觉得吃人嘴短，会和你说更多内容且容易较有耐心，或者在请教后请对方喝咖啡或请吃饭。刚来公司没多久同时也能通过这种方式搞好同事关系，让自己迅速融入团队中。
（2）干系人信息
我们需要了解这个系统涉及到的干系人，比如这个系统的上层负责人是谁，需求对接人是谁，研发团队是谁，客户或者用户是谁等。
了解他们对在这个系统的参与角色之后，是希望当我们遇到问题后，能找到合适解决这个问题的人，这个人可能是你的领导，但更多应该是和你合作的各部门相关业务负责人。
例如：由于系统功能已经建设完了，若需要了解历史需求情况，但是目前只接触到了研发和测试，如果一味的去找研发和测试进行沟通，一方面他们是从系统功能角度去思考，而不是用户需要方面出发，可能会误导产品的思考。尤其是你想推翻之前的功能，这会让研发和测试觉得否定以前的工作重新带来任务量，由于信息都是他们提供的，他们会过多的干涉，会让团队质疑你的需求以及能力。
产品经理是需要多人协作的角色，所以理清新公司的组织架构能帮我们迅速开展工作。例如：
这个系统的上级负责人，有的是项目经理。各部门的职责、权利、分工.部门成员、部门Leader都是谁，坐在哪儿。自己部门和其他部门的交叉合作关系、合作方式、合作流程都是什么。务必让自己的Leader带自己去认识一圈，先混个脸熟，尤其是会有紧密合作的技术、设计、测试、运营部门同学，以后好办事。
（3）系统资料
最后就是需要拿到系统的资料信息，例如需求文档、用户手册、设计文档等，有些项目还有合同、招投标文件信息，当然还需要新系统的体验地址和账号信息。
通过第一步的系统情况了解，我们需要明确系统的方向：针对这个现有的系统，领导的态度是希望重构这个系统，还是保留系统，让产品跟进后面的需求继续开展工作。
2. 基于现有资料和旧系统，还原产品全貌
有需求文档：
通过前面收集到的资料信息，如果过去有比较完备成体系的产品文档，那么我们可以快速从这些资料进行梳理，了解产品的定位，解决了用户哪些问题，客户群定位等，获得我们想要的信息。
如何系统的收集的资料比较多，不是需要我们把所有资料都看完，需要分个优先级了解，不要过早陷入到系统的细节情况。
没有需求文档：
如果没有资料，我们可以通过直接使用系统，把旧产品已实现的功能结构和核心逻辑全部理出来，整理成一个产品体验报告文档，跟原本最了解这个产品的人们（研发/测试）对一遍，纠正有偏差的部分。
在这个阶段，我们需要了解这个系统的目标用户、核心业务、系统功能。这是需要花费大量时间精力的事情，要带着极大的热情和求知欲去做，了解产品的前世今生，了解竞品做到了什么程度，学习产品相关行业的基础知识……
这是我曾经针对一个新系统《AI标客》做的产品体验报告。左侧是文章的目录结构，对系统从战略层、范围层、结构层、框架层、表现层进行体验分析。
在这个过程中，肯定是有一些疑问的，我们可以把问题归纳整理，然后再找相关人员进行沟通答疑。讨论请教完毕后，需要自己进行复盘，可以在自己已理解的基础上画出业务流程图，一方面帮助自己理清整个业务的来龙去脉，一方面，当业务流程图画完可以找同事确认，以免产生自己理解错误。
3. 产品情况摸底
找别人的错，总是要容易些；理解别人的套路，总是费点神。
我们在接手这个系统之前，还需要深入摸底产品情况：
核心功能完成度：是否现有的需求已经包含了全部核心功能？如果包含，实现进度是否可控？如果不包含，是否还可以调整需求？了解目前的系统细节：系统的里程碑计划、关键时间节点、现在的进度、问题都是啥？过去遇到过的问题及原因、解决方案，对于常见的问题重点说明。平时工作中的一些事项，比如项目进度的控制，最有可能耽误在哪环节；项目优先级的制定；接口的设计人员、开发人员的情况，能力强弱；。风险：有哪些坑。，出多少，取决于你在短期内与大家熟悉和建立信任的本事，也取决于你对业务理解的能力。深入细节了解，经过了解到上面的信息之后，基本大的逻辑就会比较清晰，剩下一堆细节的逻辑，很难一次性全部了解全。即使了解全，真正用的时候也比较容易遗忘，更好的办法是做一块的功能，细化了解一块细的逻辑。
毕竟历史前人留下的隐藏逻辑很多，如果开发还是之前的还容易些，如果开发也全部换了，就大家一起补逻辑，留好产品文档和技术文档，以便自己后续查阅以及下一任来查阅；
4. 产品工作要求
在新的公司做产品，需要关注产品的工作流程。
权限申请申请：
项目管理软件，比如SVN、teambition项目管理软件的权限申请和加入。
原型和文档规范：
可以参考前辈的工作流程，PRD格式、原型设计规范，比如PRD格式目前是用的word、excel、还是原型中直接标注。在开始阶段，我们先复用，不要马上用自己之前的格式！先模仿，适应公司再创新，让大家接收新的方式！
产品发布流程：
产品工作环境中，需要了解一些上线流程、紧急流程、会议流程等等“潜规则”。系统版本发布之后，是否需要邮件通知。尤其是客户所在的QQ群和微信群，版本发布之后，需要通知给哪些人员。
团队日程会议：
了解团队的成员，系统的需求提出非、研发负责人、测试人员、运营人员等等。参与团队的每日站会和周会，了解当前的状态和进度是什么情况，当前负责的日常工作，以及对应的具体要求，比如定期举行的会议、每月更新的报告等等。
5. 正式接手产品
稍微成熟一点的产品人首先在自我要求上会是产品输出导向，而非进度导向的。换言之，会花比较长时间去了解、再认识产品，调查业务瓶颈，查看用户反馈，摸清企业战略和产品的生命周期到了哪一阶段，再针对产品出现的问题，分清哪些是产品本身问题，哪些是技术问题，哪些是业务问题。
我们把前面的工作完成之后，可以把召集相关人员（老板、技术负责人、运营负责人等），一起讨论，互相纠正，达成共识。这个也是向领导和团队，表明对产品工作的重视，在团队中树立威信，以便开展后续的工作。
总结
我们在接手一个新系统的时候，前期及时做了这些工作，还后续的工作中还是会遇到困难，例如：
由于之前的历史没有参加，还是会遇到不清楚的问题，这个时候不要不懂装懂，大胆的去和团队沟通清楚。在前期还会遇到团队不信任的情况，他们会质疑你的需求，我们还是需要有理走天下。一开始不要轻易否定系统的功能，我们总是认为产品经理把系统当做孩子，其实从0到1参与的研发也是有这样的心态，不愿意轻易接收推翻现有系统。遇到这些问题，首先不要着急，前期大家是需要彼此磨合，平时一起吃饭，拉拢人心，顺便认识下这些人，尤其是技术骨干等核心，搞好关系。后面把自己的工作计划、想法发出来，多和领导沟通，获得领导和团队的支持，便于顺利开展工作。
