B端教育產品如何降低模塊之間的耦合,做出低耦合設計?

13 評論 11091 瀏覽 76 收藏 10 分鐘

編輯導語:B端教育產品的設計往往需要經過很多流程,涉及教育行業的方方面面。當我們設計一個較為復雜的功能模塊時,應該如何降低模塊之間的耦合,從而做出低耦合的設計呢?作者結合經驗進行了梳理和分析,總結出了如何才能達到簡單優雅的設計的方法論。

作為一名面向教育機構B端產品經理,往往需要設計的是整個教育行業的方方面面的流程。當然,通常情況下是按照模塊的不同進行設計,比如學生相關模塊、教師相關模塊、考試相關模塊等。

這些模塊、功能、流程或復雜或簡單,簡單的流程就不必說了,當設計復雜功能模塊時,模塊之間很強的邏輯聯系,較高的數據依賴性,在流程梳理和整個設計過程中,是令人十分頭疼的事兒。

那么怎樣在一開始通過梳理和分析,達到簡單優雅的設計,這樣的問題就擺在我們面前。

一、降低模塊之間耦合度必要性

復雜的功能模塊除了本身的流程復雜外,最重要的是它是建立在別的較完善的模塊流程的基礎上,同樣模塊流程本身的輸出又是另外的一個模塊完善的前提。

這樣交織的模塊關系,使整個系統錯綜復雜,具有較強的耦合度,在做功能擴展的時候,牽一發而動全身。降低模塊之間的耦合度是十分重要的一件事兒,其優勢如下:

  1. 模塊之間的耦合程度越低,相互影響就越小,發生異常后產生連鎖反應的概率就越低;
  2. 在修改一個模塊時,低耦合的系統可以把修改范圍盡量控制在最小的范圍內;
  3. 對一個模塊進行維護時,其他模塊的內部程序的正常運行不會受到較大的影響。

那么,如何做到降低系統模塊之間的耦合度?

筆者認為可以從以下入手:

二、降低耦合度的方法

在軟件工程中,降低耦合度,又稱“解耦”,模塊間有依賴關系必然存在耦合,理論上絕對的零耦合是做不到的,但是可以通過一定的方法將耦合度降至最低。B端系統在設計時解耦的方法要從邏輯,研發兩方面考慮。

作為產品經理將產品線的發展規律,管理差異化,系統平臺支撐方面進行邏輯梳理。當然技術方面也要進行模塊化微服務,做到客戶、合同、付款、服務、服務評價五個維度的數據閉環。

模塊間數據傳輸,模塊內部邏輯判斷。開發人員應該盡量使用數據耦合,較少使用控制耦合,限制公共耦合的使用范圍,同時堅決避免使用內容耦合。

言歸正傳,產品經理如何在一開始設計的時候降低各應用模塊之間的耦合度,這是本文討論的重點。一開始就做到最優解耦不太容易,這是一個從混沌走向清晰的漸進明細過程,我個人認為可以從以下幾方面來入手:

1. 明晰并理解需求,了解現有的系統

1)業務流程圖

B端以業務流為主,業務流程圖是首要需要明確的,而且需要足夠概括,抽象,這樣業務流程可以按不同角色來進行劃分,每個角色在每個環節在什么情況下都需要干什么、有什么權限、涉及到什么模塊和數據等,由此也可把角色權限進行定義了。

2)流程狀態梳理

就是不同的業務流,有哪幾種狀態,每種狀態之間切換的條件是什么,到底有多少條通路,需要模擬各種情況的數據走一遍。

3)系統架構圖

整體的系統架構是由不同的流程不同狀態構成的公共合集,在設計系統架構圖時,需要明確涉及到的前臺業務、底層系統、各個系統模塊,明確業務范圍,若有改動涉及到其他系統,需要梳理并抽取出共性。

通過這幾個步驟,由業務流轉化為了抽象的系統架構圖,當然這是產品自己梳理的1.0版,還需要對整個系統影響的各相關方進行訪談。

2. 對上下游系統相關方進行訪談,根據訪談結果綜合分析后更新相關流程圖、架構圖

  • 現有系統的研發人員:系統能實現什么不能實現什么,肯定看了代碼就知道了,梳理相關邏輯的時候可以分專題與研發人員進行討論,一定要控制好不要跑題。
  • 熟悉相關業務的產品或項目經理:熟悉歷史經驗教訓及組織過程資產往往能夠降低后續的項目風險,有哪些是設計如此、哪些是遺留問題,相關的產品同事多少會知道一些。
  • 運營、最終用戶及測試人員:運營人員與最終用戶是使用系統最多的相關方,運營與測試人員往往能提出很多絕妙的優化建議,有利于產品同事進行梳理。

3. 配合營銷指標及技術指標進行優化,雖然這是后期的事兒

