交付周期统计口径的关键，是先固定起点与终点事件、统计对象和时间单位三件事。常用做法是从需求进入研发流程算到交付上线，按需求逐条计算日历天或工作日，汇总时看中位数与P85分位，并单独记录等待时长。口径确定后写入指标说明并冻结版本，跨团队比较前先核对起点终点、工作日日历、拆分合并规则与缺失值处理，否则数字之间不具备可比性。
要点总览（TL;DR）
- 交付周期口径先固定四件事：起点事件、终点事件、统计对象粒度、时间单位与日历；任一变化，数字就不可比。
- 常用口径是从需求进入研发算到上线发布，按需求逐条计算，单位取自然日或工作日，汇总看中位数与P85分位，并单独记录等待时长。
- 取数依赖工作项状态流转记录、发布记录与迭代记录，每条保留起止时间、变更人和口径版本号，才能复算。
- 跨团队比较前先核对起点终点、日历、拆分合并规则与缺失值处理；周期缩短要与缺陷、返工指标同看，不直接作为个人考核依据。
- 样本过少或分母为零时只报样本数并标注样本不足，不据此做趋势判断或团队对比。
交付周期要回答什么问题，口径边界怎么划
交付周期衡量的是从需求受理到交付完成的端到端时长。它回答的是“一条需求从被团队接住，到真正可用，一共花了多久”，而不是某个环节快不快。这个定义决定了统计对象是需求这类端到端工作项，统计结果是一条条时长数据，而不是某个阶段的工作量。
一套口径通常服务三类用途。第一类是趋势对比，看同一团队在不同月份、不同季度是变快还是变慢；第二类是团队对标，在口径一致的前提下比较不同团队的交付节奏；第三类是改进验证，在调整流程、拆分需求或增加评审之后，确认周期是否真的发生变化。三类用途对精度的要求不同，趋势对比更看重口径稳定，团队对标更看重口径一致，改进验证还需要配合质量与返工数据一起看。
本文只处理时长如何量化：起点终点怎么定、数据从哪里取、公式怎么算、结果怎么读。发布执行的具体流程、发布窗口安排、等待与阻塞的定位分析属于另外的主题，本文不展开。把边界划清楚，可以避免口径说明里混入流程规范，导致同一份文档既讲算法又讲操作，执行时互相干扰。
起点、终点与统计对象：口径的四个必填字段
一套可执行的口径，至少要把四个字段写死：起点事件、终点事件、统计对象粒度、时间单位与日历。四个字段任一变化，算出来的数字就不可比。建议把这四项做成口径定义表，随指标说明一起发布。
| 字段 | 候选定义 | 选择要点 |
|---|---|---|
| 起点事件 | 需求创建、进入研发、进入迭代、开发开始 | 起点越靠前，周期越长，越能反映端到端体验；起点越靠后，越接近开发执行效率。选定后不再随团队调整 |
| 终点事件 | 上线发布、验收通过、交付客户 | 上线发布适合有明确发布动作的团队；验收通过或交付客户更贴近用户可用。三者不可混用 |
| 统计对象粒度 | 需求、任务、缺陷、发布批次 | 需求适合端到端周期；任务适合执行层节奏；缺陷适合修复时效；发布批次适合按批次观察整体交付 |
| 时间单位与日历 | 自然日或工作日；节假日表归属 | 工作日口径需明确周末与法定节假日如何扣除，节假日表由谁维护、何时更新 |
起点与终点的选择要和用途匹配。如果目标是观察用户拿到价值的速度，起点取需求受理、终点取交付客户更合适；如果目标是观察研发环节的流转效率，起点取进入研发、终点取上线发布更贴近。两种口径都能用，但不能在同一张报表里混着算，也不能在季度之间悄悄换掉。
统计对象按需求还是按任务，取决于要回答的问题。按需求统计得到的是端到端周期，适合趋势与对标；按任务统计得到的是执行层节奏，颗粒度更细但容易被拆分方式影响。缺陷可以单独用一套口径统计修复周期，不与需求周期混算。发布批次口径适合发布节奏稳定的团队，按批次统计从批次启动到发布的时长，但要注意批次内需求数量差异会放大波动。
时间单位建议在口径说明里只选一种作为主口径，另一种作为辅助参考。自然日口径计算简单、不受节假日表维护质量影响；工作日口径更贴近实际工作节奏，但对节假日表的准确性依赖较强。无论选哪种，都要在指标说明中写明，并在报表标题或脚注中标注，避免读者误读。
数据从哪里取，怎么保证可复算
交付周期的数据来源主要有三类：工作项的状态流转记录、发布记录、迭代记录。状态流转记录提供起点与终点事件的发生时间，是计算周期的核心数据；发布记录用于确认上线时间，尤其当上线动作与状态变更不同步时；迭代记录用于按迭代或时间窗归集样本。取数时建议同时保留起点时间、终点时间、状态变更人和变更前后状态，这样任何一条周期数据都能回溯到具体操作。
可复算的前提是数据可追溯。每条记录至少保留以下字段：工作项编号、统计对象类型、起点事件名称与发生时间、终点事件名称与发生时间、状态变更人、所属迭代或时间窗、口径版本号。口径版本号与生效日期要一并记录，历史数据按当时生效的版本计算，新版本只对生效日期之后的样本生效，避免同一份报表前后算法不一致。
缺失值与异常值需要事先约定处理规则，并在指标说明中写明。常见情形包括：
- 未上线：统计期末仍未到达终点事件的需求，不计入当期完成样本，单独列为在途数量，避免把未完成的需求算成短周期或直接丢弃。
- 回退：上线后回退再重新发布的需求，以最终有效发布时间为终点，回退次数单独记录，不重复计入完成数。
- 重复打开：已完成又被重新打开的需求，若重新打开后再次交付，按最后一次有效交付计算，并在明细中标注。
- 时间缺失：起点或终点时间缺失的记录不参与计算，单独列出缺失清单，由数据负责人补齐后再纳入。
当研发数据已经在统一平台上流转时，状态变更记录可以直接作为取数来源。以 ONES 为例，ONES Performance 自动收录 ONES 系统内日常流转的研发数据，基于这些记录形成分析指标，减少手工整理数据源的工作；其效能度量实践体系覆盖交付效率、交付质量、资源效率、完成情况四个维度，交付周期可以作为交付效率维度下的一项指标来配置。具体指标的起点终点定义、是否支持工作日日历与分位数统计，需要按实际版本和团队口径核验后再落地。
计算步骤：从明细到中位数与分位数
单条周期的计算公式为：单条周期 = 终点时间 − 起点时间，结果统一换算为天。若采用工作日口径，需在两端时间之间扣除周末与节假日，扣除规则以口径说明中冻结的节假日表为准。换算时注意保留小数位规则，建议统一保留一位小数，并在指标说明中写明四舍五入方式。
汇总阶段建议同时输出中位数与P85分位，并明确分母。中位数反映典型水平，不受极端值拉扯；P85分位反映较长尾部的水平，适合观察大部分需求能在多长时间内完成。分母为当期完成统计对象数，即统计期内到达终点事件的需求条数，在途需求不计入分母。计算步骤可以按以下顺序执行：
- 按统计期筛选到达终点事件的需求，形成完成样本集。
- 逐条计算单条周期，单位统一为天，工作日口径按节假日表扣除。
- 剔除按规则判定为无效的记录，保留剔除清单与原因。
- 对有效样本排序，取中位数；按分位位置取P85分位，分位位置计算方式在口径说明中写明。
- 输出样本数、中位数、P85分位，并标注口径版本号与统计期。
分母为零或样本过少时需要特殊处理。统计期内没有完成需求时，分母为零，此时不输出中位数与分位数，只报告样本数为零并说明原因。样本量过少时，例如少于10条，建议照常输出数值但标注“样本不足”，不据此做趋势判断或团队对比。样本阈值属于团队约定，不设统一标准，但要在口径说明中写清楚。
一个算例：10条需求的周期统计
以下为演示情景，用于说明计算方法，不代表任何团队的真实水平或达标线。假设统计期为某月，10条需求均在该月内到达终点事件，起点取进入研发，终点取上线发布，单条周期按自然日计算如下表。
| 需求编号 | 起点日期 | 终点日期 | 自然日周期（天） | 工作日周期（天） |
|---|---|---|---|---|
| R01 | 3月2日 | 3月6日 | 4 | 4 |
| R02 | 3月2日 | 3月9日 | 7 | 5 |
| R03 | 3月3日 | 3月10日 | 7 | 5 |
| R04 | 3月4日 | 3月13日 | 9 | 7 |
| R05 | 3月5日 | 3月16日 | 11 | 7 |
| R06 | 3月6日 | 3月18日 | 12 | 8 |
| R07 | 3月9日 | 3月20日 | 11 | 9 |
| R08 | 3月10日 | 3月24日 | 14 | 10 |
| R09 | 3月11日 | 3月27日 | 16 | 12 |
| R10 | 3月12日 | 3月31日 | 19 | 13 |
自然日口径下，10条周期排序后为4、7、7、9、11、11、12、14、16、19。中位数取第5与第6个值的平均，即（11+11）÷2=11天。P85分位按排序后第85%位置取值，位置为（10−1）×0.85+1=8.65，介于第8与第9个值之间，按线性插值约为14+（16−14）×0.65≈15.3天。工作日口径下，排序后为4、5、5、7、7、8、9、10、12、13，中位数为（7+8）÷2=7.5天，P85分位位置同样为8.65，约为10+（12−10）×0.65≈11.3天。
两种口径的差异主要来自周末扣除，跨度越长，差异越明显。这个算例能说明公式、排序、分位位置和两种日历口径的差别；它不能说明团队交付水平高低，也不能用来设定达标线，因为样本只有10条，且需求类型、复杂度未做区分。实际使用时，应把算例中的日期替换为真实状态流转记录，并保留明细以便复算。
结果怎么读：可比性、限制与常见误用
跨团队比较前，先核对四项：起点终点是否一致、日历口径是否一致、需求拆分合并规则是否一致、缺失值处理是否一致。任何一项不同，数字差异都可能来自口径而非实际效率。例如一个团队按需求统计、另一个团队把大需求拆成多个子项统计，后者周期天然更短，直接比较会得出错误结论。比较时建议同时展示口径版本号与样本数，让读者知道数字是在什么条件下产生的。
周期缩短不等于质量提升。团队可能通过减少评审、压缩测试来缩短周期，短期数字变好但缺陷率上升。因此交付周期应与缺陷密度、返工率、回退次数等指标同看，形成一组观察，而不是单指标下结论。样本量小、需求类型混杂时，结论尤其不可靠，此时更适合看趋势而非绝对值，或按需求类型分组后再比较。
交付周期适合用于改进验证：调整流程前后用同一口径对比，确认变化是否真实存在。它不适合直接作为个人考核依据，因为周期受需求拆分、依赖关系、外部等待影响，个人可控范围有限，把周期与个人绩效直接挂钩容易诱发拆小需求、抢简单任务等行为，反而让数据失真。把指标定位在团队与流程层面，配合明细回溯，才能让口径长期稳定地发挥作用。
常见问题
需求中途被拆分或合并，交付周期怎么算才不重复？
拆分和合并会改变统计对象，处理规则要在口径说明里提前写死。常见做法是：需求拆分后，以拆分出的子项分别计算周期，原需求标记为已拆分、不重复计入完成样本；多个需求合并交付时，以合并后的交付对象为一条样本，起点取最早进入研发的时间，终点取合并交付上线时间。
无论选哪种规则，都要保证同一统计期内不重复计数，并在明细中保留拆分或合并的关联关系。跨团队比较前先确认双方规则一致，否则拆分更细的团队周期天然更短，数字不可直接比较。
统计期内没完成的需求，要不要算进交付周期？
不计入当期完成样本。交付周期衡量的是已完成交付的时长，未到达终点事件的需求还没有完整周期，强行计入会人为拉低或拉高结果。正确做法是把它们单独列为在途数量，记录当前已等待天数，作为辅助观察。
如果统计期内完成样本为零，分母为零，此时不输出中位数与分位数，只报告样本数为零并说明原因。样本量过少时照常输出数值但标注样本不足，不据此做趋势判断或团队对比。
工作日口径和自然日口径，团队应该选哪个？
两种都能用，关键是只选一种作为主口径并长期稳定。自然日口径计算简单，不受节假日表维护质量影响，适合跨团队、跨地区统一比较；工作日口径更贴近实际工作节奏，但依赖节假日表的准确性，需要明确由谁维护、何时更新。
建议在指标说明中写明主口径，另一种作为辅助参考，并在报表标题或脚注中标注。两种口径的差异主要来自周末与节假日扣除，周期跨度越长差异越明显，混用会让趋势失真。
用ONES的效能度量做交付周期，起点终点能自己定义吗？
ONES Performance 自动收录 ONES 系统内日常流转的研发数据，基于这些记录形成分析指标，并对研发数据做多维度、精细化、自定义的分析，其效能度量实践体系覆盖交付效率、交付质量、资源效率、完成情况四个维度。交付周期可以作为交付效率维度下的一项指标来配置。
具体指标是否支持自定义起点终点事件、是否内置工作日日历与分位数统计，需要按实际版本和团队口径核验后再落地。建议先在测试环境用一批历史需求跑通取数与计算，确认结果可复算后再正式发布口径。
交付周期变短了，能说明团队效率提升了吗？
不能单独下结论。周期缩短可能来自流程优化，也可能来自减少评审、压缩测试或把需求拆得更细，短期数字变好但缺陷率可能上升。解读时应与缺陷密度、返工率、回退次数等指标同看，形成一组观察。
交付周期更适合用于改进验证：调整流程前后用同一口径对比，确认变化是否真实存在。它不适合直接作为个人考核依据，因为周期受需求拆分、依赖关系和外部等待影响，个人可控范围有限，与绩效直接挂钩容易诱发抢简单任务等行为，反而让数据失真。
