PM如何擁有產品架構能力？

01-08

參見： http://weibo.com/1134424202/ymaUOn0uX 應該掌握哪些知識？

架構是業務的映射，在架構之前，你需要理解你的業務。

之前回答了這個問題：什麼叫做產品架構？這裡再修改一下。

總覺得用「生態」一詞概況產品架構，強調要多實踐、要做個多少年等等把產品架構說得太玄乎了，產品架構應該且必須是可以方法化、技巧化。

所謂架構，就是對架構的對象進行合理的抽象，其結果是讓架構的對象更高效、更簡單、更易用、更易變。簡單說，架構就是為了：簡單、高效。

架構不是完美存在的結果，是一個不斷改進優化的過程。但是在每個節點上，都有好壞多少之分，這也是架構能力的體現。

產品架構的對象就是產品的商業需求以及用戶需求。如何讓滿足產品兩個需求的產品設計更加簡單、高效的規劃就是產品的架構。這裡有兩個重要的目標：1、滿足需求高效簡單；2、產品設計過程高效簡單。

產品的架構需要考慮的是與產品相關的各種影響因素，包括：用戶需求、產品戰略/商業需求、開發資源、市場運營人員等。這些因素都是在不斷變化的，一個合理的架構是要爭取儘可能能夠採用最簡單的方式去應對這些變化。

而細分開來，產品架構應該包括兩個重要方面，即：需求架構和設計架構。需求架構更多的是業務架構，即把用戶需求、商業需求、業務流程在產品層面做個合理的組織和輕重緩急的設計。這也是產品架構最主要的事情。而設計架構，則是在產品設計時，保證產品在設計層面的通用和可重用的元素一致，是個更細節的層面，提高設計效率。

上面可能有點概念化，這裡舉個例子：

新浪微博的Page化戰略，在產品層面，就是一個架構的設計過程：將人、機構、興趣、地點等事物都對象化成Page，並且將Page的關係梳理成贊、關注、訂閱三種關係。在這種產品架構下，如果要把微博上用戶正在看的書的信息整合，那就很簡單：書的Page；如果要把用戶對於「產品架構」這個話題的信息整合，那就是：」產品架構「的Page……很簡單的實現了以不變應萬變！

這樣的一種架構，所帶來的好處是：圍繞微博的生態不再是之前搞的那些微群、微吧、微刊、話題等這些完全脫離微博的另外一個孤立的產品，而是現在的一個一個Page類型。這樣滿足用戶、商業需求更簡單了、產品設計也更簡單了，這就是產品的生態：不是把孤立的產品鏈接起來，而是通過產品架構組織起來。這種簡單帶來的高效就更不用說了。

當然這不是說微博的Page化的產品設計做到上述的架構就完成了，而是要在上述大架構的基礎上，去細化一個個細的架構，比如：Page的要素有哪些，Page的產品形態有哪些，這都是進一步的抽象，也是更進一步的架構。

同樣的分析，在豆瓣的產品上，也是一樣的：小組 + 單頁面的讀書、電影、同城……

奧卡姆剃鬚刀法則同樣在產品架構設計中適用，越簡單的架構越有利於產品的生長。

其實產品架構和技術架構沒啥區別，只是架構的對象不同而已：前者架構需求和設計，後者架構硬體、軟體和數據。產品架構做得好，會有利於技術架構，同樣也就提高了開發的效率。產品架構和技術架構如何協調、配合這個就是另外一個話題了。

我一直希望在產品經理這塊相關的能力能夠具體化，別再是那些什麼邏輯能力、溝通能力、文檔能力、學習能力等等這些放在什麼崗位都或多或少的需要的抽象能力。所以對於「如何擁有產品架構能力」這個問題，個人覺得可操作的方法是：

1、系統地學習信息系統分析的方法和技巧。這可以培養抽象化能力，同時理解業務流程、產品設計、系統開發三者之間的關係。有相應的教材，是某些專業必修的一門課。

2、產品調研中，將產品架構作為一個單獨的部分調研。現在很多產品調研報告中，只是從產品現狀、功能點、產品形態等方面去調研，忽略了產品架構的調研和分析。這也是很多產品只能抄個表面，抄不到本質的一個原因。沒有分析透產品架構，很難去理解一個產品的內在業務邏輯。

