B端產品如何做好從1到10的架構搭建?

6 評論 1.7萬 瀏覽 81 收藏 16 分鐘

編輯導讀:做一款B端產品,在推進需求落地的過程中,會遇到各種大大小小的需求。如何圍繞需求,做好架構搭建呢?本文將從四個方面進行分析,希望對你有幫助。

上一篇文章,我寫了《Saas產品如何做好從0到1的架構搭建?》。

今天這篇文章,不聊從0到1。

我想拓寬思路聊一聊B端產品如何做好從1到10的架構搭建。

一款從1—10的B端產品,產品經理在推進需求落地的過程中,會遇到各種大大小小的需求,圍繞需求,如何做好架構搭建?

是我們這篇文章要聊的重點。

我把平時遇到的各種需求分為3大類,一個又一個的小需求;一個又一個模塊性的中等需求;想解決一個新業務問題的大需求。

不同類別的需求,對應著不同的架構思考,分別為:

  1. 小需求,用產品模塊內可配置思考方法;
  2. 中等需求,用高內聚、低耦合思考方法;
  3. 大需求,重啟產品線思考方法;
  4. 平衡的藝術(這是個補充)。

接下來,我一個一個講。

一、小需求:用可配置思考法

作為一個B端產品經理,我們經?;蛑鲃踊虮粍拥慕邮盏揭粋€又一個的小需求。

如果是一個B端小白產品經理,第一反應就是,那就把需求落地成功能,畫出需求相關的原型圖,交給技術開發。

結果就是產品里不斷的堆砌功能,以至于產品越來越復雜,越來越難用。

但如果是一個B端資深產品經理,

面對一個又一個的需求時,會先站在整個系統架構來看這一個又一個的小需求,把需求歸類到屬于它的模塊,然后盡量的用一個功能模塊來滿足多個類似的需求。

也就是,一個B端資深的產品經理,在面對一個一個小需求時,懂的在整體中來理解部分。

在整體中理解部分有多么重要,這里講一個經典的小故事:

有一天有三個石匠在打石頭。有個路人經過,問他們在做什么。第一個石匠說:“我在打石頭,養家糊口?!钡诙€石匠說:“我在做全國最好的石匠活?!钡谌齻€石匠抬起頭說:“我在建造一座大教堂?!?/p>

現在,假設你是這三個石匠的領導,那么請問,哪一個石匠最讓你放心?

正確的答案是:第三個石匠最讓人放心,因為他知道整體系統的目標是什么,是建造一座大教堂,盡管他只是整體系統中的一部分,但是他把整體的目標放在心中。

他從整體系統中來更高、更深的理解自己局部工作。

作為產品經理也一樣,不從產品整體架構中來理解,永遠不會成為領導放心的好幫手,領導會擔心,因為產品經理整體性思考的不夠,在解決一個一個的小需求過程中,功能模塊越堆越多,最終會導致產品越來越不好用。

這里我還是以上一篇文章聊到的景區智慧營銷Saas系統為例,講一講面對一個又一個的小需求時如何思考并落地。

首先,先介紹一下智慧景區Saas系統目前的現狀,目前模塊現狀是:一級模塊“商品管理”里包含了“門票(此時的門票是指付費門票)、特產”兩個二級模塊。

還有其它如,訂單管理、店鋪管理、數據管理等一級模塊。

大概的架構如下面這樣:

然后現在遇到了以下3個最終確定有價值的需求:

  1. 景區想提供給游客免費門票,但需游客提前預約;
  2. 某景區入園時需要出示身份證;
  3. 某景區每日游客入園數有限制。

這時需要把產品落地成功能,開發出來,然后提供給景區使用。

如果是一個小白產品經理,那么可能的思路是:

  1. 景區想要上傳免費門票,那就在商品管理模塊里增加一個免費門票上傳管理的二級模塊;
  2. 游客入園時要出示身份證,那就找一個在店鋪管理里面或者是什么位置,加一個提示游客需要出示身份證的功能按鈕。

如上面這樣,B端小白產品經理基本上就是屬于遇到問題解決問題,盡量把問題解決好,但基本上沒有從整體架構、未來產品的可拓展性角度上來思考。

