评估需求池维护效果，需要把“池子是否被管住”拆成可复算的指标：积压量看规模，停留时长看等待，状态更新及时性看维护动作是否按时发生，重复关联率看重复需求是否被识别归并，清理周期看清理是否按节奏执行。五个指标都要先固定统计对象、时间窗、分子分母和缺失值处理，再结合趋势与分布解读。下文给出定义、口径、计算步骤和一组演示数据。
要点总览（TL;DR）
- 评估对象是需求池维护机制：积压量看规模是否受控，停留时长看等待是否拉长，状态更新及时性看维护动作是否按时发生，重复关联率看重复需求是否被识别归并，清理周期看清理是否按节奏执行。
- 五个指标都要先固定统计对象、时间窗、分子分母和缺失值处理：及时性以应更新条数为分母，重复关联率以期内入池条数为分母，缺关键时间的需求单列、不默认计入分母。
- 计算后要结合趋势与分布解读：积压量需与入池量一起看，停留时长看中位数与长尾差距，及时性高仍需抽样核对状态准确性，重复关联率低需排查识别不足。
- 指标用于发现维护问题、调整规则与分工，不能直接证明需求质量或团队绩效；分母为零时比例记为不适用，避免失真。
评估目标：判断需求池维护机制是否在运转
这项评估的对象是需求池的维护机制，包括需求入池后是否被及时分类、状态是否被如实更新、重复需求是否被识别归并、过期或无效需求是否被定期清理。它回答的问题是：维护动作有没有按约定发生，池子规模与等待时间是否处于可控范围。需求本身值不值得做、优先级排第几，属于优先级评估的范畴，不在本文指标之内。
把“维护效果”转成可观察的结果，可以落在五个判断维度上：规模受控，即待处理需求条数没有持续单向增长；等待可控，即需求在池中停留的时间没有明显拉长；状态可信，即状态字段能反映需求的真实处理阶段；重复被归并，即重复或高度相似的需求被标记并关联到已有需求；清理有节奏，即清理动作按固定周期发生并覆盖到应清理的范围。
评估结论的用途是调整维护规则，例如调整入池标准、状态更新频率、清理责任人和清理节奏。它不用于给单个需求定优先级，也不直接作为团队绩效结论。明确这一点，可以避免把“池子变小”误读为“需求质量变好”。
指标与范围：五个指标各自统计什么
五个指标分别对应维护机制的不同侧面，定义时需要同时写清统计对象、状态口径、时间窗和单位，否则不同周期的数据无法比较。
| 指标 | 统计对象 | 状态口径 | 时间窗 | 单位 |
|---|---|---|---|---|
| 积压量 | 统计时点处于待评估、待处理状态的需求 | 以统计时点的状态快照为准 | 时点值，按周或按月取 | 条 |
| 停留时长 | 需求从入池到离开当前状态或离开池子的时间 | 按状态分段统计，未离开的按截至统计日计算 | 按周或按月归集 | 天 |
| 状态更新及时性 | 期内应更新状态的需求 | 按约定更新周期判断是否按时 | 周或月 | 百分比 |
| 重复关联率 | 期内入池且被标记重复或关联到已有需求的需求 | 以重复标记或关联关系为准 | 周或月 | 百分比 |
| 清理周期 | 两次清理动作之间的间隔及清理覆盖情况 | 以清理记录中的动作时间和处理条数为准 | 按清理批次统计 | 天、条 |
范围边界需要提前写明。Sprint Backlog 的维护与迭代排期归迭代管理，不计入需求池积压量；需求价值评分与优先级排序归优先级评估，不作为本组指标的评价对象。把边界写进口径说明，可以防止统计时把已进入迭代的需求重复计入池子，导致积压量虚高。
数据口径与证据：字段、分母和缺失值怎么定
指标可复算的前提是字段齐全、分母明确、缺失值有统一处理规则。建议在取数前先列一张字段清单：入池时间、每次状态变更时间、关闭或转出时间、重复标记或关联关系、清理记录（清理时间、处理条数、处理原因）。字段缺失时，先确认能否从操作日志补齐，补不齐的按缺失值规则处理。
分母选择直接决定比例类指标的含义。状态更新及时性用“期内应更新条数”作分母，只统计按规则需要更新状态的需求，避免把刚入池、尚不需要更新的需求算进分母拉低比例。重复关联率用“期内入池条数”作分母，反映新进需求中被识别为重复或关联到已有需求的比例。两个分母不同，不能互相替代。
时间窗按周或按月固定，同一份评估内不混用。跨窗口的需求，例如上月末入池、本月末仍未处理，单独标注为跨窗口需求，停留时长按实际天数计算并在结果中单列，不并入任一窗口的均值。缺失入池时间或关键状态时间的需求，单列为一组，不默认计入分母，也不默认按零处理。
证据留存方面，每次评估保留取数快照、口径说明和计算过程，记录取数日期、数据范围和排除项。这样下一次评估可以按同一口径复算，出现异常时也能回溯是数据问题还是维护问题。
在工具层面，需求池的状态流转、状态变更时间和清理记录需要有稳定的沉淀位置。ONES Project 支持建立需求池、规划迭代，并可编写需求、自定义需求状态与多种属性；ONES 在敏捷研发场景中支持用工单收集反馈、转化为需求并整理产品 Backlog，也可自定义工作流规范需求流转。这些能力为记录入池时间、状态变更和流转过程提供了承载。需要说明的是，现有资料说明 ONES Project 提供多种报表并支持自定义数据范围和维度，但是否内置积压量、停留时长等专用指标，需按实际版本核验；评估时可以先通过任务筛选器按状态、时间等条件定位工作项，再导出明细自行计算。
计算与评估步骤：从取数到形成判断
一次完整评估按以下顺序执行，每步都留下可复核的记录。
- 确定统计时点和时间窗，导出需求池明细。明细至少包含需求编号、入池时间、当前状态、各次状态变更时间、关闭或转出时间、重复标记、清理批次。时点值取统计日当天的状态快照。
- 按公式计算五个指标，逐项记录分子和分母。积压量＝统计时点待评估与待处理状态的需求条数；停留时长＝离开时间减入池时间（未离开的用统计日减入池时间），分别计算中位数和长尾分位；状态更新及时性＝按时更新条数÷应更新条数；重复关联率＝被标记重复或关联条数÷期内入池条数；清理周期＝相邻两次清理动作的时间间隔，并记录每次清理覆盖的条数。
- 对比前后两个周期的趋势，同时看分布。积压量看连续几个时点的走向，停留时长看中位数与长尾的差距，比例类指标看分子分母各自的变化，避免只看一个汇总数字。
- 对异常值抽样核查。积压量突增时，抽查新增需求来自哪些来源；停留时长异常长的需求，核对状态是否长期未更新；及时性偏低时，确认是维护动作缺失还是应更新范围定义过宽。区分维护问题和数据问题，再决定是否调整规则。
- 形成结论并对应到维护规则调整。例如积压量持续上升且入池量稳定，说明清理或评估环节跟不上，需要调整清理节奏或评估排期；及时性偏低且集中在某类需求，说明该类需求的状态更新责任需要明确。
分母为零的情况要单独处理：某月没有应更新需求时，及时性记为“不适用”，不记为零或百分之百；某月入池为零时，重复关联率同样记为不适用。这样处理可以避免比例失真。
示例：一个月的需求池维护评估怎么算
以下为一组演示情景的假设数据，用于说明计算过程，不代表真实客户数据。
假设某月入池120条需求，月末处于待评估或待处理状态的积压量为45条。上月同期积压量为38条，入池量为105条，两个月入池量接近，积压量上升，说明清理速度没有跟上入池速度，需要结合清理周期进一步看。
停留时长方面，当月离开池子或离开待处理状态的需求，停留时间中位数为9天，但存在一批超过30天的长尾需求。中位数说明多数需求等待时间尚可，长尾说明少数需求长期滞留，需要抽查这些需求的状态是否长期未更新。
状态更新及时性：期内应更新状态的需求80条，其中按时更新64条，及时性＝64÷80＝80%。剩余16条中，部分可能属于责任人变更后未交接，需要抽样确认。
重复关联率：期内入池120条，其中被标记为重复或关联到已有需求的12条，重复关联率＝12÷120＝10%。这个比例需要结合历史数据看，若长期偏低且抽查发现明显重复未被标记，说明识别环节需要加强。
清理周期：当月发生清理动作2次，间隔约15天，每次清理覆盖的条数需要与积压结构对照。若清理后待评估需求明显减少、长期滞留需求被处理，说明清理有效；若清理后积压量很快回到原水平，说明清理只处理了表面，入池标准或评估节奏需要调整。
综合五项结果：积压量上升、及时性80%、重复关联率10%、清理周期稳定但清理后积压回升，可以判断维护机制在运转但清理效果有限，优先调整清理范围和评估排期，而不是简单增加清理次数。
解读与限制：指标能说明什么、不能说明什么
积压量下降可能来自清理加快，也可能来自入池减少，解读时必须和入池量一起看。只看积压量一条曲线，无法区分“池子被管住了”和“新需求进不来”。
停留时长受需求类型和评估节奏影响。复杂需求本来就需要更长的评估时间，简单需求长期滞留则更可能是维护问题。因此不宜给所有需求设统一的停留时长达标线，可以按需求类型分组看分布。
及时性高不代表状态准确。状态按时更新，但更新内容与实际处理阶段不一致时，及时性指标仍然好看。需要定期抽样核对状态与实际进展是否一致，把抽样结果作为及时性指标的补充证据。
重复关联率低有两种可能：重复需求确实少，或者识别不足。判断时需要抽查一批新入池需求，看是否存在明显重复但未被标记的情况。清理周期稳定也不等于清理有效，还要看清理后池子的结构变化，例如长期滞留需求是否减少、待评估需求是否被及时处理。
这五个指标用于发现维护机制中的问题，帮助调整规则和分工，不能直接证明需求质量高低，也不能单独作为团队绩效结论。把它们作为一组组合指标，结合趋势、分布和抽样核查，才能形成对需求池维护效果的可信判断。
常见问题
需求池积压量下降，是否就说明维护机制变好了？
不能直接这样判断。积压量下降可能来自清理加快，也可能来自入池需求减少。评估时应把积压量与期内入池量放在一起看：入池量稳定而积压量下降，更可能是清理和评估环节在起作用；入池量同步大幅下降时，积压量下降可能只是需求来源变少。建议连续观察几个统计时点的走向，并抽查积压减少的具体去向，是关闭、转出还是进入迭代。
停留时长要不要设一个统一的达标线？
不建议对所有需求设统一达标线。停留时长受需求类型和评估节奏影响，复杂需求本来就需要更长的评估时间，简单需求长期滞留则更可能是维护问题。更稳妥的做法是按需求类型分组，分别看中位数和长尾分布，把明显超出同类需求常规范围的长尾需求挑出来核查状态是否长期未更新，再决定是否调整评估排期。
状态更新及时性达到较高比例，还需要做别的核查吗？
需要。及时性只反映状态是否按约定周期更新，不反映更新内容是否与实际处理阶段一致。状态按时更新但内容失真的情况下，及时性指标仍然好看。建议定期抽样核对状态字段与实际进展，把抽样结果作为及时性指标的补充证据；若抽样发现偏差集中在某类需求或某个环节，再针对性明确状态更新责任和判断标准。
重复关联率偏低时，应该先怀疑识别不足还是重复确实少？
两种可能都存在，需要抽查来区分。可以抽取一批新入池需求，人工比对是否存在明显重复但未被标记的情况：若抽查中重复未被识别的情况较多，说明识别环节需要加强，例如在入池环节增加查重步骤或明确关联规则；若抽查中确实很少重复，则比例偏低属于正常结果。单看比例数字无法区分这两种情况。
在 ONES 中落地这套评估，需要提前确认哪些能力？
ONES Project 支持建立需求池、规划迭代，可编写需求并自定义需求状态与多种属性；ONES 在敏捷研发场景中支持用工单收集反馈、转化为需求并整理产品 Backlog，也可自定义工作流规范需求流转。评估还需要入池时间、状态变更时间、重复标记和清理记录等字段，以及按状态、时间筛选并导出明细的能力。ONES Project 提供多种报表并支持自定义数据范围和维度，也支持任务筛选器按多重条件定位工作项，但是否内置积压量、停留时长等专用指标，需按实际版本核验；若没有现成指标，可先导出明细自行计算。
