The First Way 描述的是使工作從左到右快速流動的原則，而 The Second Way 則描述使快速且持續的回饋從右到左（從 Operations 回到 Development）在價值流所有階段中流動的原則。目標是建立一個越來越安全且具韌性的工作系統。

在複雜系統中安全地工作#

複雜系統的特性#

複雜系統的一個定義性特徵是：沒有任何單一個體能看到系統的全貌並理解所有部分如何契合。複雜系統通常具有高度的元件互連性與緊密耦合，系統層級的行為無法僅從元件的行為來解釋。

關於複雜系統的重要研究發現：

• Dr. Charles Perrow 研究三哩島事件，觀察到不可能有人能理解反應爐在所有情況下的行為。當一個元件出問題時，很難將其與其他元件隔離，問題會沿著阻力最小的路徑以不可預測的方式流動
• Dr. Sidney Dekker 觀察到複雜系統的另一個特性：做同樣的事兩次不一定會導致相同的結果。這使得靜態檢查清單和最佳實踐雖然有價值，但不足以防止災難發生

因為失敗在複雜系統中是固有且不可避免的，我們必須設計一個安全的工作系統 – 無論在製造業還是技術領域 – 讓我們能無畏地執行工作，確信任何錯誤都會被迅速偵測到，遠在造成災難性後果之前。

在複雜系統中安全工作的四個條件#

Dr. Steven Spear 在哈佛商學院的博士論文中，解碼了 Toyota Production System 背後的因果機制後指出，設計完美安全的系統可能超出我們的能力，但我們可以在以下四個條件被滿足時，使在複雜系統中工作更加安全：

1. 複雜工作被管理，使設計和營運中的問題能被揭露
2. 問題被群聚（swarmed）並解決，快速建構新知識
3. 新的局部知識被全局利用，傳播到整個組織
4. 領導者培育其他領導者，持續發展這些能力

本章聚焦於前兩項能力（後兩項在 Chapter 4 中描述）。

在問題發生時即時發現（See Problems as They Occur）#

在安全的工作系統中，我們必須不斷測試我們的設計與營運假設。目標是從盡可能多的來源增加系統中的資訊流，讓資訊來得更快、更早、更便宜，並盡可能清楚地呈現因果關係。

我們能推翻越多假設，就能越快地發現和修復問題，從而增加我們的韌性、敏捷性以及學習和創新的能力。

在技術價值流中，這意味著建立快速的回饋機制：自動化測試、生產環境監控、遙測資料收集等，使問題在產生時就被偵測到，而非等到客戶報告或災難發生。

群聚解決問題並建構新知識（Swarm and Solve Problems）#

當問題被偵測到時，正確的回應是群聚 – 集中相關人員的力量，在問題所在之處即時解決。在 Toyota Production System 中，這體現為著名的 Andon Cord（安燈繩）：任何工人發現問題都可以拉繩暫停產線，團隊領導者會立即前往協助。

群聚解決的關鍵原則：

• 在問題發生的地方解決問題，而非將問題傳遞給其他團隊
• 快速建構新知識，從每次問題中學習
• 防止問題傳遞到下游，避免缺陷累積

在技術工作中，這意味著當建構失敗、測試未通過或生產環境出現異常時，相關團隊應該立即停下手邊的工作，集中力量解決問題，而不是把問題放入待辦佇列等待處理。

在源頭確保品質（Quality at the Source）#

回饋原則的核心目標之一是在源頭建立品質。與其依賴下游的檢查和測試來發現問題，不如在工作產生的地方就確保品質：

• 開發者在提交程式碼時就執行自動化測試
• 同儕程式碼審查在變更合併前進行
• 每個團隊對其工作的品質負責

透過在每個步驟都內建品質檢查，我們避免了問題在價值流中累積，減少了返工和延遲。

為下游工作中心優化（Optimize for Downstream Work Centers）#

The Second Way 要求我們站在下游的角度思考：

• Development 為 Operations 優化：確保程式碼不僅能運作，而且容易部署、監控和維護
• 每個團隊為其內部客戶優化：確保交付的工作是「完整且準確」的（高 %C/A）

透過持續縮短並放大回饋迴路，我們最大化了組織的學習與改善機會，這是幾乎所有現代流程改善方法論的核心準則。

結論#

The Second Way 透過建立快速、頻繁且高品質的資訊流，使我們能在問題還小、便宜、容易修復時就偵測並處理它們。將失敗和事故視為學習機會而非懲罰和責備的理由，是建立安全工作系統的基礎。