度量用在改进还是问责
同一组数字，用于系统改进还是用于追责，会带来完全不同的团队行为。用于追责时，团队会先学会保护自己：数据被延迟登记、问题被标记为误报、失败被隐藏，指标越来越好看而真实情况越来越糟。用于改进时，数据是共同讨论问题的入口，异常先看系统原因再看个案。引入新指标之前，先把使用边界说清楚，比指标本身更重要。
边界与做法
| 边界约定 | 数据用于流程改进，不用于个人绩效排名 |
|---|---|
| 参与方式 | 指标由团队共同制定与解释，而不是单方面下达 |
| 预警信号 | 出现不想让上级看到某个数字的讨论，说明边界已被破坏 |
| 更换机制 | 指标本身每季度可讨论、可调整、可废弃 |
典型使用场景
- 引入新指标前：先确认数据来源、维护责任人与异常解释路径，答不上来就暂缓
- 看板公开：明确谁能看到数据、数据用来说明什么问题
- 复盘会：异常项先分析系统与流程原因，避免直接落到个人
- 指标失效时：公开说明为什么更换，并保留历史口径说明
- 跨团队比较：先统一口径与统计窗口，否则结论不可用
团队约定模板
团队约定模板
# 度量使用约定
1. 度量数据默认全团队可见，不设暗箱统计
2. 不用于个人绩效评估，不产出个人排名
3. 异常先复盘系统与流程原因，再看个案
4. 指标本身每季度可讨论、可更换
5. 数据口径与窗口在每次报告中写明两种用法对照
| 维度 | 警察化 | 共建化 |
|---|---|---|
| 数据归属 | 上级采集，团队被观察 | 团队共同定义与解读 |
| 异常处理 | 先找责任人 | 先找系统原因 |
| 行为后果 | 数据被修饰、隐藏 | 数据被用于选择改进项 |
| 指标寿命 | 长期不变，逐步失真 | 定期评估调整 |
| 普适症状 | 没人主动报问题 | 问题被主动摆上桌面 |
公开数据前先约定用途，比事后解释更有效。团队若不确定数据会不会被用于评价个人，任何统计都难以保持真实，后续基于这些数据的决策也会失真。
指标数量要少：同时追踪十几个指标，注意力被摊薄，反而没有一项被真正改进。选两三个与当前主要问题相关的指标，季度末再评估是否更换。
落地检查清单
- 数据用途边界有书面约定并公开
- 每个指标有明确的责任人与异常处理路径
- 异常复盘先系统后个人
- 约定被违反时有明确的补救动作，而不是沉默