结构摩擦：人类协调成本的指标
我曾领导一个团队，但一切进展缓慢。每个人都很忙，但推出新功能的速度依然很慢。我们追踪了开发速度和故事点，但这些指标根本不关心业务的表现或开发成本，因此我意识到它们对我来说毫无用处。
我们在理论上有一个清晰的架构，但它却因为协调的要求而束缚了我们。每一个小的功能变更都需要跨多个团队的同步会议，而变更通常也会影响到其他团队。我们在沟通和架构上的开销所花费的时间，远远超过了实际的工程工作时间。
我停止了对开发速度的测量，开始衡量结构摩擦。我将其定义为在协调任务（即会议、设计、在外部模块中的开发）上花费的总人时数，相对于在高影响力代码上花费的实际时间。这个数字令人震惊。
我必须对每个模块进行模块化，以避免领域数据的泄露。这是至关重要的，这样在该模块内的变更就不再需要协调会议或在其他模块中进行工作。
我的团队在三个月内的产出翻了三倍。结构摩擦是一种必须积极优化以保持低水平的架构特性。如果你的架构迫使你进行协调（无论是在技术上、会议上，还是两者兼而有之），那么它就是有缺陷的。消除协调的需求，你就消除了浪费。
查看原文
I was leading a team and everything felt slow. Everyone was busy, but shipping features was still very slow. We tracked velocity and story points, but those metrics don't even care about how good a business is doing or the cost of development, so I realized they were useless to me.<p>We had a clean architecture (in theory), but it was strangling us with coordination requirements. Every minor feature change required a sync meeting across multiple teams and changes usually propagated to other teams as well. We were spending more time on the communication and architectural overhead than the actual engineering work.<p>I stopped measuring velocity and started measuring Structural Friction. I defined it as the total human hours spent on coordination tasks (namely meetings, design, development in foreign modules) relative to the actual hours spent on high-impact code. The number was horrifying.<p>I had to modularize every module so domain data was no longer leaked. This was essential so changes within that module would never require coordination meetings or work in other modules.<p>My team’s output tripled in three months. Structural friction is an architectural feature that you must actively optimize to keep low. If your architecture forces you to coordinate (either in tech, in meetings, or both), it's flawed.
Eliminate the need for coordination, and you eliminate the waste.