统计需求池积压规模，先固定统计口径：以“未进入开发且仍处于待评估或已接受状态的需求条目数”为分子，以统计时点全部在池需求为分母，按周或按月取快照，得到积压总量与积压率。老旧条目则用“统计日期减去条目最近一次有效状态变更日期”得到条目年龄，按30/60/90天分档计数，并计算老化率。两项指标都要固定时间窗、状态集合和排除规则，并保留分母为零时的处理方式。ONES Project 的需求池与自定义状态、属性能力，可以作为承载这些状态与时间字段的基础。
要点总览（TL;DR）
- 积压规模按“统计时点仍在池、状态为待评估或已接受、未进入开发”的条目计数，单位是条；积压率用该数除以在池条目总数。
- 条目年龄从最近一次有效状态变更日期起算，按30/60/90天分档；老化率用超过阈值的条目数除以在池条目总数。
- 统计前固定三件事：状态集合、周或月快照时点、排除规则（已关闭、已合并、已进入迭代），口径变更记录生效日期。
- 状态变更时间缺失时用创建时间兜底并标记；分母为零时输出“无在池条目”，不写0%。
- 指标用于触发清理和观察趋势，阈值由团队自设，不设通用达标线，也不作为个人绩效依据。
评估目标：判断需求池是否需要治理
这套统计要回答两个管理问题：池子里压了多少需求，以及这些需求压了多久。积压规模回答“压了多少”，反映当前待处理需求的绝对数量；条目老化回答“压了多久”，反映需求在池中停留的时间长度。两者结合，才能判断需求池是处于正常流转状态，还是已经出现清理滞后。
指标的直接用途是触发清理动作。当积压规模持续上升、老化率超过团队自设阈值时，说明需要安排一次需求池梳理：合并重复条目、关闭失效需求、把成熟需求推进到排期。指标服务于集合维护，不用于评价个人工作量或产出。需求池条目多，可能来自业务反馈活跃，也可能来自收集渠道过宽，需要结合分类和来源进一步看。
这套统计与迭代管理、价值评分保持边界。迭代管理关注已排期需求的容量与进度，统计对象是进入迭代后的工作项；价值评分关注单条需求的优先级判断。本文的指标只描述需求集合的规模与停留时间，不替代优先级排序，也不判断某条需求是否值得做。把三者混在一起，容易让积压数字承担它无法承担的结论。
指标与范围：积压规模、积压率、条目年龄与老化率
四个核心指标需要统一公式、分子分母和单位，否则不同周期的数字无法比较。下表给出定义，统计范围统一为“统计时点仍处于在池状态的需求条目”。
| 指标 | 公式 | 分子 | 分母 | 单位 | 时间窗 |
|---|---|---|---|---|---|
| 积压规模 | 统计时点在池未开发条目数 | 状态为待评估或已接受、且未进入开发的条目数 | 无 | 条 | 周或月快照 |
| 积压率 | 在池未开发条目数 ÷ 在池条目总数 × 100% | 在池未开发条目数 | 在池条目总数 | % | 周或月快照 |
| 条目年龄 | 统计日期 − 最近一次有效状态变更日期 | 无 | 无 | 天 | 逐条计算 |
| 老化率 | 年龄超过阈值的条目数 ÷ 在池条目总数 × 100% | 年龄超过阈值的在池条目数 | 在池条目总数 | % | 周或月快照 |
纳入状态集合需要事先写清楚。常见做法是把“待评估”“已接受”“已规划但未排期”计入在池，把“已关闭”“已合并”“已进入迭代”“已上线”排除。排除规则同样要固定：已关闭和已合并的条目不再占用清理资源；已进入迭代的条目归迭代管理统计，不重复计入积压。状态名称各团队不同，统计前应把工具中的实际状态映射到这套集合，并记录映射关系。
条目年龄的起点是“最近一次有效状态变更日期”，而非创建日期。需求从待评估推进到已接受，年龄应重新起算，因为这次变更代表需求被重新确认过。若用创建时间计算，会把已经推进过的需求误判为老旧。阈值建议从30天、60天、90天三档起步，具体取值结合团队评审节奏设定，不设通用达标线。
数据口径与证据：字段、时间窗和缺失值处理
统计前需要从需求管理工具取以下字段：条目ID、当前状态、创建时间、最近状态变更时间、所属分类、关联需求。条目ID用于去重和逐条核对；当前状态用于筛选在池集合；创建时间和最近状态变更时间用于计算年龄；所属分类用于拆分积压集中区域；关联需求用于识别可能重复或合并的条目。ONES Project 支持自定义需求状态与多种属性，并可通过筛选器按多重条件定位条目，这些字段可以在需求池中维护并用于取数。
快照时点要固定。按周统计，可取每周固定一天（如周五）的日终数据；按月统计，可取每月最后一个工作日。快照时点一旦确定，后续周期沿用同一规则，避免因取数日不同造成数字波动。统计周期与快照时点应写入统计说明，供后续复算。
缺失值按以下规则处理：最近状态变更时间缺失时，以创建时间兜底计算年龄，并在结果中标记“时间兜底”，提示该条目年龄可能偏高；创建时间也缺失的条目单独列出，不纳入年龄分档，但计入在池总数。分母为零时，输出“无在池条目”，不输出0%，因为0%会被误读为积压健康。口径发生变更时，记录变更内容和生效日期，新旧口径的数字不直接比较。
计算步骤：从取数到出数的五步流程
按以下顺序执行，可以得到一组可复算的结果。每一步的产物都应保留，便于核对和下一周期对比。
- 确定快照日期与统计周期。写明本次统计的截止日期、周期类型（周或月）和取数范围（全部需求池或指定分类）。产物：统计说明一行，含日期与范围。
- 按状态集合筛出在池条目。用工具筛选器按当前状态筛选，排除已关闭、已合并、已进入迭代的条目。产物：在池条目清单，含条目ID和当前状态。
- 计算积压规模与积压率。从在池清单中筛出状态为待评估或已接受的条目，计数得到积压规模；用该数除以在池条目总数，乘以100%得到积压率。产物：两个数字及对应分母。
- 计算每条目年龄并分档计数。对每条在池条目，用快照日期减去最近状态变更日期（缺失时用创建时间并标记），得到年龄天数；按30天以内、31至60天、61至90天、90天以上分档计数。产物：年龄分档表。
- 计算老化率并按分类拆分。用超过阈值（如90天）的条目数除以在池条目总数，得到老化率；再按所属分类重复第3、4步，定位积压集中的分类。产物：老化率及分类拆分表。
五步完成后，把积压规模、积压率、年龄分档、老化率和分类拆分放在同一张结果表中，附上统计说明。下一周期用相同步骤复算，即可观察趋势。ONES Project 的报表支持自定义数据范围和维度，可以把状态、分类等字段组织成周期性视图，减少每次手工取数的重复动作；具体指标是否内置，需按实际配置确认。
例子：一次月度统计的完整算例
以下为演示情景，数字为虚构，仅用于说明公式代入过程。某团队在月末对产品需求池做一次统计，在池条目总数为120条，其中状态为待评估或已接受、未进入开发的条目为78条。年龄分档结果为：30天以内42条，31至60天25条，61至90天18条，90天以上35条。另有3条最近状态变更时间缺失，已用创建时间兜底并标记。
| 指标 | 计算过程 | 结果 |
|---|---|---|
| 积压规模 | 待评估与已接受条目计数 | 78条 |
| 积压率 | 78 ÷ 120 × 100% | 65.0% |
| 老化率（90天阈值） | 35 ÷ 120 × 100% | 29.2% |
| 时间兜底条目 | 缺失状态变更时间、以创建时间计算 | 3条，已标记 |
按分类拆分后，发现“客户端体验”分类在池46条，其中90天以上19条，老化率约41.3%；“后台能力”分类在池38条，90天以上9条，老化率约23.7%；其余分类合计在池36条，90天以上7条。积压集中在客户端体验分类，且该分类老化率明显高于整体，说明清理动作应优先覆盖这一区域。若某分类在池条目为零，该分类的老化率输出“无在池条目”，不参与横向比较。
这个算例同时展示了两个处理规则：3条时间兜底条目计入在池总数和年龄分档，但在结果中单独标记，提醒读者其年龄可能偏高；分类拆分时遇到零分母，输出文字说明而非百分比。实际统计中，还应核对关联需求字段，识别可能重复的条目，避免积压规模被重复计数抬高。
解读与限制：指标能说明什么、不能说明什么
解读这套指标，先看趋势，再看结构。连续几个周期积压规模上升、老化率同步上升，说明新增需求的速度快于清理速度，需要启动梳理；积压规模稳定但老化率上升，说明池子在“沉淀”，旧条目没有被处理。结构上看分类拆分，积压集中在少数分类时，清理范围可以收窄；分散在多个分类时，可能需要检查需求收集入口和评审机制。阈值由团队根据评审节奏设定，30/60/90天是常见起点，不构成通用达标线。
指标有明确的解释边界。积压多不等于需求质量差，业务反馈活跃、收集渠道多都会推高在池数量，需要结合分类和来源判断。老化率高提示两种可能：状态更新滞后，条目实际已处理但状态未改；或者清理机制缺失，条目长期无人推进。两种情况的管理动作不同，前者要补状态维护习惯，后者要建立定期清理节奏。指标也不能证明清理动作带来了交付改善，交付结果受排期、容量、需求质量等多因素影响，统计只能说明集合状态的变化。
把统计做成可持续的动作，需要在工具中固定字段和视图。ONES 敏捷研发管理方案中，可用工单收集反馈并转化为需求、整理产品 Backlog，并自定义工作流；ONES 可自动记录工作项滞留时间等过程数据。团队可以把状态集合、分类字段和快照周期固化到需求池视图与报表中，让每个周期的积压规模、年龄分档和老化率按同一口径出数，减少手工整理，把精力放在清理动作本身。
常见问题
需求在池期间状态改过多次，条目年龄应该从哪一次变更算起？
以最近一次有效状态变更为起点。所谓“有效”，指这次变更代表需求被重新确认或推进，例如从待评估变为已接受、从已接受变为已规划。纯粹的文字修改、补充附件、调整标签这类不改变处理阶段的编辑，通常不计入年龄起点，否则每次编辑都会让条目“变年轻”，老化率被系统性压低。
实操上需要先把工具中的状态列表映射到“有效状态变更”集合，并在统计说明里写清楚哪些状态迁移会重置年龄。映射关系一旦确定，各周期沿用同一套，避免同一批条目在不同月份被算出不同年龄。
积压率连续几个月都在上升，是不是应该马上安排一次大规模清理？
先看结构再决定动作。积压率上升可能来自新增需求变多，也可能来自清理速度下降，两者的处理方式不同。建议同时看年龄分档和分类拆分：如果上升集中在少数分类，清理范围可以收窄到这些分类；如果各分类同步上升，更可能是收集入口过宽或评审节奏跟不上，需要先调整入口和评审频率，再谈集中清理。
另外要确认统计口径没有变化。状态集合调整、快照日期改动、排除规则变化都会让数字跳变，跨周期比较前先核对统计说明。口径一致的前提下，连续两到三个周期同向上升，再启动梳理动作，判断会更稳。
团队刚建需求池，条目很少，这套指标还有必要统计吗？
条目少的时候，积压率和老化率的数值波动大，单看百分比意义有限，但统计动作本身值得保留。早期就把状态集合、快照时点和字段维护习惯固定下来，等条目规模上来后，历史数据可以直接比较，不需要回头补口径。
条目很少时，建议以绝对数和逐条清单为主：列出在池条目、各自年龄和当前状态，比计算比率更直观。分母为零或极小时，按规则输出“无在池条目”或注明样本量小，不强行给出百分比结论。
状态更新滞后导致老化率虚高，怎么在统计里区分出来？
可以在统计时增加一个核对动作：对年龄超过阈值的条目抽样回看，确认其实际处理进度与系统状态是否一致。如果条目实际已排期或已处理，只是状态没改，就归为“状态滞后”；如果确实长期无人推进，归为“真实积压”。两类条目数量分开记录，老化率的解读就有了依据。
长期看，减少状态滞后要靠流程习惯：明确谁负责在什么节点更新状态，把状态维护纳入需求评审的固定动作。ONES 可自动记录工作项滞留时间等过程数据，可作为状态维护的辅助参考，具体统计起点与状态范围需按实际配置确认。
按分类拆分后发现某个分类积压特别多，是不是这个分类的需求质量最差？
不能直接这样推断。某个分类积压多，可能因为它是主要业务方向、反馈来源集中，也可能因为该分类的需求评审标准更宽。积压规模反映的是集合状态，不直接等于需求质量。要判断质量，需要结合需求的来源、价值评分结果和后续排期情况一起看。
分类拆分的直接用途是定位清理范围：积压集中的分类优先安排梳理，逐条判断合并、关闭还是推进排期。价值判断属于需求优先级评估的范畴，和本文的规模与老化统计分开进行，避免用一个数字承担它说明不了的结论。