3、任何時候，要注意產品架構來自於需求，杜絕過度化架構，簡單的才是好的。

個人理解PM的架構能力應該是一種能夠迅速的將業務邏輯轉化為產品邏輯，將抽象的事物具象化的能力。與技術上的架構完全無關。

PM需要能夠在了解需求的業務邏輯之後，在自己的腦海中清晰的構造出產品的樣子。對產品整體有一個準確的把握，知道這個產品的突破點在哪裡，難點在哪裡。

雖然我還沒上到架構師上流的title上，不過也作為PM說說自己的理解吧，上面諸位感覺各種技術流呀~感覺不太對，其實產品架構嘛，其實就像搭建一座樓一樣，需要哪些組成部分，各方面需要投入多少注意什麼，才能保證這個樓的穩固，這個我想和技術架構的思路是一樣的，但是內容卻基本不同。

所以如果要有產品架構的能力，就得站高，你眼中看到的不是一個表單，不是一次交互，不是一個功能，而是你要達到一個目標，你需要的整個的產品循環。比如你要搭建一套UGC平台，為了能夠運轉起來，你需要用戶進入模塊，包括什麼歡迎頁面、登錄註冊甚至邀請流程，需要有新手引導等等，你需要有發布內容流程，這個就會細到各種交互表達設計等待的，然後內容組織，用分類還是標籤還是純基於人這個節點什麼的，然後瀏覽發現利用的流程，比如搜索呀，推薦呀，廣場呀按照需求考慮用什麼，然後用戶激勵需要貫穿，比如用什麼方式讓用戶交互起來，用什麼方式來表達用戶的貢獻，操作、消息是否通暢什麼的~可能還需要考慮反作弊模塊，數據挖掘的模塊等等，根據需求來吧~

上面所說可以架構一個產品的主要模塊，但是還不夠，產品需要有血有肉還得和運營配合起來，那又大了，內容和用戶的控制模塊，對外輸出內容引入用戶的渠道等等。形成一幅更完善的產品圖譜，這樣就能知道哪些模塊互相影響，哪些地方出問題了，哪些地方是短板，哪些地方不足影響了最終的產品目標等等。這是我理解的產品結構。

最後回答問題，如何擁有，蓋樓先得有根基，所以從小處學起功能是必要的，然後再慢慢站高一點，看到一個方向，一個產品，一個行業，一個生態鏈，然後去根據目標不斷地調整產品的模塊，以保證這台機器的持續運轉，這棟樓的根基穩固。

產品架構的好壞-

首先第一個問題就是你做的是class還是instance的問題

這更多是一種意識。如果做的是個instance那肯定毫無架構意識的做法，

這點要對需求和整體的結構有很好的理解，需求方總是無序的提一堆功能點，

PM需要很好的格局和產品結構理解然後把有機的類子系統的概念把需求整合。

大致目的是做成class，一勞永逸，此類instance需求都從這個口子進和出。

實例比如我們最近剛做的一個「排行榜需求」，業務方的要求是要新增收入為演算法的排行榜。

我們最後的結果是我們在已有的以點擊數維度的「暢銷榜」（特意使用抽象的名稱）修改演算法，增加收入維度的權重。而不是業務方提一個維度就上一個新榜單。

然後的問題是你的class怎麼做的好

這點需要一定的技術理解能力，對產品本身的架構和業務很好的理解怎麼區分哪些需求該怎麼設計，這需要有一些技術能力的理解，需要了解數據基礎層的結構，然後設計應用層的功能點。實際工作中會存在多點需求多種方式，就需要判斷能力。

這點的判斷基本上的原則是

首先要跟著產品的定位和戰略要求清楚結構以便建設日後更好的支撐能力，

第二保證pm理解的耦合度，現在流行的設計包括騰訊的插件方式，其實也是產品架構

的良好極致表現。任何上下某功能不會影響到最基本的功能。

問題中提到的所謂架構，在業務層面看來，無非就是歸類、整合、統一、靈活運用。

