研发效能看板常见一个诱惑：把部署、代码量、满意度和协作都折成一个分数，管理者只看排名。问题是，这些信号回答的并不是同一个问题，合成后反而很难知道该改什么。
DORA先看交付系统
当前DORA指南列出五项软件交付指标：变更前置时间、部署频率、失败部署恢复时间、变更失败率和部署返工率。它们适合帮助理解一个应用或服务的交付表现，不宜直接转成个人绩效。
例如部署频率提高，同时失败和返工也增加，说明需要一起解释变化。只给频率加分，容易鼓励拆出没有业务价值的发布。
SPACE提醒我们别漏掉人的工作体验
SPACE来自2021年的研究，并非十月新框架。Microsoft Research的论文摘要明确，开发者生产力无法由单一活动指标或单一维度衡量。这给看板一个很实际的提醒：系统事件之外，还需要理解协作、等待和工作体验。
可以把看板设计成问题列表，而不是积分表：
| 要解决的问题 | 可看信号 | 需要补的解释 |
|---|---|---|
| 改动为何迟迟不到用户手里？ | 提交到部署的时间分布 | 队列、审批与批量发布 |
| 为什么上线后反复补救？ | 失败与返工记录 | 变更类型和回退限制 |
| 工具为何没人愿意用？ | 自愿反馈与访谈 | 学习成本、权限和打断 |
| 评审为何总找同几个人？ | 评审等待与分布 | 知识集中和责任范围 |
调查不能变成另一种打卡
满意度数据应说明样本、匿名性和缺失情况。强制每个人给新工具打高分，收集到的是服从程度。活动数据同样有偏差：一次重要的设计澄清可能没有代码提交，却减少了后续返工。
可先选择一个团队问题，保留改动前后的相同口径，再结合个案理解变化。本文没有采集真实团队数据，也没有构造综合评分公式。看板的价值应当是让下一步改进更明确，而不是把复杂工作压成一个无法解释的小数。
参考
- DORA软件交付指标
- Microsoft Research：SPACE论文摘要
