這些是針對Software Friction的一些回應。

探討相似主題的部落格

Laurie Tratt 寫了What Factors Explain the Nature of Software?，也觸及了摩擦這個主題。

電子郵件與留言

我是美國海軍陸戰隊的一名步兵軍官，我們經常談論摩擦。如果你正在讀克勞塞維茲，可能會對《Marine Corps Doctrinal Publication 1 (MCDP 1) Warfighting》（文末有 PDF 連結）這本書感興趣。這本書很快就能讀完。

我們處理摩擦的方式大致就如你所描述的那樣，我們在人員職涯早期就讓他們認識摩擦，這有助於他們在累積經驗的過程中，慢慢學會找出解決摩擦的方法。

我們常用的一個戰術，是我沒看到你提到、但我認為對軟體團隊也會非常有用的，那就是「hot washes」。基本上，就是在一次任務結束後，無論是訓練還是實戰，立刻召集所有關鍵人員一起坐下來，回顧哪些地方做得好、哪些地方出了問題，以及是否應該更新標準作業程序（Standard Operating Procedures）來提升未來的表現。定期做這件事，也有助於淡化那種「自尊受挫」的感覺——姑且這麼說吧——在同儕面前被公開點出錯誤確實不好受，但跟其他事情一樣，多做幾次就會習慣了。定期進行 hot washes 也能在隊員之間建立共同的理解，有助於溝通並減少摩擦。

我問了「hot washes」和事後檢討有何不同。對方的回覆是：

我認為最主要的差別在於（或許這在敏捷圈也很常見，只是我不知道而已），通常會有一位「scribe」（紀錄者）以特定的格式（通常是 Topic-Discussion-Recommendation）來記錄重點，然後這些紀錄會被保存下來，存放在部隊層級的資料庫中，很多時候甚至會存到整個軍種層級的資料庫。這讓你可以回顧自己以前犯過的錯誤，甚至可以參考多年前、面臨類似問題的其他單位所犯的錯誤。Marine Corps Center for Lessons Learned 負責維護軍種層級的這類資料庫。

相較於大型軟體公司，我想我們面臨的一個比較獨特的挑戰是人員流動率更高，人員通常在大約兩年後就會輪調離開原單位。因此，很難光靠人員的記憶來維持知識的長期累積，必須寫下來才會有效。