如何提升產品架構能力？

01-08

PM的能力有很多面，比如：設計能力、運營能力、規劃能力。唯獨產品架構能力是最難的，需要自身具備極強的專業能力以及行業經驗。各位產品大牛是如何提升自身的產品架構能力的？從全局上去設計產品的整體架構，規劃未來的發展道路以及整合整個產業鏈。

業務的熟悉程度，對PM來說是一個十分重要的指標。這也是為什麼PM會出現細分，如「電商產品經理」、「反垃圾產品經理」、「數據產品經理」、「廣告產品經理」等。

當一個產品經理跨行業換工作時，就需要快速了解這個行業。

例如電商中有SKU管理、品類編輯、訂單系統、對賬等，到海淘又有匯率、砍單、清關等等內容。而廣告行業，CPD、CPC、CPM、CPA，DSP、DMP這些都是什麼，如何運作。餐飲中，餐前、餐後、餐中營銷都是什麼，商家更在意引流、客單價、翻台率還是別的什麼。

這些東西都需要學習，書、博客、知乎、前輩、競品，都能提供很不錯的參考。

最後還需要實踐來趟坑。

當你熟悉了這個行業的種種，了解了自己公司在行業中是一個什麼位置，有大量標準系統的積累，自然而然產品架構能力就提升了。

目前比較通用的系統有：

賬戶系統，

訂單系統，

積分系統，

數據分析可視化系統，

反垃圾系統，

計費系統，

內容管理系統（標籤、SKU、品類、文章等）

第三方授權系統。

根據業務邏輯，把這些系統像組件一樣組裝再一起，就完成了產品架構。

結果，當你自信滿滿地完成了一套完美的產品架構時。

回過神來，又看了下手中幾個人的團隊，默默神傷，哈哈哈。

建立產品架構能力都是很難的事情，別說提升了。

具備產品架構能力，有個前提要具備足夠的權力。

貼一篇自己的文章部分：

瓊恩·啥都不懂·雪諾帶著不可理解的情緒倒在雪地上，儘管廣大觀影民眾對他的死亡紛紛表示不滿，這一場權利的遊戲里，無人能夠倖免。
產品其實同樣是一場「權力的遊戲」，小到一個地方的一句描述文案，大到整個產品的功能架構，系統里的每一個組件，都是人的決策結果，需要這個負責人位置的權力支持。
剛開始工作的PM，其實做的是產品設計師的工作，設計功能、設計策略是最常見最基礎的工作部分。這裡的「設計」不像交互、UI那樣是視覺化形態的結果呈現，而是整個產品架構中的功能組件、邏輯規則的制定。
大部分公司培養產品新人，都會賦予他們限定範圍內的權力，在整體產品中負責某一個方向或具體模塊，這種由部分到整體的介入模式，對產品發展而言是一種相對安全的形式，對產品新人也是一種常規有效的鍛煉方式。
但是隨著PM的成長，業務的發展，當PM負責範圍內的產品資源無法影響產品發展時，結果是做了很多版本、功能，用戶行為沒有變化，數據也沒有明顯改觀，這時PM會感覺到無力或迷惑，俗稱遇到「瓶頸」。
有點追求的PM，會自然延伸思考「權力」範圍外的問題，為什麼產品做不起來，是自己需求把握不準、抑或產品架構不合適、還是根本市場方向就不對...
當意識到自己無法決定產品生死層面的問題後，一些人會心灰意冷覺得「學不到東西」，萌生去意；另一些人會嘗試提出一些零散的業務、架構層面想法，與自己的上級或團隊溝通，試圖去「挑戰」更高權力職責的工作。
...

完整原文：做產品是"權力的遊戲"

最近也在思考產品架構這塊的東西，借這個題順便記錄下自己的一些想法。

首先我對「產品架構」的理解，就是在充分理解面向用戶的需求之後，從0開始設計完整產品體系方案，並將其實現的過程。這裡面包括一個產品形成的全過程，包括數據層的資料庫表、後台數據處理平台和運營維護平台、前後端數據交互體系，前端的基礎產品框架等一整套系統的構造和運轉邏輯。這也就是所謂一個產品可以誕生之前所需的「骨架」。當這套骨架完成後，大家熟知的前端功能、數據介面等等實體性質的產品開發才正式開始。

有兩點可以概括產品架構的特點：

1. 架構最大的特點在於，眼中沒有產品形態的概念，只有數據流轉的過程

產品架構的工作本質是在梳理數據流。如果梳理的順，那麼未來產品會做的非常順暢，用戶需要的功能可以快速實現，產品的穩定性也很高，同時可以有效支撐幾年甚至十幾年的業務發展。而界面只是對數據的窗口或者入口而已，那是未來各位前端產品經理或者後端產品經理考慮的事情。

2.需要深刻理解不同崗位的職責，以及他們工作的內容，也要深刻理解最終的用戶

簡單來說，如果開發、運營、產品、市場的目標都是打造好產品，那麼架構師需要考慮的就是如何讓這幫人打造出好產品。知乎經典問題「產品經理是否需要懂技術」，並不是需要產品懂寫代碼，而是理解技術對於實現需求時的優勢、劣勢、風險。同樣的對於運營、市場、銷售各個環節都是一樣的道理。

