返工率衡量改完又改
返工率衡量「改完又改」的比例，包含回滚、上线后紧急修复，以及短期内对同一处代码的二次修改。它和变更失败率、逃逸缺陷一起刻画交付质量。返工率高通常指向需求不稳、评审不足或验证环节缺失，分析必须落到具体环节与具体成因，而不是归到某个人身上。
基本信息
| 口径 | 回滚、紧急修复、短期二次修改的占比 |
|---|---|
| 关联 | 需求变更、评审质量、测试漏出 |
| 动作 | 按环节归因：需求、设计、实现、发布 |
| 注意 | 区分探索性返工与质量返工 |
典型使用场景
- 发布复盘：统计本版本的回滚与紧急修复次数，定位到具体环节
- 需求侧改进：返工集中在需求澄清阶段，就把验收标准前置
- 评审改进：返工集中在同一处代码，说明评审粒度或清单缺失
- 发布流程：返工来自配置与依赖问题，就补发布前校验与依赖锁定
- 趋势观察：返工率持续上升时先暂停新增需求，优先修流程
观察示例
观察示例
# 版本 v1.8：共 12 次发布
# - 回滚 1 次（依赖版本冲突）
# - 24 小时内二次修复 2 次（断言遗漏、配置漏项）
# 归因：发布前配置校验与依赖锁定需要强化
# 动作：加入依赖锁文件检查、发布前配置项比对清单返工成因与对应动作
| 集中环节 | 典型成因 | 改进动作 |
|---|---|---|
| 需求 | 验收标准模糊，做完才发现理解不一致 | 需求评审补验收标准与边界样例 |
| 设计 | 接口定得太早，实现时被迫返工 | 设计文档先行评审再开工 |
| 实现 | 缺测试覆盖，缺陷留到集成阶段 | 补关键路径测试并做用例评审 |
| 发布 | 配置与依赖项遗漏 | 发布前校验清单与依赖锁定 |
归因要按环节而不是按人：当返工被用作个人评价，最理性的应对是隐藏与转嫁，数据质量随之崩塌；把它当成团队级的流程诊断工具，才有机会看到真实原因。
不要把探索性返工算进质量返工：需求验证阶段的快速试错会自然地改代码，与「上线后回滚」不是一类问题，混在一起会误伤正常的迭代节奏。