第 09 章：流動是否有效率？ —— Flow Efficiency

缺少檢視問題方向的指標

透過交付時間（Lead Time），團隊可以了解可以了解產品待辦項目耗費了多少時間才交付，搭配兩種圖表去監控整體趨勢，以降低到某種程度來提升專注度與敏捷性。透過 CFD 可以去現形開發流動的壅塞狀況，降低同時做太多事情。而 Delvery Rate 則是協助團隊用更簡單的成本去預測未來的排程該如何規劃。

這時候似乎還少了一個指標，去協助團隊便是現在該改善什麼地方比較好。是源自於自己技術能力？源自於團隊開發的方式？還是與外部相依造成的結果？要辨識這個狀況就可以去看流動的效率為和，藉此去判斷，而對應的指標，就是 Flow Efficiency。

實際工作時間在交付時間的佔比

在軟體開發裡，佔了交付時間最長比例的項目，不是實際開發了多久，而是等待了多久。團隊內部分合作不順、或是同時開發太多項目，都可能造成產品待辦項目很多時候在等待。更別提跨團隊、跨部門的分工協力，「你的優先順序，不是我的優先順序」，需要對方做的事行往往要等上不少天才有辦法收回來。

如果因為這些項目造成整體交付時間延長，而直接怪罪團隊技術能力不夠，能也是挺冤枉的。等待總是會有的，但總有一個可以接受的比例，這就是整個團隊該去檢視與控管的。

所以在這裡可以把交付時間（Lead Time）再拆分為實際工作時間（Work Time）與等待時間（Wait Time）：

交付時間 = 實際工作時間 + 等待時間
Lead Time = Work Time + Wait Time

實際工作時間如其名，是團隊時機有在開發該項目的時間，而等待時間則是該項目正在等待另一個成員、或是其他團隊、部門協助，以及任何造成等待的時間。

而 Flow Efficiency 正是指在整個流程中，實際工作時間與總經過時間（交付時間）的比率，它告訴我們：

• 工作項目在流程中，有多少時間是真正在被處理的
• 有多少時間是在等待或閒置的

概念公式如下：

流動效率 = 實際工作時間 / 交付時間 x 100%
Flow Efficiency = (Work Time / Lead Time) × 100%

如何計算 Flow Efficiency

以上圖為例，交付時間是從確定要開始做到交付的這段時間區間，也就是藍色的線條。等待時間與實際工作時間只要一個有記錄，就可以透過計算得到另一個。這邊以等待時間為例，有等待認領去開始做的、等待外部協力的、等待開始測試得、以及測試回報錯誤之後，到開始修復前的等待（這樣描述比較符合這個團隊的等待時間，但以回報錯誤開始等待到修復完成通常比較好紀錄），也就是紅色線的部分，剩下就是代表實際工作時間的綠色。

所以交付時間有 12 天，等待時間有 8 天，實際工作時間則為 4 天，再將實際工作時間除以交付時間並乘以 100%，就可以得到流動效率為 33% 的數值，也就是單指這項產品待辦項目的流動效率。

如何應用 Flow Efficiency

但實務上，並不太可能只看單張的流動效率。畢竟要看高速公路流動效率，也不會只看一台車，搞不好挑的對象是一台很會超車的駕駛，那就挺不準的了。所以可以仿效 Delivery Rate 的計算方式，團隊挑了一段時間區間，這邊以一週（可能剛好是 Sprint 長度）來簡單示例：

這週從禮拜一確決定做 5 張產品待辦項目，以下藍色、綠色、紅色分別代表交付時間、實際工作時間、等待時間。

這邊會有個情境要考慮進去，一旦說要做，就會開始記錄交付時間，直到完成為主。所以會看到五張都是從週一開始，但因為不同時間完成，所以結束的位置不同。而 E 則是未完成，不納入這次的計算。

所以計算上就是總實際工作天數除以總交付時間，也就大概是 58%

(2+3+1+4) / (4+5+3+5) x 100% = 10 / 17 x 100% = 58%

這時候讀者可能心中會有個疑惑，這樣沒計算到 E 會不會讓流動率的可參考性降低，這是有可能的。以一個極端的案例來看：如果團隊只有 A 做完，剩下的都要做到下週，但 A 做五天，實際工作天數四天，流動效率就有 80%，哇，真是高效率的產品開發流動！這樣是否有點詭異？

所以在計算這個流動效率時，應當必免太多未完成的項目被排除在外，如果是以時間區間來看待，可以考慮拉長這段時間週期。另外也可以考慮是以每完成 N 個項目數量就算一次的方式。

使用 Flow Efficiency 要注意的陷阱

那在參考這個指標協助判讀當前開發順暢度時，可以搭配一些概念避免踩到指標的陷阱裡。

陷阱：追求100% 流動效率

很難會有 100% 的 Flow Efficiency，如果有，那可能也是過度使用資源促成的結果，不一定是好事。所以不要過度追求 100% Flow Efficiency，應當像交付時間一樣，去訂定一個上下限作為門檻去觀測。

陷阱：用單一指標去判讀

正如前面一再強調的，不應該以單一指標的判讀去解讀當前的狀況，最好是搭配各項指標綜合考量在做決定。就像上面的舉例計算，期間會有未開發完成的產品待辦項目，所以在判讀 Flow Efficiency ，應該搭配該時期到底有多少張未完成的產品待辦項目作為輔助。

小結

Flow Efficiency 可以協助團隊判讀現在開發順暢度，時間開發的時間占多少比例，是不是符合期待。若不符合期待，要提升開發流動效率，比起強求團隊在短時間成長、進步，去減少各樣的等待時間的效益比應當更高且具備可行性。先確保等待時間造成的浪費在可接受範圍，若是發現交付時間仍不符合期待，團隊也比較不會以「會議太多、外務太多」來推拖，就可以好好專注思考如何提升團隊能力或是實際工作時間內的相關議題。