软件研发效能指标，是衡量团队交付效率、工程能力和业务价值流动的重要依据。近年来，“软件研发效能”成为行业热词，频繁出现在各类技术会议、工程管理讨论和企业实践中。许多科技企业和追求更高交付效率的团队，都在围绕研发效能建设平台、体系和方法论。

与此同时，一个核心问题仍然没有被彻底解决：什么才是合适的软件研发效能指标？

过去，团队曾经用“代码行数”来衡量开发效率。但在现代敏捷开发、持续集成和持续交付的背景下，这类指标已经无法准确反映软件开发的真实价值。软件行业至今也没有形成一套统一且被广泛认可的研发效能度量标准。

要找到合适的软件研发效能指标，首先需要明确我们究竟要衡量什么。不同目标对应不同指标。结合实践经验，常见的软件研发效能指标大致可以分为以下几类。

一、常见的软件研发效能指标有哪些

1. 规划与进度类指标

这类指标主要用于评估项目进展、了解任务状态、判断工作何时能够完成、预测潜在风险，以及复盘过去出现的问题。

常见指标包括：

• 迭代燃尽图和发布燃尽图
• 速率图
• 标准差
• 吞吐量
• 累积流图
• 控制图
• 看板在制品数量

2. 快速反馈类指标

这类指标用于衡量团队在持续集成、持续测试和持续部署方面的能力，帮助团队更快发现问题、修复问题并完成交付。

常见指标包括：

• 构建和部署耗时
• 测试执行耗时
• 合并请求评审时间
• 单元测试通过率
• 集成测试通过率

3. 团队转型类指标

这类指标用于衡量不同工作方式对团队行为的影响。它们也可以帮助团队向管理层说明某些流程存在不合理之处，需要调整工作方式，或需要更多时间、预算和资源支持。

常见指标包括：

• 结对编程时间
• 手工测试耗时
• 合并请求评审时间
• 红色构建修复时间
• 开发环境或生产环境缺陷修复成本
• 测试覆盖率
• 工作量分布，包括新需求、计划外工作、返工和其他工作

4. 辅助决策类指标

这类指标通常用于支持实验、复盘和持续改进，帮助团队不断发现新的优化方向。

常见指标包括：

• 交付周期
• 已修复缺陷数量
• 逃逸缺陷数量
• 工作量分布，包括新需求、计划外工作、返工和其他工作
• 价值交付情况

5. 工程能力类指标

这类指标用于衡量团队工程实践的成熟度，并帮助团队识别工程能力中的薄弱环节。

常见指标包括：

• 变更前置时间
• 部署频率
• 变更失败率
• 平均恢复时间

需要注意的是，研发效能指标并不存在一套放之四海而皆准的模板。团队需要结合自身业务类型、团队规模、工程文化、项目阶段和交付目标，综合分析并选择最合适的指标，同时根据价值交付情况持续调整和迭代。

不同团队使用完全不同的软件研发效能指标，是非常正常的现象。研发效能度量高度依赖上下文，而不是某个固定公式。

面对众多指标和工具链，一线开发人员往往会提出两个问题：我们真的需要把这些指标全部落地吗？在当前阶段，最应该优先关注什么？这也是很多团队开始引入研发管理工具的原因。例如，PingCode 通过覆盖目标管理、客户反馈、需求清理、评审排期、项目开发、测试发布、知识沉淀与工具集成等研发全生命周期，帮助团队把研发管理过程数据化、自动化和智能化，从而为研发效能度量提供更完整的数据基础。

下面将介绍一种快速选择合适研发效能指标的方法，并讨论在需求早期尚不清晰，也就是“模糊前端”场景下，如何定义交付周期的起始时间。

二、如何按项目类型选择研发效能指标

软件系统通常会经历不同生命周期阶段。按照项目类型，可以大致分为三类：绿地项目、黄地项目和红地项目。先判断项目类型，是快速选择软件研发效能指标的一种有效方法。

1. 绿地项目：全新开发

绿地项目指的是在一个全新环境中开发系统，不需要考虑与其他系统，尤其是遗留系统的集成。

这类项目通常风险较高，因为它们可能涉及新的基础设施、新的客户群体、新的业务模式，甚至新的组织协作方式。

