經由過程是不是計費與是不是及時監控這兩個維度，可以將復雜的營業場景劃分為四個場景類型，提煉出了4條數據鏈，并將裝備輸入經由過程紅色數據鏈加工成了數據基座。本文在數據基座的根本上，闡發具體營業實現體例的設計，一路來看一下吧。

之前，我們經由過程是不是計費與是不是及時監控兩個維度，將紛紛復雜的營業場景劃分為了四個場景類型。并抽象了要害營業模子，提煉出了 4 條數據鏈。同時將裝備輸入經由過程紅色數據鏈加工成了數據基座。下面，我們將在數據基座的根本上，最先具體營業實現體例的設計。

這里選擇既有裝備監控又需計費的商務園區場景為方針，進行能耗營業設計。由于這個營業場景，觸及到數據基座中的全數數據鏈的利用。完成這個場景的設計后，其它 3 個場景，只需此根本上設置裝備擺設各自的營業法則，便可以完成各自的營業設計。為簡化問題，我們將裝備這塊內容折疊變換將焦點營業抽象為以下模子。

從模子中可以看出，統計最小計量單位的及時用量，就可以得出分歧區域在分歧時段用量。經由過程查詢用戶利用區域，就可以統計到用戶的耗能環境。經由過程計費法則與出賬法則的計較，就可以獲得用戶賬單費用。

年夜的邏輯是如許的，但現實環境遠比這復雜。就拿付出賬單舉例：商務園區場景下有先用后付及預支后用兩種營業形態，付出體例可分線上與線下兩種體例。同時由于治理體例分歧，預支營業有充值及退還，費用不足提示，透支額度授與，主動閥控反制等營業治理需求；后付業態有滯納賬單等罰性手段等營業治理需求。下圖是對能花費功能的年夜體描寫。

拆分到上面這個水平，我們已對這塊的營業成立起了整體印象，對后續功能的整體走向有了掌控。但認知仍是逗留在宏不雅層面，營業邏輯的顆粒度太年夜，不足以指點系統開辟。需要進一步細化發掘，才能構成對營業的微不雅層面的理解，終究提煉出實現營業的要害路徑，進而設計出對用戶真正有效的功能。

下面抽出后付費模式這個營業場景舉例，其進一步細化闡發以下。

后付費模式（1:1，1:n，n:1）：

內部細節已省略，僅保存要害字段用做申明

經由過程上述的細化闡發后，我們才真正熟悉到現實場景下用戶需求的多樣性，才能設計出籠蓋周全，自在應對多種營業場景的能耗收費功能。而不是一個縫隙百出，需要頻仍打補釘才能運行的收費模塊。

綜合上述闡發與營業模子，設計了按用戶類型設置裝備擺設個性收費方案的功能，籠蓋典型營業場景下的所有業態。對無需收費的內部能耗監控場景而言，不設置裝備擺設收費方案便可。

對需要收費的場景，我們供給主動抄收，主動出賬，主動扣費，長途繳費，和主動催收，主動閥控等主動化能耗計量計費及收繳一條龍辦事。而且籠蓋了水電氣熱多種能耗類型。

后續其它功能模塊，也根據上述體例不竭闡發發掘，直到找出營業要害，構成營業洞察，成立營業模子，然后在此根本長進行界面及交互設計。

有了上述闡發的根本，我們對全部產物功能的認知已比力周全了，可以最先交互及界面線框設計，著手PRD 文檔的輸出了。

分歧于 2C 類產物尋求界面與交互的新奇性。2B 類產物重視效力，除年夜屏類界面最求炫酷外，功能界面一般以簡練高效為主。交互設計的重點是易用，趨勢于利用公共熟習的交互體例，不尋求花式立異。假如企業設計資本不是很足夠，建議直接利用年夜廠開源的 UI 設計系統，根基上能知足年夜大都的 2B 類產物，且界面樣式及交互都在平均水準以上。如許能節儉很多設計資本，減輕前端工程師的工作壓力。利于將不多的研發資本投入到營業實現與功能研發上去。

