需求吞吐量与吞吐率
单位时间或版本内完成的需求个数及平均规模，衡量现实产能。尚未建立成熟估算机制时，用需求个数而非估算点数衡量规模。
Agilean 问答指南 / 研发效能度量
研发效能怎么度量？
简要回答
研发效能度量应从业务结果出发，用一组相互制衡的指标同时观察产能、响应速度、质量和满意度，而不是只看单一指标。Agilean 的 DEF 框架以“多快好赞”为主线：多看需求吞吐量，快看需求耗费时长（建议用 85% 分位数），好看生产缺陷需求比，赞看需求方满意度；DORA 的五项软件交付指标则聚焦代码从提交到生产部署的速度与稳定性，两者可以互补使用。
作者：Agilean（爱捷软件）内容依据本站方法定义页、咨询服务页和公开案例整理
主线指标
“多快好赞”四组指标
四组指标相互制衡：既要交付快，也要兼顾数量和质量，并接受业务方的评价。需求耗费时长（Lead Time）
需求从提出到上线的时长，衡量响应能力。建议以 85% 分位数统计，并按需求分析、设计、研发、测试、验收分段计算。
生产缺陷需求比
生产缺陷数与上线需求数之比，衡量交付质量；建议按致命、严重、普通等级加权，例如权重取 3、1、0.5。
满意度
需求方对交付质量、时效、可用度和体验的综合评价；CSAT、NPS、CES 等方式按需采用，尽可能客观收集。
对比
DEF 多快好赞与 DORA 指标有什么不同
| 对比项 | DEF（多快好赞） | DORA 软件交付指标 |
|---|---|---|
| 提出方 | Agilean | DORA（DevOps Research and Assessment）研究项目 |
| 度量对象 | 以需求（业务价值单元）为单位，覆盖从提出到上线的全过程，以及业务方评价 | 以应用或服务为单位，覆盖软件变更从提交到生产部署及部署后的稳定性 |
| 指标 | 需求吞吐量/吞吐率、需求耗费时长、生产缺陷需求比、满意度 | 变更前置时间、部署频率、失败部署恢复时间、变更失败率、部署返工率 |
| 速度 | 需求耗费时长，85% 分位数，可分段统计 | 变更前置时间：从提交到版本库到部署到生产的时长 |
| 质量与稳定性 | 生产缺陷需求比，按缺陷严重级别加权 | 变更失败率、部署返工率，以及失败部署恢复时间 |
| 业务视角 | “赞”直接纳入需求方满意度 | 五项指标聚焦软件交付表现，DORA 将其视为组织绩效与员工福祉的先行指标 |
| 使用提醒 | 用于发现瓶颈、引导改进，而不是简单排名 | 建议按单个应用或服务度量，不宜设为硬性目标或在差异很大的应用之间比较 |
DORA 指标已从最初的“四个关键指标”演进为当前五项，表中描述以 dora.dev 官方指南为准。两者关注的范围不同：DORA 更贴近工程交付链路，DEF 覆盖需求全过程和业务评价。
落地步骤
六步建立研发效能度量体系
- 01
明确度量目标
从业务价值和研发交付目标出发，先回答“度量用来改进什么”，再选指标。
- 02
以多快好赞为主线选指标
用 DEF 四组指标描述需求全过程；需要观察工程交付链路时，可补充 DORA 的部署频率、变更失败率等指标。
- 03
统一口径
明确需求耗费时长从哪一步开始计算、缺陷如何分级、满意度由谁打分，口径以适合组织流程现状、能引领改善为准。
- 04
打通数据来源
接入需求、代码、测试、发布等工具数据；工具数据不完整时，先推动需求任务流程线上化。
- 05
建立基线
按 DEER 第二级“基线建立”的要求，为时效、质量、吞吐量和流动效率建立基线，后续以此衡量改进效果。
- 06
看板 + 定期分析
通过效能看板和定期分析机制，把度量用于团队改进和管理决策，并在部落、小队、角色等层级细化。
常见误区
研发效能度量的五个常见误区
- 只看一个指标：只盯速度可能牺牲数量和质量，只追数量又会忽视速度和质量。
- 用平均数统计时长：均值和 50% 分位数不具备预测作用，85% 分位数更适合作为预测平衡点。
- 把度量当排名：DEF 和 DORA 都提醒，指标用于找瓶颈、看趋势，横向排名容易引发“刷数”。
- 工时、代码行用于考核：工时不可能绝对准确，代码行也不能完全代表工作量，这些数据应作为管理者直觉的佐证。
- 为精确数据而推迟改进：先用已有数据和团队对话找到最大瓶颈，比追求完美的数据集成更重要。
适用条件
适用条件与注意事项
适合以 DEF 为主线的情况
- 需要衡量需求从提出到上线的全过程，而不只是工程部署环节
- 研发团队、产品经理和业务方需要一套共同的效能语言
- 在部落、小队等多层级组织中细化效能指标
注意事项
- 不同企业对需求耗费时长的起点理解不一致，应采用适合自身流程的口径并保持一致。
- 满意度难免带有主观因素，应通过指定打分人、需求完成后提醒打分等方式尽量客观。
- 需要评估持续交付与部署稳定性时，可补充 DORA 指标，二者并不冲突。
公开案例
相关公开客户案例
数字均摘自对应案例页原文，点击可查看完整案例。长沙银行研发交付时效优化 30%，研发吞吐量提升 35%
分两个阶段：第一阶段试点，第二阶段推广，推广阶段用时六个月；依托“多快好赞”度量体系，用需求分段时效、月度吞吐量等指标建立研发管理闭环。
查看案例 →上海银行用知微支撑全行 2500 人以上的研发数字化管理转型在一期试点成功的基础上，以知微建立线上化的敏捷部落小队运作机制和端到端敏捷管理机制。
查看案例 →某地方性银行建成覆盖需求、开发、测试、交付的金融科技度量系统形成从指标定义、数据集中管理、量化分析到持续改进的研发效能管理闭环。
查看案例 →某华北地区农商行从产能、效率、质量、满意度建立度量指标与口径知微效能度量模块脱胎于 ADAPT 规模化敏捷框架。
查看案例 →延伸阅读
相关方法论、咨询服务与延伸阅读
相关咨询与培训
- 研发效能度量体系建设指标体系、口径、数据采集与效能看板
- 精益研发流程优化价值流识别与流动效率优化
- 数字化研发效能管理培训课程包含“多快好赞”度量模块
相关工具
- 知微效能度量中心内建“多快好赞”指标体系
相关方法论
- DEF 研发绩效指标框架（多快好赞）以“多快好赞”四组相互制衡的指标衡量产能、响应能力、交付质量和业务满意度。
- DEER 研发效能提升路线图从混乱到发布受控、基线建立、协作优化、自动守护、挑战卓越的五级进阶路线。
- FLEET 精益效能提升思维框架看见、整流、细粒、润滑、小批、降本六条核心思路，快速定位研发效能问题。
公开资料
- DORA’s software delivery performance metrics（dora.dev）DORA 五项软件交付指标的官方说明
常见问题
常见问题
DEF 和 DORA 指标应该选哪个？
取决于要回答的问题。想看需求从提出到上线的全过程和业务满意度，以 DEF“多快好赞”为主线；想看工程交付链路的速度与稳定性，可使用 DORA 五项指标。两者可以组合：DEF 作为管理主线，DORA 作为工程侧补充。
为什么需求耗费时长要用 85% 分位数？
度量的意义在于支持预测和决策，均值和 50% 分位数不具备预测作用。通常均值与 85% 分位数相差约两倍，85% 分位数与 99% 分位数也往往约为两倍关系，因此 85% 分位数是较好的预测平衡点。
需求耗费时长从哪一步开始算？
不同企业理解不一致，可以从需求提出、需求就绪或进入研发开始计算。关键是采用适合组织流程现状的口径并保持一致，同时按阶段分段统计，便于定位瓶颈。
研发效能度量会不会变成考核排名？
需要主动避免。统一口径和解释方式、使用相互制衡的指标组合、把度量结果用于团队改进和管理决策，而不是横向排名，是 DEF 和 DORA 共同的建议。
生产缺陷需求比怎么计算？
一段时间或一个版本内的生产缺陷数除以上线需求数。建议按致命、严重、普通等级别加权，例如权重分别取 3、1、0.5。
工具数据不完整，还能开始度量吗？
可以。先推动需求任务流程线上化，从已有数据建立初步基线，再逐步接入代码、测试和发布数据。先找到最大瓶颈并改进，比追求完美的数据集成更重要。
想结合你们组织的实际情况讨论这个问题？可以从一个具体的业务或研发场景开始。