從技術上對應，就是面向對象的繼承、封裝、多態。

面向對象的思想從來就不是一種軟體開發思想，他完全可以用來指導我們在生活中思考問題的方式。

就好比我們的支付系統，每天會有各式各樣不同銀行渠道處理的交易，有各式各樣商戶的訂單，有各式各樣的異常，如果我們每個銀行渠道、每個商戶、每個異常都單獨處理，那排列組合下來，這個數字太嚇人了。

產品經理要做的是，把這些業務元素，歸集，統一。

好比商戶提交的訂單信息，無非就是包含了訂單號、訂單金額、時間、訂單備註、需要支付的銀行、手續費由誰支付、交易狀態等等信息，我們把這些信息整合，明確必填項和非必填項，統一稱為訂單。（架構師會建立模型，在代碼層面應當就有一個類，這些元素就是類的屬性）

那麼訂單他會遇到交易失敗，申請退款等各種業務邏輯，這些邏輯由產品經理明確，由架構師將其整合，在類中增加了它對應的方法。

對於某些特殊訂單，他既有普通訂單的特性，又有自己獨特的業務邏輯，那麼產品經理會把共性和特性描述清楚，架構師會做繼承。

總而言之，產品經理並不是一個將技術實現方案告知研發工程師的職位。實際上產品經理並不對產品的技術實現架構負責。產品經理只要能把業務邏輯描述清楚，告知技術，雙方無歧義即可。

有架構設計能力的產品經理固然好，但這個能力實際上並非必須，甚至有時候還添亂（專業的人做專業的事情）。

過於專註如何交付技術的同學，實際上還是產品設計者，並不是統籌產品的人。

當你開始考慮你產品未來的走向，開始考慮盈利模式，開始思考競爭對手的策略時，你才算開始對自己的產品進行管理。

最後：好的架構師很重要。

我覺得純銀這個架構能力指的是設計出一個嶄新的產品的能力，在這個產品的結構功能細節等等具體的地方給出自己的解決方案的能力

pm所謂的架構，顯然不是技術架構。

但架構的思想可以觸類旁通。結合手頭資源，整合外部資源，設計流程，平衡好各環節，避免出現業務能力瓶頸，最後當然是商業模式設計好，跟產品之間不斷磨合。

如果我理解的這個概念正確，鍛煉這種能力最重要的還是經驗。所以在大公司里當一個環節的專家也很難有這樣的宏觀經驗的，要麼能做到事業部老總級別。最好還是創業中鍛煉。

謝邀。PM 如何擁有產品架構能力？任何「XX 如何擁有 XX 能力的問題」，回答起來都是同一句話：「無它，唯手熟耳。」PM 如何擁有產品架構能力？當然就是練習，練習，再練習，練習得多了，自然就有產品架構能力了。

可是，問題在於，PM 為什麼必須擁有產品架構能力？PM 的知識面廣也許是件好事，譬如擁有交互設計知識啊、擁有軟體開發知識啊，擁有產品架構能力啊……對於工作，也許可以帶來一定的幫助，但這些都不是必須的。PM 最需要具備的是 PM 的能力，而不是別的什麼。

PM 能力是什麼？我個人認為，PM 最重要的能力是樹立「我要把這個產品做出來」的決心，注意，是「我」把產品「做出來」，不是領導把產品做出來，不是開發人員把產品做出來，不是設計師把產品做出來，而是「我」，PM，把產品做出來。

如果一個 PM 不能堅信產品是「我」做出來的話，是不可能把產品做好的，既然是別人做的產品，你只是去幫忙，那很多時候當別人的看法和你有衝突的時候，你就做不到去堅持，當遇到各種困難和阻力的時候，你也做不到竭盡全力去爭取各種資源，努力創造條件。

記住，產品是「我」做的，但「我」需要別人的幫助：如果「我」不懂架構，就去找懂架構的人幫忙；如果「我」不懂設計，就去找懂設計的人幫忙；如果「我」不會開發，就去找懂開發的人幫忙；如果「我」不會測試，就去找懂測試的人幫忙……但不管怎麼樣，這個產品是「我」在做，「我」要為它竭盡全力，別人都是來幫忙的，因此「我」要努力為別人創造更好的工作條件，盡量讓每個來幫忙的人都能少為自己本職工作之外的事情操心，少為各種雜事分心。

