需求討論到一半，有人說「先畫個流程圖吧」，然後畫出來的東西每個人理解都不一樣：業主看到的是自己公司的作業步驟，工程師看到的是程式判斷，主管則想知道資料最後跑到哪裡去。問題不在誰畫得不好，而是大家沒有先講好這張圖要表達什麼、用哪一套符號。這篇不談專案怎麼推進，只聚焦流程圖本身：常見符號各自代表什麼、流程圖和資料流程圖差在哪裡，以及怎麼畫出開發者與業主都能看懂的圖。
流程圖在專案裡實際被拿來做什麼
它的價值在於把口頭描述固定下來。訪談時大家講得很順，寫成文字卻各自解讀，畫成圖之後分歧會立刻現形：某個步驟到底誰執行、遇到例外要退回哪一步、有沒有第二個審核關卡，這些在圖上是空白還是有線連著，一眼就看得出來。
圖也是驗收的依據。開發完成後對照當初的圖逐條確認，比翻聊天紀錄可靠。更實際的用途是找出被忽略的分支，多數專案後期的追加需求，其實都是當初圖上沒有畫出來的例外路徑，例如取消、退回、資料重複、審核者請假。畫圖的過程本身，就是在逼所有人把例外講出來。
常見符號代表什麼，別自己發明
符號有一套約定俗成的用法，混用會讓圖失去溝通功能。
- 圓角矩形：起點與終點，一張圖應該有明確的開始，結束可以有多個。
- 矩形：處理步驟，寫的是動作，例如建立訂單、寄出通知，用動詞開頭最不會誤會。
- 菱形：判斷點，只放是非題或明確選項，每條分支都要標上條件文字，不能有沒標記的線。
- 平行四邊形：輸入或輸出，例如使用者填寫表單、系統產生報表。
- 圓柱：資料儲存，通常對應資料表或檔案。
- 小圓圈：連接點，用在圖太長要換頁或跨區域接續時，避免線條穿來穿去。
另外一個關鍵是箭頭方向要一致，主流程由上而下或由左而右，例外分支往旁邊拉。當箭頭開始交錯、必須用手指順著線走時，通常代表這張圖該拆成兩張了。
流程圖與資料流程圖關注的東西不同
兩者常被混為一談，但問的問題完全不一樣。流程圖問的是「接下來做什麼」，強調步驟順序與判斷，看得到時間先後。資料流程圖問的是「資料從哪來、經過誰、存到哪去」，畫的是資料在角色、處理程序與儲存體之間的流動，沒有先後順序的意思。
實務上兩張圖互補。跟業主確認作業程序時用流程圖，因為它貼近日常工作的思考方式；跟工程師確認系統邊界與介接時用資料流程圖，因為它能清楚呈現哪些資料會離開系統、哪些外部單位會取得資料，這在討論權限與個資保護時特別有用。
常見的錯誤是把兩者混在同一張圖裡，既畫判斷分支又畫資料庫連線，結果誰都看不懂。若真的需要兩種視角，就畫兩張，並在圖上標明各自的用途與對應關係。
怎麼畫出兩邊都看得懂的圖
第一件事是決定顆粒度。給業主確認的圖，一個步驟對應一件他們認得的工作，不要出現資料表名稱或函式名稱；給開發使用的圖才展開到系統內部動作。同一份需求可以有粗細兩個版本，但要說清楚哪一張是給誰看的。
第二件事是標示執行者。用泳道把不同角色分開，客戶、承辦人、主管、系統各佔一條，步驟放在對應的泳道裡。很多爭議其實不是流程對不對，而是誰該做這一步，泳道能把這個問題直接攤開。
第三是用對方的詞彙寫步驟名稱。業主說「請款」就不要寫成「產生應收憑證」，兩邊名詞對不上時，先在圖旁列一份簡單的名詞對照，之後寫規格與測試案例都用得到。最後保持每張圖能放進一個畫面，需要滾動很久的圖，實際上沒有人會完整看完。
圖畫完之後怎麼維護
流程圖最大的浪費是畫完就沒再更新。討論過程改了三次，圖卻停在第一版，後面所有人都在看錯的東西。合理做法是把圖放在大家都拿得到的位置，並標上版本與修改日期，每次需求變更時同步更新，改動處在旁邊註明原因。
選工具時，優先考慮能保留可編輯原始檔的方式，只留圖片檔的話下次要改就得重畫。專案結束後，這些圖應該連同規格一起交付給業主，成為日後維護與擴充的依據，而不是留在開發團隊的資料夾裡。
常見問題
一定要用標準符號嗎？自己畫方塊加箭頭不行嗎？
如果圖只給自己看，怎麼畫都可以。但只要牽涉到跨團隊溝通，就建議使用共通符號，因為它省下每次都要解釋圖例的時間，也讓判斷點與資料儲存不會被漏看。折衷做法是使用最基本的幾種符號就好，不必把所有符號都用上，重點是同一份文件裡的用法保持一致。
業主看不懂流程圖，該怎麼帶他確認？
不要把圖丟過去請他看，改成一起走一遍。用一個具體案例當主角，從頭沿著箭頭念出來，念到判斷點就問「這種情況你們實際上怎麼處理」。走完主線再問例外：如果客戶中途取消、如果審核的人不在、如果資料填錯。用情境提問，比要求對方讀懂符號有效得多。
流程圖需要畫到多細才算夠？
判斷標準是：照著這張圖，能不能寫出測試案例。如果每個判斷點都有明確條件、每條分支都有終點、每個步驟都知道誰執行，通常就夠了。相反地，如果圖上出現「系統自動處理」這種一句帶過的步驟，而背後其實有多段邏輯，那就是還需要再展開一層的訊號。
需求還沒定案，這時候畫圖會不會白做？
正好相反，需求不明確時更該畫，因為圖能把模糊的地方變成看得見的空白。初期可以先畫粗略版本，只放主要步驟與明顯的分支，用它去引導討論。與其等需求全部確定才動筆，不如把畫圖當成釐清需求的工具，隨著討論逐步補完，這也比反覆用文字往返有效率。
系統上線之後，這些圖還有用嗎？
有，而且是最容易被忽略的價值。日後要新增功能時，可以直接對照原圖評估影響範圍；交接給新同仁時，圖比程式碼更快讓人建立整體概念；出現爭議時，也能回頭確認當初約定的處理方式。前提是圖有跟著系統更新，否則過時的圖反而會誤導人。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
加入京采 LINE 好友相關主題
下一步
如果你正在評估「系統開發流程圖」相關的規劃，可以參考我們的網頁設計服務，或直接與我們聯繫，我們會依你的產業與現況給出務實的建議。