交付频率衡量单位时间内完成并进入可交付状态的批次数量，用来观察交付节奏的快慢与稳定程度。计算前要先定义“一次交付”，再确定统计对象、时间窗和单位；否则同一组数据会因口径不同得出不同结果。本文给出一套可复算的口径、取数规则与公式，并说明结果解读的边界。
要点总览（TL;DR）
- 交付频率＝统计周期内有效交付次数÷统计周期数，单位常用次/周或次/月；另一种口径是平均交付间隔，单位为天。
- 计算前先固定四件事：一次交付的判定标准、统计对象、时间窗和单位，否则同一组数据会算出不同结果。
- 取数来自工作项状态流转记录和发布记录，同一需求多次流转只计一次，完成时间缺失的记录标记为无效并记录剔除数量。
- 单个周期无交付时标记为无交付周单独说明，不直接记0参与均值；整个统计期无有效交付时输出无数据。
- 频率高不等于价值高，团队间对比必须统一口径，小样本和短周期波动大，单指标不宜作为绩效结论。
交付频率要回答什么评估问题
交付频率回答的是一个节奏问题：在给定时间窗内，团队或产品线把工作推进到可交付状态的批次有多少，批次之间的间隔是否稳定。它描述的是交付活动的密度和规律性，不直接说明交付内容的价值大小，也不反映交付之后的运行质量。
实际使用中，这个指标通常服务于三类用途，每类用途对口径的要求不同：
- 观察趋势：看同一对象在连续多个周期内的交付节奏是加快、放缓还是波动加剧。这类用途要求口径在周期之间保持一致，中途不更换交付判定状态。
- 对比团队或产品线：看不同对象在同一时间窗内的交付密度差异。这类用途要求统计对象、时间窗、单位、去重规则全部统一，否则差异可能来自口径而非实际节奏。
- 验证改进：在某项流程调整前后比较交付频率，判断节奏是否发生变化。这类用途需要保留调整前后的原始记录，并排除需求规模、人员变动等同时发生的因素。
需要说明的是，本文讨论的是量化方法，包括定义、取数、公式和解读，不涉及发布执行流程本身，也不展开等待与阻塞的定位分析。评估结论的适用边界在于：交付频率只描述节奏，不能单独支撑对团队能力或绩效的判断；它适合作为一组交付效率指标中的一项，与需求规模、交付质量等数据一起看。
指标定义与统计范围怎么划
交付频率的定义可以写成一句话：统计周期内有效交付次数除以统计周期数。要让这个定义可复算，需要先把四个要素固定下来，形成一张指标定义卡。
| 要素 | 需要确定的内容 | 常见选择 |
|---|---|---|
| 一次交付的判定标准 | 以什么事件算作完成一次交付 | 工作项流转到约定的交付完成状态；一个发布批次上线；一个版本关闭 |
| 统计对象 | 对谁统计 | 单个团队、一条产品线、某一类需求 |
| 时间窗 | 按多长的周期切分 | 周、双周、月 |
| 单位 | 结果以什么形式表达 | 次/周、次/月、平均间隔天数 |
判定标准是其中最关键的一项。以状态判定为例，团队需要约定一个明确的状态作为“已交付”，例如工作项进入“已完成”或“已上线”；以批次判定则以发布记录为准，一次发布计一次交付；以版本判定则以版本关闭时间为准。三种判定方式得出的次数可能差别很大，同一份报告内只能选一种，并在指标说明中写清楚。
统计对象决定数据范围。按团队统计适合观察小组节奏，按产品线统计适合观察整体交付能力，按需求类型统计适合比较不同性质工作的交付密度。对象一旦确定，跨周期比较时不应更换。
时间窗的选择与交付节奏本身有关。交付批次较密集时用周，批次较少时用双周或月，避免大量周期出现零交付。单位随之确定：用次数表达时写作次/周或次/月，用间隔表达时写作平均间隔天数。两种单位回答的是同一个问题的两个侧面，前者看密度，后者看间隔规律。
数据口径与证据要求
交付频率的取数应来自两类记录：工作项状态流转记录和发布记录。前者提供每个工作项进入交付状态的时间，后者提供批次层面的交付时间。关键字段包括完成时间、交付状态、所属团队，必要时补充需求类型和需求规模，用于后续分组和解读。
| 字段 | 用途 | 口径要求 |
|---|---|---|
| 完成时间 | 确定交付发生在哪个时间窗 | 取进入交付状态的首次时间，统一时区 |
| 交付状态 | 判定是否构成一次有效交付 | 与指标定义卡中的状态一致 |
| 所属团队 | 确定统计对象归属 | 以统计时点的归属为准，跨团队协作需约定归属规则 |
| 工作项标识 | 去重 | 同一标识在一个统计口径下只计一次 |
去重规则要提前写明。同一需求可能经历多次状态流转，例如从开发完成退回测试再重新完成，这类情况只计一次交付，以首次进入交付状态的时间为准。如果统计对象是发布批次，则同一批次内的多个工作项合并计为一次交付，不再按工作项重复计数。
缺失值和异常值需要单独处理，不能默认按零计算。完成时间缺失的记录应标记为无效数据并从分子中剔除，同时记录剔除数量；交付状态与定义不一致的记录应先核对再决定是否纳入。对于明显偏离的异常值，例如同一工作项出现两个相隔很久的完成时间，应回到原始记录确认，而不是直接取平均。
在工具层面，如果团队使用 ONES 管理研发过程，ONES Performance 会自动收录系统内日常流转的研发数据并形成分析指标，减少手工整理数据源的工作；其分析能力支持多维度、精细化和自定义的口径设置，便于按团队、产品线或需求类型切分统计范围。交付判定所依赖的具体状态字段和发布记录字段，需要结合团队在系统中的实际配置确认后再固定到指标定义卡中。
计算步骤与公式
交付频率有两种常用算法，分别回答密度和间隔两个问题。计算前先完成三件事：固定指标定义卡、导出统计期内的有效交付记录、按时间窗切分数据。
算法一：交付频率。
交付频率＝统计周期内有效交付次数÷统计周期数
例如统计期为一个月、按周切分，则周期数为该月包含的周数，结果单位为次/周。分子只计去重后的有效交付，分母为时间窗数量，两者必须对应同一统计对象。
算法二：平均交付间隔。
平均交付间隔＝统计期内相邻交付时间差之和÷（交付次数－1）
该公式把统计期内所有交付按时间排序，累加相邻两次交付之间的天数，再除以间隔个数。结果单位为天，反映两次交付之间平均相隔多久。交付次数为1时无法计算间隔，应标记为样本不足；交付次数为0时同样不计算。
分母为零或某个周期内没有交付时，处理方式需要统一。单个周期无交付，不宜直接记为0次/周后参与求均值，因为这会拉低整体结果并掩盖“该周期确实没有交付”与“数据缺失”的区别。推荐做法是将该周期标记为无交付并单独列出，在汇总时说明是否纳入。整个统计期都没有有效交付时，结果应标记为无数据，不输出频率数值。
按周汇总再求均值，比直接用总次数除以总周数更能反映波动。具体做法是：先算出每个周的交付次数，再对这些周值求算术平均；同时保留每周原始值，用于观察最高周与最低周的差距。如果存在明显异常周，例如长假或集中发布，应在报告中注明是否剔除，剔除与不剔除的结果并列给出，避免只呈现一个数字。
一个可复算的计算示例
假设某团队统计期为4周，按工作项进入“已交付”状态判定交付，去重后各周的有效交付次数如下：第1周3次，第2周1次，第3周4次，第4周0次。以下为演示数据，用于说明算法。
按周频率计算：总交付次数为3＋1＋4＋0＝8次，统计周期数为4周，交付频率＝8÷4＝2次/周。若按周汇总再求均值，四周的周值分别为3、1、4、0，均值为（3＋1＋4＋0）÷4＝2次/周，与直接相除结果一致。第4周无交付，按前述规则标记为无交付周并保留在序列中，报告中注明该周情况。
按平均间隔计算：把8次交付按时间排序，累加相邻交付之间的天数。假设相邻间隔合计为23天，间隔个数为8－1＝7，平均交付间隔＝23÷7≈3.3天。
| 算法 | 公式 | 本例结果 | 表达的含义 |
|---|---|---|---|
| 交付频率 | 有效交付次数÷统计周期数 | 2次/周 | 平均每周完成2次交付 |
| 平均交付间隔 | 相邻交付时间差之和÷（交付次数－1） | 约3.3天 | 两次交付之间平均相隔约3.3天 |
两种结果看起来并不完全对应：按频率折算，平均间隔约为3.5天，而实际算出的间隔是3.3天。差异来自交付在周内分布不均，间隔算法按实际时间点计算，频率算法按整周计数，周与周之间的边界会抹平部分时间差。这也说明两种算法不能互相替代，报告中应说明采用哪一种，跨周期比较时保持同一种算法。
结果怎么解读，有哪些限制
交付频率的结果首先是一个节奏描述，解读时要把它放回具体情境。频率升高可能来自批次拆分变细，也可能来自需求规模变小，还可能是统计口径发生了变化。因此看到数值变化时，应先核对分子分母是否可比，再结合需求规模和批次大小判断。
团队之间对比是最容易出错的场景。不同团队的交付判定状态、统计对象、时间窗和去重规则只要有一项不同，数值就不可直接比较。要做横向对比，必须先统一指标定义卡，并在同一时间窗内取数；即便如此，需求性质差异较大的团队之间，频率差异也更多反映工作类型而非效率高低。
小样本和短周期会放大波动。统计期只有两三周、交付次数只有几次时，单次集中发布就能显著改变结果，此时的频率不宜作为趋势判断依据。建议积累足够多的周期后再看趋势，并同时呈现每周原始值，让读者看到波动幅度而不只是一个平均值。
最后需要明确指标边界：交付频率高不等于交付价值高，它不反映需求重要性、交付质量和上线后的稳定性；它也不能单独作为团队绩效结论。合理的用法是把它作为交付效率维度中的一项观察指标，与需求规模、交付质量、完成情况等数据一起分析，用于发现节奏变化并触发进一步的原因排查。ONES Performance 从交付效率、交付质量、资源效率、完成情况等维度组织效能数据，并提供场景化卡片与仪表盘模板，便于把交付频率放在一组指标中对照查看；具体指标卡片的定义与计算口径仍需结合团队配置在系统中确认。
常见问题
统计期内某个周没有交付，应该记0还是剔除？
两种做法都会影响结果，关键是保持一致并说明。直接记0会让该周参与均值计算，拉低整体频率，但保留了“确实没有交付”这一事实；剔除该周则只统计有交付的周期，结果偏高，适合观察有交付时的节奏。推荐做法是把该周标记为无交付周，在序列中保留原始值，汇总时说明是否纳入均值，并把两种口径的结果并列呈现。如果整个统计期都没有有效交付，应输出无数据，不给出频率数值。
按状态判定和按发布批次判定，结果差异很大，报告里怎么处理？
两种判定回答的问题不同：按状态判定统计的是工作项进入交付状态的次数，颗粒度细；按发布批次判定统计的是上线批次，颗粒度粗。同一份报告内只能选一种，并在指标说明中写清判定依据。如果团队既想看工作项层面的节奏，又想看批次层面的节奏，可以分别出两份结果，但不要混在同一个数值里，也不要在跨周期比较时中途更换判定方式。选择哪种，取决于评估目的是观察小组推进节奏还是观察对外发布节奏。
交付频率和平均交付间隔，跨周期比较时能换着用吗？
不建议换用。两个指标的计算基础不同：频率按整周计数，间隔按实际时间点计算，周与周之间的边界会抹平部分时间差，同一组数据算出的两个结果并不完全对应。跨周期比较时保持同一种算法，报告中注明采用的是哪一种。如果确实需要同时呈现，应把两个数值并列给出，并说明它们各自表达的含义，避免读者把两个口径的数字直接相减或互相换算。
用 ONES 里的数据算交付频率，需要提前确认哪些配置？
需要确认三件事：一是团队约定作为“已交付”的那个状态在系统中叫什么、由谁维护；二是发布记录是否在系统中留存，批次与工作项的关联关系是否完整；三是统计对象的归属字段，例如团队或产品线，在统计时点是否准确。ONES Performance 会自动收录系统内日常流转的研发数据并形成分析指标，支持多维度、自定义的口径设置，但具体指标卡片的定义与计算口径仍需结合团队在系统中的实际配置确认后再固定到指标定义卡中。
交付频率连续几个月上升，能说明团队效率提高了吗？
不能直接下这个结论。频率上升可能来自批次拆分变细、需求规模变小、统计口径调整，也可能是流程改进带来的真实变化。判断前先核对分子分母在周期之间是否可比，再结合需求规模、批次大小和交付质量一起看。如果同期需求被拆得更细，频率上升而单个交付的规模下降，整体产出未必增加。合理的做法是把交付频率作为一组指标中的一项，用于发现节奏变化，再通过原始记录排查变化原因。
