整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
avicat Charts Creator for Mac是Mac平臺上一款專業的圖表工具，Navicat Charts Creator讓你快速安全地連接到你選擇的任何數據源，使用圖表和圖形將你的數據轉換為有效的圖像，讓你對數據有清晰的見解。Navicat Charts Creator 支持連接到許多不同的數據庫：MySQL、MariaDB、PostgreSQL、Oracle、SQLite 和 SQL Server。Navicat Charts Creator 支持多種圖表類型，以有意義的方式表達你的數據。選擇正確的圖表類型可以確保你的問題得到解答，并且確保演示文稿傳達了你想要傳達的信息。Navicat Charts Creator 能夠構建一個交互式儀表板以顯示你的圖表集。結合多種數據視圖以獲取更豐富的見解。你還可以為要追蹤的不同主題創建單獨的儀表板。
https://mac.macxz.com/mac/193220.html?id=MTY4MTYy
Navicat Charts Creator for Mac官方介紹
Navicat Charts Creator 將你的資料轉換為有效的圖像，以識別趨勢、模式和極端值。簡化資料分析并與同事分享你的工作區，以更好地支持你的業務決策和策略。
Navicat Charts Creator mac版功能特點
連接到你選擇的任何資料來源
關聯式資料庫
連接到許多不同的資料庫：MySQL、MariaDB、PostgreSQL、Oracle、SQLite 和SQL Server。
ODBC
從任何ODBC 資料來源（包括Sybase、Snowflake 和DB2）匯入資料。
檔案類型
從外部檔案（例如Excel、Access、CSV）匯入資料，或匯入儲存在電子、網路或網址上的資料。
連結檔案
將圖表連結到資料來源中的資料，以根據基礎資料的變化更新圖表。
建置自己的自訂圖表
多種圖表類型，以有意義的方式表達你的資料。選擇正確的圖表類型可以確保你的問題得到解答，并且確保你的演示傳達了你想要傳達的信息。
建立有效的儀表板
建置一個互動式儀表板以顯示你的圖表集。組合多種資料檢視以得到更豐富的見解。你還可以為要追蹤的不同主題建立單獨的儀表板。
與Navicat 協同合作完全集成。
將你的圖表工作區同步到我們的云端服務，并邀請你的團隊成員加入專案，一起建立和編輯檔案。
其他實用的功能：
- 群組圖表
- 控制項圖表
- 每個儀表板的縮略圖預覽
小編點評
Navicat Charts Creator 是一款專業且友好的圖表工具，Navicat Charts Creator支持 20 多種圖表類型：條形圖、折線圖或面積圖、餅圖、熱圖或樹狀圖、數據透視表、瀑布圖、散點圖、值、控件、KPI 或儀表盤等，Navicat Charts Creator 中的數據可隨著鼠標的移動而聯動；如果你想向決策者分享分析結果，可以通過點擊“顯示”按鈕全屏展示自定義儀表盤，從數據分析到結果匯報一站式搞定。
GoJS是一款功能強大，快速且輕量級的流程圖控件，在現代的Web瀏覽器平臺上可實現自定義交互圖和復雜的可視化。GoJS通過定制模板和布局使復雜node，鏈接以及用戶組的JS圖表構造更加容易。
GOJS為用戶交互性提供更多先進的功能，例如拖拽，復制粘貼，文本編輯，工具提示，快捷菜單，自動布局，模板，數據關聯和型號，處理狀態和撤銷管理，調色板，概述、事件處理程序、命令，以及一個可擴展工具系統的自定義操作。
用戶無需服務器和插件就能實現交互，一般可在瀏覽器上完全運行，不需要任何的服務器端就可以直接渲染一個HTML5 Canvas元素或SVG。GOJS不依賴于任何的JS庫或框架，能夠與任意HTML或JS框架協作運行，有時候，甚至根本不需要框架。
利用GOJS的強大功能可以建立自定義的建模環境，領域特定的視覺語言，一個系統編輯器和使用共享代碼及模板的只讀狀態監控器，在不同的圖表里能顯示相同數據的選擇可視化，采用子樹、子圖或其它圖表的詳細視圖擴展并進一步深入研究。
GOJS因本身具有強大靈活的系統而變得非常簡單。許多文檔的頁面介紹了其基本概念，并展示了大多數應用程序都想要提供的典型功能。節點和鏈接可根據實際需要再做詳細的說明。API接口由幾十個重要的類組成，這些類分別概述了許多相互作用之間的有效功能。其中一些都是允許做簡單自定義設置的，有些可能也需要更復雜的自定義重寫。
GOJS示例：
（1）SVG圖標示例：
此圖顯示了幾個“圖標”原本的SVG路徑，作為形狀GOJS，所有圖標都是顯示在一個樹狀圖里，不同的是，注意下圖，所有圖標則顯示在一塊更大的區域里面。
你也可以采用自己喜歡的一些幾何圖形，然后在GOJS上添加各種形狀，或著直接復制SVG路徑字符串。按照以上方法操作出現如下圖所示：
（2）GOJS導航圖
上圖展示的是同一個圖標不同部分之間的關系：
選擇一個節點或鏈接，用單選框直接突出確定因素和唯一因素之間的關系，其中，突出部分的顏色取決于各部分之間的“距離”。
（3）GoJS箭頭
這個例子展示的是所有預定義的GOJS箭頭。把鼠標放在一個節點或鏈接上就能看到箭頭的名字，每個鏈接均對應顯示兩個箭頭。鏈接模板都有確定的形狀,箭頭自身屬性決定了它的名字。模板中不同形狀的箭頭，其屬性就代表了不同箭頭的名字，每個箭頭均是按比例增大得，這樣看起來會更清晰一些。
智能社 撰稿，轉載請注明來源！！
023年9月9—10日，人人都是產品經理聯合騰訊大講堂舉辦的【2023產品經理大會·北京站】完美落幕。和度軟件CEO、軟件地圖創始人程杰老師，為我們帶來《B端數字化產品的敏捷設計建模技術與實戰方法》為題的分享，本文為演講內容實錄。目前大會回放已上架，戳此購買，即可收看回放：https://996.pm/7gX2B
今天我分享的主題是“B端數字化產品的敏捷設計建模技術與實戰方法”，主要分四個維度進行：
這幅圖是軟件工程當中的一張經典圖片，它反映了軟件工程里各個環節的溝通失真問題。而溝通失真會給軟件工程帶來很多問題，比如返工多、加班多；變更多、應對慢；用戶認可難，實施難、上線難、驗收難；包括預算超支嚴重，甲乙雙方都覺得有所虧損，合作瀕于崩潰。
實際上，當我們跳出軟件工程行業，會發現，其他的工程行業在設計環節都會輸出規范化、結構化的設計圖紙，但是軟件工程到現在為止還是使用非結構化的設計文檔。很諷刺的一點，即創造 AI 的軟件工程實際上是很“落后”的。
所以，軟件工程溝通失真的根本原因在于：設計環節沒有輸出可以“降低溝通成本、驅動工程全流程、降低系統性風險”的結構化、可視化的設計模型。各個環節當中的溝通失真問題，實際上是設計環節出了問題。
但其實軟件工程行業是有設計建模技術的。2002年OMG提出了MDA（模型驅動的軟件開發架構），但大家并沒有將其投入使用，原因在于：
所以可以得出一個結論——軟件工程行業亟需一套實用的軟件設計建模技術與系統，解決以“大量實際軟件工程仍在使用非結構化設計文檔”為表征的行業性設計不規范、設計不可視、設計質量低的問題，及其引起的軟件開發與運維過程中的“溝通失真”與大量浪費。
基于以上分析，我們做了一個自研項目，叫軟件地圖，我們希望研發出一套實用的軟件設計建模技術和系統，應滿足以下要求：
總結一點，即：快，才實用。
整體項目于2020年10月份啟動，21年9月份，我們上線了第一版，10月份的時候，軟件地圖就已經應用到一個千萬級的軟件定制化開發項目當中。23年2月份，我們發布了第二版應用，并在3月份應用到在線系統運維當中；6月份則發布了第三版。
主要功能如圖所示，包括了新型制圖功能、模板庫、全流程設計建模功能，等等。目的即降低溝通成本，提升可視化功能與自動化功能。
這里分享一個案例。
2021年，我們需要為一家服裝外貿龍頭企業搭建全流程的數字化運營平臺，即服裝ERP。這個項目屬于從0到1式的全定制開發，業務邏輯非常復雜，包括2800+系統功能、1000+用戶界面、600+數據表、對接66個外部系統接口，對軟件設計能力有很大挑戰，一不小心即會陷入設計黑洞。在當時，我帶領20多個人，分為7個開發小組，使用軟件地圖在線協同設計建模，并取得了顯著成果：
而從案例可以看出，當設計質量提高、溝通成本下降，效益也就有所提升。
再分享一個案例，當時，全球最大的針織服裝制造集團需要應用軟件地圖，對十多個在線核心業務系統進行逆向建模，理清各系統復雜邏輯，構建在線軟件設計圖紙，大幅提高運維效率，降低迭代升級風險，最終獲得了收益：
為什么運用了軟件地圖之后，設計效率、運維效率可以得到大幅提升，開發成本和BUG率可以被大幅降低？這里涉及了一個核心技術——敏捷設計建模技術。接下來講講原因所在。
我們的模型結構涵蓋了幾個方面，包括業務模型、產品模型、程序模型：
第一個核心技術，即業務模型中心驅動（BCD），它解決了 MDA 三個階段性模型的問題。而在分析與設計的過程當中，始終只有一個模型，這個模型集成了業務模型、產品模型跟程序模型；并且始終以業務模型為中心，迭代式驅動構建產品模型和程序模型。業務模型不會被拋棄，而是會迭代出結構化的業務邏輯，即數據能力——算法，并被其他模型所調用。如此，相較于MDA，BCD可以大幅提升建模效率、一致性、集成性和變更敏捷性。
如何理解？即在分析、設計與開發過程中，使用了一個大的相同結構，避免異構現象的發生，也降低或避免結構轉換之間的溝通失真與損耗。我們要求產品經理一開始就使用MVC設計框架，也方便了后續和研發團隊之間的溝通。
那么我們是如何開展的呢？從需求開始（需求包括現狀流程以及基于現狀流程的系統需求），我們分析得出過程中的業務對象（B端需求分析一定要分析出業務對象），隨后分析得出處理業務對象的能力，即數據結構+數據能力。由數據能力，則可以推出系統功能。而在考慮系統功能的用例設計時，必然會涉及到輸入輸出界面，由此驅動開發界面。在界面的詳細數據項得到用戶確認后，再結合業務對象的數據結構，即可合起來，共同構成數據表以及表字段。最后，數據能力會演化為服務端的API，界面中的算法則演化為用戶端的API。
第二個核心技術，即可視化動態樹。傳統的圖元組裝式建模技術是有較大弊端的：
所以，我們所有的模型構建統一使用樹狀圖建模，即所有的模型都是思維導圖式的，預定義了 100 多種具有特定語義和樣式的模型節點，實現了模型的結構化、可視化。此外，樹狀圖本身是可聚合、可發散的，符合人類的閱讀和理解習慣。而建模時無需要布局對齊、調整大小、可快速鍵盤操作等優勢，則大幅提升了建模效率。某種程度上，我們其實是做了一個為軟件工程而定制的思維導圖。
第三個核心技術，即業務組件模板，即我們可以一鍵生成圍繞業務對象的設計制品，包括數據表、系統功能、界面原型等等。而設計同學此時只需要明確分析得出的業務單據需匹配什么模板，之后一鍵生成好即可。這大大提升了設計效率與設計規范度，實現了模板化。
第四個核心技術，綠色的模型轉換技術。模型最終要轉換成程序源碼，同時底層軟件包由用戶單位自行設定，即用戶對生成的程序源碼完全自主可控。
總結可得，軟件地圖在多維度上取得了“敏捷化、實用化”的突破，和UML相比，軟件地圖在閱讀效率、設計信息集成度、設計效率、建模效率、變更效率等各方面都取得了很大突破。
我們希望通過敏捷化、實用化的軟件設計建模技術和工具促進軟件工程在分析和設計這兩個上游階段的數字化轉型，在源頭上解決溝通難、返工多、預算高、風險高、運維壓力大和應變慢等普遍存在的軟件工程問題。
另外，我們希望可以鏈接大模型平臺，通過“軟件設計模型+編程大模型”，構建“數字化設計+AI編程”新型軟件工程模式，優化軟件工程成本結構，大幅降低軟件工程成本，大幅縮短軟件工程交期，大幅提升軟件工程質量。
同時，我們還希望助力千行百業數字化轉型，構建開源設計社區。
其一，通過軟件邏輯的結構化、可視化和模板化，合作構建各行業應用軟件設計模板庫，大幅提升各行業數字化轉型落地速度和質量，大幅降低成本和風險，大幅減少數字化爛尾工程和豆腐渣工程，促進更多企業數字化轉型“敢轉、愿轉、轉好”。
其二，通過大幅降低軟件設計的能力門檻，在千行百業中普及推廣軟件設計能力，為各企業及機構培養數字化人才，加速業務與IT融合。
其三，推動ERP等重點開源設計項目，對標GITHUB，構建開源設計社區。
我們將軟件全棧設計過程進行了定義，包括八大過程——需求分析、業務藍圖設計、人機交互設計、系統接口設計、數據庫設計、算法設計、程序設計和測試設計；和產品經理更密切相關的可能是前三個部分，后面將詳細講述。
同時我們也定義了各個過程的產出物，以及在線系統逆向建模過程。
關于需求分析，我們定義了5個活動，包括：構建業務地圖、分析現狀業務流程、梳理系統需求、分析業務對象和確認業務需求。
首先，建立需求分析的框架，防止用戶單位“飄”出去。這個框架可以稱之為業務地圖。什么是業務地圖？即多層級的業務模塊以及下面掛載的業務流程。
接著，繪制流程圖。我們需要進一步劃分，構建流程內的結構。可以按照工作崗位和業務事件劃分業務作業，然后按先后順序、因果關系，串接業務作業，這就構成了業務流程圖。
注意，這是現狀業務流程圖，現狀業務流程需要快速構建，而后描述每一個業務作業的場景和數據處理。這里有一個觀點，即理解了業務數據，才算是真正理解了業務場景。一定要花時間研究業務數據。我們可以將所有業務數據列出來，其后將樣本數據全部放置其上，后續于此基礎上梳理系統需求，這個時候，梳理的每個系統需求都要落到一個業務作業當中去。
同時注意，千萬不要照搬業務人員所講的話，一定要做分類與歸納。
最終，需求分析一定要分析出業務作業處理的業務對象。在B端場景下，業務對象可能是業務單據，而業務單據承載著系統需求，我們需要將系統需求落地到業務對象的管理場景與應用場景，根據樣本數據與系統需求，分析業務對象的數據結構。
業務藍圖設計包括5個動作：設計核心數據邏輯、定義數據能力、設計功能地圖、設計目標業務流程、確認業務藍圖。這里重點要理解核心數據邏輯：
核心數據邏輯=數據結構+數據狀態+數據演變
核心數據邏輯是業務模型的核心，是整個系統的地基，即便不是開發同學，也需要在抽象層次上理解數據邏輯，否則就只能被開發同學反復“折磨”。所以，核心數據邏輯為整個設計過程提供了可行性邏輯內核，驅動后續設計，并持續迭代。另外需注意，B端數字化產品設計，切忌“界面原型驅動”。
首先，設計核心數據邏輯的第一步是構建業務對象的數據結構與數據關系，我們需要定義構成業務對象的數據元素。數據元素的顆粒度非常重要，但不需要到非常明細的數據字段。而某個數據元素與業務對象或上級元素的關系只有兩種類型：最多1份或最多N份。
這個數據結構不需要像“類”那樣復雜，只需要弄清楚其包含關系即可，比如這個款式檔案應該由哪幾份數據構成，可能有一份正式版數據、一份變更版數據，最多再有一份快照版數據。至于這些數據將會被存儲在哪些表格中，則是自然而然的事情。
接著，我們需要按需定義業務對象每個數據元素的狀態參數。
最終，我們便得到了數據演變圖，在這里，數據演變圖設計了業務對象及其數據元素的生命周期，由若干 {數據能力+其產生的數據變化} 二元節點組構成，表達了業務對象的核心邏輯。
綜合以上，我便可以在抽象層次上將數據演變展示出來，既不需要編程，也沒有數據表的設計，僅僅是數據結構+概要算法。
基于上述設計得出的數據演變，隨后，我們逐個定義數據演變圖中的數據能力，規范化定義數據能力的名稱和代碼（隨后我們會在這一基礎上生成API）。
接著便是定義系統功能，結合多層級的功能模塊，以業務架構為基礎，橫向擴展通用功能模塊和基礎功能模塊，縱向擴展到業務對象級模塊。
隨后，基于新的系統功能設計目標業務流程。目標業務流程可以理解為強制性的作業規范，它的要求會更為嚴謹。
在業務流程設計好了之后，我們需要更加細致地設計業務作業，說明在什么場景中執行該業務作業以及主要執行步驟、執行過程需要使用哪些系統功能、注意事項，等等。
在目標業務流程得到用戶單位認可，且業務流程是構建在可行性的數據邏輯的基礎之上時，我們便可進入到人機交互設計了。
總共包括5個動作——設計功能用例、設計界面地圖、制作界面原型、設計集成用例、確認系統原型。
首先，功能用例可能如圖所示，包含了用戶操作和系統相應的序列。
接著，設計界面地圖，大致步驟如下：
1）設計界面架構（多層級界面入口）
2）定義用戶界面 & 設計界面要素
界面要素是下階段制作界面原型的界面關鍵元素，包括：
3）生成界面地圖
下一個動作便是制作界面原型。注意，每個界面可能有多個模式，如果原型缺失界面模式，將導致原型確認失效，這也是后續發生設計變更的重要原因之一。
接著，設計集成用例，即集成多個相關功能用例，在系統響應后面設置集成界面事件、界面模式等。集成用例是重要的設計產出物，因為它可以進行仿真演示，與客戶確認系統原型，并在系統上線后培訓用戶。此外，它還可以導出PRD、測試用例、產品操作手冊。
最終，便是確認系統原型，按集成用例預設路徑確定性地與客戶確認。
除了上面所說的三個過程，此外還有：
系統接口設計，包括：定義外聯系統、設計接口地圖、設計外聯接口參數、設計接口功能參數、確認系統接口。
數據庫設計，包括：定義數據庫、設計數據地圖、設計數據標準、設計數據表、生成數據庫。
如圖所示，這個數據地圖清晰地標識出了數據模塊、模塊當中的業務對象和相應的數據表，點擊之后，即可查看數據表詳情。
算法設計，包括設計數據能力算法、設計用戶界面算法、設計接口功能算法、設計定時功能算法。
程序設計，包括設計子系統、設計程序地圖、設計DTO、設計API、生成程序源碼。
如圖所示，在子系統中，我們會設計程序模塊以及相應的類。在形成程序地圖、設計API后，最終，則可以生成程序源碼，而這些程序源碼，都為低價值編程代碼。
測試設計，包括配置API測試環境、生成API測試腳本、設計集成用例、生成集成測試用例。
從前面所講的內容來看，是不是覺得有些復雜？因為設計已經走向細顆粒度的結構化，而這必然帶來較大的工作量。這個時候，我們需要提供業務組件模板庫，以提高設計效率，降低設計門檻。模板里面包含：
我們一直在說“不要重復造輪子”，但實際上“重復造輪子”的事情一直在發生，是因為我們將業務組件固化在了代碼級別。基于這點，我們的處理策略便是將其抽象至設計圖紙層級，這樣子改起來快，看起來也更清楚、明白。
我們也希望可以建立一個開源設計社區，里面有大量的模板、參考資料和資源，方便大家查找。
目前大會回放已上架，戳此購買，即可收看回放：https://996.pm/7gX2B
本文為【2023年產品經理大會 · 北京站】 現場分享整理內容，由人人都是產品經理運營@Norah 整理發布。未經許可，禁止轉載，謝謝合作。
題圖來自大會現場
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
