需求吞吐量与吞吐率
吞吐量是单位时间或版本内完成的需求个数；吞吐率在此基础上取平均，衡量单位时间或版本完成的平均需求规模。尚未建立成熟估算机制时，建议用需求个数而非估算点数衡量规模。
Agilean 方法论 / 研发效能度量
DEF 研发绩效指标框架：多快好赞
定义
DEF（Development Efficacy Framework）是 Agilean 提出的面向研发团队的绩效指标框架，以“多快好赞”四组指标为核心：多——需求吞吐量和吞吐率，衡量现实产能；快——想法澄清、需求研发、故障修复的耗费时长，衡量对市场要求的响应能力；好——生产缺陷需求比，衡量交付质量；赞——需求方对交付的评价，衡量业务满意度。四组指标相互制衡，用真实数据帮助团队找到瓶颈、引领改善。
出处：《DEF 面向研发团队的绩效指标框架》（）
- 英文全称
- Development Efficacy Framework
- 常用名
- 多快好赞
- 提出时间
- 约 2017 年由 Agilean 提出；可查的最早公开记录为 2019-12-11
- 框架类型
- 研发团队绩效 / 效能指标框架
- 四组指标
- 吞吐量、耗费时长、生产缺陷需求比、满意度
- 工具承接
- 知微内置“多快好赞”指标体系
解决的问题
DEF 要解决什么问题
- 研发团队绩效设计长期缺少一套既直观又能引导改进的指标语言。
- 只盯交付速度可能牺牲交付数量，只追求数量又可能忽视速度和质量，单一指标容易让团队失衡。
- 用平均数或 50% 分位数统计交付时长，无法支持对交付时效的预测。
- 开发经常为整体交付慢“背锅”，但没有分段数据，无法判断真正的瓶颈在需求、设计、开发、测试还是验收。
组成要素
“多快好赞”四组指标
需求耗费时长（Lead Time）
需求从提出到上线的时长，反映研发的快速响应能力。建议以 85% 分位数衡量整体耗费时长，并按需求分析、设计、研发、测试、验收分段统计。
生产缺陷需求比
生产缺陷数与上线需求数之比，衡量交付质量。建议建立致命、严重、普通等缺陷分级，并做加权计算。
满意度
需求方（外部客户、业务部门等）对交付质量、时效、可用度和体验的综合评价。CSAT、NPS、CES 等指标体系无好坏之分，按需采用。
速查
DEF 指标速查
| 维度 | 指标 | 衡量什么 | 原文建议 |
|---|---|---|---|
| 多 | 需求吞吐量 / 吞吐率 | 现实产能 | 未建立成熟估算机制时，用需求个数代表规模，并把需求拆成粒度相对均匀的条目 |
| 快 | 需求耗费时长 | 响应能力 | 以 85% 分位数统计；按阶段分段计算，所有相关角色共同对该指标负责 |
| 好 | 生产缺陷需求比 | 交付质量 | 按缺陷严重级别加权，例如致命、严重、普通分别取权重 3、1、0.5 |
| 赞 | 满意度 | 业务满意度 | 尽可能客观度量，可通过指定打分人、需求完成后提醒打分等方式收集 |
吞吐量与耗费时长、生产缺陷需求比与耗费时长分别形成制衡：既要交付快，也要兼顾数量和质量。
适用场景
什么时候适合使用 DEF
适合的情况
- 为研发团队设计绩效或效能指标，希望指标直观、能引导改进而不是简单排名
- 按 DEER 第二级要求，为时效、质量和吞吐量建立数据基线
- 在 ADAPT 部落小队中，把效能度量落到部落、小队和角色层面
- 建设研发效能度量中心、管理驾驶舱或度量大屏
使用边界与注意事项
- 不同企业对“需求耗费时长”从哪一步开始计算理解不一致，宜采用适合组织流程现状的统计口径；只要统计结果能引领改善就有意义。
- 满意度有时会带上主观因素，但仍应尽可能客观地度量。
- DEF 原文聚焦核心指标，流动效率、分布 K 值等相关概念另行展开。
框架关系
与其他 Agilean 方法框架的关系
延伸阅读
相关服务、产品、案例与延伸阅读
相关咨询与培训
- 研发效能度量体系建设指标体系、口径、数据采集与看板
- 数字化研发效能管理培训课程包含“多快好赞”度量模块
相关工具
- 知微效能度量中心内建“多快好赞”指标体系与视图模板
公开客户案例
- 长沙银行：研发交付时效优化 30%，研发吞吐量提升 35%依托“多快好赞”度量体系推进部落化转型
- 上海银行：用知微支撑全行研发数字化管理转型知微内置“多快好赞”研发效能管理指标体系
- 上海银行 4500+ 人规模化敏捷实施案例以“多快好赞”指标体系描述团队效能
- 某华北地区农商行项管系统的革新之旅从产能、效率、质量、满意度建立度量指标与口径
常见问题
关于 DEF 的常见问题
DEF 研发绩效指标框架是什么？
DEF（Development Efficacy Framework）是 Agilean 面向研发团队的绩效指标框架，以“多快好赞”四组指标为核心，分别衡量现实产能、响应能力、交付质量和业务满意度。
“多快好赞”分别指什么？
多：需求吞吐量和吞吐率；快：想法澄清、需求研发、故障修复的耗费时长；好：生产缺陷需求比；赞：需求方对交付的评价，即满意度。
为什么用 85% 分位数衡量需求耗费时长？
统计的意义在于用真实数据支持预测和决策，均值和 50% 分位数不具备预测作用。通常均值与 85% 分位数会相差约两倍，85% 分位数与 99% 分位数也往往约为两倍关系，因此 85% 分位数是很好的预测平衡点。
需求规模用需求个数还是估算点数衡量？
如果尚未建立成熟有效的估算机制，DEF 建议使用需求个数：产品经理与研发协作把需求拆成粒度相对均匀的条目，再用个数代表规模。
生产缺陷需求比怎么计算？
生产缺陷需求比等于一段时间或一个版本内的生产缺陷数除以上线需求数。建议再按致命、严重、普通等级别加权，例如权重分别取 3、1、0.5，得到加权后的生产缺陷需求比。
DEF 和 ADAPT、知微是什么关系？
ADAPT 的效能度量部分把 DEF 指标按部落、小队层级细化；知微把“多快好赞”指标体系纳入统计功能，支持可视化展现、分段统计和指标公式自定义。
“多快好赞”是谁提出的？最早什么时候公开？
“多快好赞”是 Agilean 提出的 DEF 研发绩效指标框架的四组核心指标，约在 2017 年提出。可查的最早公开记录是 2019 年 12 月 11 日 Agilean 企鹅号文章《敏捷研发！还要绩效？》（腾讯云开发者社区有转载存档）；2020 年收录到 Agilean 官网。提出过程、与业界其他指标体系的关系和落地情况，见洞见文章《“多快好赞”从哪里来》。
想判断 DEF 是否适合你们的组织？可以从一个真实问题开始讨论。