一、什麼是 Flight Levels
Flight Levels(飛行高度)是 Klaus Leopold 提出的組織思考模型,源自 Kanban 社群的實務經驗。它用飛行高度做比喻:飛得越高,看到的範圍越廣,但細節越少;飛得越低,細節越清楚,但看不見全局。這個模型的核心主張是:團隊層級的局部優化,救不了整個組織的交付問題。想改善端到端的價值流動,必須在正確的高度做正確的事,並且把不同高度連結起來。
Flight Levels 不是成熟度模型,三個層級之間沒有優劣之分,也不是「從 FL1 升級到 FL3」的階梯。它們是同時存在的三種視角,各自回答不同的問題。
圖一:Flight Levels 三個層級與彼此的連結
FL1 操作層級(Operational)
這是單一團隊的日常工作管理:團隊看板、站立會議、任務的拉動與完成。FL1 回答的問題是「我們團隊的工作如何流動」。絕大多數導入看板的組織都停在這一層。FL1 做得再好,也只能優化局部——如果團隊的上游需求不清、下游依賴卡住,團隊內部的流動再順暢,價值還是到不了客戶手上。
FL2 協調層級(End-to-End Coordination)
FL2 看的是跨團隊、從想法到交付的端到端流動。工作單位不再是任務,而是功能或客戶價值項目。FL2 回答的問題是「價值在整個系統中如何流動、卡在哪裡」。這一層讓組織看見跨團隊依賴、整體 WIP 與瓶頸位置——這些在任何單一團隊的看板上都看不到。
FL3 策略層級(Strategy)
FL3 管理的是組織的策略主題與投資方向:決定做什麼、不做什麼、什麼時候停止。工作單位是策略選項,節奏是月或季。FL3 回答的問題是「我們是否把有限的組織能量放在對的方向上」。沒有 FL3,組織會同時啟動太多方向,每個都做一點,每個都做不完。
三個層級真正的價值不在各自的看板,而在「連結」:FL3 的策略決定 FL2 承諾什麼,FL2 的流動狀態回饋給 FL3 做取捨,FL2 的協調結果決定 FL1 團隊拉什麼進來做。斷開的三層看板只是三面牆上的裝飾。
二、AI 時代為什麼更需要 Flight Levels
AI coding 工具直接作用在 FL1:個人寫程式的速度變快了。但瓶頸不會消失,只會搬家。當生成的速度提高十倍,壓力就推向下游的驗證、審查與整合——這些大多仍是人的認知工作。METR 的 RCT 與 Faros 的遙測資料都指向同一個現象:個人變快了,但 PR 變大、review 排隊變長,端到端的交付時間未必改善。
這正是 Flight Levels 的用武之地。FL1 的欄位設計要讓「驗證」現形,而不是藏在「進行中」裡;FL2 要讓組織看見瓶頸搬去了哪裡;FL3 則要處理另一個問題——當「做出來」變便宜,「選對方向」就變貴,策略層級的 WIP 上限與主動停止,成為防止組織加速撞牆的煞車系統。
以下用三個層級的看板欄位設計,具體說明每一層在 AI 時代該長什麼樣子。
三、FL1 團隊看板欄位設計
圖二:FL1 團隊看板——把驗證與人工審查獨立成欄
傳統團隊看板通常是「待辦 → 進行中 → 測試 → 完成」。在 AI 時代,這樣的欄位設計會掩蓋真正的瓶頸,因為「進行中」混合了兩種性質完全不同的工作:AI 加速的生成,與 AI 無法取代的驗證。建議的欄位設計如下:
| 欄位 | 用途 | AI 時代設計重點 |
| 待辦 | 團隊已同意近期要做的項目 | 項目變小、變便宜,更要防止一次拉太多 |
| 規格釐清 | 用 SBE 具體範例把「對」定義清楚 | AI 生成的品質上限由規格清晰度決定,這一欄是投資報酬率最高的地方 |
| AI 生成 + 開發 | 與 AI 協作產出程式碼 | 速度最快的一欄,WIP 上限防止它淹沒下游 |
| 驗證(Eval Gate) | 自動化驗證:測試、Eval、對抗測試 | 獨立成欄才看得見堆積;這是 AI 時代的新瓶頸現場 |
| 人工審查 | 人對意圖、設計與風險的判斷 | 認知工作,無法用工具加速,WIP 上限最需要嚴格執行 |
| 完成 | 符合完成定義,可交付 | 完成定義應明確包含通過 Eval Gate 與人工審查 |
設計重點:把「驗證」與「人工審查」從「進行中」拆出來,各自設 WIP 上限。當卡片在這兩欄堆積,團隊就有了視覺證據——瓶頸不在寫程式,而在確認程式是對的。這會自然引導團隊把改善精力放在測試自動化、Eval 設計與審查流程上,而不是再買一個更快的生成工具。
四、FL2 端到端協調看板欄位設計
圖三:FL2 協調看板——工作單位是功能,不是任務
FL2 看板上的一張卡片,是一個對客戶有意義的功能或價值項目,可能橫跨多個團隊。它的欄位對應的不是某個團隊的工序,而是價值從想法到交付的整段旅程:
| 欄位 | 用途 | AI 時代設計重點 |
| 選項池 | 還沒承諾的候選項目 | AI 讓提案暴增,選項池要定期清理,而非無限堆積 |
| 已承諾 | 組織已決定要做,設有 WIP 上限 | 承諾的門檻要提高——生成便宜了,承諾依然昂貴 |
| 分析 / 拆解 | 跨團隊釐清範圍、拆解與依賴 | 標注涉及哪些團隊,依賴在這裡先現形 |
| 開發中(多團隊) | 各團隊在 FL1 執行 | 卡片停留時間變短,但別被表面速度騙了 |
| 整合驗證 | 跨團隊整合、回歸、系統層級驗證 | AI 時代最常堆積的一欄;堆積量是組織驗證能力的照妖鏡 |
| 待發布 / 已交付 | 通過驗證,等待或完成發布 | 量測從「已承諾」到這裡的時間,而非團隊各自的速度 |
設計重點:FL2 的價值在於誠實。當組織買了 AI 工具、FL1 團隊都說自己變快了,FL2 看板會顯示真相——如果「整合驗證」欄位的卡片越堆越多、blocked 標記越來越常見,那麼組織只是把庫存從「待寫的程式」換成「待驗證的程式」。導入 Eval Gate、Test Impact Analysis 這類實踐的決策依據,應該來自 FL2 的流動數據,而不是任何單一團隊的感覺。
五、FL3 策略看板欄位設計
圖四:FL3 策略看板——管理方向,而非功能
FL3 看板上的卡片是策略主題或投資方向,檢視節奏是月或季。它的欄位反映的是決策的生命週期:
| 欄位 | 用途 | AI 時代設計重點 |
| 策略選項 | 值得考慮但尚未投入的方向 | AI 讓每個提案看起來都「很快能做」,這一欄的紀律更重要 |
| 探索驗證 | 用 Safe-to-Fail 探測驗證假設 | 小成本試錯,AI 降低了探測成本,善用它 |
| 進行中 | 組織正式投入的策略主題,設 WIP 上限 | 策略層級的 WIP 上限是防止協調成本爆炸的關鍵 |
| 檢視成效 | 定期檢視策略假設是否成立 | 固定節奏,不等年度計畫 |
| 結束 / 停止 | 完成,或主動停止 | 主動停止是健康訊號,不是失敗;要公開慶祝停止的決定 |
設計重點:AI 壓低了「做出來」的成本,於是做錯方向的代價相對變高——以前做錯方向浪費幾個 sprint,現在 AI 可以在一週內產出大量完整但方向錯誤的功能。FL3 的 WIP 上限限制組織同時追逐的方向數量,「主動停止」欄位則讓停損成為正常流程的一部分。這是組織的煞車系統:不是為了開慢,而是為了敢開快。
六、結語:瓶頸不會消失,只會搬家
AI 時代的組織問題,不是「怎麼讓團隊更快」,而是「怎麼看見加速之後,系統的哪裡開始塞車」。Flight Levels 提供了三個高度的視角:FL1 的欄位設計讓驗證現形,FL2 讓組織看見瓶頸搬去哪裡,FL3 確保有限的組織能量押在對的方向上。
看板欄位從來不只是工作分類——它是組織對「工作如何流動」的信念的具體化。當生成不再稀缺,你的欄位設計,決定了你能不能看見真正稀缺的東西:驗證的能力,與選擇的智慧。
發表迴響