端到端交付周期分析把需求从进入研发流程到交付上线的完整时间拆成可复算的阶段，用统一的分母、时间窗和缺失值规则算出总周期与阶段占比，再结合样本量和分布解释结果。本文给出一套可直接落地的指标口径、取数要求、计算公式和解读边界，适合研发效能、项目管理或交付负责人建立基线并验证改进。
要点总览（TL;DR）
- 端到端交付周期分析以需求为统计单元，先固定起点（如需求受理或进入开发）和终点（如上线或验收通过），再按阶段记录时间戳，保证结果可复算。
- 核心指标包括总交付周期、阶段周期、阶段占比、周期中位数和P85分位；报告分位数时必须同时给出样本数，样本不足时只报告中位数并标注参考性质。
- 计算前要写清时间窗切分方式（按上线日期或进入日期）、纳入与排除的需求类型，以及缺失时间戳、跨阶段回退、重复上线的处理规则，前后对比必须同口径。
- 解读结果时区分等待时间与有效工作时间，控制需求类型构成，单指标不能直接代表团队绩效，改进验证需要足够样本和同口径前后对比。
端到端交付周期分析要回答什么问题
这项分析的核心任务，是用一条可追溯的时间链回答“一个需求从被接受到交付给用户，究竟花了多久、时间花在哪里”。它服务于三类具体用途，每类用途对数据的要求略有差异。
建立现状基线。在改进开始前，先算出当前一段时间的总周期中位数、P85分位和各阶段占比，形成可对比的起点。基线要固定统计单元、起点终点和时间窗，否则后续对比失去意义。
定位周期构成。把总周期拆成受理等待、排期等待、开发、提测等待、测试、上线等待等阶段，看哪一段占用的时间最多。这一步产出的是时间分布，回答“慢在哪一段”，不回答“为什么慢”。
验证改进效果。在流程调整、资源投入或工具改造之后，用同一口径重算指标，比较前后差异是否超出正常波动。验证需要足够样本和同口径对比，单次观察不足以支撑结论。
分析对象是需求级的端到端流程，统计单元为一条需求或用户故事，而非单个开发任务、代码提交或缺陷单。任务级数据可以作为阶段内部的补充证据，但不能替代需求级周期。本文聚焦量化分析本身：发布执行流程怎么走、等待和阻塞的根因如何定位，属于相邻主题，这里只在解读阶段构成时点到为止。
指标与统计范围怎么定
指标定义要在取数之前写清楚，形成一份团队共同认可的说明。下表给出核心指标的口径框架，实际使用时把“起点”“终点”替换成本团队固定的状态节点。
| 指标 | 定义 | 单位 | 说明 |
|---|---|---|---|
| 总交付周期 | 终点时间 − 起点时间 | 天或小时，全表统一 | 起点如需求受理或进入开发，终点如上线或验收通过 |
| 阶段周期 | 阶段结束时间 − 阶段开始时间 | 与总周期一致 | 各阶段之和应等于总周期，差额即未归类时间 |
| 阶段占比 | 阶段周期 ÷ 总周期 | 百分比 | 分母为总周期，各阶段占比合计约100% |
| 周期中位数 | 样本总周期排序后的中间值 | 与总周期一致 | 比平均值更抗极端值干扰 |
| P85分位 | 85%的样本周期不超过该值 | 与总周期一致 | 反映偏慢部分的水平，需同时报告样本数 |
统计单元与聚合规则。以需求或用户故事为一行记录。一个需求拆成多个子任务时，子任务的时间不单独计入周期，而是取该需求下最早开始时间和最晚完成时间参与阶段计算；子任务数量只作为辅助信息。若一个需求被拆成多个独立上线批次，需事先约定按首次上线还是末次上线计算，并在口径说明中写明。
时间窗切分。按上线日期切分样本，适合衡量“这段时间交付出去的需求有多快”；按进入日期切分，适合衡量“这段时间进入流程的需求最终表现如何”。两种切法会得到不同样本集，尤其在有大量在途需求时差异明显。建议基线分析采用按上线日期切分，并在报告中注明；做在途监控时另按进入日期统计。
范围边界。明确纳入的需求类型，例如产品需求、优化类需求；明确排除项，例如紧急线上修复、纯实验性需求、被取消的需求。排除规则要写进口径说明，避免不同人取数时各取一套。跨团队或跨项目对比时，先对齐起点终点、时间窗和排除规则，再比较数值。
数据口径与证据要求
周期计算的可信度取决于时间戳是否完整、来源是否一致。建议以工作项状态流转记录作为主要证据来源，每个阶段边界对应一次状态变更，并保留变更时间和操作记录。
| 阶段边界 | 典型时间戳字段 | 证据来源 |
|---|---|---|
| 需求受理 | 创建时间或受理时间 | 工作项创建记录 |
| 排期完成 | 进入排期状态的时间 | 状态流转记录 |
| 开发开始 | 进入开发中状态的时间 | 状态流转记录 |
| 提测 | 进入待测试或提测状态的时间 | 状态流转记录 |
| 测试通过 | 进入测试通过或待上线状态的时间 | 状态流转记录 |
| 上线 | 上线完成时间或验收通过时间 | 发布记录或验收记录 |
手工补录要标注。历史数据缺失时允许补录，但补录记录需标记来源和补录人，分析时单独统计补录比例。补录比例过高会削弱结果可信度，报告中应说明。
异常数据处理规则。缺失关键时间戳的需求，若缺失的是中间阶段，可将该阶段标记为“未记录”并从阶段占比中剔除，总周期仍按首末时间计算；若缺失起点或终点，则该需求不进入周期样本，单列数量。跨阶段回退（如测试不通过退回开发）时，阶段周期按各次停留时间累加，回退次数作为辅助指标记录。重复上线按口径约定取首次或末次，并在说明中固定，前后对比不得混用。
口径对齐。多团队汇总前，先核对各团队的起点终点定义、状态名称映射和时间单位。状态名称不同但语义相同的，建立映射表；语义不同的不强行合并。取数环节如果使用 ONES，工作项的状态流转与时间字段可以作为周期计算的原始记录来源，ONES Performance 会收录系统内日常流转的研发数据并形成分析指标，减少手工整理数据源的工作量；具体字段名称和导出方式以实际配置为准。
计算步骤与公式
计算流程按以下顺序执行，每一步都产出可复核的中间结果。
- 确定样本集。按时间窗和范围规则筛选需求，记录样本总数、排除数量和排除原因。
- 计算总周期。总周期 = 终点时间 − 起点时间，单位统一为天（或小时），保留一位小数。跨自然日按实际时长计算，不按工作日折算，除非口径中明确约定工作日口径并全表一致。
- 计算阶段周期。阶段周期 = 阶段结束时间 − 阶段开始时间。各阶段周期之和与总周期的差额记为“未归类时间”，单独列出。
- 计算阶段占比。阶段占比 = 阶段周期 ÷ 总周期。分母为总周期，总周期为零或负值的记录先剔除并说明。
- 计算分布指标。将样本总周期排序，取中位数；P85分位采用线性插值法：位置 = (样本数 − 1) × 0.85，取相邻两个值按小数部分加权。同时报告样本数、平均值和最大值，便于判断分布形态。
- 处理样本不足。样本量低于约定下限（例如30条）时，分位数不稳定，只报告中位数和样本数，或标注“样本不足，仅供参考”。分母为零、总周期为负的记录不计入统计，单独列出数量。
公式汇总：总周期 = 终点 − 起点；阶段周期 = 阶段结束 − 阶段开始；阶段占比 = 阶段周期 ÷ 总周期；中位数取排序中间值；P85按上述插值法计算。所有指标在同一张结果表中呈现，附样本数和口径说明，保证他人可以按同样步骤复算。
一个可复算的例子
以下为演示数据，用于说明计算过程，不代表任何真实团队的表现。
| 需求 | 受理 | 开发开始 | 提测 | 测试通过 | 上线 |
|---|---|---|---|---|---|
| A | 3月1日 | 3月4日 | 3月10日 | 3月14日 | 3月16日 |
| B | 3月2日 | 3月3日 | 3月9日 | 3月12日 | 3月13日 |
| C | 3月5日 | 3月9日 | 3月18日 | 3月22日 | 3月25日 |
| D | 3月6日 | 3月8日 | 缺失 | 3月15日 | 3月17日 |
需求A的计算。总周期 = 3月16日 − 3月1日 = 15天。受理到开发开始3天，开发6天，提测到测试通过4天，测试通过到上线2天。阶段占比分别为20%、40%、26.7%、13.3%。
需求B的计算。总周期 = 11天。受理到开发开始1天，开发6天，提测到测试通过3天，测试通过到上线1天。
需求C的计算。总周期 = 20天。受理到开发开始4天，开发9天，提测到测试通过4天，测试通过到上线3天。
需求D的处理。提测时间缺失，该需求的“开发到提测”阶段标记为未记录，从阶段占比中剔除；总周期仍按受理到上线计算，为11天。若缺失的是上线时间，则该需求不进入周期样本，单列数量。
分布指标。四条需求总周期为15、11、20、11天，排序后为11、11、15、20。中位数为(11+15)÷2=13天。P85位置 =(4−1)×0.85=2.55，取排序第3位15和第4位20插值：15+(20−15)×0.55=17.75天。样本仅4条，分位数仅供参考，实际分析应积累到约定样本量再解读。
结果怎么解读，以及有哪些限制
拿到结果后，先看分布再看构成，最后才谈改进。解读时注意以下几点。
区分等待时间与有效工作时间。阶段周期中包含排队、等待评审、等待环境等时间，也包含实际投入的工作时间。总周期长不等于开发慢，可能是等待占比高。报告中应把各阶段进一步拆成等待和工作两类，或至少说明哪些阶段以等待为主，避免把等待时间误读为执行效率问题。
样本量和需求类型影响可比性。样本量小时分位数波动大，前后对比容易把正常波动当成改进效果。需求类型结构不同（如大需求与小优化混在一起）也会拉高或拉低中位数，跨期对比时应控制类型构成，或分类型分别报告。
单指标不能代表团队绩效。交付周期只反映时间维度，不反映质量、返工、需求价值或团队负荷。周期缩短可能伴随质量下降或需求拆分变细，因此周期指标应与质量、返工率等指标一起看，且不直接用于个人考核。
改进验证需要同口径和足够样本。前后对比要固定起点终点、时间窗切分方式和排除规则，样本量达到约定下限后再下结论。季节性波动、需求结构变化、人员变动都可能影响结果，必要时结合阶段占比的变化方向判断改进是否真实发生。ONES Performance 从交付效率、交付质量、资源效率、完成情况等维度组织效能数据，并支持形成量化、实施、分析、改进的循环，适合把周期指标与其他维度放在同一套分析中对照使用；具体可用的指标和模板以实际版本为准。
常见问题
需求在分析期内还没上线，应该计入分母还是排除？
两种做法都可以，关键是事先声明并在前后对比中保持一致。只统计已交付需求，得到的是“已完成需求的周期表现”，适合做基线和改进验证；把在途需求单列，可以同时观察积压规模，但不要把在途需求混入周期计算，否则总周期会被截断或失真。如果分析期内有大量需求尚未上线，建议在报告中同时给出已交付样本数和在途数量，说明样本覆盖情况。
一个需求中途被拆成多个子需求分别上线，周期怎么算？
需要在口径说明中提前约定聚合方式。常见做法有两种：一是以原始需求为一行记录，取最早开始时间和最晚上线时间计算总周期，子需求只作为阶段内部的辅助信息；二是拆成多条独立记录分别计算，但要在报告中说明拆分规则，避免同一需求被重复计数。无论选哪种，前后对比必须使用同一规则，否则周期变化可能只是拆分方式变化带来的假象。
测试不通过退回开发，这段时间算进哪个阶段？
建议按各次停留时间累加：开发阶段累计所有处于开发状态的时间，测试阶段累计所有处于测试状态的时间，回退次数作为辅助指标单独记录。这样阶段周期之和仍能与总周期对齐，差额记为未归类时间。回退频繁本身是流程信号，可以在结果解读时结合回退次数说明，但根因定位属于流动效率与瓶颈分析的范畴，本文只做时间量化。
样本只有十几条需求，P85分位还能用吗？
样本量偏小时分位数不稳定，个别极端值就能明显改变结果。建议设定样本量下限（例如30条），低于下限时只报告中位数和样本数，或标注“样本不足，仅供参考”。如果必须给出分位数，应同时附上原始分布或最大值，让读者判断波动范围。做改进前后对比时，两侧样本都要达到下限，否则容易把正常波动误判为改进效果。
用ONES的工作项数据做周期分析，需要提前确认什么？
先确认状态流转记录是否覆盖起点、终点和中间各阶段，以及各团队的状态名称能否映射到统一口径。ONES Performance 会收录系统内日常流转的研发数据并形成分析指标，ONES Project 中的业务数据可实时同步，减少手工整理数据源的工作；具体字段名称、导出方式和异常数据处理规则以实际配置为准。取数前建议先用少量需求核对时间戳与状态记录是否一致，再批量计算。
