如何快速接手一个新系统

背景回顾

受今年疫情影响,公司之前负责××产品的人员准备离职了,然后领导安排你来与他做工作交接,后面产品的工作就交给你来负责了。系统的地址和资料某某一会发给你,可以去看看。

那么产品经理如何交接工作,尽量最大程度的接收信息,以便快速接手一个新系统?

此时,我们可以撸起袖子就开干么?此时我们面对的是一个全新的系统,在还没有了解这个系统的情况下,很难安排后面的工作计划。在正式开展工作之前,我们还需要做一些准备工作来迎接这个新系统。

如何接手一个新系统

做产品经理,时刻要有主人翁心态,即使是接手一个现有的系统,也不要等着别人来带领我们,记住是产品经理带领他们做产品。

此时,你需要列一份交接清单,需要经过以下5步阶段,来全面需要了解系统。

内容包括:背景了解、系统资料、经办工作,其他需交接事宜,每项需注明具体交接内容及说明。

主动了解系统的建设背景、干系人,获取系统资料信息。基于现有资料,进行结构化梳理,从产品经理角度还原产品全貌。经办工作:需要对产品情况进一步摸底,包括项目衔接,未完事宜等。了解目前进展,了解现在存在的问题及历史未解决的问题。其他需交接事宜:产品工作流程,接了新系统,需要了解该系统的发布流程,团队日程工作等情况。前面做了这些功课之后,我们就可以正式接手产品后续的工作了。

 

 

1. 主动了解系统情况

我们可以通过系统的背景、涉及到的干系人、目前的建设工作3个方面建立对系统的认知,整体掌握系统情况

 

 

 

 

 

(1)背景了解

由于这个系统已经存在了,我们在接手一个新系统的时候,往往还不了解这个系统的建设背景、设计思路,现在既然要接手了,就得了解他的过去,才能决定他的未来!

首先系统了解这个系统的建设背景:站在公司的角度,为啥公司要做这个项目,业务核心是什么,最大的盈利点是什么;如果是工具类,就站在用户的角度,用户最想解决什么。

比如之前接手TMS同类题管理平台,这个平台已经使用多年。刚看到这个系统的时候,发现系统非常的臃肿,逻辑耦合性强。第一反应就是这个系统如果继续维护,那么研发和测试的代价很高。但是如果把这个系统全部重构,成本也是非常大的。后来去调研了这个系统的建设背景,发现里面有2条业务线,一个是同类题资源的管理,另一个是锚题资源的管理。锚题资源的管理,目前已经很少使用了,只是给之前的老客户提供支撑。最后我们决定把同类题资源的管理,单独剥离出来进行维护。而锚题资源就在老系统中使用。

新来的产品经理要对每一个老产品抱有敬畏之心。老的版本不管你觉得多不合理,都有他存在的理由。

可以找该项目涉及到的部门负责人进行讨论和请教,从头到尾全面了解业务,请教时可以选择去公司附近的咖啡店请对方喝咖啡。从心理学角度来说,让对方会觉得吃人嘴短,会和你说更多内容且容易较有耐心,或者在请教后请对方喝咖啡或请吃饭。刚来公司没多久同时也能通过这种方式搞好同事关系,让自己迅速融入团队中。

(2)干系人信息

我们需要了解这个系统涉及到的干系人,比如这个系统的上层负责人是谁,需求对接人是谁,研发团队是谁,客户或者用户是谁等。

了解他们对在这个系统的参与角色之后,是希望当我们遇到问题后,能找到合适解决这个问题的人,这个人可能是你的领导,但更多应该是和你合作的各部门相关业务负责人。

例如:由于系统功能已经建设完了,若需要了解历史需求情况,但是目前只接触到了研发和测试,如果一味的去找研发和测试进行沟通,一方面他们是从系统功能角度去思考,而不是用户需要方面出发,可能会误导产品的思考。尤其是你想推翻之前的功能,这会让研发和测试觉得否定以前的工作重新带来任务量,由于信息都是他们提供的,他们会过多的干涉,会让团队质疑你的需求以及能力。

产品经理是需要多人协作的角色,所以理清新公司的组织架构能帮我们迅速开展工作。例如:

这个系统的上级负责人,有的是项目经理。各部门的职责、权利、分工.部门成员、部门Leader都是谁,坐在哪儿。自己部门和其他部门的交叉合作关系、合作方式、合作流程都是什么。务必让自己的Leader带自己去认识一圈,先混个脸熟,尤其是会有紧密合作的技术、设计、测试、运营部门同学,以后好办事。

 

 

(3)系统资料

最后就是需要拿到系统的资料信息,例如需求文档、用户手册、设计文档等,有些项目还有合同、招投标文件信息,当然还需要新系统的体验地址和账号信息。

通过第一步的系统情况了解,我们需要明确系统的方向:针对这个现有的系统,领导的态度是希望重构这个系统,还是保留系统,让产品跟进后面的需求继续开展工作。

2. 基于现有资料和旧系统,还原产品全貌

有需求文档:

通过前面收集到的资料信息,如果过去有比较完备成体系的产品文档,那么我们可以快速从这些资料进行梳理,了解产品的定位,解决了用户哪些问题,客户群定位等,获得我们想要的信息。