現在回到問題：如何提升架構能力？

產品架構與傳統產品經理以用戶為中心的基本精神雖然是相通的（只不過這裡的用戶不再是公司產品的用戶，而是公司內部的運維團隊、產品團隊甚至是技術團隊），只不過因為系統的複雜程度和擴展性要求，比起做一個支付流程、做一個評論功能來說大得多，所以一般的產品經理很難有機會接觸到。除了產品經理的常規能力要求外，還有幾個重點感悟想單獨拿出來說說：

1. 好奇心，主動性。

比如負責做註冊的，至少可以接觸到註冊的數據存到了哪裡，怎麼入庫的，中間經過了哪些技術實現環節，增刪改查可能會有什麼場景，未來其他部門或功能哪裡會用到用戶信息，一般會有哪些使用維度等等。這是一個相對完整的數據流程了。理解數據流程後，再進一步思考業務發展點，比如未來運營部門可能會用到這部分數據做用戶運營，比如會有精準的運營內容推送，就涉及到數據關聯，那麼用戶數據這塊他們如何調用可以最高效合理。帶著類似的問題去和相應的開發或運營部門去溝通，不經意間也許就可以蹦出啥火星子來，領導覺得考慮沒準就讓你去牽頭搞了。。。

不關心？那除了每個月的工資其他都和你沒啥關係了。。。

不主動，上哪兒知道這些東西去。。。

2. 對於養成考慮極端情況的習慣。

現在的產品經理設計功能的時候，都是正向思維，正常場景下沒有問題，但是對於一些極端情況很少考慮。這也是開發讓產品懂技術的一個主要原因。int不能為空值，最大數量上限多少，主鍵這些基本的概念如果產品懂一點的話，未來產品的穩定性可以大大增強，需求返工的概率也大大降低。而這些細節往往是資料庫架構、介面規則制定時必須要考慮的。

3.一定要懂數據

一定要懂數據，一定要懂數據，一定要懂數據。

只要能把一個產品還原回一個動態的數據形態和流轉過程，就可以去架構師的副本去練級了。

1、如果產品項目面向的是新商業/業務領域，建造過程才會涉及一個較為完整的周期：架構-設計-建造-運營。

2、現實中產品領域的從業人員大部分都對應後面三個工作領域。從0-1的參與機會有多稀缺，我想是不用解釋的。

所以，提升產品架構能力的第一個前置條件是：在一個開闢性的產品項目里擔任早期核心決策角色。

得到這個機會後，為了解決項目早期的問題，除了傳統的產品研發能力外，自然會要求你去解決項目面向的問題定義、邊界的確定、業務架構設計、要素規劃、開發模式設計、設計原則設計等等對抽象思維能力要求較高的工作項目。。。

需要提升這面能力的人=已經獲得稀缺機會的人，要麼是大公司的項目，公司裡面應該有牛人帶吧，跟著牛人學；要麼是自己創業的，圍繞實際問題干中學吧。

所謂架構，概而言之，分為幾個層次：

1、概念階段：需要利益干係人達成一致的草圖，可以簡單勾勒，但必須達成共識；

2、業務架構：詳細的需求分析文檔（流程、頁面、規則），原型，場景故事等

3、應用架構：系統、模塊、功能、以及之間的關係

4、數據架構：。。。。。。。

1.抽象建模的能力。

2.分清楚「真正的需求」和「實現需求的具體方式」這兩者的區別。

3.有空再更，先睡覺-_-!

產品架構：

1.從宏觀上，要看到行業的發展情況和可以預見的趨勢，如果能夠前瞻5-10年，可能是非常好的產品架構了，很多頂尖人數屬於這一個層面的。（如：比爾蓋茨，30多年前，讓每個人的桌子上面有一個電腦，馬雲15年前，預見電商。馬化騰，應該不算層面上的，他只是見步走布，一路走到路上）。

2.產品層面的。

2.1 要搞清楚產品的目標，為什麼人服務，解決哪些人的問題。

是解決剛需的，沒有很不爽的問題，沒有會死的問題，而不是一大堆偽需求和功能堆疊。

這個層面上，QQ，微信，是順應時代很好的例子，解決網上交流的需要，讓人人交流更加方便。

沒有的話，大家還是Email，電話。

2.2產品的生命周期，什麼階段的產品，怎麼規劃。初創階段，拉升階段，還是成熟階段，還是留存階段，這個時候可以用指標來算（活躍度，ROI，留存率，每個用戶的收益，等等指標量化）。

2.3 產品的業務架構，實現產品階段目標的功能點和流程，原型。入門產品經理必備。

當然對於不同的產品階段有不同的對策，如初期是驗證可行性，中後期是數據運營管理。

沒有驗證的產品，一大堆想當然的偽需求，促進了整個行業的程序員就業。

去架構產品

永遠在腦海里構思產品下個一個形態，你會得到各種不同的想法，再將這些想法由抽象不斷具象，不斷的排除和優化，你會做出出色的產品架構

架構是業務的映射。

不遺餘力地提升業務能力。