畫流程圖真正花時間的地方，通常不在第一次畫，而在後面的每一次改。

需求很少一次就定案

每當提出新需求，或既有功能需要調整時，通常需要與 BU 經過多次討論，逐步釐清業務情境、操作流程及功能範圍。待需求具備初步輪廓後，再將討論結果整理成流程圖，標示各角色的操作步驟、系統之間的串接關係，以及資料的傳遞與回應方式。完成初版流程圖後，仍須由雙方共同檢視並持續修正，以確認對正常流程、例外情境及系統處理邏輯的理解是否一致。

在需求分析階段，流程圖的主要功用是協助溝通與釐清需求，而非已經定案的交付文件。因此，完成的通常只是供討論使用的初稿，後續仍會隨著檢視結果持續補充與修正。

根據實務經驗，BU 往往會在檢視流程圖後，才發現先前未提及或遺漏的判斷條件與例外情境，甚至察覺部分流程與實際作業方式不符。不同角色也會依據各自的職責與使用情境，補充原先未涵蓋的流程細節。即使雙方已在會議中確認流程，後續仍可能受到系統限制、介接方式或資料傳遞規則等因素影響，而需要再次調整。

因此，流程圖在需求分析階段並非一次完成，而是隨著需求逐步收斂，反覆檢視與修正的溝通成果。

需求的反覆調整，本來就是釐清需求的必經過程。真正值得關注的不是「要不要改」，而是每次修改需要付出多少時間與精力。也因此，如何降低「改圖成本」，成為整個過程中的一項重要考量。

嘗試使用 Mermaid 繪製流程圖

採用 Mermaid 後，可以請 AI 協助產生或修改程式碼，再將內容渲染成流程圖。不過實際使用後，我發現這套做法仍有以下幾項問題：

整體版面主要由演算法決定，可控制的空間有限
Mermaid 可以設定流程方向、使用 subgraph 將節點分組，也能透過部分參數間接調整排列結果。不過，節點的實際位置與連線路徑，仍主要由佈局引擎計算。多數情況下，Mermaid 產生的版面已具備一定的可讀性；但如果心中已有明確的版面構想，往往很難將節點與連線精確調整成預期的樣子。（註：佈局引擎是根據節點及其連線關係，自動計算節點排列方式與連線路徑的軟體機制。）

流程規模若較大或複雜時，圖整體的可讀性便容易下降
簡單的流程通常不成問題，但實際的功能流程往往涉及多個系統、不同角色，以及多項判斷條件。隨著節點與連線增加，圖面容易出現線條交錯、區塊過於集中或流程脈絡不易辨識等情況。原本用來協助溝通的流程圖，反而需要花費更多時間查看與解讀。

修改圖主要是透過語法驅動，操作較不直觀
使用 Mermaid 新增節點、調整連線或修改樣式時，通常需要先找到對應的語法，再修改程式碼。對我而言，這增加了一層從視覺需求轉換成語法的成本；對於共同檢視流程圖，甚至希望直接參與修改的同事來說，操作門檻也會更高。

明天，我會分享 draw.io 的實際使用經驗：從手動繪製流程圖，到請 AI 產生與修改 draw.io 圖檔，以及修改局部內容時，可能連帶影響其他區塊的問題。