原创 产品已有架构迭代升级PM如何操作？

　　产品已有架构迭代升级如何操作？如果是一名刚跳槽或刚接手一个新的平台PM，怎么在KPI以及老板的期望下确定平台的架构？首先我们先理清核心问题、明确老系统阈值、在不确定性中寻找确定性等，集中主要精力解决其中的核心问题。

　　一、理清核心问题
　　针对接手的平台业务、系统以及架构，和多个部门以及团队充分沟通、多方采集、全方位梳理现有问题，进行归类，发现主要矛盾，集中主要精力解决其中几个核心问题。

　　二、明确老系统阈值
　　明确老系统阈值非常重要。平台系统作为支撑和赋能系统，如果当你刚接手一个新的平台且明确了系统最突出的问题之后，下一步就是基于原有的平台架构，明确老系统的最大性能。这一步骤是决定你后续的工作方向是基于原系统做升级还是重新规划新的架构系统。

　　打个比喻：用户（即业务方）都在使用Windows7系统（即老平台），且用户主观感受非常好（用户无法预知到未知事物或市面上没有的事物，且用户的KPI以及思考方向不在这块），但是Windows7系统（即平台）已经出现很多问题。
　　举个例子：系统可靠性为10（满分为100）（即步骤1中的核心问题），那么作为研发操作系统的人（即平台PM）你需要思考的是，基于windows7架构的系统可靠性的上限是多少？如果是50，那么50是否能够中长期的支撑业务端的需求？如果答案是可以，那么你的方向很大概率就是基于原有系统进行维护和更新，完善系统，以便于支撑业务方。
　　如果分析得出原系统Windows7架构的系统可靠性的上限是30，业务端年终目标需要平台的可靠性性能达到60，那么不言而喻，你的工作方向将会是设计一套新操作系统Windows10（即新的平台架构）。这套新的操作系统windows10的可靠性性能上限能到90，并以此方案和业务端以及其他部门进行讨论和宣贯。

　　三、在不确定性中寻找确定性
　　上面主要是摸清楚核心问题，以及采用什么思路去解决问题。最后一个关键点就是关于领导的不确定性，一般情况下领导没有很明确的指向，做A做B不做C。一般会有这样的描述：把平台这块做的智能化一些/把平台产品做的有价值一些。
　　这样的描述对于平台产品经理来说很多就是不确定性，无明确指向，那么如何在不确定性之间去寻找一定的确定性呢？相对来说，可以采取这样的方案：
　　1、定位核心问题
　　阐述核心问题以及问题带来的影响，确定领导是否认可自己分析的核心问题以及影响，如果确定，说明问题分析正确。
　　2.、明确领导方向
　　阐述老系统是否能够解决问题，以及如果解决问题后续能够持续进行支撑，或者新系统新平台的方案，确定领导认可以什么的思路来解决问题。
　　3、预期上线效果
　　提出基于自己的方案后期的预期效果，和领导确认预期结果是否ok。
　　4、拆解具体行动
　　问题和方案明确后，最后一步就是落地执行和制定KPI，对方案进行拆解落实任务。相信这块产品经理都信手拈来，不做过多阐述。

　　牢记做平台就是做操作系统，那么操作系统的迭代更新有什么特性？一种是老系统的不断打补丁，用于维护和更新，但无法解决系统瓶颈的问题；另一种是以一套全新一代的操作系统面世，性能、感观、体验全面提升一个档次提高一个等级。