很多時候系統的業務量或用戶量達到一定程度時會遇到瓶頸,市場同事在銷售時也肯定會有相關的數據指標,產品的設計、模塊的解耦往往也可以與這些需求一并考慮

  • 技術優化:業務延遲的忍耐程度、流程的長度、數據的歸檔周期等;
  • 營銷指標:線索和商機的獲取周期、用戶的使用體驗等。

三、具體實現步驟

在具體操作的時候,我們可以采用以下思路:

1. 梳理原子服務

梳理承載業務的系統所需要的模塊,然后將這些模塊拆分為一個個功能點,將相似的功能點合并為一個獨立的服務,提供單獨的一項能力,合并服務要保證每個服務都可以單獨對外提供服務且每個服務提供的能力不重合,這種稱之為原子服務。

這個步驟的完成的好壞取決于:

  • 你對業務對理解能力,如果是從0-1可以參考其他教育行業友商競品,如果不是可以參考現有系統;
  • 你對業務所處行業發展的思考,這個很大程度決定你服務的拓展性和合理性,這個可以結合行業發展史和你自己的知識認知,比較抽象;
  • 邊界一定要清晰,要明晰所做功能的邊界和現實中技術的局限性,既要天馬行空、又要明確系統邊界。

2. 找出這些服務里面的共用項,做成最底層的配置規則,然后讓他服務來調用

舉個例子:設施設備管理及相關數據采集,經常涉及多硬件、多變成語言,那么每個模塊的框架語言包就是一個共用項,這樣做的目的是保證各維度數據的一致性。

3. 有時候一個業務閉環其實需要多個服務一起提供服務,這時需要再加一層服務聚合,保證原子服務的獨立性

總之,一般應該采用:梳理出獨立原子服務(保證獨立不耦合)——找出公共底層配置項(保證維度數據統一)——聚合服務支持業務(保證原子服務解耦)這樣的流程。

四、總結

充分的降低各個模塊的耦合性,是復雜的教育系統必須解決的問題,系統的解耦要從邏輯,研發兩方面結構。將產品線的發展規律,管理差異化,系統平臺支撐方面進行邏輯梳理。技術方面要進行模塊化微服務。

這樣對后期產品功能的擴展、系統的演進都會有很大的幫助。

 

本文由 @Cloudzhang 原創發布于人人都是產品經理,未經許可,禁止轉載

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 親身體會,“流程狀態梳理” 這個非常非常重要,如果能展開講一下就美了~

    來自上海 回復
    1. 具體想了解哪些?可以關注公眾號留言。共同探討!

      來自河南 回復
  2. 概念很好,不過缺少一些具體的示意圖。

    回復
  3. 學習收藏了,今天就當一回課代表吧。搭建私域流量運營,當然必須要有工具。給大家推薦一款由【人人都是產品經理】【起點課堂】旗下獨立研發的私域流量運營工具——糧倉·企微管家。糧倉·企微管家是一款基于企業微信的一款營銷型SCRM系統。集裂變獲客、留存促活、銷售變現、客戶管理于一體的私域增長閉環系統。覆蓋企業客戶運營的生命周期,助力企業私域流量運營,提升售前/售后服務能力。還可以免費開始使用哦~ http://996.pm/M0A06

    來自廣東 回復
  4. 沒有實例,很難讓我有入木三分的理解。本來可以100分,結果就差那么一點。

    來自陜西 回復
    1. 哈哈 篇幅有限

      來自河南 回復
  5. 1、建議不要盲目解耦,B端的產品各個模塊本身就可能互相管理,將各個模塊拆分太開,對于跨模塊的數據支持是非常差的,這回導致業務支持能力會收到阻礙,除非可以保證各個領域的模塊自己就可以完成閉環,對其它模塊沒有影響;
    2、對于大型復雜的系統,建議了解下DDD(領域驅動設計)

    來自浙江 回復
    1. 多謝交流;有些問題要說明一下:
      1.b端產品重要的一方面是定制化,同一個領域的客戶上層應用需求會有很大的差別,各模塊完成一個閉環,降低相互之間的耦合度,對迅速適應定制化需求有很大幫助。
      2.DDD需要在領域建?;ㄙM很多的時間和精力,付出和收益不一定成正比,現狀是大廠仍在有選擇的使用,具體落地的不多。

      來自河南 回復
    2. 哇偶,大佬,你們真是666666!

      來自河南 回復
    3. 對于第一個問題,你們有沒有試過在業務與數據層之間增加中間層,如BFF層,這樣可以更好解決定制化的上層業務問題,當然前提是底層可以保障足夠健壯,適配多種場景的數據支撐

      來自浙江 回復
  6. 作者可否舉一些具體的場景案例?

    來自江蘇 回復
    1. 作者沒時間

      來自河南 回復
  7. 學到了

    回復