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

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

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

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

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

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

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

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

1. 好奇心，主動性。

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

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

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

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

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

3.一定要懂資料

一定要懂資料，一定要懂資料，一定要懂資料。

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

我理解的產品架構，對應《使用者體驗要素》中的「結構層」。

架構分2個層面，1是物理架構，2是邏輯架構，舉個例子，

比如一個樓盤，物理架構：樓盤→期→棟→單元→樓層→房號→房間

1邏輯架構：

2指示系統

3中央空調系統

4水電氣網路系統

5進水&排水系統

6監控系統

7房屋結構系統

……

產品也是這樣的，物理架構：頻道→頁面→模組→元素

邏輯架構：登入註冊系統、導航系統、搜尋系統……

所以，我認為產品架構能力就是指這2方面是否考慮周全並架構合理。