從0到1設計后臺產品(三):產品功能解構
物流運輸管理系統的流程是什么?如何設計這樣一款后臺產品,應該從哪幾個方面去設計呢?以下,筆者將為大家分享自己在設計后臺產品中的一些想法。
在業務需求了解清楚后,就進入了產品設計的階段。那么如何設計一款后臺產品,應該從哪幾個方面去設計呢?我們先看一下一個物流運輸管理系統大致的流程是什么。
功能域劃分
功能域,指的是在滿足某個業務流程時,將線上的操作流程拆分成不同的功能閉環。
劃分功能域是在產品設計的初期階段比較重要的一個工作。如果在產品設計的一開始就可以劃分一個比較合理的功能域,在后面產品設計的時候,就可以按照功能域進行拆分設計,不同功能域之間以接口的方式進行對接。這樣一來可以減少系統的復雜性,降低設計成本。二來可以減少不同功能之間的耦合性。防止一個功能進行迭代或者優化就會牽一發而動全身。
產供銷模式
功能域劃分可按照經典的供應鏈產供銷的思路進行劃分;產供銷在供應鏈中指的是生產、供應、銷售;指的是某個貨物的完整的供應鏈體系。這里供應鏈體系不同的是所傳遞的不是貨物,而是數據或者某個流程的結果。這種模式比較適合操作性比較強的業務系統。
所以這里的產供銷引申為:數據的生成部分,數據的處理部分,數據的最后經過系統系統流轉產生的結果,也是其價值所在。
比如要設計一個大件貨物的物流運輸管理系統:
生產:貨品/客戶數據錄入功能,車輛信息、司機信息的錄入,城市信息/點位倉庫的錄入,運輸計劃的生成,我們可以將其劃分為數據生成功能域;數據生成功能域一般來說屬于最上游的功能域,所以與系統內的往復的交互不會太多,一般其他的操作流程都是從這里取數,反而與一些承載其他的業務訴求的系統有所交互,比貨品/客戶的數據可能是從倉儲系統或者交易系統直接拿過來的數據,車輛信息、司機信息時直接從供應商系統拿過來的數據。但是理論上說,它所有的邏輯都是向上耦合而不會向下耦合的。
供應:為了達到最后的結果的流程業務功能。一般來說如果劃分供應功能域的話,所劃分的領域都是比較核心的領域,是主要業務流程的承載。對于物流運輸系統來說,就是可以說是排線、裝車流程。以及整個的任務跟蹤流程,包括實時運力的報告預警,車輛調度,在途跟蹤,司機在此過程中的送貨、簽收、回款等一系列流程。
銷售:這塊一般是已經完成了核心業務流程后所要拿到結果的部分,也是整套流程的價值所在。對于物流運輸系統來說,可以是整個費用結算模塊,根據之前的所有的流程或者內容最終的一個產出。向下流程的內容其實也屬于這塊的內容,比如物流任務完成后最終給財務系統,給交易系統的一個數據流轉,也會放在這個功能域中。
進銷存模式
還有一種思路是按照供應鏈的進銷存的思路進行劃分,這也是劃分子系統的另外一個角度。
進銷存指的是采購、入庫、銷售這樣的一個過程。這種模式比較適合邏輯復雜,中臺系統,或者中間業務流轉系統。與產供銷模式不同的是,一個偏向于產出,通過某個方式生成數據,完成業務流程。一個偏向流轉,以自己本身的業務流程屬性進行承上啟下或者承接核心業務流程。
比如訂單交易系統,可以采用進銷存的模式。
第一:訂單數據的產生來源是用戶下單,所以產生訂單的過程可以作為采購的流程;
第二:訂單數據產生后,整體的處理過程,比如訂單狀態根據不同操作的流轉、訂單的算價等;
第三:訂單處理完成后,對各個下游系統的分發,可以作為銷售環節;比如訂單在客服系統、CRM等系統中的下游邏輯處理;
這些是我在平時工作中的一些總結,肯定還有許多業務流程沒有辦法按照這個思路去劃分功能域,總之可以按照一個思路:功能域之外盡量形成閉環,通過盡量少的接口就可以滿足不同功能域之間的數據流轉,協作完成各個功能域之間的工作就可以。
主線產品設計
在劃分功能域后,我們可以按照不同的功能域進行產品的設計,每一個功能域中都可以拆分為主線產品及非主線產品。
例如在物流運輸管理系統中,我們已經按照產供銷的模式將系統拆分了不同的子功能域,第二個子功能域是業務流程的處理,數據的處理部分,那么針對這個環節中,其整個核心的流程就是從物流運輸管理系統中排線,裝車,在途運輸,簽收回款這樣一條業務流程的核心鏈路。
那么,應該如何去判斷這條鏈路是核心鏈路呢?
可以秉承這一一句話:這條鏈路跑通后,可這個子功能域的基本業務流程可以跑通,沒有比較大的功能缺陷;
有時候,我們無法確認哪些是核心鏈路。接過來一堆的業務訴求,梳理了一個龐大而繁瑣的產品流程;
在這條流程里面,我們可以進行梳理和拆解,這個過程中,我們可以遵循以下幾個原則將核心鏈路梳理出來。
第一:業務閉環是什么
這個子功能域中,最開始的節點,和最后的節點分別是哪些;比如物流運輸管理系統中,第二個子功能域的第一個環節是排線,最后一個環節是簽收回款,或者司機返倉(有返倉環節的流程),那么可以確認的是,這兩個環節一定是主鏈路之內的;
接著,通過這個鏈路往后推,往前推,直至將整條鏈路閉環。比如排線后接下來的環節是通知司機,則這個環節也是主鏈路之內的;司機接單后進行裝車,這樣是從前往后推,直至最后的環節;
另外,為了保證最終的結果正確,我們可以從后往前再推一遍,比如最后的節點是司機返倉,那前一個環節是司機接收到了貨款,再前一個環節是司機到達客戶現場進行送貨;
第二:如果沒有XX功能,該怎么辦
對于某個功能我們實在難以取舍的時候,我們可以考慮一下,如果上線的時候沒有這個功能,我們可以怎么做?比如如果沒有內置導航的功能,司機可以通過高德、百度地圖的APP直接導航使用;如果沒有裝車后拍照留存功能,可以拉一個微信群,在微信群里面上傳照片;如果沒有排線功能,那業務數據將無法流轉,無法給司機下發任務;所以哪些功能是主線功能,哪些是非主線功能,就顯而易見了。
那么,為什么我們需要梳理出一個主線產品呢?
第一,后臺產品是復雜而龐大的,我們無法一口吃成一個胖子,就需要將功能拆解開來做,所以這個時候就必須梳理出一個主線產品;
第二,在產品線上跑起來之前,所有的設計都是空中閣樓,沒有經過實際的驗證,如果這個時候我們將產品設計的特別復雜,一旦其中某個環節出現了問題,就會出現船大難調頭的尷尬局面;
第三:好多的功能,是業務沒想清楚,我們也沒想清楚的,只有產品真正用起來之后,才能之后這個產品需要什么,所以在產品最開始的階段,當務之急是讓產品先運作起來,然后再根據實際的情況決定后續的產品怎么去做;
非主線產品設計
非主線產品功能,即指的在某個功能域之內主線產品之外的功能,這些功能不會影響到主鏈路,但是如果加上這些功能可以讓產品更加完善,更符合業務訴求。
比如我們在確定了物流運輸管理系統中如果沒有裝車后的拍照留存功能,可以讓司機通過微信群上傳照片的方式進行操作;但是在主線功能上線之后,針對于每一筆訂單都會用到的這個操作,這樣的操作無疑就相當的繁瑣了。所以此時刻的功能線上化就十分有必要了。
在已經將主線產品設計出后,非主線產品相對來說就會比較好設計一些。設計非主線產品時,可以參考以下幾個設計原則:
1. 主線產品每個環節的補充
在我們將主線功能中的排線環節設計完成后,排線所要涉及的其他點,比如運單生成后的打印,排線時需要先核對訂單各個SKU的數量以及倉儲數量,這些流程是依托于主線流程,或者主線流程的擴充的,完善主線功能的某個流程的。
2. 可以形成一個業務小閉環
某些功能可能根本就和主線流程關系不大, 但的確也屬于整個業務流程之內的,比如在許多的物流運輸管理系統中會將與司機簽訂合同的功能與放到里面;這個流程可以說是完全在系統中開辟了一個新的獨立的業務小閉環,我們在設計的時候,要注意做到最小可用即可,精力更多的還是需要放在主線流程及對應的非主線流程上。
數據功能設計
數據產品的設計中包括報表設計,數據儀表盤等產品設計。
這個功能可以說是后臺產品的必備功能之一。在設計報表功能時,需要注意的設計內容有:
一、自上而下的設計,即這個功能是以管理訴求出發,基于不同的管理者希望看到什么樣的數據來確定報表設計的內容。所以一般需求的來源大部分可能是管理者,較少部分的情況下才為操作者,比如CRM系統中某個人需要看自己今天拜訪了多少客戶。
二、不同行業的報表標準都有哪些,在不同的行業中可能會有一些固定衡量的指標來確定某一次業務流程的結果如何,比如在物流運輸管理系統中的提貨準時率 / 到貨準時率 / 貨損貨差率 /回單返回率 / 車輛裝載率?等等這些比較標準的數據做成線上報表。
三、在設計報表的時候,需要在一開始的時候就注意取數字段的設計,有時候在產品功能中可能不需要在數據庫中新增一個字段來存儲,但是為了后面報表取數比較容易,最好還是可以在數據庫中冗余一個字段。這樣在后期跑數據的時候一是可以減少開發的工作量,二來可以減少跑數的時間。
四、設計報表的時候,最好是帶入到不同的使用場景中去設計,不能為了設計報表而設計。所生成的數據一定要有意義,確切的用到某個地方才去取這個數據。
非功能性設計
非功能性產品主要包括兩個部分:
1. 滿足降本增效的目的,在現有功能產品之上確定的一些產品策略
這些策略是為了讓系統更加的堅實可用。這個我認為也是之所以我們要將某些業務流程線上化的原因,因為這些功能的存在,我們可以讓原來繁瑣的業務流程變得更加精簡高效;
比如在我們將tms的業務功能產品已經做得足夠完善時,需要考慮的就是這個系統可以如何更好的服務于業務,讓業務的操作可以更精簡,效率可以更高;這個時候我們就需要考慮一些人做不到的時候,比如排線策略,根據以往的排線數據,可以推算出某個訂單的最優線路,在給某個司機進行派單時自動將最佳的訂單進行聚合生成運單。在司機裝車時,根據貨物的擺放原則(密度大的放在下方,易損的放在上方),先到后裝(優先派送的放在最后裝車),不超載等原則自動匹配配載的策略;
這些功能可能都是人為操作難以實現或者需要一個很復雜的計算的,但是這些我們通過產品本身不斷優化的策略,可以讓產品變得更加完善和健壯。
2. 非功能性產品包括在業務流程之外的一些產品能力
比如一些管控訴求,關鍵節點需要某些職位的領導進行審批;如果是從0 到1在建設完成的系統時需要設計的權限系統,賬戶系統;等等這些內容,需要滿足整體的產品閉環流程不可缺少的環節。
接口設計
對內的接口
在上文中所述,設計產品的一開始需要劃分子功能域,那么不同的功能域之間的能力即通過接口進行連接。之所以通過接口進行對接,可以保證不同子功能域之間的耦合程度比較低,在進行功能迭代時,如果只涉及到某個功能域的改動,不需要整個鏈路都改造,只改造自己本身內部即可,只要對其他功能域所輸出的接口沒有變動,則對其他功能域無感知。
在設計對內的接口時,無需考慮到的點有如下:
1. 接口的調用頻率,調用次數。因為作為一個統一的系統,所有系統的技術能力都是統一的,完備的,這些信息更多的應該是技術去考慮的。
2. 同一個系統中,不同子功能域的主數據是一致的。基于此,我們在設計接口的時候,就不需要考慮接口中過多的參數,如果一旦涉及到某個數據,只需要將表中的主鍵作為參數進行傳遞即可。比如在物流運輸管理系統中,供應子功能域需要生產子功能域提供被禁用的司機名單,以便勾選司機的時候將其置灰。那供應子功能域只需要將司機ID給到,由供應子功能域直接去主數據中查詢即可。
對外的接口
對外的接口,既包括對功能內部的不同系統的業務能力支持接口,也包括可能對外涉及的OpenAPI。相對于對內的接口,由于這些接口是對外露出的,其他業務系統的能力不受本系統的控制。所以在設計的過程中會比對內的接口復雜一些,設計時也需要更加的謹慎;
在設計對外接口的時候,需要考慮的點有以下:
1. 是主動調用接口還是推送接口。主動調用接口指的是調用方因為自己的需求調用我方系統的接口,然后我方進行一定的邏輯處理后返回給調用方。這種情況多見于調用方發起業務操作,比如TMS在于WMS進行交互時,如果TMS想要獲取WMS中的貨品數據,則需要主動請求WMS,將一定的參數(一般包括必要的條件,比如哪個城市、哪個訂單,多少貨)等傳給WMS,然后WMS返回給對應的數據。
如果是推送接口,即我方系統因為數據變化或其他原因,主動推送給調用方的方式。比如WMS中某個貨品因為不合格下架了,但是之前的數據已經推送給TMS了,這個時候就需要WMS主動推送給TMS。
2. 同步接口還是異步接口。同步接口指的是進行數據傳遞時,接收方將結果實時返回給調用方,接口一直保持通信。同步接口的好處為:信息處理比較及時,各個系統之間的操作會比較平滑。缺點為一旦數據量大的時候,接口容易超時,導致數據傳輸失敗。這種情況下,整個系統的操作相當于都被中斷 。
異步接口指的是,我接收到調用方傳過來的數據后,先進行邏輯處理,處理成功后將結果再返回給調用方,這種方式的好處和同步接口相比針對大量數據的處理有了明顯的提升。但是有一點,因為調用方接收接口不及時,如果邏輯處理不好,很容易出現下游系統數據繼續進行,但是上游后面返回一個失敗的結果,這樣就會導致整個系統的邏輯錯亂。
3. 接口的調用頻次和量級。一個系統所能承受的壓力是有限的,在設計接口的時候,也一定要考慮到系統接口所能承受的壓力是多少。這一點其實技術考慮的可能更多一些,但是對于產品來說,可能不同的壓力承受值會對產品方案有所影響,比如某個HRM系統中,員工同步的借口一次最多允許傳10000個員工,則我們需要考慮正常的操作鏈路中比如Excel導入是否也需要將操作限制于10000。
兜底邏輯、熔斷機制
系統在運行的過程中,難免會因為并發量過大,系統bug產生一些問題,這些問題輕則影響業務的正常進行,重則直接宕機,丟失數據等嚴重的情況。所以在設計產品的時候,要考慮到如果一旦系統產生問題,怎么樣可以使產生的災難降到最低;
兜底邏輯指的是因為某些不可預見性的問題,比如系統bug,產品邏輯沒有考慮到等因素,發生了異常情況或者數據的情況下,系統應當進行的操作。設計一個產品的兜底邏輯需要對這個業務十分熟悉,并且有著自己比較精準的業務判斷,否則會導致一種十分可怕的情況是兜底錯誤,造成了比原本更可怕的錯誤。
比如在物流運輸管理系統中,因為司機早上需要發貨,需要將所有的排線任務在晚上十二點之前全部完成,否則就會影響后續的流程。正常情況下,規定排線人員必須在12點前完成,一旦因為排線員工自身原因,或者網絡異常,系統bug等無法完成排線任務,兜底邏輯會使系統則會按照歷史排線規則自動分發任務。
熔斷機制指的是如果某個操作系統判定為異常業務流程了,那么立刻會進行系統流程的切斷,以免發生悲劇。比如說某一套物流運輸系統,通過測算給某司機發放運輸任務工資時,由于系統問題或者操作失誤問題,本來運送5次應該發放1000元,實際發放了10000元。這個時候,系統就應該設置一套熔斷機制,設置某個操作的閾值。比如1單配送最高金額為300元,則司機運送5次最多發放1500元,該套熔斷機制檢測到金額超過閾值,則直接將流程切斷,并且將異常拋給系統管理員。
在設計一套復雜的后臺產品時,需要考慮的點可以說是方方面面。上面是我關于在設計后臺產品中設計產品方面的一些想法,接下來會介紹一下后臺產品的交互應該如何設計。
相關閱讀:
#專欄作家#
執迷,微信公眾號:執迷有悟,人人都是產品經理專欄作家,一個后臺產品經理。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 unsplash,基于 CC0 協議
功能域可以解釋一下嗎?是理解為功能模塊好點、還是大的比如商城、管理后臺這種?
推薦書籍:
1.《軟件需求最佳實踐》強烈推薦。徐鋒老師的經典巨作,由于當時出版時間為2008年,必看書籍;后續更新書籍《有效需求分析》,書中的知識框架相同,前一本比較詳細,后面一本內容比較少,便于閱讀。
2.《軟件需求(第三版)》為BA而寫,而里面的內容卻是后臺產品的知識寶典。可以說梳理出了后臺產品所有的知識體系和架構,必讀書籍;
另外還有《七步掌握業務分析》《掌握需求過程》等書都值得一讀!
關注我的公眾號“執迷有悟”回復“后臺資料”獲取相關后臺產品相關資料哦~
學習了
寫的真好、期待下一篇、棒棒噠
感謝支持~
感覺作者應該最少有個4年的產品工作經驗了
三年哈
領域驅動設計
正在做著后臺產品設計,文章闡述得比較詳細、全面
已經不想做這種業務系統了 ??
為什么?老鐵
感覺蠻有意思、哈哈