交付周期指一个需求或工作项从进入交付流程到完成交付所经历的时间，常用“完成时间−开始时间”计算，按小时或工作日计，并以中位数和分位数呈现分布。算得准的关键是三件事：先固定起点和终点，再明确统计范围与排除规则，最后处理分母为零和不可比问题。本文给出一套可复算的口径、公式与示例，并说明结果能说明什么、不能说明什么。
要点总览（TL;DR）
- 交付周期 = 完成时间 − 开始时间，单位统一为小时或工作日；起点、终点、统计对象和排除规则需在统计前写入口径文档并固定。
- 起点常用“进入就绪队列”，终点常用“上线发布”；起点越靠前，周期中包含的排期等待越多，解释时要区分。
- 汇总以中位数和 P85/P90 为主、均值为辅；分母是统计周期内已完成的工作项数量，分母为零时标注“本期无完成项”，不计算均值。
- 缺失开始时间、时间倒挂、超长挂起项要标记剔除并保留数量，剔除前后结果对照说明差异来源。
- 周期下降可能来自批量变小、等待减少、范围缩减或口径变化，需结合在制品数量与分段周期判断，不宜单独作为团队或个人绩效结论。
评估目标：交付周期要回答什么问题
交付周期度量的价值在于把“这个需求要多久能交付”从经验判断变成可复算的数字。典型用途有三类：预测未来类似需求的交付时间，识别流程中等待最长的环节，评估某次流程调整前后的变化。三类用途对口径的要求不同，统计前需要先明确这次度量服务于哪一个问题。
用途差异会直接改变口径选择。用于预测交付时间时，起点通常选“进入就绪队列”，终点选“上线发布”，统计对象覆盖全部需求类型，关注分位数而非均值；用于识别流程等待时，需要把周期拆成开发、测试、发布等分段，观察各段占比；用于评估改进效果时，起点终点必须与改进前完全一致，否则数字变化无法归因。用于考核个人绩效是另一种用途，它要求工作项归属清晰、排除跨团队协作项，且容易诱导拆分工作项或提前改状态，本文不建议把交付周期单独作为个人考核依据。
| 用途 | 起点建议 | 终点建议 | 汇总方式 | 注意事项 |
|---|---|---|---|---|
| 预测交付时间 | 进入就绪队列 | 上线发布 | 中位数、P85/P90 | 按需求类型分层统计 |
| 识别流程等待 | 进入就绪队列 | 上线发布 | 分段周期加总 | 需配合状态停留时长 |
| 评估改进前后 | 与改进前一致 | 与改进前一致 | 中位数对比 | 统计范围与时间窗保持一致 |
| 个人绩效参考 | 首次进入开发 | 开发完成 | 仅作参考 | 排除跨团队项，防止拆分规避 |
本文聚焦量化口径与计算，发布执行流程与发布管理规范归研发交付管理主题，等待与阻塞的具体定位方法归流动效率与瓶颈分析主题，这两部分只在需要解释周期构成时简要提及。
指标与范围：起点、终点和统计对象怎么定
口径定义的目标是让不同团队、不同时间窗算出的数字可以放在一起比较。做法是把起点、终点、统计对象、排除规则、时间单位五项写进一份口径文档，统计前固定，统计中不改动。
起点有四个常见候选。进入需求池表示需求被提出，周期最长，包含大量尚未排期的等待，适合衡量需求响应速度；进入就绪队列表示需求已具备开发条件，排除了需求评审和优先级等待，适合衡量交付流程本身的效率；首次进入开发表示开发人员开始动手，周期最短，适合观察开发到上线的链路；首次提测则把开发阶段排除在外。起点越靠前，周期中包含的非交付等待越多，解释时需要区分。
终点同样有四个候选。开发完成适合评估开发环节；测试通过适合评估开发加测试的链路；上线发布是最常用的终点，代表价值真正交付；客户验收适合项目制交付，但验收时间受客户节奏影响，与团队流程效率的关联较弱。起点与终点应成对固定，例如“进入就绪队列→上线发布”是一组常用组合，中途更换任一节点都会让前后数据失去可比性。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 统计项目 | 明确产品或团队范围 | 某产品线 Web 端 |
| 起点 | 选一个状态节点并写明判定条件 | 工作项首次进入“就绪”状态 |
| 终点 | 选一个状态节点并写明判定条件 | 工作项首次进入“已上线”状态 |
| 统计对象 | 需求类型、优先级、团队、时间窗 | 全部需求类型，不含缺陷与紧急插单 |
| 排除规则 | 列出剔除项及剔除数量 | 取消项、合并项、跨团队流转项 |
| 时间单位 | 统一为小时或工作日 | 工作日，按团队日历扣除节假日 |
统计对象需要逐项确认。需求类型决定是否把缺陷修复、技术任务、紧急插单混入同一组数据，类型差异大的工作项混算会掩盖真实分布；优先级影响排期等待，高优先级需求周期天然更短；团队范围决定数据能否横向比较；时间窗决定样本量。排除规则要提前写清：取消项没有真实交付，应剔除；拆分合并项会导致同一份工作被计算两次或起止时间错位，需按最终工作项归并；跨团队流转项在单一团队口径下终点难以界定，可单独统计或标注；长期挂起项会显著拉高均值，需按阈值标记并单独说明。
数据口径与证据：从哪些记录取数才可信
交付周期计算依赖状态变更的时间记录，取数应优先使用系统自动记录的时间戳，人工填写的计划日期、完成日期容易补录或集中修改，不适合作为计算依据。可信的取数来源包括工作项状态变更记录、流转历史和发布记录，三者结合可以还原一个工作项从起点到终点的完整路径。
必要字段至少包括：工作项唯一标识、工作项类型、所属团队、每次状态变更前后的状态值、状态变更时间。若需要分段分析，还需记录各中间状态的进入与离开时间。字段齐全后，单条工作项的周期可以由终点状态时间减去起点状态时间得到，无需人工干预。
数据质量校验应在计算前完成，常见问题及处理方式如下：
- 状态跳变：工作项从“开发中”直接跳到“已上线”，缺少中间状态。若起点和终点时间都存在，仍可计算总周期，但无法分段，需在数据说明中标注。
- 时间倒挂：后一状态的变更时间早于前一状态，通常由补录或系统时区问题导致，应标记并剔除，保留剔除数量。
- 重复流转：工作项在“测试中”和“开发中”之间反复切换，取首次进入起点状态和首次进入终点状态的时间，避免把返工循环重复计入。
- 缺失终态：统计周期结束时仍未上线的工作项不进入本期分母，属于在制品，应单独统计数量。
样本量决定汇总方式。一个统计周期内完成的工作项少于约 20 条时，均值和中位数的波动都很大，此时只报分布区间和单条明细，不报均值；样本量充足时再给出中位数与分位数。时间窗建议与团队迭代节奏对齐，按周或按双周统计，避免窗口过短导致分母频繁为零。
当工作项的状态流转记录已经在同一系统内产生，取数可以省去手工整理。ONES 效能管理自动收录系统内日常流转的研发数据，基于这些数据形成分析指标，并对研发过程数据进行多维度、精细化、自定义的分析；其效能度量实践体系覆盖交付效率、交付质量、资源效率、完成情况四个维度。这意味着状态变更时间戳可以直接作为交付周期的计算输入，口径定义中的起点、终点和统计对象则需要在分析配置中明确设定。具体可用的指标卡片与字段粒度以产品实际配置为准。
计算步骤：公式、分母与缺失值处理
单条工作项的交付周期公式为：交付周期 = 完成时间 − 开始时间。开始时间取工作项首次进入约定起点状态的时间，完成时间取首次进入约定终点状态的时间，两者都使用系统时间戳。单位统一为小时或工作日，同一组数据内不得混用；按工作日计算时需按团队日历扣除周末与节假日，并在口径文档中写明日历来源。
汇总指标包括均值、中位数和分位数。均值等于全部有效工作项周期之和除以有效条数，容易受超长挂起项拉高；中位数是排序后位于中间的值，反映典型交付体验；P85 或 P90 表示有 85% 或 90% 的工作项周期不超过该值，适合用于对外承诺交付时间的参考。三者应同时给出，单独报均值容易误导。
| 指标 | 公式 | 单位 | 适用场景 |
|---|---|---|---|
| 单条周期 | 完成时间 − 开始时间 | 小时或工作日 | 逐条核算与明细核对 |
| 均值 | 周期总和 ÷ 有效条数 | 小时或工作日 | 样本充足且无极端值时参考 |
| 中位数 | 排序后第 (n+1)/2 位的值，偶数条取中间两值平均 | 小时或工作日 | 反映典型交付周期 |
| P90 | 排序后第 90% 分位对应的值 | 小时或工作日 | 承诺交付时间的参考上限 |
分母定义为统计周期内“已完成”的工作项数量，即在本期进入终点状态且通过数据校验的条数。分母为零时，说明本期没有完成项，此时不计算均值和中位数，结果标注为“本期无完成项”，并给出在制品数量，避免把空值当作零周期。
缺失值与异常值按以下顺序处理：缺少开始时间的工作项无法确定起点，剔除并计数；缺少完成时间的工作项属于未完成，不进入本期分母；超长挂起项先按阈值标记，阈值可参考历史 P95 或业务约定的最长可接受周期，标记后分别计算剔除前后的结果，并在报告中保留剔除数量与剔除规则。所有剔除都应可复核，剔除比例过高时需回头检查口径定义是否合理。
算一个例子：从原始记录到分位数结果
以下为演示数据，用于说明计算过程，不代表任何真实团队表现。某团队一个双周统计周期内共有 10 条已完成工作项，口径为“进入就绪队列→上线发布”，单位为工作日。
| 工作项 | 开始时间 | 完成时间 | 周期（工作日） | 备注 |
|---|---|---|---|---|
| A | 3月2日 | 3月5日 | 3 | |
| B | 3月2日 | 3月6日 | 4 | |
| C | 3月3日 | 3月6日 | 3 | |
| D | 3月3日 | 3月9日 | 4 | |
| E | 3月4日 | 3月10日 | 4 | |
| F | 3月4日 | 3月11日 | 5 | |
| G | 3月5日 | 3月12日 | 5 | |
| H | 3月5日 | 3月13日 | 6 | |
| I | 3月6日 | 3月13日 | 5 | |
| J | 3月2日 | 4月10日 | 27 | 中途挂起，超长项 |
先计算单条周期，得到 10 个数值：3、4、3、4、4、5、5、6、5、27。排序后为 3、3、4、4、4、5、5、5、6、27。中位数为第 5 位与第 6 位的平均，即 (4+5)÷2 = 4.5 个工作日。P90 取排序后第 9 位的值，为 6 个工作日。均值为 (3+3+4+4+4+5+5+5+6+27)÷10 = 6.6 个工作日。
工作项 J 的 27 个工作日明显偏离其余数据，按超长挂起项标记并剔除后，剩余 9 条：3、3、4、4、4、5、5、5、6。中位数为第 5 位的 4 个工作日，P90 为第 9 位的 6 个工作日，均值为 39÷9 ≈ 4.3 个工作日。剔除前后对照如下：
| 指标 | 剔除前（10 条） | 剔除后（9 条） | 差异说明 |
|---|---|---|---|
| 中位数 | 4.5 个工作日 | 4 个工作日 | 受极端值影响较小 |
| P90 | 6 个工作日 | 6 个工作日 | 分位数对极端值不敏感 |
| 均值 | 6.6 个工作日 | 4.3 个工作日 | 均值被超长项显著拉高 |
这组结果说明：该团队本期典型交付周期约 4 个工作日，90% 的工作项在 6 个工作日内完成，同时存在个别长期挂起的工作项需要单独排查。它不能说明周期长短的原因，也不能直接与其他团队比较，因为其他团队的需求类型、起点终点和统计窗口可能不同。剔除前后的均值差异提示，报告交付周期时应以中位数和分位数为主，均值作为辅助并注明是否包含超长项。
解读与限制：数字变化说明什么、不能说明什么
交付周期下降有多种可能原因：批量变小使单个工作项更快走完流程，等待环节减少，统计范围缩小把长周期项排除在外，或者起点终点口径发生变化。仅凭周期数字无法区分这些原因，需要结合在制品数量、分段周期、需求类型分布一起判断。例如周期下降同时在制品数量上升，可能只是工作项被拆得更小，整体交付量并未改善。
不可比情形主要来自三方面：团队规模变化导致并行能力和排队时间改变；需求类型构成变化，技术任务占比上升会拉低周期；统计窗口变化，短窗口更容易受个别极端值影响。做前后对比或跨团队对比前，应核对口径文档中的起点、终点、统计对象、排除规则和时间单位是否完全一致，任何一项变动都需要在报告中说明。
达标线应来自团队自身的历史基线和业务约束，例如以过去若干周期的 P90 作为承诺参考，或按业务方要求的最长可接受周期设定目标。不同团队、不同需求类型的合理周期差异很大，不存在通用的达标数值。把交付周期单独作为团队或个人绩效结论也不合适，它只反映时间维度，不反映交付质量和价值大小。
解读时可按下述清单逐项核对：
- 本期与上期的起点、终点是否一致，是否有状态定义调整。
- 统计对象是否变化，需求类型、优先级、团队范围是否相同。
- 剔除项数量与比例是否异常升高，剔除规则是否被改动。
- 分母是否为零或过小，样本不足时是否只报了分布。
- 是否同时查看了在制品数量、分段周期和交付质量指标。
- 结论表述是否限定了范围和条件，是否避免了因果断言。
交付周期适合与流动效率、瓶颈分析类指标配合使用：前者回答“多久交付”，后者回答“时间花在哪里”。ONES 研发效能管理解决方案将交付效率、交付质量、进度情况、资源效率等效能数据集中展示，形成量化、实施、分析、改进的循环，并提供预置的场景化仪表盘模板，可按管理人员、项目经理等角色视角直接使用，仪表盘支持共享与权限控制。把本文的口径定义落到这类分析配置中时，需要先确认起点、终点和统计对象与分析配置一致，再解读图表中的周期变化。
常见问题
交付周期用自然日还是工作日计算，两者结果差多少？
两种单位都可以，关键是同一组数据内保持一致，并在口径文档中写明。工作日口径按团队日历扣除周末与节假日，更贴近实际可工作的时间，适合评估流程效率；自然日口径包含周末，适合对外承诺交付时间。同一批工作项用两种单位算出的数值不同，跨周期或跨团队对比时必须使用同一单位，中途切换会让前后数据失去可比性。
需求在开发中途被拆分或合并，交付周期怎么算才不重复？
拆分和合并会让同一份工作出现多个起止时间，直接逐条计算容易重复计数或起止错位。处理方式是按最终交付的工作项归并：拆分后的子项各自计算周期，但统计总量时以父项或最终上线项为准；合并项取最早进入起点状态的时间作为开始时间，取最终完成时间作为终点。归并规则要写进口径文档，并在报告中说明本期有多少条工作项涉及拆分合并，便于复核。
统计周期内完成的工作项很少，还能报平均交付周期吗？
样本过少时均值和中位数波动都很大，单个超长项就能明显改变结果。一个统计周期内完成项少于约 20 条时，建议只报分布区间和逐条明细，不报均值；需要汇总时优先给中位数并注明样本量。也可以把时间窗拉长到多个迭代合并统计，或按需求类型分层后再看，避免用几条数据得出“周期变长”或“周期变短”的结论。
交付周期下降，能直接说明团队效率提升了吗？
不能直接下这个结论。周期下降可能来自批量变小、等待环节减少、统计范围缩小把长周期项排除，或者起点终点口径调整。判断时需要同时看在制品数量、分段周期和需求类型分布：例如周期下降但在制品数量上升，可能只是工作项被拆得更小，整体交付量并未改善。结论表述应限定统计范围和时间窗，说明口径是否变化，避免把时间维度的变化归因为流程改进。
把交付周期接入系统自动统计时，需要先确认哪些配置？
先确认三件事与口径文档一致：起点和终点对应的状态节点、统计对象范围（需求类型、团队、时间窗）、排除规则。系统内的状态流转时间戳可以直接作为计算输入，但状态定义调整、跨团队流转项的归属需要在配置中明确。ONES 效能管理自动收录系统内日常流转的研发数据并形成分析指标，支持多维度自定义分析，也提供场景化仪表盘模板；具体可用的指标卡片与字段粒度以产品实际配置为准，接入前建议先用一小批工作项核对系统结果与手工计算结果是否一致。
