B端產(chǎn)品如何做好從1到10的架構(gòu)搭建?
編輯導(dǎo)讀:做一款B端產(chǎn)品,在推進(jìn)需求落地的過程中,會遇到各種大大小小的需求。如何圍繞需求,做好架構(gòu)搭建呢?本文將從四個(gè)方面進(jìn)行分析,希望對你有幫助。
上一篇文章,我寫了《Saas產(chǎn)品如何做好從0到1的架構(gòu)搭建?》。
今天這篇文章,不聊從0到1。
我想拓寬思路聊一聊B端產(chǎn)品如何做好從1到10的架構(gòu)搭建。
一款從1—10的B端產(chǎn)品,產(chǎn)品經(jīng)理在推進(jìn)需求落地的過程中,會遇到各種大大小小的需求,圍繞需求,如何做好架構(gòu)搭建?
是我們這篇文章要聊的重點(diǎn)。
我把平時(shí)遇到的各種需求分為3大類,一個(gè)又一個(gè)的小需求;一個(gè)又一個(gè)模塊性的中等需求;想解決一個(gè)新業(yè)務(wù)問題的大需求。
不同類別的需求,對應(yīng)著不同的架構(gòu)思考,分別為:
- 小需求,用產(chǎn)品模塊內(nèi)可配置思考方法;
- 中等需求,用高內(nèi)聚、低耦合思考方法;
- 大需求,重啟產(chǎn)品線思考方法;
- 平衡的藝術(shù)(這是個(gè)補(bǔ)充)。
接下來,我一個(gè)一個(gè)講。
一、小需求:用可配置思考法
作為一個(gè)B端產(chǎn)品經(jīng)理,我們經(jīng)?;蛑鲃踊虮粍拥慕邮盏揭粋€(gè)又一個(gè)的小需求。
如果是一個(gè)B端小白產(chǎn)品經(jīng)理,第一反應(yīng)就是,那就把需求落地成功能,畫出需求相關(guān)的原型圖,交給技術(shù)開發(fā)。
結(jié)果就是產(chǎn)品里不斷的堆砌功能,以至于產(chǎn)品越來越復(fù)雜,越來越難用。
但如果是一個(gè)B端資深產(chǎn)品經(jīng)理,
面對一個(gè)又一個(gè)的需求時(shí),會先站在整個(gè)系統(tǒng)架構(gòu)來看這一個(gè)又一個(gè)的小需求,把需求歸類到屬于它的模塊,然后盡量的用一個(gè)功能模塊來滿足多個(gè)類似的需求。
也就是,一個(gè)B端資深的產(chǎn)品經(jīng)理,在面對一個(gè)一個(gè)小需求時(shí),懂的在整體中來理解部分。
在整體中理解部分有多么重要,這里講一個(gè)經(jīng)典的小故事:
有一天有三個(gè)石匠在打石頭。有個(gè)路人經(jīng)過,問他們在做什么。第一個(gè)石匠說:“我在打石頭,養(yǎng)家糊口?!钡诙€(gè)石匠說:“我在做全國最好的石匠活?!钡谌齻€(gè)石匠抬起頭說:“我在建造一座大教堂?!?/p>
現(xiàn)在,假設(shè)你是這三個(gè)石匠的領(lǐng)導(dǎo),那么請問,哪一個(gè)石匠最讓你放心?
正確的答案是:第三個(gè)石匠最讓人放心,因?yàn)樗勒w系統(tǒng)的目標(biāo)是什么,是建造一座大教堂,盡管他只是整體系統(tǒng)中的一部分,但是他把整體的目標(biāo)放在心中。
他從整體系統(tǒng)中來更高、更深的理解自己局部工作。
作為產(chǎn)品經(jīng)理也一樣,不從產(chǎn)品整體架構(gòu)中來理解,永遠(yuǎn)不會成為領(lǐng)導(dǎo)放心的好幫手,領(lǐng)導(dǎo)會擔(dān)心,因?yàn)楫a(chǎn)品經(jīng)理整體性思考的不夠,在解決一個(gè)一個(gè)的小需求過程中,功能模塊越堆越多,最終會導(dǎo)致產(chǎn)品越來越不好用。
這里我還是以上一篇文章聊到的景區(qū)智慧營銷Saas系統(tǒng)為例,講一講面對一個(gè)又一個(gè)的小需求時(shí)如何思考并落地。
首先,先介紹一下智慧景區(qū)Saas系統(tǒng)目前的現(xiàn)狀,目前模塊現(xiàn)狀是:一級模塊“商品管理”里包含了“門票(此時(shí)的門票是指付費(fèi)門票)、特產(chǎn)”兩個(gè)二級模塊。
還有其它如,訂單管理、店鋪管理、數(shù)據(jù)管理等一級模塊。
大概的架構(gòu)如下面這樣:
然后現(xiàn)在遇到了以下3個(gè)最終確定有價(jià)值的需求:
- 景區(qū)想提供給游客免費(fèi)門票,但需游客提前預(yù)約;
- 某景區(qū)入園時(shí)需要出示身份證;
- 某景區(qū)每日游客入園數(shù)有限制。
這時(shí)需要把產(chǎn)品落地成功能,開發(fā)出來,然后提供給景區(qū)使用。
如果是一個(gè)小白產(chǎn)品經(jīng)理,那么可能的思路是:
- 景區(qū)想要上傳免費(fèi)門票,那就在商品管理模塊里增加一個(gè)免費(fèi)門票上傳管理的二級模塊;
- 游客入園時(shí)要出示身份證,那就找一個(gè)在店鋪管理里面或者是什么位置,加一個(gè)提示游客需要出示身份證的功能按鈕。
如上面這樣,B端小白產(chǎn)品經(jīng)理基本上就是屬于遇到問題解決問題,盡量把問題解決好,但基本上沒有從整體架構(gòu)、未來產(chǎn)品的可拓展性角度上來思考。
而如果是一個(gè)資深的B端產(chǎn)品經(jīng)理,那么可能的思路是:
景區(qū)想提供給游客免費(fèi)門票,但需游客提前預(yù)約。
首先這業(yè)務(wù)需求肯定要?dú)w類到商品管理里面的門票管理模塊里面去,通過梳理發(fā)現(xiàn),免費(fèi)門票和付費(fèi)門票的業(yè)務(wù)邏輯,在整個(gè)后臺景區(qū)工作人員的工作流里,基本上是一致的,不同點(diǎn)就是有的景區(qū)門票收費(fèi),有的免費(fèi)。
這時(shí)只需要在門票管理模塊里配置一個(gè)是否要收費(fèi)的功能,就能把這這個(gè)問題解決了。
如果不需要收費(fèi)的門票,工作人員選擇了不需要按鈕,圖片中的市場價(jià)和銷售價(jià)框就會被置灰,不能操作。
某景區(qū)入園時(shí)需要出示身份證。
進(jìn)入場景思考,景區(qū)在軟件的什么地方放這句話,游客會百分百的看到這句話,買票的時(shí)候,對,就是買票的時(shí)候,因此景區(qū)可以在上傳門票的時(shí)候添加這樣的字段。
但這里又引來了一個(gè)新問題,入園時(shí)不需要門票的景區(qū)此時(shí)怎么辦?
這時(shí)也簡單,在門票管理模塊里配置一個(gè)“景區(qū)可選擇取票時(shí)是否需要出示身份證按鈕可供選擇”就能解決問題了。
以上就是遇到一個(gè)又一個(gè)小需求時(shí),產(chǎn)品經(jīng)理可以用可配置思考法來解決問題。
二、中等需求:用高內(nèi)聚,低耦合思考法
在工作過程中,我們除了會遇到一個(gè)又一個(gè)的小需求,我們也會遇到一些比較大的模塊性的需求需要落地。
比如:
現(xiàn)在你接手到了要增加一個(gè)“大轉(zhuǎn)盤抽獎(jiǎng)”功能,這個(gè)功能要解決的問題是,景區(qū)想用大轉(zhuǎn)盤抽獎(jiǎng)功能來和游客現(xiàn)場互動,游客通過抽獎(jiǎng)可以抽到優(yōu)惠券獎(jiǎng)品。
接下來需要把這個(gè)需求落地,設(shè)計(jì)出來。
像面對這樣的中等需求,如何落地推進(jìn),這個(gè)時(shí)候就要用到高內(nèi)聚,低耦合思考法了。
高內(nèi)聚的意思是指,產(chǎn)品結(jié)構(gòu)中單個(gè)模塊內(nèi)各個(gè)元素聯(lián)系緊密,也就是一個(gè)模塊內(nèi)的代碼只完成一個(gè)任務(wù)。
低耦合的意思是指,產(chǎn)品結(jié)構(gòu)內(nèi)不同模塊間的聯(lián)系弱,關(guān)系簡單,修改一個(gè)模塊則不會影響另一個(gè)模塊。
產(chǎn)品通過低耦合、高內(nèi)聚的思想來設(shè)計(jì),會給產(chǎn)品未來帶來更好的可擴(kuò)展性和靈活性,避免了后期產(chǎn)品的難以迭代,需要重構(gòu)。
回到大轉(zhuǎn)盤抽獎(jiǎng)活動功能模塊,我們看看整個(gè)活動落地的一個(gè)思考過程。
這里我簡單做了一個(gè)大轉(zhuǎn)盤抽獎(jiǎng)活動的業(yè)務(wù)流程圖(流程圖做的不詳細(xì),僅供參考,不具有實(shí)用價(jià)值)。
這張流程圖里有3個(gè)關(guān)鍵點(diǎn),創(chuàng)建大轉(zhuǎn)盤活動時(shí),需要添加優(yōu)惠券,而添加優(yōu)惠券的時(shí)候要添加商品。
資深的B端產(chǎn)品經(jīng)理這時(shí)會知道,產(chǎn)品設(shè)計(jì)要低耦合,讓功能模塊更聚焦。
不能把大轉(zhuǎn)盤、優(yōu)惠券聚集在一起。大轉(zhuǎn)盤模塊解決大轉(zhuǎn)盤的問題,優(yōu)惠券模塊解決優(yōu)惠券問題,優(yōu)惠券屬于和大轉(zhuǎn)盤同一層級的另一個(gè)模塊,商品則又屬于另一個(gè)模塊,大轉(zhuǎn)盤和優(yōu)惠券之間的關(guān)系則是調(diào)用關(guān)系。
大轉(zhuǎn)盤功能帶著這樣的思想去設(shè)計(jì),就做到了低耦合,會大大降低未來產(chǎn)品的迭代成本。
如果是一個(gè)B端小白產(chǎn)品經(jīng)理,在設(shè)計(jì)大轉(zhuǎn)盤活動時(shí),就可能會把大轉(zhuǎn)盤和優(yōu)惠券給聚合在一起,這會導(dǎo)致,任何一個(gè)模塊要做修改和迭代時(shí),都會最大程度的影響另一個(gè)模塊,導(dǎo)致后期的迭代成本非常高,甚至?xí)?dǎo)致產(chǎn)品需要重構(gòu)。
以上就是遇到一個(gè)又一個(gè)中等需求時(shí),產(chǎn)品經(jīng)理可以用高內(nèi)聚,低耦合思考法來解決問題。
三、大需求:重啟產(chǎn)品線思考方法
一家公司,或者一家公司的某條產(chǎn)品線。
在往前發(fā)展的過程中,可能會遇到以下這么幾種情況:
- 產(chǎn)品本身沒有突破從0到1的破局點(diǎn),無邊界的在找各種需求(或者說有一定的邊界,但邊界已遠(yuǎn)遠(yuǎn)超出產(chǎn)品從0到1架構(gòu)的邊界),一直在做各種嘗試;
- 本來公司業(yè)務(wù)是解決營銷問題的,因?yàn)榭蛻舻男枰?,或者是老板發(fā)現(xiàn)了新機(jī)會,想在目前的產(chǎn)品基礎(chǔ)上增加人力資源管理的功能模塊;
- 原本是一款Saas產(chǎn)品,在發(fā)展的過程中,有了一定的客戶量,公司領(lǐng)導(dǎo)想在Saas產(chǎn)品的基礎(chǔ)上增加行業(yè)信息化解決方案;
- 等等。
反正,用一句話來總結(jié)就是:
公司有了新需求,且這個(gè)需求已經(jīng)遠(yuǎn)遠(yuǎn)超過了產(chǎn)品從0到1的架構(gòu)邊界。
甚至這個(gè)需求是不是真需求?這個(gè)需求有沒有價(jià)值?能不能規(guī)模化發(fā)展?等等都是一個(gè)未知。
這時(shí)最好的解決方案就是重新啟動一個(gè)獨(dú)立的新產(chǎn)品來解決這個(gè)問題,千萬不要把新需求聚合在老產(chǎn)品里。
不然會讓產(chǎn)品越來越不好用,影響了老業(yè)務(wù)的發(fā)展,得不償失。
四、平衡的藝術(shù)
當(dāng)然我上面講的也沒那么絕對,它只是一種思考方法。
比如,我文章中提到的:要把需求對應(yīng)的功能設(shè)計(jì)在符合業(yè)務(wù)屬性的模塊內(nèi)?
實(shí)際工作中,也不一定非要這樣做。
實(shí)際情況還是要根據(jù)產(chǎn)品經(jīng)理對業(yè)務(wù)的理解,客戶的理解,公司現(xiàn)狀、目標(biāo)的理解綜合考慮之后,才能給出一個(gè)更優(yōu)的解決方案。
這里舉個(gè)例子:
現(xiàn)在有一個(gè)需求:文章提到的景區(qū)智慧營銷Saas要給不等等級的會員設(shè)置權(quán)益,權(quán)益是不同等級的會員買商品時(shí)可以有不同的折扣價(jià)。
理論上來講,這個(gè)需求搭架構(gòu)時(shí)的業(yè)務(wù)思考邏輯是這樣的:
不過由于景區(qū)業(yè)務(wù)低頻,權(quán)益管理并不復(fù)雜,所以思考邏輯有所簡化,如下:
從客戶管理這個(gè)模塊來講,把“調(diào)用商品,添加折扣數(shù)”這個(gè)需求,放在權(quán)益管理這個(gè)二級模塊里,可能是最優(yōu)解,但它對整體來講不是最優(yōu)解。
對產(chǎn)品整體來講,由于景區(qū)商品品類少,產(chǎn)品設(shè)計(jì)和開發(fā)成本、對客戶的影響范圍等綜合考慮之下,設(shè)計(jì)思路可以如下(這樣會降低成本):
這里把不同等級會員設(shè)置不同的商品折扣這個(gè)需求,放在客戶模塊里。
調(diào)用商品,添加折扣數(shù)這個(gè)需求,直接在添加商品的業(yè)務(wù)流程里配置了一個(gè)“可以啟用會員價(jià)”功能的這么一個(gè)小按鈕。
而不需要在客戶模塊里面“調(diào)用商品,添加折扣數(shù)”,就把問題解決了,同時(shí)也不影響未來產(chǎn)品的可拓展性。
所以,產(chǎn)品架構(gòu)設(shè)計(jì)沒有什么非黑即白的準(zhǔn)則,它是一個(gè)平衡的藝術(shù)。
需要你在各種要素之間進(jìn)行判斷、取舍和平衡。
#專欄作家#
豐憲飛,微信公眾號:小飛哥筆記,個(gè)人微信:f1506620495。人人都是產(chǎn)品經(jīng)理專欄作家。某互聯(lián)網(wǎng)創(chuàng)業(yè)公司合伙人兼運(yùn)營總監(jiān),多個(gè)項(xiàng)目“從0到1”項(xiàng)目負(fù)責(zé)人,擅長戰(zhàn)略、運(yùn)營、產(chǎn)品的整體規(guī)劃及落地執(zhí)行。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)允許,禁止轉(zhuǎn)載。
題圖來自Unsplash, 基于CC0協(xié)議。
其實(shí)針對于產(chǎn)品架構(gòu)之類的文章,可以學(xué)習(xí)下《數(shù)據(jù)庫原理》、《軟件工程》這幾門學(xué)科,很多概念都是由這些學(xué)科演變出來的。
B段產(chǎn)品小白
小需求那塊有些問題,1.免費(fèi)門票,我的想法是直接設(shè)置價(jià)格為零,讓用戶有支付操作,后臺前臺都不用改,如果按照作者寫的那樣改,后臺傳到服務(wù)器的幾個(gè)值都為null,是把價(jià)格、支付的模塊都隱藏掉嗎?原先定義的產(chǎn)品極有可能是支付后才走下一步的,把支付隱藏掉,怎么走下一步?還是免費(fèi)門票直接跳到了預(yù)約呢? 這個(gè)做法實(shí)際上增加了一條路徑。
2.出示身份證,我作為一個(gè)游客,有可能提前買票,也有可能不現(xiàn)場買票,提前買票的話,產(chǎn)品上的提示其實(shí)對我就沒用了,我已經(jīng)被美麗的景色吸引了,產(chǎn)品上的信息很難吸引到我了;現(xiàn)場買票的話,產(chǎn)品上只是提示,現(xiàn)場人員肯定需要再喊“進(jìn)去要拿身份證”,如果這個(gè)需求是做提示用的,好吧。
第一個(gè)問題,做的是前端多樣化,后端標(biāo)準(zhǔn)化,也就是游客在購買門票和免費(fèi)門票的預(yù)定是兩套流程和邏輯。
第二個(gè)問題,只要商家在后臺選擇了“取票時(shí)需要出示身份證”,那么即在游客提前購買或預(yù)定門票的時(shí)候,在填寫訂單頁加一個(gè)功能框“身份證:取票時(shí)需要出示身份證”,游客需要填寫使用門票角色的身份證,才能購買或預(yù)定成功。
第二個(gè)問題,我理解成單個(gè)景區(qū)了,不好意思;
第一個(gè)問題,我覺得免費(fèi)門票,咱倆對它的定義不一樣,我理解的免費(fèi)門票是價(jià)格為0的門票,用戶還是需要進(jìn)行門票跟金錢的交換的。
感謝分享????
感謝支持??