一種可拯救產(chǎn)品與開發(fā)關(guān)系的良藥——“高內(nèi)聚低耦合”
需求是一個(gè)很玄的東西,總會(huì)影響產(chǎn)品經(jīng)理和開發(fā)的關(guān)系。為此,本文作者分享了一種可拯救產(chǎn)品與開發(fā)關(guān)系的良藥——“高內(nèi)聚低耦合”。因?yàn)椤案邇?nèi)聚低耦合”的產(chǎn)品設(shè)計(jì)能保證“可復(fù)用/可擴(kuò)展/夠靈活/可維護(hù)”,從而提升產(chǎn)品迭代效率/增進(jìn)和開發(fā)的感情。
產(chǎn)品經(jīng)理做功能規(guī)劃時(shí)一定經(jīng)常遇到這樣的問題:
- 需求變更或產(chǎn)品設(shè)計(jì)不合理導(dǎo)致修改成本很高時(shí),產(chǎn)品被開發(fā)罵,甚至被打。
- 需求評(píng)審時(shí),開發(fā)會(huì)說“不要相信產(chǎn)品經(jīng)理“/”這里不要聽他的,到時(shí)候肯定會(huì)讓我們改” ,信任崩壞。
其實(shí),產(chǎn)品一點(diǎn)也不想改需求??墒菢I(yè)務(wù)情況不斷在變,導(dǎo)致和開發(fā)的關(guān)系總是被改需求這件事破壞。
怎么辦?
- 首先,沖突是不可避免的。承認(rèn)產(chǎn)品和開發(fā)中任務(wù)目標(biāo)和思考方式上存在差異,不必太過緊張,在沖突中協(xié)作并推進(jìn)項(xiàng)目是常態(tài)。
- 其次,需求總是會(huì)改的。與其承諾不改,不如讓產(chǎn)品改起來十分順滑。這就要努力去理解開發(fā)的工作特征,在設(shè)計(jì)產(chǎn)品的時(shí)候做個(gè)“有腦子的pm”。
今天和大家分享其中非常重要的一點(diǎn)——產(chǎn)品設(shè)計(jì)中的 *高內(nèi)聚低耦合* 就是拯救產(chǎn)品開發(fā)關(guān)系的良藥。
什么是高內(nèi)聚低耦合?
這犀利的措辭一看就是來自開發(fā)界的術(shù)語(yǔ)。高內(nèi)聚是說一個(gè)功能模塊最好僅完成一個(gè)獨(dú)立的子功能并且完成的很好。低耦合是指模塊與模塊之間盡量獨(dú)立/聯(lián)系少/接口簡(jiǎn)單。
這個(gè)原則出現(xiàn)的背景是為了讓程序“可復(fù)用/可擴(kuò)展/夠靈活/可維護(hù)”。干過一陣子產(chǎn)品的人對(duì)這幾個(gè)詞應(yīng)該都不陌生。對(duì)于程序設(shè)計(jì)者來說,這幾個(gè)詞是十分重要的,不亞于產(chǎn)品經(jīng)理口中的“用戶體驗(yàn)”(原則or擋箭牌)。
那么,怎么能讓你的需求設(shè)計(jì)符合以上原則呢?
分3步:
- 把一個(gè)具體的問題抽象成一類問題;
- 根據(jù)用戶體驗(yàn)流程劃分功能模塊;
- 針對(duì)每個(gè)功能設(shè)計(jì)封閉的解決方案。
下面一個(gè)一個(gè)講:
1、從對(duì)象到類,從具體到抽象,產(chǎn)品經(jīng)理要盡量解決一類問題而不是一個(gè)問題
比如老板說這周要上一個(gè)大轉(zhuǎn)盤抽獎(jiǎng)的活動(dòng),送兩部iPhone7拉升一下用戶活躍。大轉(zhuǎn)盤幾乎時(shí)每個(gè)產(chǎn)品經(jīng)理/開發(fā)的噩夢(mèng),拿到題目立即打開axure開始飆車?no!先把這個(gè)具體到活動(dòng)需求升級(jí)到一類問題來考慮:
- 這次的大轉(zhuǎn)盤送iPhone7,下次送話費(fèi)怎么改?
- 大轉(zhuǎn)盤是個(gè)抽獎(jiǎng)活動(dòng),下次老板又看上了砸金蛋怎么改?
- 這次是獎(jiǎng)勵(lì)新用戶的,下次換成會(huì)員才可以抽獎(jiǎng)怎么改?
- 大轉(zhuǎn)盤是運(yùn)營(yíng)型產(chǎn)品,萬(wàn)一下個(gè)月要對(duì)接外部合作者引流怎么改?
- 甚至下次開始做轉(zhuǎn)發(fā)集贊送禮品了,怎么改?
你要從“策劃一個(gè)(抽獎(jiǎng))活動(dòng)系統(tǒng)”的角度來思考,目標(biāo)定為解決快速支持運(yùn)營(yíng)(抽獎(jiǎng))活動(dòng)這一類問題;如此得出的方案才有可能是“通用”的,支持比較多的“變種”。
2、繪制用戶體驗(yàn)流暢圖,按照“單一責(zé)任原則”劃分功能模塊
不同的角色甚至同一角色都可能有不同的任務(wù)目標(biāo),需要逐一分析。
比如在大轉(zhuǎn)盤類產(chǎn)品中,一個(gè)參與用戶在活動(dòng)中的體驗(yàn)流程是:
①用戶看到活動(dòng)頁(yè)面→②系統(tǒng)判斷活動(dòng)有效性→③用戶執(zhí)行抽獎(jiǎng)操作→④系統(tǒng)判斷用戶是否符合參與條件→⑤系統(tǒng)給出獎(jiǎng)勵(lì)結(jié)果→⑥輸出結(jié)果頁(yè)面給用戶→⑦用戶執(zhí)行領(lǐng)獎(jiǎng)操作
- 最初應(yīng)該如何劃分事件模塊?我的經(jīng)驗(yàn)是參考生活經(jīng)驗(yàn)并根據(jù)你當(dāng)前所要處理的任務(wù)目標(biāo)來確定粒度的粗細(xì),比如現(xiàn)在我們?cè)谠O(shè)計(jì)一個(gè)抽獎(jiǎng)的活動(dòng)系統(tǒng),我的劃分粒度就先到組成這個(gè)系統(tǒng)的大模塊。如果現(xiàn)在我們開始設(shè)計(jì)抽獎(jiǎng)的前端頁(yè)面,我們的劃分粒度就要拆解到頁(yè)面的組成部分。
- 如何確定模塊規(guī)劃符合高內(nèi)聚低耦合的標(biāo)準(zhǔn)?一個(gè)判斷標(biāo)準(zhǔn)是:單一責(zé)任原則。簡(jiǎn)單說就是一個(gè)模塊只做一件事,只承擔(dān)一項(xiàng)職責(zé),因?yàn)槌袚?dān)的責(zé)任越多,它被復(fù)用的可能性就越小。如果承擔(dān)的職責(zé)過多,就相當(dāng)于將這些職責(zé)耦合在一起,當(dāng)其中一個(gè)職責(zé)變化時(shí),可能會(huì)影響其他職責(zé)的運(yùn)作,于是就會(huì)導(dǎo)致開發(fā)罵娘——“這個(gè)功能改不動(dòng)”、“這相當(dāng)于重做一個(gè)”
為了方便操作,我個(gè)人總結(jié)如下圖:
左邊舉例:假設(shè)將“④系統(tǒng)判斷用戶是否符合參與條件→⑤系統(tǒng)給出獎(jiǎng)勵(lì)結(jié)果”規(guī)劃為一個(gè)功能模塊A,我們將會(huì)發(fā)現(xiàn)A的輸出結(jié)果有兩種類型,一個(gè)類型是用戶老王不是注冊(cè)用戶不具備抽獎(jiǎng)資格(假設(shè)活動(dòng)要求平臺(tái)注冊(cè)用戶才能抽獎(jiǎng)),另一個(gè)類型是老王具備抽獎(jiǎng)資格但是沒有抽中(假設(shè)完全隨機(jī)抽獎(jiǎng))。在這種情況下,出現(xiàn)兩種類型的結(jié)果輸出,說明該模塊的耦合度高了——應(yīng)該拆成2個(gè)模塊,一個(gè)專門判斷用戶是否有資格來抽一把,一個(gè)專門判斷有資格的用戶得到哪個(gè)獎(jiǎng)品。
①用戶看到活動(dòng)頁(yè)面→②系統(tǒng)判斷活動(dòng)有效性→③用戶執(zhí)行抽獎(jiǎng)操作→**A 系統(tǒng)給出獎(jiǎng)勵(lì)結(jié)果**→⑥輸出結(jié)果頁(yè)面給用戶→⑦用戶執(zhí)行領(lǐng)獎(jiǎng)操作
右邊舉例:假設(shè)將“⑤系統(tǒng)給出獎(jiǎng)勵(lì)結(jié)果”拆成兩個(gè)模塊“A 用戶抽中哪個(gè)獎(jiǎng)品→B 該獎(jiǎng)品是否已達(dá)最大量”,我們將會(huì)發(fā)現(xiàn)要得到用戶中獎(jiǎng)結(jié)果一定要模塊A和B同時(shí)起作用才行,也可以說A和B在承擔(dān)同一個(gè)責(zé)任。說明該模塊的內(nèi)聚度低——應(yīng)該合并成1個(gè)模塊。
①用戶看到活動(dòng)頁(yè)面→②系統(tǒng)判斷活動(dòng)有效性→③用戶執(zhí)行抽獎(jiǎng)操作→④系統(tǒng)判斷用戶是否符合參與條件→**A 用戶抽中哪個(gè)獎(jiǎng)品→B 該獎(jiǎng)品是否已達(dá)最大量(已抽完或每日限量)**→⑥輸出結(jié)果頁(yè)面給用戶→⑦用戶執(zhí)行領(lǐng)獎(jiǎng)操作
3、針對(duì)每個(gè)功能模塊,明確輸入和輸出,設(shè)計(jì)完整封閉的解決方案,打造對(duì)上下游的黑盒
根據(jù)第2部分的用戶體驗(yàn)流程,把活動(dòng)系統(tǒng)劃分歸類出以下模塊:
- 活動(dòng)頁(yè)面管理:頁(yè)面創(chuàng)建、編輯、banner圖替換、轉(zhuǎn)盤樣式切換、活動(dòng)規(guī)則頁(yè)編輯等;
- 活動(dòng)有效性管理:基礎(chǔ)信息配置、活動(dòng)時(shí)間設(shè)定、定時(shí)上線下線等;
- 參與條件管理:配置參與活動(dòng)的各項(xiàng)條件,比如用戶等級(jí)、性別、購(gòu)物滿××元等;
- 獎(jiǎng)池系統(tǒng):獎(jiǎng)品配置、數(shù)量限制、概率參數(shù)調(diào)整等。
我們以“參與條件管理?!眽K為例:
- 輸入:供判斷的一堆參數(shù),較大可能會(huì)隨業(yè)務(wù)變化而增減
- 黑盒:內(nèi)部工作單元,根據(jù)參數(shù)輸入執(zhí)行具體的判定
- 輸出:告訴抽獎(jiǎng)系統(tǒng)該用戶上否有資格參與抽獎(jiǎng),yes/no
如下圖:
厘清之后,該功能模塊和上下游切割的就比較干凈了:僅完成判斷用戶是否有資格參與抽獎(jiǎng)的任務(wù),高內(nèi)聚。上游對(duì)接判斷的參數(shù)條件,根據(jù)業(yè)務(wù)需求增加入?yún)⒑蛯?duì)應(yīng)的判斷模塊即可,下游只輸出是否可以參加有獎(jiǎng)的信息,低耦合。
總結(jié)
“高內(nèi)聚低耦合“的產(chǎn)品設(shè)計(jì)能保證“可復(fù)用/可擴(kuò)展/夠靈活/可維護(hù)”,從而提升產(chǎn)品迭代效率/增進(jìn)和開發(fā)的感情。
產(chǎn)品經(jīng)理可參考以下方法規(guī)劃產(chǎn)品模塊:
- 從對(duì)象到類,從具體到抽象,產(chǎn)品經(jīng)理出手是要解決一類問題而不是一個(gè)問題;
- 繪制用戶體驗(yàn)流暢圖,按照“單一責(zé)任原則”劃分功能模塊;
- 對(duì)每個(gè)功能模塊,明確輸入和輸出,設(shè)計(jì)完整封閉的解決方案,打造對(duì)上下游的功能黑盒。
最后,本人無(wú)技術(shù)背景,技術(shù)出身的pm如果想打我,請(qǐng)不要打臉。
作者:kk,前騰訊產(chǎn)品經(jīng)理,創(chuàng)業(yè)中,柚子生活COO。個(gè)人公眾號(hào):K星異客。
本文由 @kk 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
深入淺出,還有手繪,點(diǎn)個(gè)贊
耦合度是指模塊之間的關(guān)聯(lián)程度,內(nèi)聚是指模塊內(nèi)部的元素的關(guān)聯(lián)度
黑盒的輸入數(shù)據(jù)有用戶信息和訂單信息,可以理解為多個(gè)模塊輸出一種結(jié)果,那是否和單一責(zé)任制的低內(nèi)聚互相矛盾呢
感謝,總算搞明白產(chǎn)品設(shè)計(jì)該怎么利用這個(gè)概念了
感謝,文章淺顯易懂,簡(jiǎn)單明了,例子也很清晰,不過技術(shù)小白最后的解決方式?jīng)]怎么看懂
感謝!之前一直弄不懂這個(gè)概念!
最好的產(chǎn)品經(jīng)理是全棧型的,懂運(yùn)營(yíng)、懂市場(chǎng)、懂開發(fā)、懂設(shè)計(jì)也就是俗稱的公司老板!哈哈!
干貨滿滿,深入淺出,感謝分享。
所以其實(shí)設(shè)計(jì)模式對(duì)產(chǎn)品而言也是必修課。
以后要做一個(gè)這種產(chǎn)品
開發(fā)眼里最好的產(chǎn)品經(jīng)理自然是有開發(fā)思維的產(chǎn)品??偨Y(jié)的很好,在現(xiàn)實(shí)中也不難做到。
感謝,分析的很好,同為不懂技術(shù)的產(chǎn)品一枚!學(xué)習(xí)了
作為一個(gè)干了10年開發(fā)的老技術(shù),贊同高內(nèi)聚低耦合的設(shè)計(jì)原則。系統(tǒng)就應(yīng)該這樣設(shè)計(jì)??!軟件工程書里寫了幾十年了!