如何系统的收集的资料比较多,不是需要我们把所有资料都看完,需要分个优先级了解,不要过早陷入到系统的细节情况。

没有需求文档:

如果没有资料,我们可以通过直接使用系统,把旧产品已实现的功能结构和核心逻辑全部理出来,整理成一个产品体验报告文档,跟原本最了解这个产品的人们(研发/测试)对一遍,纠正有偏差的部分。

在这个阶段,我们需要了解这个系统的目标用户、核心业务、系统功能。这是需要花费大量时间精力的事情,要带着极大的热情和求知欲去做,了解产品的前世今生,了解竞品做到了什么程度,学习产品相关行业的基础知识……

这是我曾经针对一个新系统《AI标客》做的产品体验报告。左侧是文章的目录结构,对系统从战略层、范围层、结构层、框架层、表现层进行体验分析。

在这个过程中,肯定是有一些疑问的,我们可以把问题归纳整理,然后再找相关人员进行沟通答疑。讨论请教完毕后,需要自己进行复盘,可以在自己已理解的基础上画出业务流程图,一方面帮助自己理清整个业务的来龙去脉,一方面,当业务流程图画完可以找同事确认,以免产生自己理解错误。

3. 产品情况摸底

找别人的错,总是要容易些;理解别人的套路,总是费点神。

我们在接手这个系统之前,还需要深入摸底产品情况:

核心功能完成度:是否现有的需求已经包含了全部核心功能?如果包含,实现进度是否可控?如果不包含,是否还可以调整需求?了解目前的系统细节:系统的里程碑计划、关键时间节点、现在的进度、问题都是啥?过去遇到过的问题及原因、解决方案,对于常见的问题重点说明。平时工作中的一些事项,比如项目进度的控制,最有可能耽误在哪环节;项目优先级的制定;接口的设计人员、开发人员的情况,能力强弱;。风险:有哪些坑。,出多少,取决于你在短期内与大家熟悉和建立信任的本事,也取决于你对业务理解的能力。深入细节了解,经过了解到上面的信息之后,基本大的逻辑就会比较清晰,剩下一堆细节的逻辑,很难一次性全部了解全。即使了解全,真正用的时候也比较容易遗忘,更好的办法是做一块的功能,细化了解一块细的逻辑。

毕竟历史前人留下的隐藏逻辑很多,如果开发还是之前的还容易些,如果开发也全部换了,就大家一起补逻辑,留好产品文档和技术文档,以便自己后续查阅以及下一任来查阅;

4. 产品工作要求

在新的公司做产品,需要关注产品的工作流程。

权限申请申请:

项目管理软件,比如SVN、teambition项目管理软件的权限申请和加入。

原型和文档规范:

可以参考前辈的工作流程,PRD格式、原型设计规范,比如PRD格式目前是用的word、excel、还是原型中直接标注。在开始阶段,我们先复用,不要马上用自己之前的格式!先模仿,适应公司再创新,让大家接收新的方式!

产品发布流程:

产品工作环境中,需要了解一些上线流程、紧急流程、会议流程等等“潜规则”。系统版本发布之后,是否需要邮件通知。尤其是客户所在的QQ群和微信群,版本发布之后,需要通知给哪些人员。

团队日程会议:

了解团队的成员,系统的需求提出非、研发负责人、测试人员、运营人员等等。参与团队的每日站会和周会,了解当前的状态和进度是什么情况,当前负责的日常工作,以及对应的具体要求,比如定期举行的会议、每月更新的报告等等。

5. 正式接手产品

稍微成熟一点的产品人首先在自我要求上会是产品输出导向,而非进度导向的。换言之,会花比较长时间去了解、再认识产品,调查业务瓶颈,查看用户反馈,摸清企业战略和产品的生命周期到了哪一阶段,再针对产品出现的问题,分清哪些是产品本身问题,哪些是技术问题,哪些是业务问题。

我们把前面的工作完成之后,可以把召集相关人员(老板、技术负责人、运营负责人等),一起讨论,互相纠正,达成共识。这个也是向领导和团队,表明对产品工作的重视,在团队中树立威信,以便开展后续的工作。

总结

我们在接手一个新系统的时候,前期及时做了这些工作,还后续的工作中还是会遇到困难,例如:

由于之前的历史没有参加,还是会遇到不清楚的问题,这个时候不要不懂装懂,大胆的去和团队沟通清楚。在前期还会遇到团队不信任的情况,他们会质疑你的需求,我们还是需要有理走天下。一开始不要轻易否定系统的功能,我们总是认为产品经理把系统当做孩子,其实从0到1参与的研发也是有这样的心态,不愿意轻易接收推翻现有系统。遇到这些问题,首先不要着急,前期大家是需要彼此磨合,平时一起吃饭,拉拢人心,顺便认识下这些人,尤其是技术骨干等核心,搞好关系。后面把自己的工作计划、想法发出来,多和领导沟通,获得领导和团队的支持,便于顺利开展工作。

posted @ 2020-04-01 17:13  Nina  阅读(640)  评论(0编辑  收藏  举报