說到看板，汽車業其實是它的老家。豐田生產方式（TPS）用實體看板卡片驅動拉動式生產，正是 Kanban 一詞的源頭。但今天的汽車業，戰場已從產線延伸到車載軟體、ADAS 與電子控制單元（ECU）的開發——這些長週期、跨領域、講究功能安全的工作，同樣能靠看板管好流動。這篇談汽車團隊怎麼把看板從產線思維，帶進工程開發協作。
看板的兩種面貌
在汽車業，看板有兩層意義。生產現場的看板是「拉動」——後工序需要了，才通知前工序供料，用來壓低庫存、平順產出。而工程開發的看板是「流動」——讓需求、設計、實作、驗證的工作項，持續平穩地流過各關卡。兩者原理相通：限制在製品、讓阻塞浮現。這篇聚焦後者，也就是研發團隊的協作。
導入看板的步驟
步驟一：選定一個開發場景起步
從一個範圍清楚的模組開始，例如某項車載軟體功能或一顆 ECU 的開發。避免一次涵蓋整車專案，先在小範圍驗證做法。
步驟二：建立反映真實關卡的欄位
汽車開發有嚴謹的驗證關卡，欄位就該包含它們，例如「需求 → 設計 → 實作 → 單元測試 → 整合驗證 → 安全審查 → 完成」。把安全與合規關卡明確畫進流程，而不是事後補做。
步驟三：設定 WIP 限制，對齊驗證節奏
汽車驗證環節（如 HIL 硬體在環測試）往往是瓶頸。用 WIP 限制讓上游不要一味塞任務給驗證端，維持整條線的流動平衡。
步驟四：視覺化跨領域相依
一項功能常牽動機構、電子、軟體三方。把跨模組的相依關係畫在看板上，讓「誰在等誰的介面」一目了然，避免整合階段才爆出問題。
步驟五：管理長週期與變更
汽車專案動輒數年，需求變更難免。讓每次變更成為可追蹤的卡片，帶著影響範圍一起流動，維持可追溯性——這對日後的安全論證尤其重要。
步驟六：用數據持續改善
追蹤各關卡的前置時間與卡關次數，找出研發流程真正的瓶頸。持續縮短回饋循環，正是汽車軟體愈來愈需要的敏捷能力。
用 Meegle 管理汽車研發的流動
汽車研發的難點在於跨領域、長週期與可追溯。Meegle 用視覺化工作流把機構、電子、軟體的任務與相依關係攤在同一畫面，安全審查可設為必經節點，任何變更都留下可追溯的歷程。看板視圖搭配 WIP 限制讓驗證瓶頸現形，儀表板則把長週期專案的進度與卡關即時呈現，讓數千個工作項的流動仍在掌握之中。
結語
看板從汽車產線走出來，如今又回到汽車研發。無論管的是實體物料還是程式碼，核心都一樣：限制在製品、讓阻塞浮現、用數據改善。從一個模組開始，把驗證與安全關卡誠實地畫進流程，看板就能在講究安全的汽車開發裡，穩穩地發揮作用。