編輯導讀：做一款B端產品，在推進需求落地的過程中，會遇到各種大大小小的需求。如何圍繞需求，做好架構搭建呢？本文將從四個方面進行分析，希望對你有幫助。
上一篇文章，我寫了《Saas產品如何做好從0到1的架構搭建？》。
今天這篇文章，不聊從0到1。
我想拓寬思路聊一聊Ｂ端產品如何做好從1到10的架構搭建。
一款從1—10的Ｂ端產品，產品經理在推進需求落地的過程中，會遇到各種大大小小的需求，圍繞需求，如何做好架構搭建？
是我們這篇文章要聊的重點。
我把平時遇到的各種需求分為3大類，一個又一個的小需求；一個又一個模塊性的中等需求；想解決一個新業務問題的大需求。
不同類別的需求，對應着不同的架構思考，分別為：
小需求，用產品模塊內可配置思考方法；
中等需求，用高內聚、低耦合思考方法；
大需求，重啓產品線思考方法；
平衡的藝術。
接下來，我一個一個講。
一、小需求：用可配置思考法
作為一個Ｂ端產品經理，我們經常或主動或被動的接收到一個又一個的小需求。
如果是一個Ｂ端小白產品經理，第一反應就是，那就把需求落地成功能，畫出需求相關的原型圖，交給技術開發。
結果就是產品裏不斷的堆砌功能，以至於產品越來越複雜，越來越難用。
但如果是一個Ｂ端資深產品經理，
面對一個又一個的需求時，會先站在整個系統架構來看這一個又一個的小需求，把需求歸類到屬於它的模塊，然後儘量的用一個功能模塊來滿足多個類似的需求。
也就是，一個Ｂ端資深的產品經理，在面對一個一個小需求時，懂的在整體中來理解部分。
在整體中理解部分有多麼重要，這裏講一個經典的小故事：
有一天有三個石匠在打石頭。有個路人經過，問他們在做什麼。第一個石匠説：“我在打石頭，養家餬口。”第二個石匠説：“我在做全國最好的石匠活。”第三個石匠抬起頭説：“我在建造一座大教堂。”
現在，假設你是這三個石匠的領導，那麼請問，哪一個石匠最讓你放心？
正確的答案是：第三個石匠最讓人放心，因為他知道整體系統的目標是什麼，是建造一座大教堂，儘管他只是整體系統中的一部分，但是他把整體的目標放在心中。
他從整體系統中來更高、更深的理解自己局部工作。
作為產品經理也一樣，不從產品整體架構中來理解，永遠不會成為領導放心的好幫手，領導會擔心，因為產品經理整體性思考的不夠，在解決一個一個的小需求過程中，功能模塊越堆越多，最終會導致產品越來越不好用。
這裏我還是以上一篇文章聊到的景區智慧營銷Saas系統為例，講一講面對一個又一個的小需求時如何思考並落地。
首先，先介紹一下智慧景區Saas系統目前的現狀，目前模塊現狀是：一級模塊“商品管理”裏包含了“門票、特產”兩個二級模塊。
還有其它如，訂單管理、店鋪管理、數據管理等一級模塊。
大概的架構如下面這樣：
然後現在遇到了以下3個最終確定有價值的需求：
景區想提供給遊客免費門票，但需遊客提前預約；
某景區入園時需要出示身份證；
某景區每日遊客入園數有限制。
這時需要把產品落地成功能，開發出來，然後提供給景區使用。
如果是一個小白產品經理，那麼可能的思路是：
景區想要上傳免費門票，那就在商品管理模塊裏增加一個免費門票上傳管理的二級模塊；
遊客入園時要出示身份證，那就找一個在店鋪管理裏面或者是什麼位置，加一個提示遊客需要出示身份證的功能按鈕。
如上面這樣，Ｂ端小白產品經理基本上就是屬於遇到問題解決問題，儘量把問題解決好，但基本上沒有從整體架構、未來產品的可拓展性角度上來思考。
而如果是一個資深的Ｂ端產品經理，那麼可能的思路是：
景區想提供給遊客免費門票，但需遊客提前預約。
首先這業務需求肯定要歸類到商品管理裏面的門票管理模塊裏面去，通過梳理發現，免費門票和付費門票的業務邏輯，在整個後台景區工作人員的工作流裏，基本上是一致的，不同點就是有的景區門票收費，有的免費。
這時只需要在門票管理模塊裏配置一個是否要收費的功能，就能把這這個問題解決了。
如果不需要收費的門票，工作人員選擇了不需要按鈕，圖片中的市場價和銷售價框就會被置灰，不能操作。
某景區入園時需要出示身份證。
進入場景思考，景區在軟件的什麼地方放這句話，遊客會百分百的看到這句話，買票的時候，對，就是買票的時候，因此景區可以在上傳門票的時候添加這樣的字段。
但這裏又引來了一個新問題，入園時不需要門票的景區此時怎麼辦？
這時也簡單，在門票管理模塊裏配置一個“景區可選擇取票時是否需要出示身份證按鈕可供選擇”就能解決問題了。
以上就是遇到一個又一個小需求時，產品經理可以用可配置思考法來解決問題。
二、中等需求：用高內聚，低耦合思考法
在工作過程中，我們除了會遇到一個又一個的小需求，我們也會遇到一些比較大的模塊性的需求需要落地。
比如：
現在你接手到了要增加一個“大轉盤抽獎”功能，這個功能要解決的問題是，景區想用大轉盤抽獎功能來和遊客現場互動，遊客通過抽獎可以抽到優惠券獎品。
接下來需要把這個需求落地，設計出來。
像面對這樣的中等需求，如何落地推進，這個時候就要用到高內聚，低耦合思考法了。
高內聚的意思是指，產品結構中單個模塊內各個元素聯繫緊密，也就是一個模塊內的代碼只完成一個任務。
低耦合的意思是指，產品結構內不同模塊間的聯繫弱，關係簡單，修改一個模塊則不會影響另一個模塊。
產品通過低耦合、高內聚的思想來設計，會給產品未來帶來更好的可擴展性和靈活性，避免了後期產品的難以迭代，需要重構。
回到大轉盤抽獎活動功能模塊，我們看看整個活動落地的一個思考過程。
這裏我簡單做了一個大轉盤抽獎活動的業務流程圖。
這張流程圖裏有3個關鍵點，創建大轉盤活動時，需要添加優惠券，而添加優惠券的時候要添加商品。
資深的Ｂ端產品經理這時會知道，產品設計要低耦合，讓功能模塊更聚焦。
不能把大轉盤、優惠券聚集在一起。大轉盤模塊解決大轉盤的問題，優惠券模塊解決優惠券問題，優惠券屬於和大轉盤同一層級的另一個模塊，商品則又屬於另一個模塊，大轉盤和優惠券之間的關係則是調用關係。
大轉盤功能帶着這樣的思想去設計，就做到了低耦合，會大大降低未來產品的迭代成本。
如果是一個Ｂ端小白產品經理，在設計大轉盤活動時，就可能會把大轉盤和優惠券給聚合在一起，這會導致，任何一個模塊要做修改和迭代時，都會最大程度的影響另一個模塊，導致後期的迭代成本非常高，甚至會導致產品需要重構。
以上就是遇到一個又一箇中等需求時，產品經理可以用高內聚，低耦合思考法來解決問題。
三、大需求：重啓產品線思考方法
一家公司，或者一家公司的某條產品線。
在往前發展的過程中，可能會遇到以下這麼幾種情況：
產品本身沒有突破從0到1的破局點，無邊界的在找各種需求，一直在做各種嘗試；
本來公司業務是解決營銷問題的，因為客户的需要，或者是老闆發現了新機會，想在目前的產品基礎上增加人力資源管理的功能模塊；
原本是一款Saas產品，在發展的過程中，有了一定的客户量，公司領導想在Saas產品的基礎上增加行業信息化解決方案；
等等。
反正，用一句話來總結就是：
公司有了新需求，且這個需求已經遠遠超過了產品從0到1的架構邊界。
甚至這個需求是不是真需求？這個需求有沒有價值？能不能規模化發展？等等都是一個未知。
這時最好的解決方案就是重新啓動一個獨立的新產品來解決這個問題，千萬不要把新需求聚合在老產品裏。
不然會讓產品越來越不好用，影響了老業務的發展，得不償失。
四、平衡的藝術
當然我上面講的也沒那麼絕對，它只是一種思考方法。
比如，我文章中提到的：要把需求對應的功能設計在符合業務屬性的模塊內？
實際工作中，也不一定非要這樣做。
實際情況還是要根據產品經理對業務的理解，客户的理解，公司現狀、目標的理解綜合考慮之後，才能給出一個更優的解決方案。
這裏舉個例子：
現在有一個需求：文章提到的景區智慧營銷Saas要給不等等級的會員設置權益，權益是不同等級的會員買商品時可以有不同的折扣價。
理論上來講，這個需求搭架構時的業務思考邏輯是這樣的：
不過由於景區業務低頻，權益管理並不複雜，所以思考邏輯有所簡化，如下：
從客户管理這個模塊來講，把“調用商品，添加折扣數”這個需求，放在權益管理這個二級模塊裏，可能是最優解，但它對整體來講不是最優解。
對產品整體來講，由於景區商品品類少，產品設計和開發成本、對客户的影響範圍等綜合考慮之下，設計思路可以如下：
這裏把不同等級會員設置不同的商品折扣這個需求，放在客户模塊裏。
調用商品，添加折扣數這個需求，直接在添加商品的業務流程裏配置了一個“可以啓用會員價”功能的這麼一個小按鈕。
而不需要在客户模塊裏面“調用商品，添加折扣數”，就把問題解決了，同時也不影響未來產品的可拓展性。
所以，產品架構設計沒有什麼非黑即白的準則，它是一個平衡的藝術。
需要你在各種要素之間進行判斷、取捨和平衡。
題圖來自Unsplash, 基於CC0協議。