泳道圖指南:是什麼、何時使用,以及如何製作

普通的流程圖顯示發生了什麼。泳道圖顯示發生了什麼以及誰負責每個步驟。當流程跨越團隊邊界時,這種區別很重要——而大多數重要的流程都是如此。

本指南涵蓋什麼是泳道圖、何時是正確選擇,以及如何建立有效的泳道圖。

泳道圖一覽

元素	代表意義
泳道(列/欄)	一個角色、團隊、部門或系統
泳道內的步驟	由該角色負責的工作
跨泳道箭頭	角色之間的交接
泳道內的決策	由該角色所做的選擇

想要快速完成泳道圖?可使用泳道圖製作工具——描述流程與各方分工,AI 會自動為你排版泳道與交接。

什麼是泳道圖?

泳道圖是一種被分為水平或垂直帶（泳道）的流程圖，每條泳道代表一個人、團隊、部門或系統。活動被放置在負責它們的人的泳道中，使參與者之間的交接清晰可見。

這個名字來自於視覺上與游泳池泳道的相似性——不同的參與者在各自指定的空間內工作的平行軌道。

基本結構：

┌─────────────────────────────────────────────────┐
│ 客戶    │ 提交訂單 ──→ 接收確認                  │
├─────────────────────────────────────────────────┤
│ 銷售    │ 審查訂單 ──→ 批准？                    │
│         │                  ├─ 是 → 處理           │
│         │                  └─ 否 → 通知           │
├─────────────────────────────────────────────────┤
│ 倉庫    │ 揀貨 ──→ 包裝 ──→ 出貨                 │
├─────────────────────────────────────────────────┤
│ 財務    │ 生成發票 ──→ 收款                       │
└─────────────────────────────────────────────────┘

每個活動都位於負責方的泳道中。跨越泳道邊界的箭頭代表交接——工作從一個人或團隊轉移到另一個人的時刻。

泳道圖 vs 普通流程圖

兩者都是有效的工具。問題是哪個適合你的情況。

面向	普通流程圖	泳道圖
顯示	發生了什麼（序列）	發生了什麼 + 誰做的
最適合	單人或單團隊流程	跨功能流程
複雜性	建立和閱讀更簡單	更複雜但更有資訊量
交接	看不見	明確可見
瓶頸檢測	較難——責任不清	更容易——看到哪條泳道超載
所需空間	緊湊	更寬/更高——需要更多空間

使用普通流程圖的情況：

一個人或團隊處理整個流程
流程簡單且線性
你在記錄技術邏輯（演算法、決策樹）
空間有限（投影片、報告）

使用泳道圖的情況：

涉及多個人、團隊或系統
交接點導致延遲或錯誤
你需要釐清責任
你在改進跨功能流程

關鍵組件

泳道（或池）

每條泳道代表一個參與者：

人員：「經理」、「員工」、「客戶」
團隊：「銷售」、「工程」、「支援」
系統：「CRM」、「付款閘道」、「資料庫」
角色：「審批者」、「審查者」、「請求者」

將泳道保持在 3-6 個參與者。超過 6 條泳道就難以閱讀。

活動

放置在負責方泳道中的流程步驟。使用標準流程圖形狀：

矩形用於流程步驟
菱形用於決策
圓角矩形用於起始/終止
平行四邊形用於輸入/輸出

交接

跨越泳道邊界的箭頭。這些是最重要的元素——交接點是流程通常出問題的地方。每個跨泳道箭頭代表一個時刻：

資訊在團隊之間轉移
可能發生延遲（等待對方）
可能產生誤解
責任轉移

序列流

顯示步驟順序的泳道內箭頭。與普通流程圖箭頭相同，但在交接點之間限制在單一泳道內。

何時使用泳道圖

跨部門流程

任何涉及多個部門的流程都受益於泳道可見性：

採購： 請求者 → 審批者 → 採購 → 供應商 → 收貨 → 財務
招募： 招募經理 → HR → 招募人員 → 面試小組 → HR → 入職
客戶投訴： 支援 → 產品 → 工程 → QA → 支援 → 客戶

識別交接瓶頸

如果流程很慢，泳道圖揭示在哪裡。當你看到箭頭頻繁跨越邊界時，每次跨越都是潛在的延遲點。減少跨泳道交接通常可以提高流程速度。

合規和審計文件

受監管的行業需要清晰的責任追蹤。泳道圖清楚地顯示誰在每個步驟負責，審計員和合規官員很欣賞這一點。

軟體開發工作流程

開發工作流程自然涉及多個角色：

產品經理 │ 撰寫需求 ──→ 優先排序
─────────────────────────────────────────────────
開發人員 │ 實施 ──→ 程式碼審查 ──→ 修復
─────────────────────────────────────────────────
QA       │ 測試 ──→ Bug？ ──→ 驗證修復
─────────────────────────────────────────────────
DevOps   │ 部署到測試環境 ──→ 部署到生產環境

何時不應使用泳道圖

