度量与复盘
度量与复盘是同一枚硬币的两面：度量给复盘提供事实，复盘给度量指明方向。团队不是「因为被度量而变好」，而是「因为基于事实持续改进而变好」。本篇讲三件事：选什么指标、怎么开一场有效的回顾、项目结束后如何系统复盘。
指标设计：先想清楚为什么度量
| 维度 | 反例（错） | 正例（对） |
|---|---|---|
| 目的 | 「老板要看报表」 | 「想找出交付瓶颈在哪」 |
| 对象 | 度量个人 | 度量系统与流程 |
| 后果 | 谁更快谁得奖 | 数据用于改进而非惩罚 |
古德哈特定律（Goodhart's Law）：当指标变成目标，它就不再是好指标。成员盯着「代码行数」就会注水，盯着「燃尽图好看」就会推迟暴露问题。对策：指标搭配背后的原因与上下文一起看，并明确「这是为了改进，不是考核」。
常用交付指标
| 指标 | 看什么 | 解读注意 |
|---|---|---|
| 周期时间（Cycle Time） | 单需求从开始到完成 | 上升说明流程劣化；对比前后端差异找瓶颈 |
| 吞吐量（Throughput） | 单位时间完成数 | 与周期时间互证，别只看其一 |
| 在制品（WIP） | 同时进行中数量 | 过高是拥堵信号（关联方法论与流程看板） |
| 燃尽/燃起 | 迭代剩余工作 vs 新增 | 燃起持续走高说明范围在渗透（见需求与范围） |
| 缺陷逃逸率 | 线上缺陷 / 阶段内发现 | 区分需求/设计/代码缺陷来源 |
| 速率（Velocity） | 单迭代完成点数 | 用于规划参考，不要跨团队比较 |
速度与吞吐属于「过程指标」；产品是否被用户认可属于「结果指标」，体系设计见产品指标与增长。
迭代回顾：让它真的有用
推荐流程（40~60 分钟）
- 开场：重申回顾不是追责会；
- 数据铺底：贴出周期时间、吞吐、燃尽等事实（见上表）；
- 三问收集：做得好的 / 做得差的 / 感到困惑的；
- 聚类投票：合并同类项，每人投 3 票选出最值得改的主题；
- 定行动项：每个主题产出具体、可验证的改进动作（有 owner、有验收方式）；
- 收尾：下个迭代评审时回查行动项是否真的生效。
四类回顾格式（按需替换三问）
| 格式 | 提问框架 | 适用 |
|---|---|---|
| 4L | Liked / Learned / Lacked / Longed for | 通用，最常用 |
| Starfish | 保持 / 增多 / 减少 / 停止 / 开始 | 需显式保留成果时 |
| Sailboat | 助力的风 / 拖慢的锚 / 风险暗礁 | 团队需要可视化隐喻 |
| Start-Stop-Continue | 开始做 / 停止做 / 继续做 | 快节奏小团队 |
项目复盘：把经验变成资产
一次项目结束后，除了过程记录里的个人复盘模板，团队级复盘还要回答系统性问题。沿用四段框架，把度量数据作为证据：
| 环节 | 问什么 | 数据来源 |
|---|---|---|
| 目标回顾 | 当初的目标与验收标准是什么 | 项目章程、范围基线 |
| 结果核对 | 交付/质量/时间/成本的预期 vs 实际 | 燃尽图、缺陷率、工时记录 |
| 原因分析 | 决策与假设哪里错了、哪些外因 | 风险登记表、评审记录、回顾结论 |
| 行动项 | 下个项目要保留/改变/补学的做法 | 汇总历次迭代回顾 |
复盘最容易失效的两个时刻：一是项目一结束团队就散伙，无人汇总；二是复盘会开完，行动项无人跟踪。落地闸门同个人复盘：行动项必须进下一项目的启动会议，并设复查时间。
度量体系的常见坑速查
| 坑 | 表现 | 应对 |
|---|---|---|
| 只看结果不看过程 | 交付晚才发现流程问题 | 同时跟踪周期时间/吞吐/在制品 |
| 指标被当绩效 | 成员开始操纵数据 | 明确数据用途是改进，匿名化采集 |
| 跨团队比较速率 | 伤了士气又没意义 | 速度只用于本团队规划 |
| 回顾走过场 | 每迭代说同样的话 | 行动项带 owner 与验收，迭代首日回查 |
| 复复盘盘不落地 | 行动项写过即忘 | 立项会强制纳入上期行动项 |
检查清单
- [ ] 已明确指标目的，且不会因指标引入激励扭曲（Goodhart 自查）
- [ ] 选定 3~5 个核心指标并持续采集至少 2 个迭代
- [ ] 迭代回顾按「数据 → 三问 → 投票 → 行动项」流程执行
- [ ] 行动项有 owner、有验收方式，下个迭代初回查
- [ ] 项目结束后完成团队复盘，结论进入下一项目的启动文档
- [ ] 数据用于改进而非问责，团队清楚这一点