需求交付周期通常按“交付完成时间减去流程起点时间”逐条计算，再汇总为均值、中位数和分位数。算得准的关键在于先固定起点与终点、统一时间单位与统计窗口，并单独处理未完成和返工需求。本文给出一套可复算的口径、字段清单、计算步骤与算例，并说明结果解读时的边界。
要点总览（TL;DR）
- 需求交付周期按“终点时间−起点时间”逐条计算，起点与终点必须固定一种配套口径，并在跨期统计中保持一致。
- 汇总时同时给出均值、中位数、P75/P90 和样本量；均值与分位数以已完成且数据完整的需求数为分母，未完成需求单列在途。
- 取数以状态流转记录为主要证据，缺失时间戳的需求标记剔除并报告数量；口径变更需记录生效时间，避免跨期直接比较。
- 解读时均值受长尾影响，应与中位数、分位数同看；样本量小、口径变更、需求构成变化都会削弱可比性。
- 不设通用达标线，阈值来自自身基线与改进目标；周期缩短需结合返工与缺陷数据判断是否为真实改进。
评估目标：用交付周期回答什么问题
需求交付周期回答的是一个具体问题：一个需求从进入交付流程到完成交付，经历了多长时间，这个时间的波动有多大。它衡量的是需求在交付流程中的停留时长，判断对象是需求本身，而不是团队成员的忙碌程度，也不是某一次发布是否顺利。
这条指标适合三类用途，每类用途对数据的要求不同：
- 趋势观察：按周或按迭代连续统计，看周期水平是在上升、下降还是保持稳定。这类用途要求口径长期不变，样本量足够。
- 改进验证：在流程调整、协作方式变化或资源投入之后，对比调整前后的周期分布，判断变化是否真实存在。这类用途要求记录口径变更时间，并控制需求构成的影响。
- 对外汇报：向管理层或业务方说明交付节奏。这类用途要求同时给出样本量、统计窗口和口径说明，避免只报一个均值。
需要明确的是，交付周期不承担发布执行与阻塞定位的职责。它能告诉你“需求在流程里待了多久”，不能直接告诉你“卡在哪个环节、为什么卡住”。要定位等待和阻塞，需要另外采集各状态的停留时长、队列长度和阻塞原因，这属于另一类分析。把交付周期当成效率总分，容易导致为了缩短数字而拆分需求、跳过评审等行为，反而损害交付质量。
评估目标说明可以写成一句话：本指标用于观察指定需求集合在固定口径下的交付时长水平与波动，服务于趋势观察、改进验证和对外汇报，不用于发布执行评价和阻塞原因归因。
指标与范围：起点、终点与统计对象
交付周期的定义必须固定一种起点和一种配套终点，并在全篇和跨期统计中保持一致。起点和终点随意组合，会让不同批次的数据失去可比性。
起点与终点的候选组合
| 口径组合 | 起点 | 终点 | 衡量的内容 | 适用条件 |
|---|---|---|---|---|
| 开发周期 | 需求进入“待开发”状态 | 开发完成 | 开发环节的停留时长 | 关注研发执行段，测试与上线另算 |
| 交付周期（常用） | 需求进入“待开发”状态 | 上线交付 | 从进入流程到交付完成的全程时长 | 状态流转记录完整，上线时间可采集 |
| 承诺周期 | 需求被承诺交付（进入排期） | 上线交付 | 承诺之后的兑现时长 | 有明确的排期与承诺动作 |
| 测试通过口径 | 需求进入“待开发”状态 | 测试通过 | 到质量验证为止的时长 | 上线动作与测试通过分离记录 |
选择哪一种，取决于你要回答的问题。观察整体交付节奏，通常选“进入待开发到上线交付”；只关心研发执行段，选“进入待开发到开发完成”。无论选哪种，起点状态和终点状态都要在指标定义卡上写清楚，包括状态名称、由谁触发、是否允许回退。
统计对象的纳入与排除
统计对象需要明确四类条件：需求类型、优先级、所属团队和时间窗。常见做法是只纳入进入交付流程的需求，排除咨询类、运维类记录和重复录入的条目；优先级可以全量纳入，也可以按高优先级单独统计，但要说明；团队维度按需求归属团队划分，跨团队协作的需求归入主责团队；时间窗按需求完成时间落在窗口内来筛选，而不是按创建时间。
时间单位统一为小时或工作日，全篇一致。用工作日时需要写明工作日历，包括节假日和调休的处理方式，否则跨期数据无法对齐。按需求逐条计算，每条需求产生一个周期值，汇总值由这些明细值计算得出，不先汇总再相减。
数据口径与证据：从哪些字段取数
交付周期的计算依赖状态流转记录，取数的核心是每条需求在起点状态和终点状态上的时间戳。字段清单如下：
| 字段 | 用途 | 质量要求 |
|---|---|---|
| 需求标识 | 唯一识别每条需求，关联明细与汇总 | 全局唯一，不重复 |
| 需求类型 | 纳入排除与分组 | 取值受控，避免自由填写 |
| 优先级 | 分组统计 | 取值受控 |
| 所属团队 | 分组统计 | 与组织架构对应 |
| 状态流转记录 | 提取起点时间与终点时间 | 记录每次状态变更的时间与操作人 |
| 完成时间 | 确定统计窗口与终点 | 与终点状态变更时间一致 |
状态变更记录的完整性是数据质量的第一道关。需要检查：起点状态是否被记录、终点状态是否被记录、是否存在跳过中间状态直接完成的情况、是否存在状态回退后再次进入的情况。对于缺失时间戳的需求，处理方式要事先约定，常见做法是标记为“数据不完整”并从当期汇总中剔除，同时单独报告剔除数量；如果缺失比例较高，当期结果应标注为参考值，不作为改进验证的依据。
口径变更必须记录生效时间。例如从某月起把终点从“测试通过”改为“上线交付”，变更前后的数据不能直接比较，需要在趋势图上标注断点，或分别统计两段。以系统流转记录为主要证据，人工登记作为补充；人工补录的条目要标注来源，避免与系统记录混在一起计算。
在研发管理工具中沉淀状态流转，可以让取数动作固定下来。ONES 效能管理自动收录系统内日常流转的研发数据，并基于这些数据形成分析指标，需求的状态变更时间随流程推进被记录，减少手工整理数据源的工作；其效能度量实践体系覆盖交付效率、交付质量、资源效率、完成情况四个维度，交付周期属于交付效率维度下的观察对象。具体指标的预置情况以产品实际配置为准。
计算步骤：从明细到汇总
计算分两步：先算每条需求的周期，再汇总为分布指标。
第一步：单条周期
单条周期 = 终点时间 − 起点时间。结果为正数才有效。出现负值通常意味着时间戳记录错误或状态顺序异常，应标记异常并核查，不直接参与汇总。明显异常值，例如远超历史分布的极端值，需要先确认是否为真实的长周期需求；确认为真实数据的保留，确认为录入错误的剔除，剔除规则和剔除数量都要记录。
第二步：汇总指标
| 指标 | 公式 | 分母 | 说明 |
|---|---|---|---|
| 均值 | 所有有效周期之和 ÷ 有效需求数 | 已完成且数据完整的需求数 | 受长尾影响明显 |
| 中位数 | 有效周期排序后取中间值 | 同上 | 反映典型水平 |
| P75 | 有效周期排序后第 75 百分位 | 同上 | 观察偏长部分的起点 |
| P90 | 有效周期排序后第 90 百分位 | 同上 | 观察长尾程度 |
| 样本量 | 有效需求条数 | — | 与上述指标同时报告 |
均值与分位数的分母都是已完成且数据完整的需求数。未完成需求不进入分母，单独列出数量和已停留时长，用于观察在途积压。返工需求的处理需要事先约定：可以按原始起点计算全程周期，也可以从返工后重新进入起点计算，两种方式结果不同，选定一种并在定义卡上注明。
按周或按迭代聚合时，保留每条需求的明细，包括标识、起点时间、终点时间、周期值和是否纳入，便于回溯和复算。聚合表只放汇总结果，明细表承担核对职责。
算例：一个迭代的周期计算
以下为一组演示数据，用于说明公式、分母与缺失值处理，数值为示例，不代表任何实际团队水平。假设口径为“进入待开发到上线交付”，单位为工作日。
| 需求 | 起点 | 终点 | 周期（工作日） | 处理 |
|---|---|---|---|---|
| A | 第1天 | 第6天 | 5 | 纳入 |
| B | 第1天 | 第4天 | 3 | 纳入 |
| C | 第2天 | 第12天 | 10 | 纳入 |
| D | 第2天 | 第5天 | 3 | 纳入 |
| E | 第3天 | 第23天 | 20 | 纳入，长尾 |
| F | 第3天 | 未完成 | — | 单列在途 |
| G | 缺失 | 第9天 | — | 数据不完整，剔除 |
有效样本为 A 到 E 共 5 条，周期值排序为 3、3、5、10、20。均值 = (5+3+10+3+20) ÷ 5 = 41 ÷ 5 = 8.2 个工作日；中位数为第 3 个值，即 5 个工作日；P90 在 5 个样本下取排序后接近第 90 百分位的值，示例中为 20 个工作日。未完成需求 F 单列，已停留时长按统计截止日计算；需求 G 因起点缺失被剔除，当期报告需注明剔除 1 条。
如果同一迭代中需求 C 因评审未通过返工，重新进入待开发，按“原始起点计算全程”的口径，其周期仍为 10 个工作日；按“返工后重新计时”的口径，则从重新进入待开发的时间起算。两种口径下的均值分别为 8.2 和更低的值，差异需要在报告中说明，不能混用。
当分母为零，例如某个迭代没有已完成需求，均值和中位数不计算，报告写“本期无已完成需求”，并给出在途需求数量。样本过少时，例如有效样本少于 5 条，建议只报中位数和明细，不报分位数，避免单个极端值主导结论。
解读与限制：周期数字能说明什么
交付周期的数字首先是一个分布，而不是一个点。均值受长尾影响明显，上例中均值 8.2 个工作日高于中位数 5 个工作日，说明少数长周期需求拉高了整体水平。解读时应把均值、中位数和 P75/P90 放在一起看：中位数反映典型需求的交付时长，P90 反映偏长部分的程度，两者差距扩大通常意味着流程中存在不稳定因素。
可比性受三类因素削弱。样本量小，单条需求的变动就能改变均值；口径变更，例如终点从测试通过改为上线交付，会让前后数据不可直接比较；需求构成变化，例如某期集中处理了几个大型需求，周期自然上升，这不代表效率下降。跨期比较前，先确认这三项是否发生变化，必要时分段统计或按需求类型分组。
周期缩短不直接等于质量提升。如果缩短来自减少评审、压缩测试或拆分需求，返工和缺陷可能同步上升。判断改进是否真实，需要结合返工率、缺陷数量和上线后的稳定性数据一起看。周期指标适合作为流动状况的观察入口，不适合单独作为团队绩效结论。
不设通用达标线。不同产品、不同需求类型、不同团队的历史基线差异很大，阈值应来自自身连续多个周期的基线数据和明确的改进目标，并在口径稳定的前提下设定。ONES 效能管理支持对系统内产生的研发数据进行多维度、精细化、自定义的分析，并提供场景化卡片与仪表盘模板，便于按团队和需求类型查看周期分布；预置模板的具体内容以产品实际配置为准。把周期数据与返工、缺陷等质量数据放在同一套度量体系中观察，再结合「量化—实施—分析—改进」的循环推进，能让周期数字落到具体的改进动作上，而不是停留在汇报层面。
常见问题
需求在统计期内未完成，应该计入交付周期的分母吗？
不计入。均值与分位数的分母是已完成且数据完整的需求数，未完成需求单独列出数量和截至统计日的已停留时长，用于观察在途积压。如果把未完成需求按截止日强行截断计入，周期会被系统性低估，且不同统计窗口的结果无法比较。
当在途需求数量明显上升时，即使已完成需求的周期没有变化，也说明交付节奏可能正在承压，这部分信息应在报告中与周期指标并列呈现。
需求中途返工、重新进入开发，周期从哪一次开始算？
两种口径都可用，关键是事先约定并全篇统一。按“原始起点计算全程”，返工前后的时间都计入，反映需求从首次进入流程到最终交付的总时长；按“返工后重新计时”，只计算最后一次进入起点之后的时长，反映返工后的兑现速度。
两种口径算出的结果不同，同一份报告里混用会让趋势失真。建议在指标定义卡上写明选择，并在出现返工需求时注明条数，便于读者判断数字的构成。
起点或终点的时间戳缺失，这条需求怎么处理？
常见做法是标记为“数据不完整”并从当期汇总中剔除，同时单独报告剔除数量。如果缺失比例较高，当期结果应标注为参考值，不作为改进验证的依据。
更根本的处理是回到流程侧：检查起点状态是否被规范触发、终点状态是否被跳过、是否存在状态回退后未重新记录的情况。状态流转记录完整，是这条指标能够连续统计的前提。
周期数字下降了，可以直接说明交付效率提升了吗？
需要先排除三类干扰：样本量是否过小、口径是否发生过变更、需求构成是否变化。三项都稳定时，周期下降才具备可比性。
在此基础上，还要结合返工率、缺陷数量和上线后的稳定性一起看。如果周期缩短伴随返工和缺陷上升，更可能是评审或测试被压缩的结果，而非流程改善。周期适合作为流动状况的观察入口，单独作为团队绩效结论并不充分。
团队刚开始统计，历史数据不足，阈值怎么定？
先积累连续多个周期的基线数据，在口径稳定的前提下观察均值、中位数和 P90 的实际水平与波动，再结合明确的改进目标设定阈值。样本过少时，建议只报中位数和明细，不报分位数，避免单个极端值主导结论。
不同产品、不同需求类型的历史基线差异较大，直接套用外部数字容易得出误导性判断。阈值设定后也应随口径和需求结构的变化定期复核。
