---
title: "DEF 面向研发团队的绩效指标框架"
url: https://www.agilean.cn/insights-new/43/
updated: 2023-12-13
description: "DEF 是 Agilean 以“多快好赞”为核心的研发绩效指标框架。本文说明吞吐量、需求耗费时长、生产缺陷需求比和满意度四组指标的含义、算法与相互制衡关系，以及不同角色应关注哪些指标。"
publisher: "Agilean（爱捷软件开发（深圳）有限公司）"
language: zh-CN
---

研发团队绩效设计，一直是一个备受关注的话题。结合过往十余年为企业进行敏捷咨询和敏捷转型落地，以及研发绩效体系设计的实践经验，Agilean 推出了以「多快好赞」为核心的 DEF 研发绩效体系，与大家分享我们的观点与实践

# DEF 面向研发团队的绩效指标框架

作者：编辑部 发布于 2022/4/19 更新于 2023/12/13

## DEF 面向研发团队的绩效指标框架

DEF，Development Efficacy Framework，这套研发绩效体系以\*\*「多快好赞」4组指标\*\*为核心：

- 多：需求吞吐量和吞吐率，衡量**现实产能**；
- 快：想法澄清、需求研发、故障修复的耗费时长，衡量研发部门对市场要求的**响应能力**；
- 好：生产缺陷需求比，衡量**交付质量**；
- 赞：需求方对交付的评价，衡量**业务满意度**。

![DEF研发绩效体系的四组核心指标](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/DEF/DEF-01.png)

图 / DEF研发绩效体系的四组核心指标

**Agilean 自研的零代码数字化管理系统知微**，已将这套指标体系纳入统计功能，从而进行可视化展现和快速统计。下面将结合知微研发同学的真实数据，对重要指标进行详细解释。

## 需求耗费时长

需求耗费时长（即需求前置时间，Lead time）衡量研发团队需求交付速度，它**反映了研发的快速响应能力**，受到很多研发团队关注。

计算单一「需求耗费时长」的公式如下：

![需求耗费时长计算公式](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/DEF/DEF-02.png)

如果一个需求11月5日提出，11月20日上线，则该需求耗费时长为15天。

基于过往经验，在 DEF 研发绩效体系中，Agilean 建议研发部门**以85%分位数来衡量整体需求耗费时长指标**。随机取10个需求为例，耗费时长分别是15、25、40、45、45、45、48、52、65、80天，85%分位数为第9个数字（10\*85%并四舍五入），由此可知85%的需求在65天内交付。

零代码数字化管理系统知微的统计视图即可以85%分位数对需求耗费时长进行可视化展示。下图为2017年7月至今年11月13日的真实数据，即知微研发近3年的需求耗费时长统计。图里方框内的数字，表示如果以2017年11月28日之前的90天为采样周期，知微85%的需求在26天内完成。

![零代码数字化管理系统知微以85分位数计算统计的需求耗费时长](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/DEF/DEF-03.jpg)

图 / 零代码数字化管理系统知微以85分位数计算统计的需求耗费时长

> 为什么选用85%分位数而不是使用更广的平均数？统计的意义在于以真实有效的数据进行预测，从而支持更优决策，避免由于主观或经验判断布下的雷区，而**均值和50%分位数无法具备支持预测的作用**。通常情况下，均值和85%分位数的统计结果会出现两倍的差距，85%分位数和99%分位数也往往是约两倍关系。因此，**85%分位数是一个很好的预测平衡点**。

![知微研发团队近3年来的需求耗费时长](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/DEF/DEF-04.png)

图 / 知微研发团队近3年来的需求耗费时长

上面这张柱形分布图，真实展现了知微研发团队三年来的需求耗费时长。可以看到，**数据较好地符合了韦伯分布（Weibull Distribution）**，即存在一个众数尖峰以及一条长尾。排除掉异常时间影响后，我们就可以自信地**进行整体交付时效和响应指标的预测**。

