平台产品经理如何正确的迭代升级已有架构

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

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

询问上篇提到的很多方法论，是不是更多适用于已经在这个平台打磨了很久，适合老手去推进事情；如果是一名刚跳槽或刚接手一个新的平台，如何在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。一般会有这样的描述：把平台这块做的智能化一些/把平台产品做的有价值一些。

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

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

1. 定位核心问题

阐述核心问题以及问题带来的影响，确定leader是否认可自己分析的核心问题以及影响，如果确定，说明问题分析正确。

2. 明确leader方向

阐述老系统是否能够解决问题，以及如果解决问题后续能够持续进行支撑，或者新系统新平台的方案，确定leader认可以什么的思路来解决问题。

3. 预期上线效果

提出基于自己的方案后期的预期效果，和leader确认预期结果是否ok。

4. 拆解具体行动

问题和方案明确后，最后一步就是落地执行和制定KPI，对方案进行拆解落实任务。相信这块产品经理都信手拈来，不做过多阐述。

牢记做平台就是做操作系统，那么操作系统的迭代更新有什么特性呢？

一种是老系统的不断打补丁，用于维护和更新，但无法解决系统瓶颈的问题 ；另 一种是以一套全新一代的操作系统面世，性能、感观、体验全面提升一个档次，当然天花板也提高一个level。

本文主要是针对面对一个老系统或刚接手一个新系统时，尤其是平台产品经理，如何以一种迭代性的思维去思考和处理问题。

当然，视野跨开了看，这种思维方式依然适用于其他产品经理，欢迎大家在评论区进行讨论。

 

作者：楠神，公众号《音波楠神》

本文由 @楠神 原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自 Pexels，基于 CC0 协议