绿地项目的开发团队通常更接近最终用户，因此更有机会进行端到端的价值流度量。同时，由于没有历史包袱，团队在架构设计、技术栈选择和工程实践建设方面也拥有更大空间。

对于绿地项目，可以将“辅助决策”和“工程能力”作为主要指标。团队应重点关注端到端价值流，并在项目早期建立良好的工程实践。“规划与进度”和“快速反馈”可以作为辅助指标，用来补充和验证端到端价值流的度量结果。

主指标和辅助指标之间往往会相互影响、相互验证。例如，快速反馈类指标中的合并请求评审时间缩短，通常会带来辅助决策类指标中交付周期的缩短。

在绿地项目中，“模糊前端”可以定义为最终用户向团队提出某个需求的时刻；而用户需求被清晰记录下来的时刻，则可以作为提前期的起点。

2. 黄地项目：改造、升级与共存

黄地项目指的是新软件必须考虑既有系统，并与已经部署运行的软件共存。

对于这类项目，“规划与进度”和“工程能力”可以作为主要指标。工程能力的提升能够帮助团队加快交付速度。“辅助决策”则可以作为辅助指标，用于扩展对功能交付价值的衡量，并推动端到端价值流度量。

可持续扩展的度量方式，也有助于提升价值流效率。

在黄地项目中，“模糊前端”可以定义为业务方将需求移交给开发团队，并且用户故事卡已经被明确定义的时刻。

根据以往经验，接手这类项目通常需要大量协调和沟通。由于既有系统中可能存在明显的“孤岛效应”，团队需要花费额外精力打通上下游流程。同时，这类项目往往伴随着自上而下的变更请求，尤其是在生命周期较长、业务价值较高的产品中更为常见。

在这种情况下，“团队转型”和“快速反馈”也可以作为主要指标，帮助团队更好地应对变更请求。

3. 红地项目：维护与缺陷修复

红地项目指的是软件系统已经进入维护期，不再开发新功能，只修复最终用户发现的缺陷。维护期结束后，系统可能会被新系统完全替代。

对于红地项目，“规划与流程”可以作为主要指标，用于确保缺陷修复具备良好的吞吐量。如果产品团队希望提高部署频率，并更快响应最终用户的缺陷报告，则可以将“快速反馈”作为辅助指标。

在红地项目中，“模糊前端”可以定义为最终用户向客服人员明确报告缺陷的时刻。

4. 如何快速区分三类项目

区分绿地项目和黄地项目的关键在于：是否需要考虑与遗留系统的集成和共存。

区分黄地项目和红地项目的关键在于：系统是否已经只处于维护模式。

根据项目类型推荐的绩效指标

三类项目可以简要概括如下：

• 绿地项目：面向全新环境开发系统，不需要考虑与其他系统，尤其是遗留系统的集成。
• 黄地项目：新软件必须考虑并能够与已经部署运行的软件共存。
• 红地项目：系统已经进入维护期，不再开发新功能，只修复最终用户发现的缺陷。

指标选择与团队具体情况密切相关。团队应根据自身上下文选择推荐指标集，并对其中的具体指标进行裁剪和调整。

三、研发效能度量债务与治理

随着度量工作逐步推进，以及项目从绿地阶段过渡到黄地阶段，或从黄地阶段过渡到红地阶段，团队可能会逐渐意识到一个问题：如果在全新开发阶段没有建立必要的度量能力，那么进入后续阶段后，就可能背负“度量债务”。

度量能力建设得越晚，初始度量成本就越高。这与技术债务中的“债务”和“利息”概念非常相似。

举个例子，假设有一个系统需要分析并统计请求在各个阶段的耗时，以便进行流程优化和性能优化。如果团队在一开始不愿承担初始度量成本，例如没有创建 TraceID、标签或其他属性来跟踪请求在多个系统之间的流转，那么后续很可能无法准确测量流程中间阶段的耗时。

当团队之后试图补充这些必要信息时，往往会发现涉及的系统太多，其中一些系统甚至已经超出了团队当前的认知范围，改造成本也变得非常高。

度量债务也是如此。从长期看，在系统早期设置必要的度量属性，比在后期补建要容易得多，也更具成本效益。到了后期，某些度量能力甚至可能已经无法补建。

