起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識B端數字化產品的敏捷設計建模技術與實戰方法
2023年9月9—10日，人人都是產品經理聯合騰訊大講堂舉辦的【2023產品經理大會·北京站】完美落幕。和度軟件CEO、軟件地圖創始人程杰老師，為我們帶來《B端數字化產品的敏捷設計建模技術與實戰方法》為題的分享，本文為演講內容實錄。目前大會回放已上架，戳此購買，即可收看回放：https://996.pm/7gX2B
今天我分享的主題是“B端數字化產品的敏捷設計建模技術與實戰方法”，主要分四個維度進行：
- 問題與分析；
- 研發與應用；
- 技術與愿景；
- 實戰方法。
一、問題與分析
這幅圖是軟件工程當中的一張經典圖片，它反映了軟件工程里各個環節的溝通失真問題。而溝通失真會給軟件工程帶來很多問題，比如返工多、加班多；變更多、應對慢；用戶認可難，實施難、上線難、驗收難；包括預算超支嚴重，甲乙雙方都覺得有所虧損，合作瀕于崩潰。
實際上，當我們跳出軟件工程行業，會發現，其他的工程行業在設計環節都會輸出規范化、結構化的設計圖紙，但是軟件工程到現在為止還是使用非結構化的設計文檔。很諷刺的一點，即創造 AI 的軟件工程實際上是很“落后”的。
所以，軟件工程溝通失真的根本原因在于：設計環節沒有輸出可以“降低溝通成本、驅動工程全流程、降低系統性風險”的結構化、可視化的設計模型。各個環節當中的溝通失真問題，實際上是設計環節出了問題。
但其實軟件工程行業是有設計建模技術的。2002年OMG提出了MDA（模型驅動的軟件開發架構），但大家并沒有將其投入使用，原因在于：
- UML建模慢，跟不上開發節奏；
- UML圖例繁雜，閱讀效率低，溝通成本高；
- 需求發生變更后，CIM/PIM/PSM三個模型都改嗎？還是只改部分？前者面臨效率問題，后者則面臨著一致性問題。
所以可以得出一個結論——軟件工程行業亟需一套實用的軟件設計建模技術與系統，解決以“大量實際軟件工程仍在使用非結構化設計文檔”為表征的行業性設計不規范、設計不可視、設計質量低的問題，及其引起的軟件開發與運維過程中的“溝通失真”與大量浪費。
二、研發與應用
基于以上分析，我們做了一個自研項目，叫軟件地圖，我們希望研發出一套實用的軟件設計建模技術和系統，應滿足以下要求：
- 項目各方對于設計模型都能夠讀懂、理解，而且閱讀效率高；
- 設計建模快、變更快，設計模型可詳可略、靈活可控，能適應開發節奏；
- 設計規范性和質量大幅提升，可以快速、充分地評審設計，大幅降低項目風險；
- 由設計模型可以自動生成程序源碼、測試用例，大幅降低開發成本；
- 可支撐大型項目協同化設計建模；
- 學習快、上手快。
總結一點，即：快，才實用。
整體項目于2020年10月份啟動，21年9月份，我們上線了第一版，10月份的時候，軟件地圖就已經應用到一個千萬級的軟件定制化開發項目當中。23年2月份，我們發布了第二版應用，并在3月份應用到在線系統運維當中；6月份則發布了第三版。
主要功能如圖所示，包括了新型制圖功能、模板庫、全流程設計建模功能，等等。目的即降低溝通成本，提升可視化功能與自動化功能。
這里分享一個案例。
2021年，我們需要為一家服裝外貿龍頭企業搭建全流程的數字化運營平臺，即服裝ERP。這個項目屬于從0到1式的全定制開發，業務邏輯非常復雜，包括2800+系統功能、1000+用戶界面、600+數據表、對接66個外部系統接口，對軟件設計能力有很大挑戰，一不小心即會陷入設計黑洞。在當時，我帶領20多個人，分為7個開發小組，使用軟件地圖在線協同設計建模，并取得了顯著成果：
- 提升了設計規范性、質量和效率，降低了溝通成本；
- 自動生成了服務端程序50%的源碼；
- 程序員每人每天平均產出300行有效源碼（不含自動生成的代碼），高效保障項目成功交付。
而從案例可以看出，當設計質量提高、溝通成本下降，效益也就有所提升。
再分享一個案例，當時，全球最大的針織服裝制造集團需要應用軟件地圖，對十多個在線核心業務系統進行逆向建模，理清各系統復雜邏輯，構建在線軟件設計圖紙，大幅提高運維效率，降低迭代升級風險，最終獲得了收益：
為什么運用了軟件地圖之后，設計效率、運維效率可以得到大幅提升，開發成本和BUG率可以被大幅降低？這里涉及了一個核心技術——敏捷設計建模技術。接下來講講原因所在。
三、技術與愿景
我們的模型結構涵蓋了幾個方面，包括業務模型、產品模型、程序模型：
- 業務模型：包括業務架構、業務流程、業務對象；
- 產品模型：包括數據表、系統功能、用戶界面、接口等；
- 程序模型：包括子系統、API、DTO。
第一個核心技術，即業務模型中心驅動（BCD），它解決了 MDA 三個階段性模型的問題。而在分析與設計的過程當中，始終只有一個模型，這個模型集成了業務模型、產品模型跟程序模型；并且始終以業務模型為中心，迭代式驅動構建產品模型和程序模型。業務模型不會被拋棄，而是會迭代出結構化的業務邏輯，即數據能力——算法，并被其他模型所調用。如此，相較于MDA，BCD可以大幅提升建模效率、一致性、集成性和變更敏捷性。
如何理解？即在分析、設計與開發過程中，使用了一個大的相同結構，避免異構現象的發生，也降低或避免結構轉換之間的溝通失真與損耗。我們要求產品經理一開始就使用MVC設計框架，也方便了后續和研發團隊之間的溝通。
那么我們是如何開展的呢？從需求開始（需求包括現狀流程以及基于現狀流程的系統需求），我們分析得出過程中的業務對象（B端需求分析一定要分析出業務對象），隨后分析得出處理業務對象的能力，即數據結構+數據能力。由數據能力，則可以推出系統功能。而在考慮系統功能的用例設計時，必然會涉及到輸入輸出界面，由此驅動開發界面。在界面的詳細數據項得到用戶確認后，再結合業務對象的數據結構，即可合起來，共同構成數據表以及表字段。最后，數據能力會演化為服務端的API，界面中的算法則演化為用戶端的API。
第二個核心技術，即可視化動態樹。傳統的圖元組裝式建模技術是有較大弊端的：
- 閱讀效率低；沒有顯性的閱讀路徑，圖源多了以后，圖很凌亂，有效承載的信息量大大受限；再者，表達顆粒度固化，無法在一張圖當中按需切換，查看全局和細節；
- 建模效率低：調整圖元位置、大小，都相對費時。
所以，我們所有的模型構建統一使用樹狀圖建模，即所有的模型都是思維導圖式的，預定義了 100 多種具有特定語義和樣式的模型節點，實現了模型的結構化、可視化。此外，樹狀圖本身是可聚合、可發散的，符合人類的閱讀和理解習慣。而建模時無需要布局對齊、調整大小、可快速鍵盤操作等優勢，則大幅提升了建模效率。某種程度上，我們其實是做了一個為軟件工程而定制的思維導圖。
第三個核心技術，即業務組件模板，即我們可以一鍵生成圍繞業務對象的設計制品，包括數據表、系統功能、界面原型等等。而設計同學此時只需要明確分析得出的業務單據需匹配什么模板，之后一鍵生成好即可。這大大提升了設計效率與設計規范度，實現了模板化。
第四個核心技術，綠色的模型轉換技術。模型最終要轉換成程序源碼，同時底層軟件包由用戶單位自行設定，即用戶對生成的程序源碼完全自主可控。
總結可得，軟件地圖在多維度上取得了“敏捷化、實用化”的突破，和UML相比，軟件地圖在閱讀效率、設計信息集成度、設計效率、建模效率、變更效率等各方面都取得了很大突破。
我們希望通過敏捷化、實用化的軟件設計建模技術和工具促進軟件工程在分析和設計這兩個上游階段的數字化轉型，在源頭上解決溝通難、返工多、預算高、風險高、運維壓力大和應變慢等普遍存在的軟件工程問題。
另外，我們希望可以鏈接大模型平臺，通過“軟件設計模型+編程大模型”，構建“數字化設計+AI編程”新型軟件工程模式，優化軟件工程成本結構，大幅降低軟件工程成本，大幅縮短軟件工程交期，大幅提升軟件工程質量。
同時，我們還希望助力千行百業數字化轉型，構建開源設計社區。
其一，通過軟件邏輯的結構化、可視化和模板化，合作構建各行業應用軟件設計模板庫，大幅提升各行業數字化轉型落地速度和質量，大幅降低成本和風險，大幅減少數字化爛尾工程和豆腐渣工程，促進更多企業數字化轉型“敢轉、愿轉、轉好”。
其二，通過大幅降低軟件設計的能力門檻，在千行百業中普及推廣軟件設計能力，為各企業及機構培養數字化人才，加速業務與IT融合。
其三，推動ERP等重點開源設計項目，對標GITHUB，構建開源設計社區。
四、實戰方法
我們將軟件全棧設計過程進行了定義，包括八大過程——需求分析、業務藍圖設計、人機交互設計、系統接口設計、數據庫設計、算法設計、程序設計和測試設計；和產品經理更密切相關的可能是前三個部分，后面將詳細講述。
同時我們也定義了各個過程的產出物，以及在線系統逆向建模過程。
1. 需求分析
關于需求分析，我們定義了5個活動，包括：構建業務地圖、分析現狀業務流程、梳理系統需求、分析業務對象和確認業務需求。
首先，建立需求分析的框架，防止用戶單位“飄”出去。這個框架可以稱之為業務地圖。什么是業務地圖？即多層級的業務模塊以及下面掛載的業務流程。
接著，繪制流程圖。我們需要進一步劃分，構建流程內的結構?？梢园凑展ぷ鲘徫缓蜆I務事件劃分業務作業，然后按先后順序、因果關系，串接業務作業，這就構成了業務流程圖。
注意，這是現狀業務流程圖，現狀業務流程需要快速構建，而后描述每一個業務作業的場景和數據處理。這里有一個觀點，即理解了業務數據，才算是真正理解了業務場景。一定要花時間研究業務數據。我們可以將所有業務數據列出來，其后將樣本數據全部放置其上，后續于此基礎上梳理系統需求，這個時候，梳理的每個系統需求都要落到一個業務作業當中去。
同時注意，千萬不要照搬業務人員所講的話，一定要做分類與歸納。
最終，需求分析一定要分析出業務作業處理的業務對象。在B端場景下，業務對象可能是業務單據，而業務單據承載著系統需求，我們需要將系統需求落地到業務對象的管理場景與應用場景，根據樣本數據與系統需求，分析業務對象的數據結構。
2. 業務藍圖設計
業務藍圖設計包括5個動作：設計核心數據邏輯、定義數據能力、設計功能地圖、設計目標業務流程、確認業務藍圖。這里重點要理解核心數據邏輯：
核心數據邏輯=數據結構+數據狀態+數據演變
核心數據邏輯是業務模型的核心，是整個系統的地基，即便不是開發同學，也需要在抽象層次上理解數據邏輯，否則就只能被開發同學反復“折磨”。所以，核心數據邏輯為整個設計過程提供了可行性邏輯內核，驅動后續設計，并持續迭代。另外需注意，B端數字化產品設計，切忌“界面原型驅動”。
首先，設計核心數據邏輯的第一步是構建業務對象的數據結構與數據關系，我們需要定義構成業務對象的數據元素。數據元素的顆粒度非常重要，但不需要到非常明細的數據字段。而某個數據元素與業務對象或上級元素的關系只有兩種類型：最多1份或最多N份。
這個數據結構不需要像“類”那樣復雜，只需要弄清楚其包含關系即可，比如這個款式檔案應該由哪幾份數據構成，可能有一份正式版數據、一份變更版數據，最多再有一份快照版數據。至于這些數據將會被存儲在哪些表格中，則是自然而然的事情。
接著，我們需要按需定義業務對象每個數據元素的狀態參數。
最終，我們便得到了數據演變圖，在這里，數據演變圖設計了業務對象及其數據元素的生命周期，由若干 {數據能力+其產生的數據變化} 二元節點組構成，表達了業務對象的核心邏輯。
綜合以上，我便可以在抽象層次上將數據演變展示出來，既不需要編程，也沒有數據表的設計，僅僅是數據結構+概要算法。
基于上述設計得出的數據演變，隨后，我們逐個定義數據演變圖中的數據能力，規范化定義數據能力的名稱和代碼（隨后我們會在這一基礎上生成API）。
接著便是定義系統功能，結合多層級的功能模塊，以業務架構為基礎，橫向擴展通用功能模塊和基礎功能模塊，縱向擴展到業務對象級模塊。
隨后，基于新的系統功能設計目標業務流程。目標業務流程可以理解為強制性的作業規范，它的要求會更為嚴謹。
在業務流程設計好了之后，我們需要更加細致地設計業務作業，說明在什么場景中執行該業務作業以及主要執行步驟、執行過程需要使用哪些系統功能、注意事項，等等。
在目標業務流程得到用戶單位認可，且業務流程是構建在可行性的數據邏輯的基礎之上時，我們便可進入到人機交互設計了。
3. 人機交互設計
總共包括5個動作——設計功能用例、設計界面地圖、制作界面原型、設計集成用例、確認系統原型。
首先，功能用例可能如圖所示，包含了用戶操作和系統相應的序列。
接著，設計界面地圖，大致步驟如下：
1）設計界面架構（多層級界面入口）
2）定義用戶界面 & 設計界面要素
界面要素是下階段制作界面原型的界面關鍵元素，包括：
- 數據控件及其事件、事件中的界面流轉與模式轉化；
- 界面事件、事件中的界面流轉與模式轉化。
3）生成界面地圖
下一個動作便是制作界面原型。注意，每個界面可能有多個模式，如果原型缺失界面模式，將導致原型確認失效，這也是后續發生設計變更的重要原因之一。
接著，設計集成用例，即集成多個相關功能用例，在系統響應后面設置集成界面事件、界面模式等。集成用例是重要的設計產出物，因為它可以進行仿真演示，與客戶確認系統原型，并在系統上線后培訓用戶。此外，它還可以導出PRD、測試用例、產品操作手冊。
最終，便是確認系統原型，按集成用例預設路徑確定性地與客戶確認。
除了上面所說的三個過程，此外還有：
系統接口設計，包括：定義外聯系統、設計接口地圖、設計外聯接口參數、設計接口功能參數、確認系統接口。
數據庫設計，包括：定義數據庫、設計數據地圖、設計數據標準、設計數據表、生成數據庫。
如圖所示，這個數據地圖清晰地標識出了數據模塊、模塊當中的業務對象和相應的數據表，點擊之后，即可查看數據表詳情。
算法設計，包括設計數據能力算法、設計用戶界面算法、設計接口功能算法、設計定時功能算法。
程序設計，包括設計子系統、設計程序地圖、設計DTO、設計API、生成程序源碼。
如圖所示，在子系統中，我們會設計程序模塊以及相應的類。在形成程序地圖、設計API后，最終，則可以生成程序源碼，而這些程序源碼，都為低價值編程代碼。
測試設計，包括配置API測試環境、生成API測試腳本、設計集成用例、生成集成測試用例。
從前面所講的內容來看，是不是覺得有些復雜？因為設計已經走向細顆粒度的結構化，而這必然帶來較大的工作量。這個時候，我們需要提供業務組件模板庫，以提高設計效率，降低設計門檻。模板里面包含：
- 基礎組件：數據字典、組織管理、用戶管理、權限管理、文件管理等；
- 通用組件：按有無狀態、單/多崗管理、單/多版、單/多層、界面模式等劃分；
- 專用組件：按行業、應用劃分，例如：銀行、電力、制造業ERP、制造業MES等。
我們一直在說“不要重復造輪子”，但實際上“重復造輪子”的事情一直在發生，是因為我們將業務組件固化在了代碼級別?；谶@點，我們的處理策略便是將其抽象至設計圖紙層級，這樣子改起來快，看起來也更清楚、明白。
我們也希望可以建立一個開源設計社區，里面有大量的模板、參考資料和資源，方便大家查找。
大會直播回放
目前大會回放已上架，戳此購買，即可收看回放：https://996.pm/7gX2B
本文為【2023年產品經理大會 · 北京站】 現場分享整理內容，由人人都是產品經理運營@Norah 整理發布。未經許可，禁止轉載，謝謝合作。
題圖來自大會現場
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論，等你發揮！
