交付周期统计经常出现“同一个团队、两个数字”的情况，原因多半不在数据本身，而在口径：从哪个状态开始计时、到哪个状态停止、按自然日还是工作日、等待外部依赖的时间算不算。本文给出一套可复用的字段规则，并用一个标注为演示情景的需求走通完整计算，主口径取“进入开发→上线完成”，同时保留“需求受理→上线完成”的端到端口径作对照。
要点总览（TL;DR）
- 交付周期口径先定四件事：起止点状态、计时单位、暂停扣除规则、取整方式，再开始取数。
- 示例主口径取“进入开发→上线完成”，按自然日计算并扣除等待外部依赖的暂停时段，算得约14.8天。
- 端到端口径取“需求受理→上线完成”，同一示例约18.8天，两条口径的差值对应评审与排期停留。
- 换团队时起止点随交付形态调整，暂停扣除原则和口径版本记录方式保持不变。
- 该口径只描述耗时，不覆盖发布执行过程，也不用于定位等待与阻塞原因。
示例要解决的口径问题与目标
交付周期是派生指标，它由状态时间戳和一组计算规则共同决定。团队各自按习惯取数时，常见分歧集中在四处：起点放在需求受理还是开发启动，终点放在提测通过还是上线完成，计时用自然日还是工作日，等待外部依赖的时段是否扣除。任何一处不同，都会让两个团队的平均交付周期失去可比性，看起来是效率差异，实际是口径差异。
本示例的目标是交付一套可直接复用的字段规则，包含四项内容：起止点的状态定义、计时单位、暂停扣除的判定与记录方式、取整与小数位规则。规则确定后，再配一个完整算例，让读者能对照自己的数据复算一遍。
示例设置两条口径，分工不同：
| 口径 | 起止点 | 回答的问题 | 使用场景 |
|---|---|---|---|
| 主口径（开发交付周期） | 进入开发 → 上线完成 | 研发环节把需求做成可上线状态用了多久 | 团队内部改进、迭代节奏复盘 |
| 端到端口径（需求交付周期） | 需求受理 → 上线完成 | 从提出到可用，需求整体走了多久 | 向业务方汇报、跨部门对齐预期 |
两条口径并列使用，可以避免单一数字被误读：主口径变短而端到端口径不变，说明瓶颈前移到了受理与排期阶段；两者同步变化，才说明整体流转在改善。
完整示例：一个需求从受理到上线的交付周期计算
以下为一个演示情景，需求信息与时间戳均为假设，用于说明计算方法，不代表任何真实团队的数据。
示例需求：类型为功能优化，规模为中等（预估 5 人日），负责人角色为后端开发，协作角色包括产品经理与测试工程师。统计区间为 2024 年 3 月，全部按自然日计算。
| 时间点 | 状态 | 说明 |
|---|---|---|
| 3月4日 10:00 | 需求受理 | 需求单创建并进入待评审 |
| 3月6日 15:00 | 评审通过 | 范围与验收标准确认 |
| 3月8日 09:30 | 进入开发 | 开发人员开始编码，主口径起点 |
| 3月12日 18:00 | 暂停（等待外部接口） | 依赖第三方接口文档，暂停计时 |
| 3月15日 10:00 | 恢复开发 | 接口文档到位，恢复计时 |
| 3月19日 17:00 | 提测 | 提交测试，进入测试环节 |
| 3月22日 11:00 | 测试通过 | 验收标准全部满足 |
| 3月25日 20:00 | 上线完成 | 生产环境发布并验证，主口径与端到端口径终点 |
暂停记录：3月12日 18:00 至 3月15日 10:00，共 2 天 16 小时，按自然日折算约 2.67 天，暂停原因登记为“等待外部接口文档”，恢复时由负责人补录恢复时间。
主口径计算：起点 3月8日 09:30，终点 3月25日 20:00，日历跨度为 17 天 10.5 小时，约 17.44 天；扣除暂停 2.67 天，得 14.77 天，按一位小数取整为 14.8 天。
端到端口径计算：起点 3月4日 10:00，终点 3月25日 20:00，日历跨度为 21 天 10 小时，约 21.42 天；扣除同一段暂停 2.67 天，得 18.75 天，取整为 18.8 天。
两条口径的差值为 4.0 天，对应受理到进入开发之间的评审与排期时间。这个差值本身就是一个可观察指标：差值扩大，说明需求在进入开发前的停留变长，值得单独复盘。
逐项解释：每个字段为什么这样取值
示例中的每个取值都有理由，也存在合理的替代做法。下表按字段列出选择依据与替代口径，便于团队按自身情况取舍。
| 字段 | 示例取值 | 选择理由 | 替代口径与适用条件 |
|---|---|---|---|
| 起点 | 进入开发 | 研发团队能直接影响的状态，排除评审与排期等待，便于衡量自身改进 | 需求受理：适合衡量端到端体验；评审通过：适合范围已稳定的团队 |
| 终点 | 上线完成 | 以用户可用为完成标志，包含测试与发布验证，避免“提测即完成”的高估 | 提测通过：适合发布由独立团队负责、研发只对代码质量负责的分工 |
| 计时单位 | 自然日 | 与业务方感知一致，跨周末与假期不需额外换算 | 工作日：适合排班稳定、周末不推进的团队，需维护节假日日历 |
| 暂停扣除 | 扣除等待外部依赖时段 | 该时段研发无法推进，计入会掩盖真实投入 | 不扣除：适合衡量需求整体等待体验的端到端口径 |
| 取整 | 保留一位小数 | 保留半天级差异，汇总时误差可控 | 取整到天：适合样本量大、只看趋势的场景 |
起点选进入开发，核心考虑是可控性。需求受理到进入开发之间，往往包含评审排期、资源协调等研发团队难以单方面改变的因素，把它计入主口径，会让改进动作的效果被稀释。代价是主口径无法反映需求在队列中的等待，这正是保留端到端口径的原因。
终点选上线完成，是为了让“完成”与用户可用对齐。若以提测通过为终点，测试返工与发布验证的时间会被排除在外，周期数字偏短，且容易在发布环节出问题时失真。当组织内发布由独立团队执行、研发只对代码交付负责时，改用提测通过作为终点也成立，但需要在口径说明中写明，且不与采用上线完成口径的团队直接比较。
自然日与工作日的差异在跨长假时最明显。自然日算法简单、与业务方沟通成本低；工作日更贴近实际推进节奏，但需要维护节假日日历，且不同地区假期不同，跨地域团队汇总时容易出错。选择哪一种取决于比较对象：对外沟通用自然日更直观，内部排产复盘用工作日更贴近资源投入。
暂停扣除需要两个条件同时满足才成立：一是暂停原因属于外部依赖且研发确实无法推进，二是暂停与恢复都有明确时间戳和原因记录。仅有口头说明的暂停不应扣除，否则口径会被随意放宽。记录要求包括暂停原因分类、暂停开始时间、恢复时间、登记人，缺一项就无法复核。
取整方式影响汇总。保留一位小数时，单条需求的半天差异得以保留，平均值误差较小；直接取整到天，单条误差最多 0.5 天，在样本量小时会明显扭曲平均值。建议明细保留原始精度，展示层再统一取整，并注明取整规则。
可迁移规律：把示例口径套到其他团队
换团队或换需求类型时，需要调整的是起止点与扣除规则，保持不变的是“先写规则、再算数、留版本”的工作方式。以下清单可作为迁移时的核对项。
- 起止点随交付形态调整。判断方法是问“哪个状态之后，工作进入本团队可控范围”和“哪个状态之后，结果对使用者可用”。前者定起点，后者定终点。移动端发版受应用商店审核影响时，可将终点定为提审通过并单独记录审核时长；数据类需求可将终点定为数据上线并可查询。
- 暂停扣除遵循同一原则。外部依赖导致无法推进、且有完整时间戳记录的时段可扣除；内部原因造成的等待，如排队等测试资源，一般不扣除，因为它属于团队可改进的范围。这条原则不随团队变化。
- 口径变更必须留版本。每次修改起止点、单位或扣除规则，记录变更日期、变更内容、生效范围，历史数据按原口径保留，需要对比时注明各自口径。缺少版本记录，跨期对比就会失真。
- 跨团队对比前先对齐口径。对齐内容包括起止点状态名、计时单位、暂停扣除范围、取整方式四项。四项一致后再比较数值；无法一致时，比较趋势而非绝对值。
- 主口径与端到端口径成对使用。只保留一条口径时，容易把等待时间误判为研发效率问题；两条并列，才能区分“做得慢”和“等得久”。
在口径落地环节，状态流转与时间戳需要被稳定记录，否则规则写得再好也无法复算。ONES 的工作项状态流转会留下状态变更时间，配合自定义字段可以记录暂停原因与恢复时间，使上述起止点与扣除规则能按同一套字段取数；具体字段配置方式以团队实际使用为准。
适用边界：这些口径不覆盖什么
本示例口径用于衡量需求从开发启动到上线的耗时，适用范围之外的情形需要另设指标，混用会得出错误结论。
- 不覆盖发布执行过程。发布成功率、回滚次数、发布耗时属于发布质量与发布效率的度量，交付周期只记录到上线完成这一时间点，不评价发布过程本身。
- 不用于定位等待与阻塞原因。暂停扣除只记录“扣了多少”，不解释“为什么等”。阻塞原因分布、等待时长按环节拆解，属于流动效率分析的范畴，需要单独的状态停留数据支撑。
- 需求频繁返工或范围大幅变更时口径受限。返工会导致状态回退，起止点之间的时间被反复拉长，此时周期数字更多反映变更次数而非交付效率；范围大幅变更后，前后两段的时间不宜直接相加，建议按变更点分段统计或重新起算。
- 示例数据仅用于演示。文中需求信息、时间戳与计算结果均为假设情景，用于说明计算方法，不代表任何真实团队的数据，也不构成对特定周期水平的参考基准。
明确这些边界后，交付周期数字才能被正确解读：它是一个描述耗时的指标，配合端到端口径看整体，配合状态停留数据看瓶颈，单独使用时只适合做趋势观察。
常见问题
暂停扣除需要哪些记录才算数？口头说明可以吗？
暂停扣除要同时满足两个条件：暂停原因属于外部依赖且研发确实无法推进，暂停与恢复都有明确时间戳和原因记录。记录至少包括暂停原因分类、暂停开始时间、恢复时间、登记人四项，缺一项就无法复核。仅有口头说明的暂停不应扣除，否则口径会被随意放宽，不同人登记的结果也无法对齐。
团队周末不推进工作，应该用自然日还是工作日？
取决于比较对象。对外沟通、向业务方汇报时用自然日更直观，跨周末与假期不需额外换算；内部排产复盘、衡量资源投入时用工作日更贴近实际推进节奏，但需要维护节假日日历，跨地域团队汇总时还要注意各地假期不同。无论选哪种，同一组对比数据必须使用同一单位，并在口径说明中写明。
需求中途范围大幅变更，交付周期还能直接算吗？
范围大幅变更后，前后两段的时间不宜直接相加。变更会导致状态回退或工作内容重置，周期数字更多反映变更次数而非交付效率。建议按变更点分段统计，或从变更确认后重新起算，并在口径说明中注明分段规则。返工频繁的需求同理，需要单独标注，避免混入平均值拉偏整体趋势。
两个团队口径不一致，还能比较交付周期吗？
先对齐四项内容再比较：起止点状态名、计时单位、暂停扣除范围、取整方式。四项一致后可以直接比较数值；无法一致时，比较趋势而非绝对值，并注明各自口径。口径变更时保留版本记录，历史数据按原口径保留，跨期对比时注明各自适用的口径版本。
主口径和端到端口径应该同时用吗？
建议成对使用。只保留一条口径时，容易把等待时间误判为研发效率问题。主口径变短而端到端口径不变，说明瓶颈前移到了受理与排期阶段；两者同步变化，才说明整体流转在改善。两条并列，才能区分“做得慢”和“等得久”。
