编辑导语：对于产品经理来说，如果刚刚接手了一个新平台，应该如何正确的迭代升级已有的架构呢？本文作者分享了规划平台架构的几个很重要的点，希望看后能够对你有所启发。

有幸得到认可，接上篇《平台产品经理如何避免落为工具平台》后，有很多小伙伴后台私信我。

询问上篇提到的很多方法论，是不是更多适用于已经在这个平台打磨了很久，适合老手去推进事情；如果是一名刚跳槽或刚接手一个新的平台，如何在KPI以及老板的期望下尽快确定平台的架构？

这个问题非常nice，也反向逼着我去思考我的上篇文章的前提条件，确实很适合去打磨自己手里的平台；如果是刚刚接手新的平台，有几个很重要的点去规划平台架构，愿分享以抛砖。

一、理清核心问题

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

聚焦主要精力解决其中几个核心问题（PS：附图为我最近针对手头的系统进行问题收集以及收敛问题定位聚焦的excel，已模糊关键信息，仅供大家参考）：

二、明确老系统阈值

这一点非常重要。

平台系统作为支撑和赋能系统，如果当你刚接手一个新的平台且明确了系统最突出的问题之后，下一步就是基于原有的平台架构，明确老系统的**性能。

这一步骤是决定你后续的工作方向是基于原系统做升级还是重新规划新的架构系统。

ok，这段稍微比较绕，打个比喻：

用户（即业务方）都在使用Windows7系统（即老平台），且用户主观感受非常好（用户无法预知到未知事物或市面上没有的事物，且用户的KPI以及思考方向不在这块），但是Windows7系统（即平台）已经出现很多问题。

举个例子：系统可靠性为10（满分为100）（即步骤1中的核心问题），那么作为研发操作系统的人（即平台PM）你需要思考的是，基于windows7架构的系统可靠性的上限是多少？

如果是50，那么50是否能够中长期的支撑业务端的需求？

如果答案是可以，那么你的方向很大概率就是基于原有系统进行维护和更新，完善系统，以便于支撑业务方。

如果分析得出原系统Windows7架构的系统可靠性的上限是30，业务端年终目标需要平台的可靠性性能达到60，那么不言而喻，你的工作方向将会是设计一套新操作系统Windows10（即新的平台架构）。

这套新的操作系统windows10的可靠性性能上限能到90，并以此方案和业务端以及其他部门进行讨论和宣贯。

三、在不确定性中寻找确定性

上面两点主要是摸清楚核心问题，以及采用什么思路去解决问题。

**一个关键点就是关于leader的不确定性，一般情况下，Leader没有很明确的指向，做A做B不做C。一般会有这样的描述：把平台这块做的智能化一些/把平台产品做的有价值一些。

这样的描述对于平台产品经理来说很多就是不确定性，无明确指向，那么如何在不确定性之间去寻找一定的确定性呢？

相对来说，可以采取这样的方案：