如何管理研发效能度量债务

度量债务与技术债务非常相似。我们可以借鉴技术债务治理中的常见思路，将度量债务也分为几类：鲁莽的、审慎的、有意的和无意的。

当你向团队建议“让我们衡量一下研发效能，看看还有哪些地方可以改进”时，可能会得到不同类型的回应：

• “我们没时间做度量，先把功能做完再说。”
• “我们不知道哪些指标值得度量。”
• “我们知道需要度量，但当前阶段先有意识地延后。”
• “随着系统演进，我们才发现当初遗漏了一些关键数据。”

与现实生活中的债务不同，某些类型的度量债务是不可避免的。因此，尽早建立正确的研发效能度量体系就显得尤为重要。

由于行业缺乏通用的度量标准，研发效能度量必须建立在对团队流程和项目类型的分析之上。不同团队的指标可能差异很大，但所有团队都应尽可能早地实施关键指标，以避免未来背负过重的度量债务。

四、选择软件研发效能指标的三个原则

前文讨论了什么样的指标更适合衡量软件研发效能，也介绍了如何快速识别这些指标。接下来，我们将基于实践观察，总结三项原则，帮助团队结合业务情况和团队背景选择更合适的研发效能指标。

原则一：不要让指标本身成为目标

经济学中有一条著名规律：当一个指标成为目标时，它就不再是一个好的指标。

一个经典例子是，某地曾试图通过悬赏捕杀老鼠来控制鼠患，结果却刺激人们为了获取赏金而饲养老鼠。虽然“被割掉尾巴的老鼠数量”通常与“被杀死的老鼠数量”呈正相关，本身可以作为一个观察指标；但一旦将其设定为优化目标，就产生了完全相反的结果。

根据我们的经验，同样的规律也适用于软件开发领域。

例如，当团队被要求在每次迭代中完成固定数量的故事点时，团队可能会倾向于将故事拆分成比平时更多的卡片，以便更容易达成目标。这种行为可能以多种方式出现。

团队可能会在墙上贴一张三点的“团队建设”卡片，因为他们希望在每次迭代中获得更多故事点。度量开始之后，估算标准也可能发生变化。例如，原本估算为一点的数据库创建任务，可能被重新估算为三点。又或者，当某张卡片因为第三方依赖而受阻时，团队可能会决定将其移回待办列表，以避免该任务被反复标记为延期，从而拉长周期时间。

从表面上看，目标也许达成了。但这种度量方式真的为业务创造价值了吗？它能够真正融入管理实践或技术实践，并带来改进吗？

为了让指标和数据收集尽可能贴近真实情况，我们应更多关注趋势和瓶颈，而不是单点目标。

在上述案例中，我们可以观察每次迭代完成卡片数量的整体趋势。通常，每次迭代完成的卡片数量会在合理范围内波动。观察整体趋势，有助于识别瓶颈及其原因，并采取针对性措施来加快价值流动。

团队无需与其他团队进行横向比较。设定过高或过于刚性的目标，反而可能带来意料之外的负面结果。

假设我们观察一个持续 24 次迭代的项目，并统计每次迭代完成的故事点数，可以得到以下分析：

首先，整体趋势逐步提升，说明团队随着时间推移变得更加熟练。

其次，第 7 次和第 8 次迭代之间出现下降，原因可能是用户故事卡过大，导致沟通复杂度增加、开发时间延长。相应的改进方式是：开发人员与业务分析师更紧密协作，从一开始就创建更小、更独立的用户故事卡。

再次，第 14 次和第 15 次迭代之间的产出下降，是由于第三方 API 出现问题，导致累计超过 10 个故事点的卡片被推迟到下一次迭代才能完成。相应的改进方式是：更密切地跟踪依赖系统状态，并及时调整开发任务，避免阻塞和过度等待。

原则二：无法分解的指标不是好指标

好的研发效能指标应该能够进一步分解。

例如，变更交付周期或功能交付时间都是重要指标，因为它们与价值流交付直接相关。然而，从需求提出到功能上线，时间跨度往往很大，涉及因素也很多。如果只看整体时间，很难准确捕捉两个时间点之间的具体耗时结构，也很难识别真正的阻塞点。