本回答答非所問，但希望對於提問者不是沒有幫助。

1.先界定產品架構：在給定的產品定位和市場環境之下，求最大化實現產品目標的產品結構設計。

如，在博客流行、社交網路逐漸火熱的環境下，我們要創造一款想要更加流行於大眾的、具有社交性的內容發布產品。如何架構？你可能想或許應該打破長篇大論的內容習慣、打破雙向關係的關係機制、增加傳播效率的機制。最後你可能就設計出了twitter。

2.如何擁有產品架構能力？

分析現有主流產品的架構，思考其優缺點
總結產品架構的基本原理，融會貫通
練習原創架構各方向的產品，找機會實踐檢驗並從中學習

資料庫結構

網站架構

uml

產品的大局觀，要對產品的每個功能的細節了如指掌，對產品本身和其他產品的互通深入深入了解。除了對產品本身外，對產品可能出現的擴展做中長期的規劃

分析整理能力一定要強

個人感受到的一些方法

1、PM是從技術出身，做過技術多年，然後轉作產品；這個時候結合業務的思考，可以具備架構能力；

2、PM是純粹業務出身，做過業務多年，典型是發散性思維，要具備架構能力，可以逐步從「如何把想法實現，更好的實現」的角度考慮下從「想到」到「做出」的步驟。

純粹做業務，也是非常關鍵的，如果有時間PM可以把精力集中在業務領域上的歸納和規劃吧，把架構和項目的開發給更擅長的人做個人覺得更合適。

打好地基

產品王道：一生二，二生三，三生無窮。

其實產品最重要的是簡單，然後是規則。規則可以把簡單的東西組全成複雜的世界。互聯網即是如此。舉例：互相指向的網頁本來是簡單的。但因此構成了互聯網的世界。

再舉例：象棋是簡單的，只有32個棋子。但有了規則之後，就衍變出無限的棋局來。

最後一個例子：twitter是極其簡單的。140個字，再加上收聽，關注、@等等幾個簡單的規則。但創造了創業的新神話。

當然，一個產品本質的東西得保證。比如說常說的：產品需求大不大；還有產品第一要義是滿足需求！再次才是我說的：簡單，通過簡單創造複雜！

PM我理解有兩種：產品管理，負責規劃；項目管理，負責項目交付。

作為產品管理，產品架構應該關注於（1）解決方案架構或者說是產品組合架構；（2）產品和對手的對應關係；（3）商業架構。

其擁有架構的能力是通過戰略管理、規劃中學習和提升，通過市場和客戶反饋矯正。

作為項目管理，產品架構應該關注於（1）產品軟/硬/文檔的架構；（2）產品系統/模塊的靜態架構，以及動態運行的架構。非軟硬體類產品，關注於產品的組成結構。

其擁有架構的能力是通過需求分析、設計中學習和提升，通過發布後客戶、市場的評價反饋矯正。通過產品下一步開發的障礙矯正。

產品架構是什麼：

從商業邏輯》產品邏輯》系統邏輯看它是嫁接商業（業務）和技術之間的橋樑。

雖然有架構一詞，但絕不等同於系統架構方面的知識領域，

需要宏觀到商業的眼光，也需要有面向對象的結構化思路，

但更需要的是儒道釋和自然科學，需要至少10年左右的多角度工作經驗領悟

架構師關注的是整體流態、關鍵節點和活性.....

PM是說項目管理的意思嗎？

很有趣的問題，先說什麼才是我理解的產品架構，我主要從產品、技術、運營、市場、管理幾方面去講，當然我是站在產品人員的角度來說這個問題。

產品：

