如何從零規劃一個解決方案級產品矩陣(三)

2 評論 8747 瀏覽 55 收藏 13 分鐘

通過是否計費與是否實時監控這兩個維度,可以將復雜的業務場景劃分為四個場景類型,提煉出了4條數據鏈,并將設備輸入通過紅色數據鏈加工成了數據基座。本文在數據基座的基礎上,分析具體業務實現方式的設計,一起來看一下吧。

一、設計業務實現方案

之前,我們通過是否計費與是否實時監控兩個維度,將紛繁復雜的業務場景劃分為了四個場景類型。并抽象了關鍵業務模型,提煉出了 4 條數據鏈。同時將設備輸入通過紅色數據鏈加工成了數據基座。下面,我們將在數據基座的基礎上,開始具體業務實現方式的設計。

https://image.woshipm.com/wp-files/2022/10/wIFQN4Qn2BX1hPH7pjHZ.png

這里選擇既有設備監控又需計費的商務園區場景為目標,進行能耗業務設計。因為這個業務場景,涉及到數據基座中的全部數據鏈的使用。完成這個場景的設計后,其它 3 個場景,只需此基礎上配置各自的業務規則,就可以完成各自的業務設計。為簡化問題,我們將設備這塊內容折疊變換將核心業務抽象為如下模型。

https://image.woshipm.com/wp-files/2022/10/116R6T4iNvL34oihzn91.png

從模型中可以看出,統計最小計量單元的實時用量,就能得出不同區域在不同時段用量。通過查詢用戶使用區域,就能統計到用戶的耗能情況。通過計費規則與出賬規則的計算,就能得到用戶賬單費用。

大的邏輯是這樣的,但實際情況遠比這復雜。就拿支付賬單舉例:商務園區場景下有先用后付及預付后用兩種業務形態,支付方式可分線上與線下兩種方式。同時因為管理方式不同,預付業務有充值及退還,費用不足提醒,透支額度授予,自動閥控反制等業務管理需求;后付業態有滯納賬單等罰性手段等業務管理需求。下圖是對能耗費功能的大體描述。

https://image.woshipm.com/wp-files/2022/10/MWJPzBtHCn8o1MVwJssk.png

拆分到上面這個程度,我們已經對這塊的業務建立起了總體印象,對后續功能的總體走向有了把握。但認知還是停留在宏觀層面,業務邏輯的顆粒度太大,不足以指導系統開發。需要進一步細化挖掘,才能形成對業務的微觀層面的理解,最終提煉出實現業務的關鍵路徑,進而設計出對用戶真正有用的功能。

下面抽出后付費模式這個業務場景舉例,其進一步細化分析如下。

后付費模式(1:1,1:n,n:1):

https://image.woshipm.com/wp-files/2022/10/sZSgF5mPvDONvYY7iUlx.png

內部細節已省略,僅保留關鍵字段用做說明

通過上述的細化分析后,我們才真正認識到實際場景下用戶需求的多樣性,才能設計出覆蓋全面,從容應對多種業務場景的能耗收費功能。而不是一個漏洞百出,需要頻繁打補丁才能運行的收費模塊。

綜合上述分析與業務模型,設計了按用戶類型配置個性收費方案的功能,覆蓋典型業務場景下的所有業態。對于無需收費的內部能耗監控場景而言,不配置收費方案即可。

對于需要收費的場景,我們提供自動抄收,自動出賬,自動扣費,遠程繳費,以及自動催收,自動閥控等自動化能耗計量計費及收繳一條龍服務。并且覆蓋了水電氣熱多種能耗類型。

https://image.woshipm.com/wp-files/2022/10/zYtn6DUiGoAHQYMhb40u.png

后續其它功能模塊,也依據上述方式不斷分析挖掘,直到找出業務關鍵,形成業務洞察,建立業務模型,然后在此基礎上進行界面及交互設計。

二、輸出PRD 文檔

有了上述分析的基礎,我們對整個產品功能的認知已經比較全面了,可以開始交互及界面線框設計,著手PRD 文檔的輸出了。

不同于 2C 類產品追求界面與交互的新穎性。2B 類產品注重效率,除大屏類界面最求炫酷外,功能界面一般以簡潔高效為主。交互設計的重點是易用,趨向于使用大眾熟悉的交互方式,不追求花式創新。如果企業設計資源不是很充足,建議直接使用大廠開源的 UI 設計體系,基本上能滿足大多數的 2B 類產品,且界面樣式及交互都在平均水準以上。這樣能節約不少設計資源,減輕前端工程師的工作壓力。利于將不多的研發資源投入到業務實現與功能研發上去。

