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