以下是针对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）负责维护军种层面的资料库。

相比大型软件公司，我认为我们面临的一个较为独特的挑战是人员流动率更高，人员通常在大约两年后就会轮调离开原单位。因此，很难仅靠人员的记忆来维持持久的知识储备，必须把它写下来才能真正发挥作用。