先给结论：别数活塞，先修引擎。用个人 KPI 去丈量一个复杂系统里的节点，就像拿 PPT 测网速——数字很顺眼，网还是卡。
Daniel 的故事主角 Tim，点数永远是 0。原因很简单：他不抢故事，不攒“个人产出”；他在四处结对，把别人的活做顺，把团队的习惯拉直。看起来他没交付软件，实际上他在交付“能持续交付的软件团队”。
一、硬结论
- 点数不是钱：故事/点数 ≠ 价值。价值要回到“省下/赚到/守住”的美元；点数只是易碎的代理。
- 个体贡献不可分：复杂系统里，很难把“这一点产出”切成某人的份额。度量引擎，不要数活塞。
- 真正的杠杆在“熵减”：结对、统一语言、脚手架、标准化，这些事儿降低系统摩擦，让大家“稳定地更好”。
- DORA 有边界：它测的是“工作系统”把变更推到生产的能力，不是个人年终奖模板。把系统指标拽进个人奖惩，只会把数据优化成样子货。
二、为什么这篇文章会戳中我
- 我见过 KPI 挟持的团队：行数漂亮、评审摆拍、测试挤兑、事故连环，最后“高产个人”走了，技术债留给还款部。
- 也见过 Tim 型同事被误伤：他们花时间对齐、沉淀、配对，系统顺了，但 Excel 分数=0。有人觉得“摸鱼”，其实他们在替系统止血。
- 我见过“系统增益”被忽视：他们默默修好边界，但没人给他们“价值”的度量。
三、怎么干
团队对价值负责，不是个人对点数负责
- 团队层：发布频率、Lead Time、变更失败率、MTTR（DORA）。
- 业务代理：功能触达/成功率、回滚率、问题单寿命、SLO 违约次数。
- 观察角度：瓶颈常在边界（交接/依赖/环境），不在“英雄”。
把“系统增益”变成明牌职责
- 配对/辅导要产出“可复用”资产：规范、模板、脚手架、回顾结论。
- 把“教”和“做”拆账：教会一个人=后面十个人更快，这是资本性投入。
- 回顾会上讲证据：因为某人介入，DORA 哪条变好了，别讲玄学。
用工程手法治理系统，而不是喊口号
- 设计默认：分支策略、审批阈值、回滚/特性旗帜、蓝绿/金丝雀、SLO 红线。
- 保持流动：小批量、WIP 限制、可中断队列、把 CI 加速到“等得起”。
- 给修系统的人留时间与权限：他们不是“产出为零”，他们在给团队“压熵”。
四、我和原文的两点分歧
- 指标不是原罪，拿来当终点才是。继续测，但只做反馈回路；一旦进奖惩，默认它会失真。指标的核心作用是“发现问题”，不是“评判人”。
- 不是每个组织都配得上 Tim。请给“系统增益”角色一个公开的职责说明与认可路径，否则人会被误读成“游走”。
五、行动清单
- 看板加一列 System Enablers：脚手架/自动化/规范/知识迁移。每月复盘一次这列的“熵减收益”。
- 回顾会固定两问：
- 最近两周交付被什么卡住（环境/依赖/沟通/审批）？
- 哪件事沉淀下来，能让后面 10 次更快？
- 把结对纳入节拍：新人/复杂需求/高风险变更优先结对；给“结对时间”记账，不和点数对冲。
- 用 DORA + 业务代理看系统健康；个人维度只谈“能力建设”（学习/分享/工程实践达成）。
- 给“系统增益职位”写清楚：职责、目标（比如把平均 Lead Time 压到 X）、公平的认可方式。
六、给不同角色的一句话
- 管理者：度量引擎，不数活塞。把“增益型工作”从隐形劳动拉到台前，保护节拍时间。
- 资深同学：少当英雄，多修系统。把隐性知识产品化，让别人稳定地更快。
- 初级同学：多和 Tim 配对。学他的提问法、分解法、风控法；把学到的方法写回资产库。
一句话总结
衡量可以也应该做，但“问责对象”请切到“工作系统的产能与一致性”。当我们开始奖励修系统的人，系统才会真的变好。剩下的，就让点数安静地做个反馈信号吧。
延伸阅读
- Accelerate / DORA（发布频率、Lead Time、变更失败率、MTTR）
- 《The Goal》：流动效率与瓶颈思维
- Team Topologies：团队拓扑与平台化“启用函数”