我們這個項目上,選擇使用了螞蟻的 Ant Design。從產品的線框設計,到 UI,再到前端都使用同一套組件庫,效率提升明顯。

2B 類產品涉及很多業務領域的背景知識,業務規則也相對復雜,簡單的線框+標注的形式很難保證研發人員正確理解需求。因此需要有較為詳細的 PRD 文檔進行輔助說明,幫助團隊對齊業務理解。

我一般會將確認的產品需求放在待辦供團隊成員查看,使團隊成員對后續研發工作胸中有數。在Sprint Retrospective 會議上對下個沖刺的需求做講解與答疑,并在會后將會議上的提出問題更新到 PRD 文檔。

因為時間有限,不太可能按寫論文的嚴格程度去寫 PRD 文檔。我一般會根據項目內容確定一個文檔模板,然后是格式化寫作,內容多是條目式。這當然不完美,但對我而言高效,對團隊溝通也夠用,這就行了。

1. PRD 文檔示例

我從項目中抽取了一個 sprint 的PRD文檔貼在下面,僅供參考。

我從項目中抽取了一個 sprint 的PRD文檔貼在下面,僅供參考。

三、項目總結

實際情況工作中,產品經理不太可能有時間一次性將上述工作全部做完,然后再啟動線框設計。但時間不夠不是不做上述工作的理由,否則會給整個項目埋下天坑,給研發平添工作量。

2B類型的產品,特別是方案級的產品矩陣,相關方眾多,業務復雜,需求多變,尤其需要有產品的頂層設計。否則項目范圍極易蔓延,項目進度失控,極有可能胎死腹中。

當然,過早設置僵化的頂層設計也不可取,很可能導致最終實現與市場需求相去甚遠,企業付出極大的資源與時間成本后,卻得不到相應的市場回報。

個人經驗是采取漸進明細的方式進行規劃設計。進入功能設計前,先要對產品在行業的生態位有清晰認知,在腦海中對產品的全貌有基本輪廓,在這個基礎上進行初步的頂層設計,用以指導后續規劃。然后在做詳細設計的過程中,逐步豐富并修正頂層設計。再用更有血肉的頂層設計,指導后續模塊設計。這是一個交錯進行,相互增強的過程。

在上述方案的規劃設計過程中,我就是用上述方法論,從零開始規劃設計了智慧能耗管理解決方案,并推動整個研發過程。項目團隊以一到兩周一個 sprint 的頻率穩定推進,4個月 不到的時間,我們上線第一個試用版,開啟市場測試。前后持續進行了 24 個增量迭代沖刺,完成解決方案第一階段的軟硬件產品目標,中間沒出現過一次大的需求變更。同時為后續的產品功能拓展及系統拆分留出了數據與功能結構上的插槽。

整個項目過程中,我們始終面向業務規劃,面向市場開發,一直牟定行業痛點,緊盯客戶需求,最終取得了不錯的結果。對照市場定位于行業問題,我們提出并實現了如下功能。

https://image.woshipm.com/wp-files/2022/10/3xNBrCTL4SMfM3vWLAtS.png

通過這次的產品研發,軟件團隊很快熟悉了 scrum 開發模式,技術能力得到了提升。硬件部門也在這個過程中梳理了自己產品組合,構建了園區能耗相關的硬件產品矩陣。

https://image.woshipm.com/wp-files/2022/10/IVGRojjUlWgGXGVqAqDt.png

下面是能耗管理系統企業業務端的部分產品界面展示。是從我給商務做的推介材料上截取的,算不上商業機密。放在此處,讓大家從沉悶的業務分析中放松一下下。

https://image.woshipm.com/wp-files/2022/10/Dmei4X3HWppBYpgKVAvX.png

https://image.woshipm.com/wp-files/2022/10/BdOajCorrbn088ie8U7k.png

https://image.woshipm.com/wp-files/2022/10/7jyRZQCijatLJ4sUZ5Cw.png

https://jasonli-1256314698.cos.ap-shanghai.myqcloud.com/picgo/大屏-能耗項目復盤寫作.gif

在規劃智慧能耗解決方案的過程中,我收獲了對對智慧園區的領域知識,砥礪自身產品設計與項目管理技能,同時也總結了一套規劃與設計 AIoT軟件項目的方法論。這套方法論,對我設計后來的“智慧水務綜合管理系”與“汽車充電管理系統”,幫助甚大。如果大家感興趣的話,以后找時間再分享下這兩個產品的設計過程。

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

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

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 來自浙江 回復
  2. 非常缺此類文章,感謝阿堯

    來自上海 回復