交付周期指一个需求或工作项从进入交付流程到完成交付所经过的时间。要算得可复算，需要先定三件事：起点和终点事件、单条周期的计算公式、统计范围内的分母。本文围绕这三项给出定义、字段要求、汇总方式和示例，并说明结果能支持哪些判断、不能支持哪些判断。
要点总览（TL;DR）
- 交付周期是工作项从起点事件到终点事件的时间跨度，起止点要按评估目的选定，并在指标名称中写明，例如“需求交付周期（进入队列至上线）”。
- 单条周期 = 终点事件时间 − 起点事件时间，单位统一为小时或工作日；按工作日计算时需先约定工作日历，按日历逐日折算。
- 汇总以中位数为主指标，P85用于观察大多数工作项的上限，平均值与中位数并列呈现；分母为同一批完成的工作项数，排除项要同步扣除并注明有效样本数。
- 分母为零时显示“无数据”，样本过少时合并相邻时间窗或只呈现明细；缺失时间戳的工作项需单独统计缺失率。
- 交付周期不能直接归因于团队效率，需与吞吐量、在制品数量结合解读，达标线用本团队历史基线结合业务承诺确定。
先确定要回答的评估目标
“交付周期怎么算”没有唯一答案，起止点的选择取决于你要用这个数字回答什么问题。先写清评估目的，再选口径，可以避免同一张报表在不同月份换了算法却没人察觉。
| 评估目的 | 建议起点 | 建议终点 | 口径特点 |
|---|---|---|---|
| 观察交付速度的长期趋势 | 工作项进入待开发队列 | 上线或交付验收完成 | 包含排队等待，反映需求从提出到落地的真实跨度 |
| 评估团队对承诺日期的兑现情况 | 承诺确认或排期进入迭代 | 承诺的交付节点完成 | 与承诺口径对齐，便于逐项核对是否按期 |
| 对比改进前后的变化 | 改进措施生效前后保持一致 | 保持一致 | 起止点一旦确定，对比期内不调整 |
| 观察开发执行阶段的耗时 | 开始开发 | 提交测试或开发完成 | 剔除排队时间，跨度较短，适合定位执行环节 |
同一份数据可以按不同目的算出多个周期值，但每个指标都要在名称或说明中写明起止点，例如“需求交付周期（进入队列至上线）”。本文讨论的是交付效率的量化计算，发布执行流程本身以及等待与阻塞的具体定位属于另外的分析任务，这里不展开。
指标定义与统计范围
交付周期的可复算定义是：在统一的工作项类型下，单个工作项从起点事件发生到终点事件发生之间的时间跨度。定义卡需要同时写清统计对象、时间窗和排除规则，三者缺一，数字就无法被他人复现。
统计对象
先确定统计哪一类工作项。需求、用户故事、缺陷的流转路径和耗时结构差异明显，混在一起统计会让结果失去解释力。常见做法是选定一类作为主口径，例如“已上线的产品需求”，其他类型单独出指标。工作项类型的判定标准要写进定义卡，例如以创建时选择的类型为准，还是以完成时的类型为准，中途改类型的工作项如何处理。
时间窗归集
按周或按月统计时，需要明确工作项归入哪个时间窗。按完成时间归集，表示“本周完成了哪些工作项，它们的周期是多少”，适合观察已交付成果的速度；按开始时间归集，表示“本周启动的工作项最终花了多久”，适合跟踪在途工作，但时间窗末期启动的工作项尚未完成，会产生缺失。多数交付速度报表采用按完成时间归集，并在报表说明中注明。
排除规则
以下情况需要在定义卡中明确处理方式，并保持各期一致：
- 已取消或关闭为“不做”的工作项：通常排除，不计入分子也不计入分母。
- 被合并到其他工作项的重复项：保留主项，排除被合并项，避免同一交付被计算两次。
- 测试或演示用途创建的无效工作项：排除，并在数据源上做标记。
- 统计期内未完成的工作项：不计入当期分母，留待完成时归入对应时间窗。
数据口径与证据来源
交付周期依赖时间戳，时间戳来自工作项的状态流转记录。数据可用性的核心要求是：工作流配置中的状态与实际流转记录一致，每个关键事件都有可追溯的时间点。
所需字段
| 字段 | 用途 | 质量要求 |
|---|---|---|
| 工作项类型 | 确定统计对象 | 类型定义稳定，变更留痕 |
| 创建时间 | 辅助判断起点，识别补录 | 与实际提出时间偏差可接受 |
| 状态流转时间戳 | 确定起点事件与终点事件的发生时间 | 每次状态变更均有记录，含变更前后状态与操作时间 |
| 完成时间 | 确定终点与时间窗归集 | 与终点状态变更时间一致 |
| 所属团队或项目 | 分组统计与对比 | 归属关系在统计期内稳定 |
一致性与缺失处理
状态变更记录需要与工作流配置对照检查：配置中存在“提交测试”状态，但历史记录里大量工作项直接从“开发中”跳到“已完成”，说明该状态未被实际使用，此时以“提交测试”为终点会得到大量缺失值。处理方式有三种，需在定义卡中选定一种：改用实际被稳定使用的状态作为事件锚点；对缺失值单独统计缺失率并说明；将缺失工作项排除并同步调整分母。跨系统数据不一致时，以工作项系统的流转记录为准，外部系统时间仅作参考。
定性核验方面，可抽取若干工作项，对照其状态流转记录与评审记录，确认起点和终点事件确实在对应时间发生，判断时间戳是否被批量补录或集中修改。ONES 的项目与工作项管理会记录工作项的状态流转，可作为上述时间戳字段的来源之一；具体字段名称和导出方式以实际配置为准。
计算步骤与公式
计算分两步：先算单条周期，再在时间窗内汇总。两步的单位和分母必须一致。
单条周期
单工作项交付周期 = 终点事件时间 − 起点事件时间。单位统一为小时或工作日，全表只选一种。选择工作日时，需先约定工作日历：每周几个工作日、法定节假日如何扣除、跨时区团队以哪个时区为准。自然日与工作日的换算不能用一个固定系数简单相乘，因为周末和假期的分布不均匀，应按日历逐日折算。
时间窗汇总
| 汇总方式 | 适用场景 | 注意事项 |
|---|---|---|
| 中位数 | 样本存在少量超长周期，需要反映典型水平 | 对极端值不敏感，适合作为主指标 |
| P85 | 关注大多数工作项的等待上限，用于承诺或服务水平参考 | 需说明分位数算法，样本少时波动大 |
| 平均值 | 需要与总工时、总成本口径衔接 | 易被个别超长工作项拉高，宜与中位数并列呈现 |
分母为统计范围内完成的工作项数，且必须与分子使用同一批工作项。若分子排除了缺失时间戳的工作项，分母也要相应扣除，并在报表中注明有效样本数。分母为零时，指标显示为“无数据”，不显示为0，避免被误读为周期极短。样本量过少时，例如一个时间窗内完成的工作项不足5个，建议合并相邻时间窗或只呈现明细，不单独给出分位数。
一个可复算的计算例子
以下为演示数据，用于说明计算过程。某团队统计某一周按完成时间归集的需求交付周期，起点为“进入待开发队列”，终点为“上线完成”，单位取工作日。
| 工作项 | 进入队列 | 上线完成 | 周期（工作日） |
|---|---|---|---|
| A | 周一 | 周三 | 2 |
| B | 周一 | 次周一 | 5 |
| C | 周二 | 次周二 | 5 |
| D | 周三 | 第三周周一 | 3 |
| E | 周一 | 第三周周三 | 7 |
| F | 周四 | 次周五 | 6 |
该周共完成6个工作项，另有一个工作项G因缺少“进入队列”的时间戳被排除，因此有效分母为6，缺失率为1/7。将6个周期值排序为2、3、5、5、6、7，中位数为第3与第4个值的平均，即(5+5)/2=5个工作日。P85按常用线性插值法计算，位置为(6−1)×0.85+1=5.25，取第5个值6与第6个值7之间插值，得6.25个工作日。平均值为(2+3+5+5+6+7)/6≈4.67个工作日。
呈现时建议同时给出有效样本数、中位数、P85和缺失率，例如“本周完成6项，交付周期中位数5个工作日，P85为6.25个工作日，缺失1项”。只给一个平均数会掩盖分布形态，读者无法判断是否存在长尾。
结果解读与使用限制
交付周期是一个时间跨度指标，它记录的是工作项在流程中实际经过的时间，不能直接等同于团队效率。周期变长可能来自需求变大、评审等待增加、依赖外部系统，也可能来自统计口径变化。解读时应回到具体工作项的流转记录，找出时间花在哪个阶段。
可比性条件
- 样本量：时间窗内完成的工作项过少时，中位数和P85波动明显，不宜据此下结论。
- 工作项构成：需求规模、类型、复杂度变化会直接影响周期，改进前后对比需控制构成变化，例如按规模分层比较。
- 口径稳定：起止点、单位、排除规则在对比期内保持不变，变更需在报表中标注生效时间。
与其他指标配合
交付周期宜与吞吐量（单位时间完成的工作项数）、在制品数量结合解读。周期缩短同时吞吐量下降，可能只是减少了并行任务；周期缩短且吞吐量稳定或上升，才更可能反映流程改善。单看周期一个数字，容易把排队减少误判为执行提速。
达标线的确定
交付周期没有通用的达标数值。合理的做法是用本团队过去若干个月的历史数据建立基线，结合业务承诺和客户期望确定目标区间，并说明目标适用的工作项类型和时间窗。目标一旦设定，应定期复核，避免基线漂移后仍沿用旧标准。
最后，指标用于发现问题和验证改进方向，不宜直接作为个人绩效的唯一依据。当周期被用作考核项时，工作项拆分方式和人為调整状态时间的动机都会改变数据本身，指标的可比性随之下降。
常见问题
工作项中途变更了类型或所属团队，统计时应该按变更前还是变更后归入？
这属于定义卡需要提前约定的例外情形。常见做法有两种：以完成时的类型和归属为准，反映最终交付成果的属性；或以创建时为准，反映需求提出时的分类。两种做法都能复算，关键是全期一致并在报表说明中注明。若中途改类型的工作项数量较多，建议单独统计这部分工作项，避免它们在不同口径下被重复计入或漏计。
团队同时有按自然日汇报的承诺和按工作日统计的内部指标，两者如何对齐？
建议保留两套口径但明确各自用途：对外的承诺日期按自然日表达，内部统计按工作日计算，并在报表中同时给出换算说明。换算时按工作日历逐日折算，例如扣除周末和法定节假日，不用固定系数相乘。若承诺日期本身按工作日约定，则两套口径可以直接对齐，只需在定义卡中写明节假日的处理方式。
历史数据里状态时间戳大量缺失，还能算交付周期吗？
可以先评估缺失的分布再决定。若缺失集中在某一段时期或某一类工作项，可改用实际被稳定使用的状态作为事件锚点，例如以“开始开发”替代“提交测试”作为终点，并说明口径调整的生效时间。若缺失分散且比例较高，建议先补齐数据采集，再对可用的部分单独出指标，同时公布缺失率。把缺失工作项直接当作零周期或直接剔除而不调整分母，都会让结果失真。
按周统计时，跨周完成的工作项应该算进哪一周？
按完成时间归集时，工作项计入其完成事件所在的那一周，与它何时开始无关。这样每周的分母都是当周实际完成的工作项，指标含义清晰。按开始时间归集则会出现时间窗末期启动、尚未完成的工作项，需要单独标记为在途，不计入当期分母。两种归集方式不能混用于同一张趋势图，切换时要在图上标注。
交付周期缩短了，是否可以直接说明流程改进有效？
不能直接下这个结论。周期缩短可能来自工作项拆分变细、需求规模变小、并行任务减少，也可能来自状态时间被集中调整。判断改进是否有效，需要同时看吞吐量和在制品数量：周期缩短且吞吐量稳定或上升，才更可能反映流程改善；周期缩短但吞吐量下降，可能只是减少了并行。对比改进前后时，还应控制工作项构成的变化，例如按规模分层比较。
