產品分析88-產品的耦合性
耦合度指程式模組間存在聯絡的緊密程度,內聚性則是模組內部的相互依賴程度。
低耦合就是模組之間的關聯少,越獨立耦合度越低。
高內聚就是模組的內容針對乾的事情少,功能越單一內聚越高。
我們在設計產品的時候,為了功能的簡單行,將兩個模組融合在一起。當業務複雜起來的時候,程式猿那邊則說改起來很複雜。
“支付訂單”、“菜品下單”和“營銷模組”的耦合性
做餐飲系統的時候,針對顧客在餐桌上使用硬體平板下單場景,設計點菜流程,最初是將菜品下單與支付訂單連在一起。就是使用者下單一次,就支付一次。對比電商領域,一個商品列表訂單也對應一個支付訂單。
而實際場景下使用者加飯、加菜的情況佔到70%以上。
在同一餐次下面,使用者是可以重複下單的,因為可以選擇加菜,也可以選擇退菜。
另外,本餐次的優惠券的使用要支撐每個支付訂單。也就是說你的退菜和加菜的支付訂單都要加上營銷模組。
基於1對1不適用於現在餐廳消費的場景,所以將支付訂單、菜品訂單、營銷模組分開,都統一關聯到餐次下。
這樣的好處是:
1、支付訂單不與菜品下單關聯,只與餐次訂單關聯
使用者不需要及時支付,程式碼裡也不用記住每次的支付狀態,例如待支付、已支付,鎖定中,已取消等等。
2、支付的實際結算頻次下降
因為使用者可以選擇一次性付款,也可以選擇先付款最後再退付款。營銷模組是載入在餐次訂單下的所有支付訂單。
“內容上傳”、“內容編輯”、“內容傳送”的耦合性
而在做媒體網站的時候,做發表文章的功能。發表文章的本質是將內容傳送給不同網站頻道。
很自然想到demo功能,填寫內容到點擊發送。
但可能會有以下場景需要考慮
1、我們要重複傳送同一篇文章到不同模組呢?
2、內容是需要有人編輯稽核的,內容的投放也是有專門的人員。
3、作者傳送的內容會有敏感詞怎麼辦?
那最初的方案能且只能達到:讓網站將文章傳送給多個頻道。
而對於部落格來說,後臺編輯則沒有如此的使用者需求,因為是屬於個人的東西,最多增加一個草稿箱作為過渡。
而正由於運營者使用場景的多樣性,無法在同一個頁面上同時完成這麼多功能。
這個設計轉成技術方案就會很明顯感知到“耦合”了,因為這套方案同時包含了“內容上傳”、“內容編輯”、“內容下發”,在功能上,產生了“交叉關聯”。
我們採用的方案則是將“內容上傳”、“內容編輯”、“內容下發”分別獨立成一個功能,三者之間存在“呼叫”的順序關係,不存在“交叉”的耦合關係。而獨立之後,可以更多考慮模組的功能使用場景。
內容上傳:
不限作者投稿;
專注於內容創作,強調編輯;
以“內容”作為最小單位;
可記錄訪問,轉發等資料。
內容編輯:
強調檢視,用於稽核;
強調編輯,使用者修改;
內容下發:
可選擇投放到不同頻道;
記錄“傳送歷史”及“傳送狀態”;
以“下發行為”作為最小單位;
可重複投放;
那使用者體驗和功能耦合性的衝突,怎麼解決呢?
我們在避免功能耦合的時候,確實會增加一定的操作成本,但“使用者體驗”更多的是產品經理的自我素養,是一個加分項,而不是價值體現。
使用者在使用產品時,通常是為價值買單,而不是為體驗買單 ,儘管我們都很努力,且很刻意的追求使用者體驗,但當體驗與價值產生衝突時,必然會出現“降維”。