需求交付周期按单个需求从计时起点到交付完成的时间差计算，常用公式是“交付周期 = 交付完成时间 − 计时起点时间”，需要时再扣除暂停时长。要让结果可复算、可比较，计算前必须先固定三件事：计时起点、完成时点、暂停规则。本文给出统计范围、字段口径、计算步骤和一个10条需求的完整示例，并说明结果如何解读。
要点总览（TL;DR）
- 需求交付周期按单条需求计算：交付周期 = 完成时间 − 起点时间 − 暂停时长；聚合时以中位数和P85/P90分位数为主，均值仅作参考。
- 计算前必须固定三件事：计时起点（如需求受理、进入待开发、首次排期）、完成时点（如上线、验收通过、交付客户）、暂停规则（外部等待是否扣除），同一批需求使用同一口径。
- 统计范围要写明纳入的需求类型、时间窗归集方式（按完成时间或按进入时间）和时间单位；自然日与工作日不能混用，跨团队对比建议用自然日。
- 示例中10条需求的中位数为8天、P90为15天、均值为10.4天，均值被30天的长尾需求拉高，说明单看均值会高估典型耗时。
- 周期缩短不等于效率提升，需结合吞吐量和在制品观察；口径变更后前后数据不可直接比较，应分段展示并标注变更日期。
先定评估目标：交付周期要回答什么问题
交付周期衡量的是单个需求从进入研发流程到完成交付所经历的时间跨度。它回答的是“一条需求通常要等多久才能交付”“哪些需求拖得特别久”，属于对流动状况的描述，适合用于识别长尾需求、观察趋势变化、设定改进基线。
在开始取数之前，先把用途写清楚，能避免后面反复改口径。常见的用途有三类：
- 评估流动状况：了解一批需求从进入到完成的整体时间分布，判断交付是否顺畅。
- 识别长尾需求：通过P85、P90等高分位数找出耗时明显偏长的需求，作为后续分析的样本。
- 设定改进基线：以当前口径下的中位数和分位数为起点，观察改进措施实施后的变化。
需要明确的是，交付周期是过程指标，不能单独作为团队绩效结论，也不能直接推出“周期缩短等于效率提升”的因果判断。周期变短可能来自批量变小、需求拆分变细，也可能来自统计范围变化。把它与吞吐量、在制品数量放在一起看，结论才站得住。
指标与范围：算哪些需求、用什么单位
统计范围决定了分母，也决定了结果能否与历史数据比较。建议在计算前用一张定义表把纳入与排除规则固定下来，之后每次统计沿用同一张表。
| 维度 | 需要确定的规则 | 常见选择 |
|---|---|---|
| 需求类型 | 纳入哪些工作项类型 | 仅产品需求；或产品需求加技术需求，分开统计 |
| 来源与优先级 | 是否区分来源、优先级 | 全部纳入，按来源或优先级分组对比 |
| 缺陷与紧急插单 | 是否纳入缺陷修复和紧急需求 | 缺陷单独统计；紧急插单纳入但单独标记 |
| 时间窗 | 按哪个时间归集 | 按交付完成时间归集，便于与产出对齐；按进入时间归集，便于观察输入压力 |
| 时间单位 | 自然日、工作日或小时 | 跨团队对比用自然日；内部改进跟踪可用工作日；短周期团队可用小时 |
| 排除项 | 哪些记录不计入 | 已取消、被合并、重复录入、测试数据 |
时间窗的选择会影响结论方向。按交付完成时间归集，统计的是“这段时间交付的需求花了多久”，适合评估产出；按进入时间归集，统计的是“这段时间进入的需求最终花了多久”，需要等这些需求全部完成后才能算，适合观察输入侧压力。两种方式都合理，但同一份报告里只能选一种，并在口径说明中写明。
自然日与工作日不能混用。自然日包含周末和节假日，适合跨团队、跨地区的统一对比；工作日剔除了非工作时间，更贴近团队实际作业节奏。如果组织节假日安排差异较大，建议同时保留两种单位的结果，用于交叉核对。
数据口径与证据：起点、终点和暂停怎么定
起点和终点是计算的核心，必须落到系统里可查询、可追溯的字段或状态变更记录上。仅凭人工回忆或口头约定，会导致同一批需求在不同时间算出不同结果。
| 口径项 | 候选定义 | 适用场景与注意事项 |
|---|---|---|
| 计时起点 | 需求受理时间 | 衡量端到端客户感知周期，包含受理后的等待 |
| 计时起点 | 进入待开发状态时间 | 衡量研发侧可控周期，剔除受理到排期之间的等待 |
| 计时起点 | 首次排期时间 | 衡量从排定资源到交付的时间，适合资源约束明显的团队 |
| 完成时点 | 上线时间 | 以发布记录为准，适合有明确发布动作的团队 |
| 完成时点 | 验收通过时间 | 以验收状态变更为准，适合交付物需要客户或业务方确认的场景 |
| 完成时点 | 交付客户时间 | 以交付记录为准，适合对外交付项目 |
| 暂停规则 | 不扣除任何等待 | 衡量端到端周期时的默认做法，结果包含全部外部等待 |
| 暂停规则 | 扣除外部等待 | 衡量团队可控作业时间时使用，需逐项列明扣除范围，如等待业务方确认、等待第三方依赖 |
暂停规则要写成清单，而不是笼统地说“扣除等待”。例如只扣除“等待业务方确认需求细节”和“等待外部接口联调”两类，其他等待一律计入。清单越具体，不同人复算的结果越一致。
证据方面，每条需求至少需要以下字段：需求唯一标识、计时起点对应的时间戳、完成时点对应的时间戳、暂停区间及其起止时间、当前状态。状态流转记录是判断时间戳是否可信的主要依据，如果出现完成时间早于起点时间、同一状态反复跳转、时间戳为空等情况，应将该条需求标记为异常，单独列出处理，不直接参与聚合。
缺失值的处理也要提前约定。常见做法是：起点或终点缺失的需求不计入分母，并在报告中说明剔除条数；暂停区间缺失时按不扣除处理，同时标注该批数据的完整度。这样读者能判断结果覆盖了多少需求。
计算步骤：从单条需求到分布指标
计算分两步：先算每条需求的周期，再对一批需求做聚合。单条需求的公式为：
交付周期 = 完成时间 − 起点时间 − 暂停时长
其中暂停时长是各暂停区间时长之和，不扣除暂停时该项取0。结果按统一单位换算，自然日按日历日期差计算，工作日需按节假日表逐日折算。
聚合阶段建议以中位数和分位数为主：
- 中位数（P50）：一半需求的周期不超过该值，反映典型水平。
- P85、P90：分别表示85%、90%的需求周期不超过该值，用于观察长尾。
- 均值：作为参考，长尾明显时会被拉高，不宜单独使用。
- 分母：纳入统计的需求条数，需与剔除条数一并说明。
分位数的计算方式要固定。以P90为例，将n条需求按周期升序排列，取第⌈0.9×n⌉条的值（向上取整），或采用线性插值，两种方式结果略有差异，选定一种后在口径说明中注明。
分母为零或样本过少时，不输出分位数结论。样本量少于20条时，P90实际上只由一两条需求决定，波动很大，此时应展示逐条数据或改用中位数加最大值描述，并注明样本量。分组对比时，按需求类型、团队、时间段分别计算，每组独立给出分母，避免小组数据被大组稀释。
在工具层面，ONES Performance 可自动收录 ONES 系统内日常流转的研发数据并形成分析指标，支持多维度、自定义的分析与图表展示，适合把上述口径落到状态流转记录上反复计算。具体指标的字段配置方式需以实际系统设置为准。
算一个例子：10条需求的周期分布
以下为演示数据，用于说明计算过程。单位为自然日，暂停规则为扣除“等待业务方确认”的时长。
| 需求 | 起点（进入待开发） | 完成（上线） | 暂停时长 | 交付周期 |
|---|---|---|---|---|
| R1 | 3月1日 | 3月6日 | 0 | 5 |
| R2 | 3月1日 | 3月9日 | 1 | 7 |
| R3 | 3月2日 | 3月8日 | 0 | 6 |
| R4 | 3月3日 | 3月10日 | 2 | 5 |
| R5 | 3月4日 | 3月12日 | 0 | 8 |
| R6 | 3月5日 | 3月14日 | 1 | 8 |
| R7 | 3月6日 | 3月16日 | 0 | 10 |
| R8 | 3月7日 | 3月20日 | 3 | 10 |
| R9 | 3月8日 | 3月25日 | 2 | 15 |
| R10 | 3月9日 | 4月8日 | 0 | 30 |
将10条需求按周期升序排列：5、5、6、7、8、8、10、10、15、30。
- 中位数：第5和第6个值均为8，P50 = 8天。
- P90：⌈0.9×10⌉ = 9，取第9个值，P90 = 15天。
- 均值：(5+5+6+7+8+8+10+10+15+30) ÷ 10 = 10.4天。
这组数据里，均值10.4天明显高于中位数8天，原因是R10的30天把均值拉高了。如果只看均值，会高估典型需求的耗时；P90为15天，说明绝大多数需求在两周内完成，而R10这类长尾需求需要单独分析原因。这正是聚合时以中位数和分位数为主、均值仅作参考的原因。
解读与限制：结果能说明什么、不能说明什么
交付周期能说明一批需求的时间分布和长尾情况，不能单独说明团队效率高低。周期缩短可能来自需求拆分变细、批量变小，也可能来自统计范围缩小，需要结合吞吐量（单位时间完成的需求条数）和在制品数量一起观察。如果周期下降的同时在制品也在下降、吞吐量保持稳定，改进的可信度更高。
口径变更是可比性的主要风险。起点从“需求受理”改为“进入待开发”、完成时点从“上线”改为“验收通过”、暂停规则增减扣除项，都会让前后数据不可直接比较。口径调整后，应在报告中标注变更日期，新旧口径数据分段展示，不画成一条连续趋势线。
小样本和长尾会显著影响结果。样本量少时，分位数不稳定，单条长尾需求就能改变P90；长尾明显时，均值被拉高，容易误判典型水平。建议同时给出分母、中位数、P90和最大值，让读者看到分布形态。
验证改进效果时，用趋势和分组对比比单点数值更可靠。例如按季度观察中位数变化，或按团队分组对比同一时间段内的周期分布，并确认各组口径一致。交付周期与流动效率、瓶颈分析分工不同：交付周期描述“花了多久”，流动效率描述“其中多少时间在做有效工作”，瓶颈分析则定位时间消耗在哪个环节，三者配合使用才能支撑改进决策。
常见问题
需求交付周期和需求响应时间有什么区别？
需求响应时间通常指需求被受理到开始处理之间的等待，交付周期则覆盖从计时起点到交付完成的完整跨度。两者可以同时使用：响应时间帮助判断需求进入流程后多久被接住，交付周期帮助判断一条需求整体要等多久。如果起点选的是“进入待开发”，交付周期已经剔除了受理到排期之间的等待，此时它更接近研发侧可控周期，与端到端响应时间的口径不同，报告中需分别说明。
暂停时间扣除后，结果会不会失真？
扣除暂停时间衡量的是团队可控作业时间，适合内部改进跟踪；不扣除则反映端到端客户感知周期。两种做法都合理，关键在于扣除项要写成清单并固定下来，例如只扣除“等待业务方确认需求细节”和“等待外部接口联调”，其他等待一律计入。扣除范围越宽，结果越依赖人工标注的准确性，因此需要状态流转记录作为证据，并定期抽查暂停区间是否标注完整。
样本量很少时还能算P90吗？
样本量少于20条时，P90实际上只由一两条需求决定，波动很大，不建议直接输出分位数结论。此时可以展示逐条数据，或改用中位数加最大值描述分布，并在报告中注明样本量。分组对比时每组独立给出分母，避免小组数据被大组稀释；如果某组样本过少，可以合并时间段或只做趋势观察。
中途变更口径后，历史数据怎么处理？
口径变更会让前后数据不可直接比较。建议在报告中标注变更日期，新旧口径数据分段展示，不画成一条连续趋势线。如果确实需要跨期对比，可以按新口径回溯重算历史数据，但重算依赖历史状态流转记录的完整性，重算范围和数据完整度也要一并说明。
需求交付周期能直接用来考核团队吗？
交付周期是过程指标，适合描述流动状况和识别长尾需求，单独作为团队绩效考核容易引发需求拆分变细、统计范围调整等应对行为。更稳妥的做法是把它与吞吐量、在制品数量放在一起观察，用于改进讨论而非排名。如果确需纳入考核，应同时固定统计口径、样本范围和分组方式，并接受小样本带来的波动。
