編輯導語：對于產品經理來說，如果剛剛接手了一個新平臺，應該如何正確的迭代升級已有的架構呢？本文作者分享了規劃平臺架構的幾個很重要的點，希望看后能夠對你有所啟發。

有幸得到認可，接上篇《平臺產品經理如何避免落為工具平臺》后，有很多小伙伴后臺私信我。

詢問上篇提到的很多方法論，是不是更多適用于已經在這個平臺打磨了很久，適合老手去推進事情；如果是一名剛跳槽或剛接手一個新的平臺，如何在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 協議