[技能~產品]後端產品經理要懂的知識點

在前端，用戶完成簡單的商品瀏覽、商品選定、下單支付過程，就涉及到後端六個系統之間的交互。對於體量更大的公司，系統模塊只會更多。

這就要求產品經理不再侷限於前端的頁面層次，而是基於業務對整體後端系統有一個宏觀的認知，能區分各個系統的主功能，搭建一個好的產品架構。

2.2 性能需求

性能需求指定系統必須滿足的定時約束或容量約束，常包括速度（響應時間）、信息量速率、安全性等方面的需求。

比如，“支付系統必須在半分鐘內返回用戶支付狀態”就是一項性能需求。

2.3 可靠性需求

可靠性需求定量地指定系統的可靠性。

比如，“商品系統在一個月內不能出現2次以上故障”。

2.4 出錯處理需求

出錯處理需求說明系統對錯誤應該怎樣響應。

比如，“訂單取消後，用戶支付已取消訂單成功會怎樣”。

2.5 逆向需求

逆向需求說明系統不應該做什麼。

產品經理應該選取能澄清真實需求且可消除可能發生誤解的那些逆向需求。

2.6 將來可能提出的需求

應明確那些雖然不屬於當前系統開發範疇，但是據分析將來可能會提出的需求。

比如需求迭代、增加新功能等。

其目的是，對系統將來可能的擴充和修改做準備，以便日後確定需求時能比較容易地實現。

3. 好的系統是什麼樣子

模塊化：把程序劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一些類別相似的子功能。把這些模塊集成起來構成一個整體，可以完成指定的功能滿足用戶需求。

在章節2.1的流程圖裡，訂單系統、商品系統、運營系統等，都是相互獨立的模塊。

3.1 為什麼要系統模塊化？

首先來思考一個感性的認知，如果淘寶這麼大體量的電商系統，只有一個模塊，那麼一點小變動就會導致開發人員在海量代碼裡找尋相關的代碼，遺漏、錯誤的可能性很高，系統安全備受質疑。其次，如果團隊加入新的開發人員，他對系統代碼的熟悉成本也是巨大的。

再來一個理性的認識：

設函數 c（x）表示問題 x 的複雜度，函數 t（x）表示解決問題 x 需要的工作量（時間）

對於問題 x1 和 x2 ，

如果 c（x1）> c（x2），

則 t （x1）> t（x2）

根據人類解決一般問題的經驗，還有一個有趣的規律：

c（x1 + x2）> c（x1）+ c（x2）

則 t（x1 + x2）> t（x1）+ t（x2）

即是：由多個問題組成的問題的複雜度，大於分別考慮每個問題的複雜度之和。

則：解決集合問題的工作量比分別解決每個問題工作量之和更大。

這帶給我們的啟示是：

利用模塊化，可以將總功能拆解為一個個子集，提高系統的分工效率。

3.2 如何界定模塊的獨立程度？

首先，模塊的獨立性很重要：

• 基於有效的模塊化（即具有獨立性的模塊）的系統比較容易開發；
• 獨立的模塊比較容易測試和維護。

相對於不進行模塊化的系統，有效模塊化修改系統需要的工作量更小、錯誤傳播範圍更小，需要擴充時也能更容易地加入新模塊。

其次，界定模塊的獨立程度有兩個標準：

• 耦合
• 內聚

耦合：度量一個產品結構內不同模塊之間的互連程度。

耦合強弱取決於模塊間接口的複雜程度，進入或訪問一個模塊的點，以及通過接口的數據。

內聚：度量一個模塊內各個元素彼此結合的緊密程度。

比較理想的模塊化是：低耦合，高內聚。各個子系統便於開發和維護，提高整體分工效率。

4. 總結

後端產品經理一職，要求產品經理非常懂業務。對於系統架構、業務認知以及行業發展的前瞻性都要形成自己獨特的思考體系。

想要成為後端產品經理？

我認為主要是兩點：

（1）找準想要深耕的行業

電商、金融、B端產品等等，多體驗多思考，比如想從事電商行業可以去淘寶開一下店，體驗一下面向商家的系統；想從事金融行業，那麼基礎的金融知識肯定是必須的；實在不行，公司的CRM系統、OA系統也可以觀摩學習。

（2）積累一點技術基礎，提升邏輯思維

建議閱讀《計算機網絡》，對OSI模型有一個大體的認識，知道底層數據如何傳輸、計算機如何互連。像API、RPC這些名詞也要知道其作用是什麼。可以看看技術同事的開發文檔，基於單個功能的系統交互圖，不懂多問。

產品經理每天都很忙，沉迷工作是一個好事，但一定要騰出時間思考、學習和總結，長期的輸入才能帶來思維的提升。

最後，祝願我們都能成為優秀的產品經理，不忘初心、砥礪前行。

---

分享到:

---

閱讀更多 壹號職 的文章

關鍵字: 美好，一直在身邊 經理 支付

---