從長遠規劃來看，產品的戰略定位如何？最終是需要達到什麼要的目標？產品定位問題，互聯網產品基本都不會是一次成型，都是分多次，把產品且分為多個階段，去實現原先的產品目標。而每個階段都是一個相對較為完整的產品，且有階段目標，階段目標是特定的目的。所以，從產品角度來講，需要知道整個產品的定位和戰略目標。清晰的知道如何通過一個個產品升級和迭代達到或者接近那個目標。做到這一步需要近可能的成為那個戰略定為者，或者通過某種方式了解戰略定位。當這個產品定位深深的印在腦海里的時候扔掉它，專心的把階段目標完成。這樣你才能知道產品為什麼這樣做，以後要做成什麼樣。

技術：

很遺憾，依然按照產品的角度來講，和技術相關的是產品的開發周期，這個會影響到產品實施周期以及後續的迭代或者重構甚至返工的事情。因為產品畢竟是技術執行的。對產品整體規劃的不了解，只知道階段計劃會導致技術的靈活性和擴展性不足，嚴重影響實施進度。所以需要從產品戰略角度了解產品目標，制訂可實施的擴展介面，讓代碼更容易向下個階段擴展，同時能保證當前階段的實施進度。這點很難，說早一點是因為產品階段目標有可能和整體目標稍有矛盾。因為運營策略。所以技術更需要做到如何在少量核心代碼改動，添加部分代碼的情況下完成系統升級和迭代。這個很難，很多人都努力想做到這一點。

運營：

產品的實施上線計劃階段目標一定是帶有運營目標的，也就是產品每個階段都有相對應的運營方案和策略。產品是否當前階段面向最終用戶，種子用戶是誰？當前產品是否適合當前用戶使用？是否有助於當前階段用戶提升？是否有助於品牌形象提升？等等，而運營策略會再某些方面影響到產品的階段規劃，從而影響到技術。所以，需要了解運營策略。

市場：

當前產品進入市場是否合適？市場反饋如何？用戶不喜歡？改唄。市場低迷？轉型唄。看到沒有，直接影響到產品的階段目標甚至戰略目標轉移。所以關了解產品的階段目標沒用，了解最終目標也沒有。還知道根據市場進行快速反映？如何做到？看你對市場的理解和了解程度。通常需要靠時間去熬出感覺。

管理：

怎麼還有管理的事？當然，產品構架的決定性因素是你的產品團隊執行能力，是否做好了對應的技術準備？是否對當前的產品有極大的興趣。得了解，得準備。根據你團隊的情況和你的經濟和關係能力評估一下你能做到什麼程度。人員不足的情況下通過什麼方式能去逐步補充？

看到這些基本了解了吧？如何做到？以PM的心去努力做到CEO做的事情。加油吧。

PS：未審定，歡迎批評指正。

找個做架構的男（女）朋友

坦白說我也很想知道這個問題的答案。

在此說下我的迷惑和猜想吧（基本都在迷惑-_-）：

1.產品架構能力：這個的定義我不是太明確的涅，感覺是個方向性的大東西同時又需要特別多的心思啦，數據啦和細節考慮。比如我看到如今到處是吃貨，我覺得可以做一個這方面的產品，那麼我要知道吃貨們需要什麼喜歡什麼，我做這個產品的各個方面都是如何去滿足他們的，滿足的同時又是如何引導下一步轉化的，怎樣形成收益，再怎樣把收益投入繼續循環，然後還有中間的銜接，產品的成長，新產品的接力。

2.怎樣具備這個能力：我總覺得這是偏運營和商業的一種能力，要求腦容量比較大。。一方面要有產品本身的專業能力，另一方面要足夠了解產品所屬領域，同時還要能結合起來，也就是說要有想法還要能實現。做為一個超級新手，工作時我現在沒啥想法，只是每天努力去實現……不過業餘時間就不一樣了，盡量多吸收知識吧，噢對了，多交朋友，我覺得這個很重要，是個好渠道。

3.具備了這個能力以後：我所在的工作環境呢，很多東西做出來和自己的想法已經是偏離很遠了，不過還是堅持先把自己的想法做出來，努力，討論，說服。所以有時候會想，如果我只是具備了這個能力卻沒有權力，那麼是不是有點悲哀？可是我又一想，具備這個能力的人，應該有能力讓自己掌握權力了。

迷惑完了，感謝看我的廢話……

要想做公交車的架構，你得是開飛機的，呵呵