需求交付周期的统计口径，需要先固定三件事：起止点（从哪个状态开始计时、到哪个状态停止）、计时方式（自然日还是工作日、是否扣除等待与阻塞）、统计对象与分母（哪些需求进入样本、按需求数还是按批次）。口径确定后，用分位数（P50/P85/P90）描述分布，并写明时间窗、单位与缺失值处理，数据才能在不同团队、不同周期之间可比、可复算。本文给出一套可直接填写的口径字段与计算步骤。
要点总览（TL;DR）
- 口径由四类字段决定：起点、终点、计时方式、样本范围；先写清评估目标，再逐项填写，避免每次汇报临时调整。
- 起点常用“进入开发”、终点常用“上线发布”，衡量研发与发布环节；要覆盖完整链路时起点前移到需求创建或承诺交付，并注明包含排队时间。
- 计时以自然日为主、易复算；阻塞记录完整时，可并列输出扣除阻塞后的净时长，两个口径不混入同一条趋势线。
- 样本只统计已到达终点且起止记录完整的需求，未完成需求不进入分母；分母为零记为“无数据”，不记为0。
- 用P50/P85/P90描述分布，平均值与分位数并列呈现；口径变更需版本化，新旧数据不直接拼接。
先明确要回答什么：交付周期口径的评估目标
定口径的第一步是写清楚这个数字要支撑哪类判断。目标不同，起止点和样本范围的选择就不同；目标含糊，口径就会在每次汇报时被临时调整，历史数据随之失去可比性。
常见的评估目标有三类，各自对口径的要求如下：
| 评估目标 | 要回答的问题 | 对口径的关键要求 |
|---|---|---|
| 交付快慢趋势 | 本季度比上季度是变快还是变慢 | 起止点、计时方式、样本规则在比较期内保持一致；时间窗等长 |
| 团队间可比 | 两个团队的需求交付周期差异有多大 | 状态定义一致、需求类型构成接近、同一计时方式与排除规则 |
| 改进前后对比 | 某项流程调整是否带来了周期变化 | 口径版本固定，变更点有记录；样本范围不因改进而悄悄扩大或缩小 |
把目标写成一句话，再逐条对应需要的口径要素，可以避免“为了统计而统计”。例如目标是“观察趋势”，起止点选内部可控的状态即可；目标是“团队间可比”，就必须先统一状态含义，否则数字差异可能来自定义差异而非交付差异。
口径一旦确定，应作为稳定约定使用。确需调整时，记录变更内容、生效时间和原因，形成版本号；新旧版本的数据分开呈现，不直接拼接成一条曲线。
起止点、计时方式与样本范围：口径的四个必填字段
把“交付周期”拆成可定义、可复算的字段，至少需要四类信息：起点、终点、计时方式、样本范围。下表给出可选值与默认建议，团队可据此填写自己的口径说明。
| 字段 | 可选值 | 默认建议 | 影响说明 |
|---|---|---|---|
| 起点 | 需求创建；进入待开发；进入开发；承诺交付（排期确认） | 进入开发 | 起点越靠前，周期包含的排队时间越多；选“创建”适合观察端到端响应，选“进入开发”更适合观察开发执行段 |
| 终点 | 开发完成；测试通过；上线发布；客户验收 | 上线发布 | 终点越靠后，周期越接近用户可感知的交付；选“客户验收”会引入验收等待，需单独说明 |
| 计时方式 | 自然日；工作日；扣除阻塞与等待后的净时长 | 自然日，另附扣除阻塞的净时长作为辅助指标 | 自然日口径简单、易复算；净时长更能反映实际投入，但依赖阻塞记录的完整性 |
| 样本范围 | 需求类型（新功能、优化、缺陷修复等）；优先级；是否含紧急插单；排除规则 | 仅统计已上线的产品需求，排除缺陷与紧急插单，单独统计 | 样本构成变化会直接改变分位数；混合统计会让结果难以解释 |
关于起止点的选择，一个实用的判断方法是问：这个指标要归谁负责、在哪个环节可以被改善。起点选“进入开发”、终点选“上线发布”，衡量的是研发与发布环节的周期；如果希望覆盖从提出到上线的完整链路，起点应前移到需求创建或承诺交付，并在口径说明中注明包含排队时间。
关于计时方式，自然日与工作日各有适用场景。自然日适合跨团队统一比较，计算简单；工作日适合排除周末影响、贴近实际工作节奏，但需要维护节假日日历。是否扣除阻塞与等待，取决于阻塞记录是否完整：如果阻塞状态被规范记录，可以同时输出“含等待”和“扣除阻塞”两个数字，前者反映用户等待，后者反映流程内实际耗时。
样本范围要写清楚纳入与排除规则。常见做法是：只统计已到达终点的需求，未完成的需求不进入分母；缺陷修复、紧急插单、被取消的需求单独统计或排除；跨团队比较时，确认双方的需求类型构成接近，否则分位数差异可能来自需求结构而非交付能力。
数据从哪里取、怎么保证可比：数据口径与证据
周期计算依赖三类原始记录：工作项的状态变更时间戳、状态流转日志、发布记录。时间戳用于计算单条需求的起止时间；流转日志用于还原状态路径、识别跳变与回退；发布记录用于确认终点时间与版本对应关系。三者应能相互印证，单靠人工填报的日期容易产生补录偏差。
可比性的前提是状态定义一致。不同团队可能都叫“开发中”，但一个团队指编码开始，另一个团队指方案评审通过，同名状态含义不同，周期数字就不可比。核对时逐项确认：起点状态在各方是否指同一动作、终点状态是否都代表已上线、是否存在团队特有的中间状态影响计时。
数据核对可按以下清单执行：
| 核对项 | 检查内容 | 不通过时的处理 |
|---|---|---|
| 状态定义 | 各团队起点、终点状态的含义是否一致 | 统一状态命名与流转规则，或在口径中注明差异 |
| 时间戳完整性 | 每条需求是否都有起点与终点记录 | 缺失记录的需求标记为无效样本，不计入分母 |
| 状态跳变 | 是否存在未经中间状态直接到达终点的情况 | 核对是否为补录或流程简化，必要时人工确认 |
| 长期挂起 | 是否有长期停留在某状态的需求 | 设定挂起阈值，超期需求单独列出，不混入常规统计 |
| 时间窗一致 | 比较双方是否使用同一统计区间 | 统一按自然周、自然月或季度切分 |
缺失与异常的处理规则要写进口径，而不是每次临时判断。常见规则包括：起点或终点时间缺失的需求不进入样本；状态跳变且无法核实的需求标记为异常并单独统计；补录时间需注明来源；长期挂起需求设定阈值（如超过一个统计周期未推进）后单独呈现。
计算步骤：从原始记录到分位数
单条需求的周期按以下公式计算：
单条周期（天）= 终点时间 − 起点时间，结果按天保留一位小数；若采用工作日口径，则按工作日历折算。
样本周期集合形成后，按从小到大排序，取分位数：
- P50（中位数）：排序后位于50%位置的取值，代表典型需求的经验；
- P85：85%的需求周期不超过该值，用于观察大多数需求的交付上限；
- P90：90%的需求周期不超过该值，用于观察长尾；
- 平均值：所有周期之和除以样本数，受长尾需求影响明显，适合与分位数并列呈现而非单独使用。
分位数的取值方法需在口径中写明。样本量较小时，可采用排序后按位置取最近值的方式，并注明所用规则，保证他人能复算出相同结果。
分母定义为进入样本的需求数，即同时满足样本范围规则、且起点与终点记录完整的需求条数。分母为零时（如某周无需求上线），该时间窗的周期指标记为“无数据”，不记为0，也不参与趋势线的连接；在报表中保留空值并注明原因。
时间窗切分建议与团队复盘节奏一致：按周统计用于过程观察，按月或季度统计用于趋势与对比。滚动窗口（如最近8周）可以平滑单周波动，但需注明窗口长度，且不与固定周期口径混用。
一个可复算的例子：10条需求的周期分布
以下为演示数据，用于说明计算过程。假设口径为：起点“进入开发”、终点“上线发布”、自然日计时、仅统计产品需求。
| 需求 | 起点日期 | 终点日期 | 周期（天） | 其中阻塞天数 |
|---|---|---|---|---|
| A | 3月1日 | 3月5日 | 4 | 0 |
| B | 3月1日 | 3月8日 | 7 | 1 |
| C | 3月2日 | 3月9日 | 7 | 0 |
| D | 3月3日 | 3月12日 | 9 | 2 |
| E | 3月4日 | 3月14日 | 10 | 0 |
| F | 3月5日 | 3月17日 | 12 | 1 |
| G | 3月6日 | 3月20日 | 14 | 3 |
| H | 3月8日 | 3月25日 | 17 | 2 |
| I | 3月10日 | 4月2日 | 23 | 5 |
| J | 3月12日 | 4月20日 | 39 | 12 |
排序后周期为：4、7、7、9、10、12、14、17、23、39。样本数10，合计142天，平均值14.2天。按排序位置取值：P50为第5、6位的均值，即（10+12）÷2=11天；P85取第9位附近，约23天；P90取第9、10位之间，约27天（若按最近值规则取39天，需在口径中注明规则）。
解读时可以看到：平均值14.2天高于中位数11天，差距主要来自需求J这条39天的长尾；如果只看平均值，会高估典型需求的交付时间。P85约23天说明大多数需求在23天内完成，而J的39天提示存在需要单独分析的长周期需求。
换一种口径：扣除阻塞天数后，各需求净周期为4、6、7、7、10、11、11、15、18、27，合计116天，平均值11.6天，中位数约10.5天。两个口径的差值反映了阻塞对交付的实际影响，适合在复盘时并列呈现，但不应混用在同一趋势线中。
怎么读这些数字：解读边界与常见误用
周期缩短本身只说明时间变短，不直接等于效率提升。需求规模变小、范围被裁剪、质量要求放松，都可能让周期下降；解读时应结合需求规模、缺陷率、返工情况一起看，避免把单指标当作改进成效的全部证据。
跨团队比较前，先确认三件事：口径版本一致、需求类型构成接近、统计时间窗相同。若一方包含大量小需求、另一方以大型需求为主，分位数差异很可能来自需求结构，此时应分类型对比，或补充需求规模分布。
分位数在样本量过小时不稳定。样本只有三五条时，P85、P90实际上接近最大值，波动很大；建议样本量达到一定规模（如单窗口不少于20条）再使用高分位数，样本不足时以中位数和明细列表为主，并注明样本量。
口径变更需要版本化。调整起止点、计时方式或排除规则后，历史数据不能直接与新数据拼接成一条趋势线；应在新版本生效处标注断点，或按新旧口径分别呈现。常见误用还包括：把未完成需求计入分母、把分母为零的周期记为0、用平均值单独对外汇报、把周期数字直接用于个人绩效排名。这些做法都会削弱指标的可解释性。
把口径落到协作流程里：状态定义与记录责任
口径要稳定执行，依赖三件管理动作：状态定义统一、流转记录完整、口径文档留痕。状态定义与流转规则应在工具中统一配置，使起点和终点对应的工作项状态变更被系统自动记录时间戳，减少人工补录带来的偏差。ONES 的工作项支持自定义状态与流转规则，状态变更会留下记录，可作为周期计算的时间来源；具体配置方式以团队实际使用的版本为准。
口径说明、字段表、排除规则与版本变更记录，适合放在团队文档中集中维护，评审后留痕。ONES 文档可用于承载这类口径说明与评审记录，使口径变更与生效时间可追溯，便于新成员按同一份说明复算。
落地时明确责任分工：由效能或项目管理角色负责口径评审与版本发布，由各团队负责人确认状态定义与本团队实际流程一致，由数据维护人定期核对样本与排除规则，检查缺失记录与异常需求的处理是否符合口径。每季度或口径变更时做一次核对，把核对结果记入文档，保证下一周期的数据仍可复算、可比较。
常见问题
需求在统计周期内未完成，应该计入分母还是直接剔除？
常规做法是只把已到达终点、且起点与终点记录完整的需求计入分母，未完成需求不进入本期样本。这样每个周期数字都对应一批已交付需求，含义清晰、可复算。
如果团队关心在途需求的积压情况，可以另设一个指标单独呈现，例如统计期末仍处于开发中的需求数量与已停留天数，与交付周期并列展示。两类数字分开统计，避免把“还没交付”混进“交付用了多久”的计算里。
扣除阻塞与等待后的净时长，和自然日口径能放在同一张趋势图里吗？
不建议放在同一条趋势线上。两种口径的计时基础不同，混在一起会让曲线出现无法解释的跳变，读者也难以判断变化来自流程改善还是口径切换。
可行的做法是并列呈现：主图用自然日口径反映用户实际等待，辅图用扣除阻塞的净时长反映流程内耗时，两图使用同一时间窗与同一批样本。若某期阻塞记录缺失较多，净时长口径应标注数据完整度，或该期暂不输出。
样本量只有几条时，P85、P90还能用吗？
样本量很小时，高分位数接近样本最大值，一次波动就会带来大幅变化，参考价值有限。此时以中位数和需求明细列表为主，并在报表中注明样本量。
等单窗口样本积累到一定规模（例如不少于20条）再启用P85、P90，并保持分位数取值规则不变，保证前后可复算。跨窗口比较时，同时看样本量是否接近，样本量差异过大时先说明再解读。
两个团队的状态名称一样，周期数字仍差很多，先查什么？
先核对同名状态的实际含义。常见差异是“开发中”在一个团队指编码开始，在另一个团队指方案评审通过；起点含义不同，周期自然不可比。
接着核对需求类型构成与统计时间窗：一方以小需求为主、另一方以大型需求为主时，分位数差异可能来自需求结构。可以按需求类型分组对比，或补充需求规模分布，再判断差异是否反映交付能力。
口径调整后，历史数据怎么处理才不影响趋势判断？
把口径变更当作版本切换处理：记录变更内容、生效时间与原因，给新口径一个版本号。趋势图上在新版本生效处标注断点，断点前后分段解读，不把新旧数据连成一条连续曲线。
如果确需长周期对比，可以按新口径回溯重算历史数据，并注明为重算结果；无法重算的部分保留原口径呈现。两种方式都要求口径说明与计算规则同步更新，便于他人复算。