而如果是一個資深的B端產品經理,那么可能的思路是:

景區想提供給游客免費門票,但需游客提前預約。

首先這業務需求肯定要歸類到商品管理里面的門票管理模塊里面去,通過梳理發現,免費門票和付費門票的業務邏輯,在整個后臺景區工作人員的工作流里,基本上是一致的,不同點就是有的景區門票收費,有的免費。

這時只需要在門票管理模塊里配置一個是否要收費的功能,就能把這這個問題解決了。

如果不需要收費的門票,工作人員選擇了不需要按鈕,圖片中的市場價和銷售價框就會被置灰,不能操作。

某景區入園時需要出示身份證。

進入場景思考,景區在軟件的什么地方放這句話,游客會百分百的看到這句話,買票的時候,對,就是買票的時候,因此景區可以在上傳門票的時候添加這樣的字段。

但這里又引來了一個新問題,入園時不需要門票的景區此時怎么辦?

這時也簡單,在門票管理模塊里配置一個“景區可選擇取票時是否需要出示身份證按鈕可供選擇”就能解決問題了。

以上就是遇到一個又一個小需求時,產品經理可以用可配置思考法來解決問題。

二、中等需求:用高內聚,低耦合思考法

在工作過程中,我們除了會遇到一個又一個的小需求,我們也會遇到一些比較大的模塊性的需求需要落地。

比如:

現在你接手到了要增加一個“大轉盤抽獎”功能,這個功能要解決的問題是,景區想用大轉盤抽獎功能來和游客現場互動,游客通過抽獎可以抽到優惠券獎品。

接下來需要把這個需求落地,設計出來。

像面對這樣的中等需求,如何落地推進,這個時候就要用到高內聚,低耦合思考法了。

高內聚的意思是指,產品結構中單個模塊內各個元素聯系緊密,也就是一個模塊內的代碼只完成一個任務。

低耦合的意思是指,產品結構內不同模塊間的聯系弱,關系簡單,修改一個模塊則不會影響另一個模塊。

產品通過低耦合、高內聚的思想來設計,會給產品未來帶來更好的可擴展性和靈活性,避免了后期產品的難以迭代,需要重構。

回到大轉盤抽獎活動功能模塊,我們看看整個活動落地的一個思考過程。

這里我簡單做了一個大轉盤抽獎活動的業務流程圖(流程圖做的不詳細,僅供參考,不具有實用價值)。

這張流程圖里有3個關鍵點,創建大轉盤活動時,需要添加優惠券,而添加優惠券的時候要添加商品。

資深的B端產品經理這時會知道,產品設計要低耦合,讓功能模塊更聚焦。

不能把大轉盤、優惠券聚集在一起。大轉盤模塊解決大轉盤的問題,優惠券模塊解決優惠券問題,優惠券屬于和大轉盤同一層級的另一個模塊,商品則又屬于另一個模塊,大轉盤和優惠券之間的關系則是調用關系。

大轉盤功能帶著這樣的思想去設計,就做到了低耦合,會大大降低未來產品的迭代成本。

如果是一個B端小白產品經理,在設計大轉盤活動時,就可能會把大轉盤和優惠券給聚合在一起,這會導致,任何一個模塊要做修改和迭代時,都會最大程度的影響另一個模塊,導致后期的迭代成本非常高,甚至會導致產品需要重構。

以上就是遇到一個又一個中等需求時,產品經理可以用高內聚,低耦合思考法來解決問題。

三、大需求:重啟產品線思考方法

一家公司,或者一家公司的某條產品線。

在往前發展的過程中,可能會遇到以下這么幾種情況:

  1. 產品本身沒有突破從0到1的破局點,無邊界的在找各種需求(或者說有一定的邊界,但邊界已遠遠超出產品從0到1架構的邊界),一直在做各種嘗試;
  2. 本來公司業務是解決營銷問題的,因為客戶的需要,或者是老板發現了新機會,想在目前的產品基礎上增加人力資源管理的功能模塊;
  3. 原本是一款Saas產品,在發展的過程中,有了一定的客戶量,公司領導想在Saas產品的基礎上增加行業信息化解決方案;
  4. 等等。

反正,用一句話來總結就是:

公司有了新需求,且這個需求已經遠遠超過了產品從0到1的架構邊界。

甚至這個需求是不是真需求?這個需求有沒有價值?能不能規?;l展?等等都是一個未知。

這時最好的解決方案就是重新啟動一個獨立的新產品來解決這個問題,千萬不要把新需求聚合在老產品里。

不然會讓產品越來越不好用,影響了老業務的發展,得不償失。

四、平衡的藝術

當然我上面講的也沒那么絕對,它只是一種思考方法。

比如,我文章中提到的:要把需求對應的功能設計在符合業務屬性的模塊內?

實際工作中,也不一定非要這樣做。

實際情況還是要根據產品經理對業務的理解,客戶的理解,公司現狀、目標的理解綜合考慮之后,才能給出一個更優的解決方案。

這里舉個例子:

現在有一個需求:文章提到的景區智慧營銷Saas要給不等等級的會員設置權益,權益是不同等級的會員買商品時可以有不同的折扣價。

理論上來講,這個需求搭架構時的業務思考邏輯是這樣的:

不過由于景區業務低頻,權益管理并不復雜,所以思考邏輯有所簡化,如下:

從客戶管理這個模塊來講,把“調用商品,添加折扣數”這個需求,放在權益管理這個二級模塊里,可能是最優解,但它對整體來講不是最優解。

對產品整體來講,由于景區商品品類少,產品設計和開發成本、對客戶的影響范圍等綜合考慮之下,設計思路可以如下(這樣會降低成本):

這里把不同等級會員設置不同的商品折扣這個需求,放在客戶模塊里。

調用商品,添加折扣數這個需求,直接在添加商品的業務流程里配置了一個“可以啟用會員價”功能的這么一個小按鈕。

而不需要在客戶模塊里面“調用商品,添加折扣數”,就把問題解決了,同時也不影響未來產品的可拓展性。

所以,產品架構設計沒有什么非黑即白的準則,它是一個平衡的藝術。

需要你在各種要素之間進行判斷、取舍和平衡。

#專欄作家#

豐憲飛,微信公眾號:小飛哥筆記,個人微信:f1506620495。人人都是產品經理專欄作家。某互聯網創業公司合伙人兼運營總監,多個項目“從0到1”項目負責人,擅長戰略、運營、產品的整體規劃及落地執行。

本文原創發布于人人都是產品經理,未經允許,禁止轉載。

題圖來自Unsplash, 基于CC0協議。

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 其實針對于產品架構之類的文章,可以學習下《數據庫原理》、《軟件工程》這幾門學科,很多概念都是由這些學科演變出來的。

    回復
  2. B段產品小白
    小需求那塊有些問題,1.免費門票,我的想法是直接設置價格為零,讓用戶有支付操作,后臺前臺都不用改,如果按照作者寫的那樣改,后臺傳到服務器的幾個值都為null,是把價格、支付的模塊都隱藏掉嗎?原先定義的產品極有可能是支付后才走下一步的,把支付隱藏掉,怎么走下一步?還是免費門票直接跳到了預約呢? 這個做法實際上增加了一條路徑。
    2.出示身份證,我作為一個游客,有可能提前買票,也有可能不現場買票,提前買票的話,產品上的提示其實對我就沒用了,我已經被美麗的景色吸引了,產品上的信息很難吸引到我了;現場買票的話,產品上只是提示,現場人員肯定需要再喊“進去要拿身份證”,如果這個需求是做提示用的,好吧。

    回復
    1. 第一個問題,做的是前端多樣化,后端標準化,也就是游客在購買門票和免費門票的預定是兩套流程和邏輯。

      第二個問題,只要商家在后臺選擇了“取票時需要出示身份證”,那么即在游客提前購買或預定門票的時候,在填寫訂單頁加一個功能框“身份證:取票時需要出示身份證”,游客需要填寫使用門票角色的身份證,才能購買或預定成功。

      回復
    2. 第二個問題,我理解成單個景區了,不好意思;
      第一個問題,我覺得免費門票,咱倆對它的定義不一樣,我理解的免費門票是價格為0的門票,用戶還是需要進行門票跟金錢的交換的。

      回復
  3. 感謝分享????

    回復
    1. 感謝支持??

      回復