Agilean 在十数年企业研发敏捷咨询过程中，发现需求耗费时长是一项非常重要的协作指标。研发部门任何环节掉队，都会导致该指标发生敏感变化，因此，所有相关角色都应对该指标负责。基于以上考虑，**零代码数字化管理系统知微支持对需求耗费时长进行分段计算**。不仅能实时展示需求端到端耗费时长，也可以分成需求分析、设计、研发、测试、验收等各段分别展示，并以不同颜色的线条表现其变化趋势。

![零代码数字化管理系统知微支持对需求耗费时长进行分段统计](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/DEF/DEF-05.jpg)

图 / 零代码数字化管理系统知微支持对需求耗费时长进行分段统计

举一个典型例子。开发同学经常为整体交付慢背锅，很多人认为需求交付慢的根源在于开发耗时太久。但通过知微产品团队累积的真实数据可以看到，开发环节耗费时长（11天）少于需求设计（14.45天）和验收（13天）。事实上，知微产品团队用了1.5倍于开发阶段的时间，来想清楚需求。通过自身经历，Agilean 深深感受到对创新产品来说，想清楚需求要花很多时间，过程中需要不同角色参与，需要头脑风暴和反复讨论。在这个过程中，研发并不是瓶颈，「想好」是「做好」的前提。

通过上述的分段计算方式，需求完成链条中不同阶段的具体耗时一目了然。团队可以快速发现影响整体交付速度的环节，找到真正的痛点，并采取有针对性的改善措施，而不是仅凭主观做出判断。

现实中，不同企业不同研发部门对「需求耗费时长」的理解并不一致，主要差异在于该从哪个步骤开始计算：用需求提出时间？需求澄清时间？还是需求确认选择时间？我们认为最好采用适合组织流程现状的统计方式，这并不会影响该指标蕴含的价值。因此，**知微上所有的统计指标和计算公式**，都能**根据企业需要进行灵活定义和实时调整**，人们可以**自行编辑诸如需求耗费时长一类的计算公式**，只要该统计结果能在现实中引领改善，对企业就是有意义的。

## 需求吞吐量和吞吐率

需求吞吐量（单位时间或版本内完成的需求个数），是最直观粗暴的研发产能度量指标，表述通常为「上个版本完成了XX个需求」。

需求**吞吐率在吞吐量基础上增加了平均计算**，以衡量单位时间或版本完成的平均需求规模，表述通常为「今年以来，每个版本平均完成XX个需求」。

这两个指标容易理解且应用广泛。以知微为例，下图是知微研发团队需求吞吐量的按月统计结果（也可按需选择日、周、双周等不同统计周期），从图中数据可以自动汇总计算出研发团队的吞吐率。比如，2020年5-9月这段时间，需求吞吐率为78个需求/月。

![知微研发团队近5个月的需求吞吐量统计](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/DEF/DEF-06.jpg)

图 / 知微研发团队近5个月的需求吞吐量统计

除了按时间统计产能，知微也支持按版本进行吞吐量和吞吐率统计。下图可以看出知微的迭代速度（差不多每两周一个版本），以及每个版本完成了多少个需求，以及产能的变化。

![知微近7个版本的产能统计](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/DEF/DEF-07.jpg)

图 / 知微近7个版本的产能统计

采用吞吐量和吞吐率作为产能指标，往往被问到一个问题：如何衡量需求规模？目前，需求规模衡量通常有两种选择：需求个数、需求估算点数。如果尚未建起一套成熟有效的估算机制，Agilean 强烈建议使用需求个数而非需求估算点数来衡量需求规模。产品经理与研发共同协作，将需求拆分成粒度相对均匀的条目，再用需求个数来代表需求规模。

除度量产能这个作用以外，**需求吞吐量/率还能够与需求耗费时长形成制衡**，二者共同使用，可以避免只改善交付速度但降低交付数量，或者只考虑数量增加而忽视了速度。在二者基础之上，研发还应关注交付质量和交付成效，助力业务指标的达成。

那么，好的质量指标该是什么样？请继续往下看。