因此，仅仅知道“交付周期变长了”并不够。团队还需要知道它到底在哪个环节变长，以及为什么变长。

问题分解是管理分析中的经典方法。它将一个庞大而难以直接观察的问题，拆解成多个子问题，再逐一分析这些子问题，最终解决原本的大问题。这个思路同样适用于研发效能评估。

研发效能指标可以按照阶段进行衡量和分解，每个阶段还可以继续细分。通过分解功能交付时间，团队可以找到更多优化点。

例如，可以在最近一次迭代中寻找规模相近的功能，并分别拆解每个流程阶段的耗时和占比，观察这些指标在不同迭代中是增加还是减少。

假设与上一次迭代中规模相近的功能相比，本次迭代的功能设计时间增加了 2.18%。团队就可以继续追问：造成这种变化的原因是什么？是否可以改进？

进一步分析后可能发现，原因是前期分析不够充分，导致收到反馈后多次修改设计，最终造成延误。对应的改进方式是：为功能分析产出增加更清晰的检查清单，确保需求在提交给设计团队之前已经被充分分析。

这正体现了可分解指标如何被应用到管理实践和技术实践中。

原则三：只有持续扩展度量边界，才能提升价值流效率

研发效能度量通常会从更宏观的指标开始，例如功能交付时间，因为它能更直观地反映业务价值。然而，度量也可以从局部开始，再通过持续扩展度量边界，逐步提升价值流效率。

以交付周期为例，它可以衡量从代码提交到部署到生产环境所需的时间。海外某些工程效能研究认为，完整的交付周期是指从客户提出需求到需求得到满足所需的时间。但在需求设计阶段，起始时间往往并不明确，而且通常存在较大波动。相比之下，交付阶段，也就是工作被实现、测试并交付所需的时间，更容易衡量，波动也相对较小。

这说明，我们可以先将“交付阶段的周期”作为初始指标。较短的交付周期通常意味着团队具备较强的工程实践能力和较完善的持续集成、持续交付能力。但这并不必然意味着团队能够快速响应客户需求。

因此，团队应不断扩展度量边界，以真正提升价值流效率。

来看一个实际案例。某团队最初度量的是变更前置时间，通常大约为 10 分钟。然而，团队发现有些代码提交需要几天时间才能真正部署上线。

进一步分析后发现，这些代码提交后进入了合并请求评审阶段，需要客户团队参与审查。由于客户团队未能及时完成评审，流水线无法触发，最终造成数天延迟。相比之下，团队能够自行审查和合并的合并请求，已经可以快速完成评审和合并。

于是，团队将变更前置时间的度量边界向左扩展：起始时间从“合并到主干分支的时刻”前移到“合并请求中的第一次代码提交时刻”。通过这种方式，团队识别出了与客户团队协作进行合并请求评审时可以优化的环节，从而加快了合并请求处理速度。

之后，团队又进一步将变更前置时间的起始点前移到“用户故事卡移动到开发列的时刻”。当用户故事进入开发列后，变更前置时间就开始计时。这有助于团队识别开发过程中与业务分析师、质量保证人员沟通时可能存在的障碍，并找到进一步优化空间。

如果某个已开发功能受到功能开关保护，且代码部署后功能开关尚未开启，那么变更前置时间的结束点也可以向右扩展到“功能开关被开启的时刻”。这样，团队就可以分析业务决策时间是否过长，以及它是否影响了功能真正上线。

五、结语：合适的研发效能指标来自团队上下文

研发效能度量不是为了追求漂亮的数据，而是为了帮助团队发现问题、改进流程，并更稳定地交付业务价值。

希望以下三项原则能够帮助团队在使用软件研发效能指标评估团队表现时取得更好的结果：

1. 不要让指标本身成为目标。为了让指标和数据更贴近真实情况，团队应关注趋势和瓶颈，而不是单一目标。
2. 无法分解的指标不是好指标。只有能够拆解，团队才能定位问题并采取有效行动。
3. 只有持续扩展度量边界，才能提升价值流效率。团队应从容易度量的局部指标开始，并逐步扩展到端到端价值流。

最终，合适的软件研发效能指标不取决于行业里流行什么，而取决于团队当前最需要解决什么问题。只有与业务目标、项目类型和团队上下文相匹配的指标，才是真正有价值的指标。