如何建立泳道圖
如何建立泳道圖：按誰負責這項工作來劃分泳道，把每個步驟放進真正執行它的泳道，讓每一次跨泳道流轉都成為可見的交接。附一個可以逐步示範的即時示例。
泳道圖是按負責方拆開的流程圖：每條泳道屬於一個角色或團隊，每個步驟位於執行它的那條泳道，而每一次跨越泳道的連線都是一次交接。
簡而言之
- 每個負有問責的角色一條泳道——不是每人一條，也不是每個部門一條。
- 四至五條泳道是可讀性的上限；超過這個數目，就應該拆分流程。
- 步驟屬於執行它的那條泳道，而不是出事後被追究的那條。
- 每一條跨越泳道界線的連線都是一次交接——延誤就藏在那裡。
- 在 QueryChart 中，泳道就是試算表裡的兩欄：負責方與階段。
泳道究竟是用來解決甚麼的
泳道圖回答了一個普通流程圖回答不了的問題：這件事現在壓在誰手上。這一點之所以重要，是因為營運流程很少在某個步驟內部出問題。它們出問題在步驟之間——上一個團隊做完了、下一個團隊還未開始的那道空隙裡，而且誰都沒有察覺，因為每個團隊自己的核對清單看上去都是完成的。把流程拆進泳道，正是讓這些空隙成為版面上最顯眼的東西。
泳道本身才是真正的設計決策。按問責來劃分，而不是照搬組織架構圖：每條泳道對應一個能夠為「把某個步驟做完」承擔責任的群組，通常是一個角色或一項職能，而不是某個人或某個部門。四至五條泳道是實務上的上限——再往上，跨泳道的連線就會纏成一團，圖表也就不再可讀；這是應該拆分流程的訊號，而不是應該調細字型的訊號。
QueryChart 的泳道同時運行在兩個座標軸上。縱向泳道是負責方，橫向泳道是流程的各個階段，因此放置一個步驟時要同時指定這兩者。下面的示例是一個真實的員工入職流程，橫跨四個負責方與六個階段——這類流程最容易變成四份各自獨立、卻必須在同一個早上全部完成的核對清單。
看一張泳道圖如何搭建起來
一個橫跨四條負責方泳道與六個階段的跨職能入職流程。下面每個階段都會加入一條泳道的工作量——以及一次交接。
由一條泳道開始
只有人力資源，處於「聘用與合約」階段。泳道只有在有步驟被放進去之後才會出現，所以此時這張圖看起來就是一張普通的流程圖——在工作易手之前，它確實就是。
把決策放進擁有它的那條泳道
背景審查屬於人力資源，但例外判斷不屬於：例外由招聘經理決定，因此那個菱形位於招聘經理的泳道。決策是最容易被放錯泳道的東西，而這個錯誤正是讓大家事後爭論「本應由誰行動」的原因。
交接才是重點所在
設備與帳戶的開通落到 IT，再落到行政後勤，此時你已經能看到決定第一天是否順利的那兩次跨泳道流轉。留意那條後備路徑：來不及送達的設備會轉往備用機，而不是讓新入職同事沒有電腦可用。
工作會跨着泳道回流
第一天由人力資源走到 IT 再走回來，隨後第一星期落在招聘經理身上。真實流程裡的交接是雙向的；一張工作只會向下流動的圖，畫的通常是一種願望。
每條泳道收好自己的分支
試用期在招聘經理的泳道收尾，有兩個結果——確認聘用，或延長並附上一份支援計劃。每條泳道都應該把自己的工作收妥，而不是留下一條連線拖進別人的泳道。
運作方式
先列角色，再列步驟
寫下每一個需要動手做事的群組，然後合併，直至只剩四至五個。按問責合併：如果兩個名稱總是一起行動、被催進度時也會被當成一個整體，那它們就是同一條泳道。一人一條泳道，只會保證下一次有人轉職時這張圖就是錯的。
在頂部為各個階段命名
階段就是橫向泳道——流程的各個階段，例如篩選、開通、第一天。它們讓讀者對時間有個概念，又不會假裝自己是一份時間表；同時也讓「某一個階段承擔了別人兩倍的工作量」變得一目了然。
把步驟寫成列，並填好兩個泳道欄
在 QueryChart 中，每一列都帶有一個橫向泳道（階段）和一個縱向泳道（負責方）。開啟上面示例下方的試算表檢視就能看到：泳道圖不過是一張多了兩欄的普通表格，版面是從這兩欄推導出來的，而不是拖出來的。
把每個步驟放進真正做這件事的泳道
判斷標準是：如果這一步延誤了，會去催誰。不是誰關心它，也不是誰負責匯報它——而是誰去做。把步驟停在「誰投訴得最大聲」的泳道，正是泳道圖被悄悄棄用的原因。
逐一細看每一次跨泳道
每一條越過泳道界線的連線都是一次交接，而流程正是在交接處停滯。對每一次交接都要問：接收方那條泳道是怎樣得知有工作在等它的——一張工單、一封電郵、一個共用佇列，還是甚麼都沒有。「甚麼都沒有」本身就是一個發現，而且往往是最值得拿到的那一個。
檢查泳道之間的平衡，然後發出去傳閱
只有一個方框的泳道也許不必存在；有十五個方框的泳道多半是三個角色戴着同一頂帽子。調整之後，把圖表分享給每一位泳道負責人並收集他們的簽署，讓這張圖成為各團隊認可的東西，而不是某一個人代他們畫出來的東西。
應避免的錯誤
照搬組織架構圖的泳道
部門不是負責方。把「營運」做成一條泳道，會把它內部真正互相交接工作的三個團隊掩蓋起來，結果整張圖一次可見的交接都沒有——而那恰恰是泳道圖存在的意義。
一人一條泳道
為角色命名，不要為人命名。人會流動，流程理應比他們活得更久。這樣做也能避免圖表變成一份關於個人的文件，而那正是令檢討變得尷尬的原因。
九條泳道
超過大約五條，跨泳道的連線就會佔據主導，沒有人能完整追蹤出一條路徑。要麼是範圍劃得太闊——在一次明確的交接處拆成兩個流程——要麼是其中好幾條泳道其實是同一條。
決策放錯了泳道
決策屬於作出判斷的那個人，而那往往不是準備資料的人。這一點弄錯，圖表就會暗示某位分析員在批准自己的工作。
建立您自己的泳道圖
把上面的入職示例作為您自己的圖表開啟，把泳道改成你們團隊的名稱，再替換掉裡面的步驟。
相關指南
常見問題
泳道圖和流程圖有甚麼分別？
流程圖展示次序與邏輯。泳道圖展示同樣的次序，但按誰執行每個步驟拆開，於是職責與交接都變得可見。任何泳道圖都是流程圖；是泳道令它由一張關於作業程序的圖，變成一張關於機構的圖。如果一個流程始終留在一個團隊內部，泳道不會帶來任何資訊——一旦它跨越了界線，就應該用泳道。
泳道應該橫向還是縱向？
慣例是橫向泳道，流程由左往右閱讀，多數人也覺得這樣最容易掃讀。QueryChart 同時使用兩個座標軸：縱向泳道代表負責方，橫向泳道代表流程的各個階段。這樣的組合讓你既能看到誰在行動，也能看到流程走到了哪一步，而不必讓其中任何一個維度只靠位置去暗示。
一張圖應該有多少條泳道？
四至五條。兩三條很常見，對於只跨越一次界線的流程也完全足夠。超過大約五條，跨泳道的連線互相重疊，追蹤一條路徑就要花些氣力；通常的解決辦法不是換一塊更大的畫布，而是把範圍收窄：在一次自然的交接處把流程切開，讓每一半各有一張自己的圖，而那次交接本身就是前一張的終點、後一張的起點。
供應商、客戶這類外部方應該放在哪裡？
只要他們的動作是流程的一部分，就放進他們自己的泳道。供應商提交發票、客戶確認投訴已解決、應徵者接受聘用——這些都是流程要等待的步驟，把它們藏進某條內部泳道，就等於讓等待變得不可見。給他們一條泳道，同時也令「你們的周期時間裡有多少其實並不由你們控制」變得一目了然。
