结构性摩擦：衡量人类协作成本的指标
2 分•作者: davidvartanian•3 天前
我当时带领着一个团队，感觉一切都很缓慢。每个人都很忙，但交付功能的速度仍然很慢。我们跟踪了团队的“速度”和“故事点”，但这些指标根本不关心业务做得有多好，也不关心开发成本，所以我意识到它们对我来说毫无用处。
我们（理论上）有一个干净的架构，但它却因为协调需求而束缚了我们。每次小的功能更改都需要跨多个团队的同步会议，而且更改通常也会波及到其他团队。我们花在沟通和架构开销上的时间，比实际的工程工作还要多。
我停止了衡量“速度”，开始衡量“结构性摩擦”。我将其定义为用于协调任务（即会议、设计、在其他模块中进行开发）的总人力工时，相对于用于高影响代码的实际工时。这个数字令人震惊。
我不得不将每个模块进行模块化，这样领域数据就不会再泄露。这至关重要，这样一来，该模块内的更改就永远不需要协调会议或在其他模块中工作。
我的团队在三个月内的产出翻了三倍。“结构性摩擦”是一个架构特性，你必须主动优化以保持其较低水平。如果你的架构迫使你进行协调（无论是在技术上、在会议上，还是两者兼而有之），那么它就是有缺陷的。消除协调的需求，你就能消除浪费。
查看原文
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.