在他的著作《戰爭論》（On War）中，克勞塞維茲將摩擦定義為軍事理論與現實之間的落差：

因此，在戰略中，一切看似非常簡單，但絕非因此就很容易。戰爭中的一切都很簡單，但最簡單的事卻很困難。這些困難累積起來，便產生了一種摩擦，唯有親歷戰爭的人，才能真切想像。

舉一個摩擦的例子，就拿天氣來說。在這裡，濃霧讓人無法及時發現敵軍，讓砲兵無法在正確的時機開火，讓報告無法送達將軍手中；在那裡，大雨讓一個營無法抵達，讓另一個營無法準時到達，因為原本三小時的路程，結果得走上八小時；讓騎兵無法有效衝鋒，因為深陷泥濘、動彈不得。

自從讀到這段話之後，我發現軟體開發中到處都是「摩擦」：

• 廠商的 API 運作起來跟你想的不太一樣，或者本來是一樣的，後來被他們改掉了。
• Bug、安全警示、升級一個依賴套件結果搞壞了東西。
• 有人生病了、有人的小孩生病了、有人離職了、有人跑去參加 Burning Man。
• 需求不清楚，或客戶在開發過程中改變主意。客戶在開發完成後又改變主意。
• 筆電壞掉或被偷了、Slack 當機一整天。
• 開發工具壞掉、Word 把所有字型都變成 Wingdings。（這是真有其事）

這份清單只是舉例，不可能列出所有摩擦的來源。

摩擦的一些特性

時間拉得越長、範圍越大，摩擦的影響就越嚴重，原因很簡單：可能出錯的地方更多了。

摩擦會自我疊加：兩次挫折帶來的影響，遠比一次挫折的兩倍還糟。這是因為多數系統至少都有一定的韌性，可以自行調整來繞過某個問題，但這麼一來，下一個問題就更難處理了。

（這也是「週五不要部署」這個具爭議性觀念背後的因素之一。部署時出錯、或是需要 rollback 所造成的摩擦，會因為週末大家都不在線上這種摩擦而變得更加嚴重。爭議的雙方，一邊是主張「不要這麼做」的人，另一邊則是主張應該對流程進行系統性改革的人。不管哪種說法，目標都是要確保摩擦不會造成問題，爭的是究竟該怎麼做。）

試圖處理摩擦本身也可能製造出新的摩擦來源，例如你為了修補安全警示而升級依賴套件，結果新版本在一些細微的地方不向下相容。然後你還得跟住在不同時區的同事一起處理這個問題……

如何應對摩擦

摩擦無可避免，也不可能完全消除。我認為甚至不可能完全預料到它。但我們還是可以做一些事來減輕它，也可以讓計畫對它更有韌性。我不清楚軍事規劃者是如何降低摩擦的。以下是我在軟體領域中看到的做法：

更小的範圍、更短的迭代

這就是主張「敏捷」優於「瀑布」的理由。時程短，摩擦就比較沒有機會疊加。你做的事越多、時程越長，不確定性就越高，可能出錯的地方也越多。不過，如果你只是把一堆小衝刺一個接一個地排下去，摩擦依然有機可乘。那樣只是在跑一場沒有效率的馬拉松。

更大的自主性

摩擦是模型與現實之間的落差，而在高層次上你只能看到模型。如果人們有足夠的自主權做出在地化的明智決策，就能更容易從摩擦中恢復。但如果自主權大到讓人各自為政，情況反而會變得更糟。我就曾看過一位擁有高度自主權的工程師，把一個「太慢」的資料庫給刪掉了。

備援

這可能是倉庫裡的備用設備、較高的 bus factor，或是在時程中預留緩衝。這樣一來，一旦出事就能更快修復，留給下一個問題疊加的空間就更小。但這在平時會以犧牲效率為代價，這也是為什麼專案自然會朝著減少備援的方向漂移。

更好的規劃

好的規劃無法找出所有摩擦來源，但規劃能找出更多來源，這本身就是很大的好處。舉例來說，撰寫形式化規格可以暴露設計中的問題，或是將未知的未知轉變為已知的未知（接下來你就可以進一步深入研究）。這可能是被五件事突襲和被十五件事突襲的差別。這也是為什麼我如此看好形式化方法。

自動化

這是一把雙面刃。一方面，流程自動化讓人犯錯的空間變小。另一方面，自動化流程本身也可能有 bug，反而製造出新的摩擦來源。而且，如果自動化運作得夠久，人們會忘記它是如何運作的、或是它涵蓋的完整範圍，結果當它壞掉時，所有人都完全措手不及。自動化可能會以犧牲經驗為代價。

經驗

你遇過的問題越多，就越能預見接下來會出現的問題，也就越有經驗去從問題中恢復。不幸的是，這大多只能靠硬碰硬學來。但有一個捷徑是……

兵棋推演

關於這點，有一本很有意思的書是美國海軍戰爭學院的《Fundamentals of War Gaming》。書中主張，兵棋推演有兩個目的：蒐集情勢可能如何發展的資訊，以及在安全的環境中讓指揮官獲得（一定程度的）經驗。如果學員在兵棋推演中就學到「天氣可能會打亂你的計畫」，就不需要用真實的人命來學這堂課。同樣的道理，我寧可在不需要拼命搶救被誤刪的資料表時，就先練習如何取回資料庫備份。就我所知，資安與維運團隊也是基於這個理由而進行演練。

（同時，人們必須投入時間來執行與參與演練，這和增加備援一樣，是一種沒有效率的做法。）

檢查清單與操作手冊

將處理特定問題的隱性知識加以形式化的方法。

關於摩擦，我還有的疑問

將摩擦的來源進一步細分有用嗎？把工具問題稱為「技術性」摩擦而非「社會性」摩擦，對我們有任何實質幫助嗎？

其他領域是如何處理摩擦的？我問過一些營建業的人關於摩擦，他們認同這個概念，但沒有一個詞來稱呼它。那活動企劃、護理師、軍官呢？

我們該如何在「做了 X 能減輕摩擦的影響」與「不做 X 眼前更有效率」之間找到適當的平衡？

摩擦對個人來說重要嗎？即使團隊中沒有其他人這麼想，我在專案中思考摩擦對我有好處嗎？

感謝 Jimmy Koppel 提供的回饋。如果你喜歡這篇文章，歡迎訂閱我的 newsletter！我每週都會在上面發表新的文章。

我為企業提供形式化方法的培訓，讓軟體開發更快、更便宜、更安全。歡迎點此了解更多。

更新 2024-05-30

我把這篇文章收到的一些留言整理在這裡。