## 生产缺陷需求比

生产缺陷需求比是一项质量指标，用于**衡量研发交付质量**，计算公式如下：

![DEF 框架生产缺陷需求比计算公式](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/DEF/DEF-08.png)

图 / DEF 框架生产缺陷需求比计算公式

直接以知微研发团队的实际数据进行介绍：

![知微生产缺陷相关指标统计](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/DEF/DEF-09.png)

图 / 知微生产缺陷相关指标统计

知微上一个版本V1.1.1，上线需求59个，生产缺陷7个，生产缺陷需求比为0.11个缺陷每需求。这是对该指标的基础统计，我们建议研发团队建立一套生产缺陷分级机制，按照致命缺陷、严重缺陷、普通缺陷等严重级别对生产缺陷数量进行加权计算。

依然采用知微V1.1.1版本的数据。过滤后发现7个缺陷均为普通缺陷，如果致命、严重、普通缺陷权重分别为3、1、0.5，加权后的生产缺陷个数为0*3+0*1+7\*0.5=3.5，即加权后的生产缺陷需求比为0.06个缺陷每需求。

不同业务类型、不同规模的研发组织对质量的要求不尽相同。生产缺陷需求比与需求耗费时长可以形成制衡，既要交付快，也要兼顾质量水平。很多角色可能对质量造成影响，比如产品经理、开发工程师、测试工程师、架构师等。

## 满意度指标

与需求耗费时长、吞吐量等指标相比，满意度是一个外部指标，它反映**需求方（外部客户、业务部门等）对研发交付质量、时效、可用度、体验等的综合评价**。满意度有时会带上主观因素，但我们仍应尽可能客观地度量它。

一个需求上线后，其耗费时长、吞吐量、生产缺陷需求比等指标已经可以得出。到此阶段时，对需求的评价已暂时脱离研发体系，转而由业务部门处理，通过适合的评价体系，在客户处获得对该需求的满意度评价。

目前流行的满意度指标体系中，常见的是CSAT「非常满意」-「非常不满意」5重评价，NPS（净推荐值）的0分（完全不可能）- 1分（完全可能）推荐倾向。对于服务型产品，有CES（用户费力度）的评价体系。这些指标无好坏之分，企业按需采用即可。

![根据实际情况在知微上配置满意度指标](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/DEF/DEF-10.png)

针对满意度指标统计，知微能够配置出不同的满意度评价指标，将该指标作为一项属性，由具体的需求卡片承载（见上图）。也具备指定打分人、需求完成后打分提醒等功能。

## 总结部分

我们总结出以下表格，来直观展现**哪些角色应该关注哪些指标**：