我們這個項目上，選擇利用了螞蟻的 Ant Design。從產物的線框設計，到 UI，再到前端都利用統一套組件庫，效力晉升較著。

2B 類產物觸及良多營業范疇的布景常識，營業法則也相對復雜，簡單的線框+標注的情勢很難包管研發人員準確理解需求。是以需要有較為具體的 PRD 文檔進行輔助申明，幫忙團隊對齊營業理解。

我一般會將確認的產物需求放在待辦供團隊成員查看，使團隊成員對后續研發工作匠意于心。在Sprint Retrospective 會議上對下個沖刺的需求做講授與答疑，并在會后將會議上的提出問題更新到 PRD 文檔。

由于時候有限，不太可能按寫論文的嚴酷水平去寫 PRD 文檔。我一般會按照項目內容肯定一個文檔模板，然后是格局化寫作，內容多是條目式。這固然不完善，但對我而言高效，對團隊溝通也夠用，這就好了。

我從項目中抽取了一個 sprint 的PRD文檔貼鄙人面，僅供參考。

我從項目中抽取了一個 sprint 的PRD文檔貼鄙人面，僅供參考。

現實環境工作中，產物司理不太可能有時候一次性將上述工作全數做完，然后再啟動線框設計。但時候不敷不是不做上述工作的來由，不然會給全部項目埋下天坑，給研發平增工作量。

2B類型的產物，特殊是方案級的產物矩陣，相干方浩繁，營業復雜，需求多變，特別需要有產物的頂層設計。不然項目規模極易舒展，項目進度掉控，極有可能胎死腹中。

固然，過早設置僵化的頂層設計也不成取，極可能致使終究實現與市場需求相去甚遠，企業支出極年夜的資本與時候本錢后，卻得不到響應的市場回報。

小我經驗是采納漸進明細的體例進行計劃設計。進入功能設計前，先要對產物在行業的生態位有清楚認知，在腦海中對產物的全貌有根基輪廓，在這個根本長進行初步的頂層設計，用以指點后續計劃。然后在做具體設計的進程中，慢慢豐碩并批改頂層設計。再用更有血肉的頂層設計，指點后續模塊設計。這是一個交織進行，彼此加強的進程。

在上述方案的計劃設計進程中，我就是用上述方式論，從零最先計劃設計了聰明能耗治理解決方案，并鞭策全部研發進程。項目團隊以一到兩周一個 sprint 的頻率不變推動，4個月 不到的時候，我們上線第一個試用版，開啟市場測試。前后延續進行了 24 個增量迭代沖刺，完成解決方案第一階段的軟硬件產物方針，中心沒呈現過一次年夜的需求變動。同時為后續的產物功能拓展及系統拆分留出了數據與功能布局上的插槽。

全部項目進程中，我們始終面向營業計劃，面向市場開辟，一向牟定行業痛點，緊盯客戶需求，終究獲得了不錯的成果。對比市場定位于行業問題，我們提出并實現了以下功能。

經由過程此次的產物研發，軟件團隊很快熟習了 scrum 開辟模式，手藝能力獲得了晉升。硬件部分也在這個進程中梳理了本身產物組合，構建了園區能耗相干的硬件產物矩陣。

下面是能耗治理系統企業營業真個部門產物界面展現。是從我給商務做的推介材料上截取的，算不上貿易秘密。放在此處，讓大師從煩悶的營業闡發中輕松一下下。

在計劃聰明能耗解決方案的進程中，我收成了對對聰明園區的范疇常識，砥礪本身產物設計與項目治理技術，同時也總結了一套計劃與設計 AIoT軟件項目標方式論。這套方式論，對我設計后來的“聰明水務綜合治理系”與“汽車充電治理系統”，幫忙甚年夜。假如大師感愛好的話，今后找時候再分享下這兩個產物的設計進程。