單人流程。 如果一個人做所有事情，泳道增加了複雜性而沒有價值。
簡單的線性流程。 5 步順序流程不需要泳道。
技術演算法。 程式碼邏輯沒有「部門」。使用普通流程圖。
快速溝通。 當你需要在 30 秒內解釋流程時，簡單的流程圖更清晰。

如何建立泳道圖：逐步說明

步驟一：定義流程和範圍

設定清晰的邊界：

開始事件： 什麼觸發了流程？（例如「客戶提交訂單」）
結束事件： 什麼標誌著完成？（例如「訂單已交付並收款」）
範圍： 包含什麼和排除什麼？

步驟二：識別參與者

列出流程中涉及的所有人。將相似的角色分組：

不要為「初級開發人員」和「高級開發人員」建立單獨的泳道——使用「工程」
如果「財務」和「法務」有不同的活動，就分開它們
如果系統執行自動化步驟，則包含系統

步驟三：列出所有活動

寫下流程中的每個步驟，無論順序如何。對於每個活動，注意：

發生了什麼
誰做它（哪條泳道）
什麼觸發它
它產生什麼

步驟四：安排序列

按時間順序將活動放置在各自的泳道中。用箭頭連接它們。用菱形標記決策點。

步驟五：識別交接

在工作轉移的地方繪製泳道之間的箭頭。對於每個交接，考慮：

需要傳遞什麼資訊？
交接通常需要多長時間？
這一點可能出什麼問題？

步驟六：審查和驗證

與實際流程參與者一起走過圖表：

這與現實相符嗎（而不只是理想？）
是否缺少任何步驟？
交接是否準確？
泳道分配是否正確？

常見的泳道圖範例

採購訂單審批

請求者  │ 建立 PO ──→ 附報價單 ──→ 提交
──────────────────────────────────────────────────────
經理    │ 審查 ──→ 低於 $5K？ ──→ 是 → 批准
        │                         └─ 否 ↓
──────────────────────────────────────────────────────
總監    │ 審查 ──→ 低於 $25K？ ──→ 是 → 批准
        │                          └─ 否 ↓
──────────────────────────────────────────────────────
VP/CFO  │ 審查 ──→ 批准/拒絕
──────────────────────────────────────────────────────
採購    │ 建立訂單 ──→ 傳送給供應商 ──→ 追蹤
──────────────────────────────────────────────────────
收貨    │ 接收貨品 ──→ 檢驗 ──→ 確認
──────────────────────────────────────────────────────
財務    │ 匹配 PO/發票 ──→ 處理付款

Bug 修復工作流程

客戶支援  │ 接收報告 ──→ 重現？ ──→ 否 → 請求詳情
          │                      └─ 是 ↓
──────────────────────────────────────────────────────
工程      │ 分類 ──→ 優先級？ ──→ 緊急 → Hotfix 分支
          │                    └─ 一般 → 衝刺待辦事項
          │ 實施修復 ──→ 程式碼審查 ──→ 合併
──────────────────────────────────────────────────────
QA        │ 測試修復 ──→ 通過？ ──→ 否 → 退回給工程
          │                       └─ 是 ↓
──────────────────────────────────────────────────────
DevOps    │ 部署 ──→ 監控
──────────────────────────────────────────────────────
客戶支援  │ 通知客戶 ──→ 確認解決

最佳實踐

將泳道保持在 3-6 條。 超過 6 條泳道使圖表難以閱讀。如果你有更多的參與者，考慮對相關角色分組或拆分為子流程。

按互動頻率排列泳道。 將最常互動的泳道相鄰放置。這減少了箭頭交叉，使交接更清晰。

顯示真實流程，而非理想流程。 記錄實際發生的事情，包括變通方法和非正式步驟。你可以稍後建立「目標狀態」版本進行改進。

突出痛點。 用視覺提示標記常見的延遲點、容易出錯的交接或瓶頸。這使圖表立即具有可操作性。

使用一致的符號。 遵循標準流程圖標記法。決策菱形、流程矩形和終結符橢圓在每個圖表中應具有相同的含義。

常見錯誤

太多泳道。 每個角色都有自己的泳道，導致 10 多條泳道沒有人能閱讀。對相關角色分組。

混合細節層次。 一條泳道有 15 個詳細步驟，而另一條只有 2 個高層次步驟。在各泳道中保持一致的粒度。

忽略交接。 記錄了活動，但泳道之間的箭頭沒有得到關注。交接是流程出問題的地方——重點放在那裡。

做得太大。 需要滾動或縮放的泳道圖失去了其價值。如果流程太大而無法放在一頁上，將其拆分為子流程。

使用 AI 建立泳道圖

由於泳道結構和跨邊界連接，泳道圖歷來建立起來很費時。像 Flowova 這樣的工具可以從文字描述生成泳道風格的圖表——描述你的流程，提及負責方，就能獲得你可以完善的結構化圖表。

對於更複雜的泳道需求，Flowova 的泳道圖製作工具是專為跨功能流程視覺化設計的。