![DEF 框架中，不同角色关注的指标列表](https://kanban-dev.oss-cn-shanghai.aliyuncs.com/static/test/post/DEF/DEF-11.png)

图 / DEF 框架中，不同角色关注的指标列表

除了文中谈到的几个指标，还有很多相关概念和内容值得展开阐述，包括上表里的流动效率、分布K值。在 [Adapt 规模化敏捷框架](https://www.agilean.cn/insights/adapt/)的效能度量部分，将 DEF 的指标按照 Adapt 的部落制架构，细化为部落小队不同层级。本文为DEF「研发绩效体系」系列的首篇，在后续文章中，我们将继续以真实数据为例，详细解读其它指标和背后的逻辑，敬请期待。

Agilean 方法论

## 本文相关的 Agilean 方法框架

- [研发效能度量](https://www.agilean.cn/methodology/def-rd-performance-metrics/)：DEF 研发绩效指标框架（多快好赞）；以“多快好赞”四组相互制衡的指标衡量产能、响应能力、交付质量和业务满意度。
- [规模化敏捷](https://www.agilean.cn/methodology/adapt-scaled-agile-framework/)：ADAPT 规模化敏捷框架；产品部落敏捷研发章程，面向金融等复杂组织的百人级产品部落。

## 订阅洞见

新文章发布时，通过邮件第一时间收到。

推荐阅读

- [RISE:适合复杂业务场景的版本迭代节奏](https://www.agilean.cn/insights-new/42/)
- [精益研发效能提升框架 FLEET：提速增质的无限可能](https://www.agilean.cn/insights-new/44/)
- [DEER：研发效能提升路线图](https://www.agilean.cn/insights-new/45/)
- [ADAPT-中国金融企业规模化敏捷框架](https://www.agilean.cn/insights-new/46/)
- [聚焦研发效能度量5年时间，6点思考与沉淀](https://www.agilean.cn/insights-new/47/)
- [OKR的组织落地之旅：一步天堂，一步地狱](https://www.agilean.cn/insights-new/48/)
- [Agilean 2020年终巨献：数智化敏捷银行路线图](https://www.agilean.cn/insights-new/49/)
- [金融组织数字化研发管理的12种武器](https://www.agilean.cn/insights-new/50/)
- [数字时代组织效能的秘密](https://www.agilean.cn/insights-new/51/)
- [研发组织该如何设计绩效体系？](https://www.agilean.cn/insights-new/52/)
- [Google的软件工程概述](https://www.agilean.cn/insights-new/53/)
- [首发！第15份中文版全球敏捷状态报告来了](https://www.agilean.cn/insights-new/54/)
- [从0-1做产品快速启动，大型干货案例分享](https://www.agilean.cn/insights-new/55/)
- [你理解的精益可能是错的！——从源头重新解读精益](https://www.agilean.cn/insights-new/56/)
- [9个从零开始的B端产品自动化测试实践](https://www.agilean.cn/insights-new/57/)
- [金融组织做规模化敏捷怎么划小队，一文讲清](https://www.agilean.cn/insights-new/58/)
- [银行规模化敏捷速赢术第一式：部落制](https://www.agilean.cn/insights-new/59/)
- [从进化角度看规模化敏捷，上海银行4500+人实施案例——2023RSG大会演讲实录](https://www.agilean.cn/insights-new/60/)
- [软件国产化大潮下，这家金融企业是怎么替换Jira的](https://www.agilean.cn/insights-new/61/)
- [交付时效提升21%，宁波银行规模化敏捷试点这一年](https://www.agilean.cn/insights-new/62/)
- [上海银行｜用知微支撑全行2500人研发数字化管理转型](https://www.agilean.cn/insights-new/63/)
- [万字长文，细说长沙银行的数字化研发管理转型之路](https://www.agilean.cn/insights-new/64/)
- [日产万行业务代码背后，我们真正修的是一条 Harness 公路](https://www.agilean.cn/insights-new/65/)
- [AI强了，为什么组织还没变快？](https://www.agilean.cn/insights-new/66/)
- [当 AI 开始理解企业：金融复杂系统下的智能体实践](https://www.agilean.cn/insights-new/67/)
- [利用本体论和 EntClaw 构建软件开发生产线](https://www.agilean.cn/insights-new/68/)
- [别再拿“随缘发版”当版本火车了：跨越研发管理中“知道”与“做到”的生死线](https://www.agilean.cn/insights-new/69/)
- [从工作流到价值流：组织效能提升成不成，关键看这步 “转场”！](https://www.agilean.cn/insights-new/70/)
- [研发价值流：回退不是“后悔药”，警惕异常状态拖慢交付效率](https://www.agilean.cn/insights-new/71/)
- [AI时代的研发效能进化：从单点提效到组织重塑](https://www.agilean.cn/insights-new/72/)
- [对话吴穹：软件开发的终局，是我们将迎来自己的“黑灯工厂”](https://www.agilean.cn/insights-new/73/)
- [当CIO回答“我回去了解一下”的时候，科技就已经输了](https://www.agilean.cn/insights-new/74/)
- [研发的结构性拥堵，版本火车如何建立节奏与共识？](https://www.agilean.cn/insights-new/75/)
- [AI时代科技组织该怎么做？——先提质，再增效](https://www.agilean.cn/insights-new/76/)
- [最新预测：DeepSeek时代，科技组织即将发生的12大变化](https://www.agilean.cn/insights-new/77/)
- [破局研发管理困境：敏稳双态下的研发效能洞察](https://www.agilean.cn/insights-new/78/)
- [BizDevOps：从理念到实践，贯通企业全链路协同](https://www.agilean.cn/insights-new/79/)
- [解锁研发效能：平台工程的建设策略与实践](https://www.agilean.cn/insights-new/80/)
- [揭秘科技组织度量中心：构建透明、量化、高效的科技管理新体系](https://www.agilean.cn/insights-new/81/)
- [研发效能度量中心的底层逻辑](https://www.agilean.cn/insights-new/82/)
- [从测试本质看质量](https://www.agilean.cn/insights-new/83/)
- [管好研发团队四大要义](https://www.agilean.cn/insights-new/84/)
- [规模化敏捷下小队的协作机制](https://www.agilean.cn/insights-new/85/)
- [科技团队治理能力成长路线图](https://www.agilean.cn/insights-new/86/)
- [什么是引导？引导能为你带来什么？](https://www.agilean.cn/insights-new/87/)
- [提升代码质量：代码检查工具规模化使用实践](https://www.agilean.cn/insights-new/88/)
- [一窥科学管理：从误解到理解、再到构建](https://www.agilean.cn/insights-new/89/)
- [战略管理：质疑模型，理解模型，构建模型](https://www.agilean.cn/insights-new/90/)
- [6个原则+15项举措，重塑敏捷组织的绩效管理（下）](https://www.agilean.cn/insights-new/91/)
- [6个原则+15项措施，重塑敏捷组织的绩效管理（上）](https://www.agilean.cn/insights-new/92/)
- [合作模型与组织设计思考](https://www.agilean.cn/insights-new/93/)
- [渐进与激进的舞台，变革管理的艺术](https://www.agilean.cn/insights-new/94/)
- [管理变革思想，竟藏在运动康复之中？](https://www.agilean.cn/insights-new/95/)
- [看板方法：始于可视化，成于管理机制](https://www.agilean.cn/insights-new/96/)
- [数字化转型，组织架构先行](https://www.agilean.cn/insights-new/97/)
- [从推动到拉动：研发效能提升的第一性原理](https://www.agilean.cn/insights-new/98/)
- [3步，手把手教你用数据开好回顾会](https://www.agilean.cn/insights-new/99/)
- [一法则，一定理，数据驱动管理必备理念](https://www.agilean.cn/insights-new/100/)
- [魔幻的数字7±2 ——小队规模的底层逻辑](https://www.agilean.cn/insights-new/101/)
- [要管理，先可视](https://www.agilean.cn/insights-new/102/)
- [详述银行业数字化转型中的敏捷变革](https://www.agilean.cn/insights-new/103/)
- [数字化金融企业的产品体系长啥样？](https://www.agilean.cn/insights-new/104/)
- [研发效能度量的两大法宝、四大法门和七种武器](https://www.agilean.cn/insights-new/105/)
- [敏捷与规模兼得的高绩效组织打造](https://www.agilean.cn/insights-new/106/)
- [踩了那么多坑后，我们为什么还是要做目标管理？](https://www.agilean.cn/insights-new/107/)
- [从Cynefin框架重新理解不确定性管理](https://www.agilean.cn/insights-new/108/)
- [AI时代更需要敏捷组织](https://www.agilean.cn/insights-new/ai-era-agile-organization/)
- [WorkBuddy正当红，但Agent的未来不在聊天框](https://www.agilean.cn/insights-new/workbuddy-agent-future-not-chatbox/)

联系我们

发送邮件

联系方式

地址

深圳市南山区粤海街道南油社区建南路15号恒大天璟A座A2902

邮箱

contact@agilean.cn

---

来源：[DEF 面向研发团队的绩效指标框架](https://www.agilean.cn/insights-new/43/)（更新于 2023-12-13）