透過是否計費與是否實時監控這兩個維度，可以將複雜的業務場景劃分為四個場景型別，提煉出了4條資料鏈，並將裝置輸入透過紅色資料鏈加工成了資料基座。本文在資料基座的基礎上，分析具體業務實現方式的設計，一起來看一下吧。

一、設計業務實現方案

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

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

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

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

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

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

後付費模式（1：1，1：n，n：1）：

內部細節已省略，僅保留關鍵欄位用做說明

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

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

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

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

二、輸出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 個增量迭代衝刺，完成解決方案第一階段的軟硬體產品目標，中間沒出現過一次大的需求變更。同時為後續的產品功能拓展及系統拆分留出了資料與功能結構上的插槽。

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

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

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

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

本文由 @阿堯 原創釋出於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於CC0協議。

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