研发交付效率可以用一组可复算的指标来刻画，核心是交付吞吐、交付周期和流动效率三类：吞吐看单位时间完成了多少需求，周期看从开始到交付用了多久，流动效率看有效工作占在制时间的比例。计算前先固定统计对象、起止时点、时间窗和单位，再按公式取数；分母为零、样本过少或跨团队口径不一致时单独标注，避免把单一指标当成效率结论。
要点总览（TL;DR）
- 研发交付效率由三类可复算指标共同刻画：吞吐量、交付周期（中位数与85分位数）、流动效率，单看任何一类都不足以说明整体效率。
- 计算前先固定统计对象、起止时点、时间窗和单位：吞吐量=时间窗内完成需求数÷时间窗长度，流动效率=有效工作时间÷在制时间×100%。
- 周期类指标用中位数和85分位数替代均值，避免少数长尾需求把平均值拉偏；样本过少或分母为零时照常标注，不静默替换成零或均值。
- 结果要组合解读：吞吐上升同时周期下降说明交付在加快，85分位数拉长则提示长尾积压；需求拆分粒度、紧急插入和状态更新不及时都会造成失真。
- 跨团队比较需满足完成定义一致、需求类型构成相近、时间窗长度相同等前提，条件不满足时结果只作参考，不用于排名。
评估目标：交付效率要回答什么问题
交付效率度量服务于改进诊断，先明确要回答哪类问题，再决定取哪些指标。常见的问题可以归为三类：交付快慢，即一个需求从进入研发到完成需要多长时间；交付多少，即团队在固定时间窗内能完成多少需求或工作项；时间花在哪里，即工作项处于在制状态的时间里，有多少是真正在推进。三类问题对应不同的指标，单独回答其中一类都不足以说明整体效率。
评估对象需要区分团队级与需求级。团队级评估关注一段时间内团队整体的吞吐和周期分布，用于观察趋势和安排容量；需求级评估关注单个或单批需求的流转时间，用于定位具体交付环节的耗时。两类对象的统计单位和取数范围不同，混在一起计算会让结果失去解释力。
指标用途要在开始计算前写清楚。交付效率指标适合用于团队复盘、流程改进和容量规划，作为发现问题的线索；把它直接换算成个人绩效排名，容易诱导拆分工作项、压低任务粒度等行为，使数据失真。评估目标清单可以写成三行：本次要回答的问题、评估对象是团队还是需求、结果用于哪类决策。
指标与范围：三类核心指标及统计边界
三类核心指标各有明确的定义和统计边界，建议先用一张表把口径固定下来，后续取数和复算都以此为准。
| 指标类别 | 指标 | 定义 | 单位 | 统计边界 |
|---|---|---|---|---|
| 吞吐类 | 需求完成数 | 时间窗内状态达到完成定义的需求数量 | 个/周或个/月 | 按需求类型筛选，排除已取消项 |
| 吞吐类 | 工作项完成数 | 时间窗内完成的任务、缺陷等工作项数量 | 个/周或个/月 | 与需求完成数分开统计，不混算 |
| 周期类 | 需求交付周期 | 需求从开始研发到完成交付的时间 | 天 | 起止时点按状态流转时间戳取值 |
| 周期类 | 前置时间 | 需求从创建到完成交付的时间 | 天 | 包含等待时间，与交付周期区分 |
| 流动效率类 | 有效工作时间占比 | 有效工作时间占在制时间的比例 | % | 分子分母取同一批工作项 |
| 流动效率类 | 在制数量 | 统计时点处于进行中状态的工作项数量 | 个 | 按固定时点快照取值 |
统计范围要覆盖四个维度：团队范围，明确纳入哪些小组或成员；需求类型，区分产品需求、技术需求、缺陷修复，避免把不同性质的工作混在同一口径里；时间窗，统一用自然周、自然月或固定的两周窗口；是否包含缺陷与紧急插入，紧急需求会拉长周期分布，需要在口径中说明是纳入统计还是单独列出。
完成定义是范围里最容易被忽略的一项。需求状态停在“待验证”还是“已上线”，会直接改变完成数和周期值。建议在指标定义表里写明完成对应的状态名称，并保持整个统计周期内不变。
数据口径与证据：取数字段和可信度要求
可复算的前提是每个指标都能追溯到具体字段。取数至少需要以下几类数据：状态流转时间戳，记录需求或工作项每次状态变更的时间和变更前后状态；创建时间与完成时间，作为前置时间和交付周期的起止依据；需求类型字段，用于按类型筛选和分组；经办团队或项目字段，用于确定统计范围。
口径统一要处理三件事。完成定义统一为具体状态，例如“已完成”或“已上线”，并在口径文档中写明；时区统一，跨地域团队按同一时区换算时间戳；工作日与自然日统一，周期类指标默认按自然日计算，若业务按工作日统计，需在指标名称或口径说明中标注，两种口径不能混用。
数据处理规则需要提前约定：数据缺失时，缺少关键时间戳的工作项从对应指标中剔除并记录剔除数量，不用估算值填补；状态回退时，以最终完成前最后一次进入完成状态的时间为准，回退期间的时间计入周期；重复工作项按唯一标识去重，同一需求被拆分成多个子项时，明确以父需求还是子项作为统计单位。
证据留存让结果可以被复核。每次取数保留取数脚本或查询条件、报表快照和统计时间，口径变更时记录变更日期和影响范围。这样当结果出现波动时，可以区分是效率变化还是口径变化。在工具层面，ONES 效能管理会自动收录系统内日常流转的研发数据并形成分析指标，也能实时同步 ONES Project 中的业务数据，减少手动整理数据源的工作；状态流转时间戳和完成状态仍需要在项目配置中保持规范，取数口径才有稳定来源。
计算步骤：公式、分母与时间窗
计算按固定顺序进行：先确定时间窗和统计对象，再取数、套公式、处理异常，最后输出结果和标注。三个核心公式如下。
- 吞吐量 = 时间窗内完成需求数 ÷ 时间窗长度，单位取个/周或个/月，分母的时间单位必须与结果单位一致。例如两周完成 12 个需求，按周计算为 12 ÷ 2 = 6 个/周。
- 周期中位数：将该时间窗内完成需求的交付周期按从小到大排序，取中间位置的值；样本数为偶数时取中间两个值的平均。85 分位数表示 85% 的样本周期不超过该值，按排序后第 85% 位置取值，位置不是整数时在相邻两个值之间按比例插值。
- 流动效率 = 有效工作时间 ÷ 在制时间 × 100%。有效工作时间指工作项处于开发、测试等推进状态的时间之和，在制时间指工作项从进入进行中到完成的总时间，分子分母取同一批工作项和同一时间口径。
异常情形按规则处理并标注。时间窗内完成数为零时，吞吐量不输出数值，标注“本期无完成项”；周期样本少于约定下限（例如少于 10 个）时，中位数和 85 分位数照常计算但标注“样本不足，仅供参考”；在制时间为零时，流动效率不计算，避免除零。所有标注随结果一起呈现，不把异常值静默替换成零或均值。
算例：一个两周时间窗的完整计算
以下数值为演示情景，用于说明计算过程，不代表任何团队的真实水平或达标线。
某团队统计两周（10 个工作日）内完成的产品需求，共 12 个，交付周期（自然日）分别为：3、4、5、5、6、7、8、9、10、12、15、22。按周计算吞吐量：12 ÷ 2 = 6 个/周。周期排序后共 12 个样本，中位数为第 6、7 位的平均，即 (7 + 8) ÷ 2 = 7.5 天；85 分位数位置为 (12 − 1) × 0.85 + 1 = 10.35，在第 10 位（12 天）和第 11 位（15 天）之间插值，约为 12 + 0.35 × (15 − 12) = 13.05 天。
流动效率取同一批 12 个需求：有效工作时间合计 96 天，在制时间合计 160 天，流动效率 = 96 ÷ 160 × 100% = 60%。
| 指标 | 计算式 | 结果 | 说明 |
|---|---|---|---|
| 吞吐量 | 12 ÷ 2 | 6 个/周 | 两周时间窗，按周折算 |
| 周期中位数 | (7 + 8) ÷ 2 | 7.5 天 | 12 个样本取中间两位平均 |
| 周期 85 分位数 | 第 10.35 位插值 | 约 13.05 天 | 长尾需求拉高上分位 |
| 流动效率 | 96 ÷ 160 × 100% | 60% | 分子分母同一批需求 |
结果呈现时同时说明异常值：22 天的需求明显偏离分布，若该需求属于紧急插入或跨团队依赖，应在备注中标注，并在下一期观察它是否重复出现。中位数 7.5 天与 85 分位数约 13 天之间的差距，说明多数需求交付较快，少数需求耗时明显更长，改进方向可以优先看长尾需求的等待环节。
解读与限制：结果怎么用、哪里会失真
三个指标要组合解读。吞吐量上升而周期中位数同步下降，通常说明交付在加快；吞吐量上升但 85 分位数拉长，可能是完成了一批短需求、长尾仍在积压；流动效率偏低则提示在制时间里等待占比高。任何单一指标的变化都可能有多种原因，结论应写成待验证的假设，再回到具体需求和时间段核对。
常见失真情形有几类。需求拆分粒度变化会直接影响吞吐量和周期：把一个大需求拆成多个小项，完成数会上升、单项周期会缩短，但实际交付内容未必增加，跨期比较前要确认拆分规则一致。紧急插入需求会同时抬高吞吐量和周期上分位，纳入统计时应在口径中说明，或单独列出一组数据。状态更新不及时会让时间戳失真，周期被拉长或压缩，流动效率的分子分母也会偏移。
跨团队比较需要满足前提：完成定义一致、需求类型构成相近、时间窗长度相同、统计单位一致。条件不满足时，比较结果只能作为参考，不能直接排名。指标反映的是流程结果，改进动作与结果之间需要经过验证，例如调整在制数量上限后，观察后续几个时间窗的周期分布是否变化，再判断措施是否有效。
把度量落到日常管理时，可以在 ONES 效能管理中按交付效率等维度查看分析结果，利用预置的场景化仪表盘模板减少配置工作，让团队把精力放在口径核对和结果解读上。指标口径、取数规则和异常标注一旦固定，后续每个时间窗都能按同一方法复算，趋势才有可比性。
常见问题
团队刚开始度量，没有历史数据，第一个时间窗的结果能直接用吗？
第一个时间窗的结果可以作为基线，但不宜直接当作改进依据。建议先连续统计两到三个时间窗，确认取数流程稳定、口径没有中途变更，再观察趋势。首期数据更重要的作用是暴露口径问题，例如完成定义是否统一、状态更新是否及时、需求拆分粒度是否一致，这些问题修正后，后续数据才具备可比性。
需求交付周期和前置时间应该选哪个？
两者回答的问题不同。交付周期从需求开始研发算起，反映研发环节的交付快慢；前置时间从需求创建算起，包含进入研发前的等待，反映需求从提出到交付的整体耗时。如果改进重点是研发过程本身，用交付周期；如果关注需求从提出到落地的全流程，用前置时间。两个指标同时统计时，二者之差可以粗略反映需求在进入研发前的排队时间。
流动效率算出来偏低，应该先查什么？
先确认分子分母取的是同一批工作项和同一时间口径，排除口径错误。口径无误后，再看在制时间里等待占比高的环节出现在哪里，例如需求在等待评审、等待测试环境或等待跨团队依赖。流动效率本身只说明有效工作占比，定位具体阻塞环节属于流动效率与瓶颈分析的范畴，需要结合状态流转记录逐段核对。
紧急插入的需求要不要计入吞吐量和周期统计？
两种做法都可以，关键是口径固定并说明。纳入统计时，紧急需求会同时抬高吞吐量和周期上分位，需要在备注中标注；单独列出时，常规需求和紧急需求各出一组数据，避免两类性质不同的工作混在一起比较。无论选哪种，同一统计周期内保持一致，跨期比较前先确认处理方式没有变化。
用工具自动取数后，还需要人工核对吗？
需要。自动取数解决的是数据收集效率，口径是否准确仍取决于项目配置。ONES 效能管理会自动收录系统内日常流转的研发数据并形成分析指标，也能实时同步 ONES Project 中的业务数据，减少手动整理数据源的工作；前提是完成状态、需求类型、经办团队等字段在项目中配置规范。建议每期抽查若干工作项，核对时间戳与状态流转记录是否一致，并保留报表快照以便复核。
