需求池条目持续增多、清理优先级又说不清时，健康度评估要回答两个问题：这个池子现在要不要治理，先清哪一批。做法是用积压规模、条目老化、状态准确性、重复关联、分类覆盖五个维度各算一组指标，每个指标写清分子、分母、时间窗和缺失值处理，再合成一个分档结论，并据此排出优先清理清单。
要点总览（TL;DR）
- 需求池健康度用五个维度判断：积压规模、条目老化、状态准确性、重复关联、分类覆盖；前两个直接支撑清理决策，后三个决定池子是否可维护。
- 每个指标都要写清分子、分母、时间窗和缺失值处理，分母为零时记为“不适用”而非0，关键字段缺失的条目计入分母、不计入分子。
- 分档阈值应基于团队自身历史基线设定，先连续跑两到三个周期形成基线，再定健康、需关注、需治理三档，外部通用达标线缺乏可比性。
- 结论要落到条目：输出分档判断加优先清理清单，排序依次看停留是否超阈值、状态是否异常、字段是否缺失、是否存在疑似重复。
- 指标反映池子运行状态，不替代需求价值评分，也不宜作为个人绩效依据；数据质量不足时先只算积压规模与条目老化两个维度。
评估目标：先回答需求池要不要治理
健康度评估的对象是需求池整体和池内条目的分层情况，统计范围限定在尚未进入迭代、仍处于待评估或待排期状态的条目。已经排入Sprint Backlog的内容属于迭代容量与排期问题，不纳入本次评估。把边界划清，指标才有稳定的分母，不同周期的结果也才能相互比较。
评估的结论形式是“分档判断加优先清理清单”。分档判断回答池子整体处于健康、需关注还是需治理的状态；优先清理清单则给出具体条目和清理动作建议，例如关闭、合并、补充信息或重新评估。只给一个分数而不落到条目，评估就无法转化为清理动作。
评估周期建议按月或按双周执行一次，与需求评审节奏对齐。出现以下情况时应临时触发：单月新增条目数明显高于此前几个周期的平均水平；池内超过既定停留阈值的条目占比连续上升；团队反映评审会上无法快速判断先讨论哪条需求。触发式评估只跑积压规模与条目老化两个维度即可，用于快速判断是否需要启动完整评估。
指标与范围：五个维度各自量什么
五个维度分别对应池子的规模压力、时间压力和数据可维护性。积压规模看池子有多大、流入流出是否失衡；条目老化看条目在池内停留多久；状态准确性看状态字段是否反映真实进展；重复关联看条目之间是否存在重复或缺失关联；分类覆盖看分类、责任人等字段是否填全。前两个维度直接支撑清理决策，后三个维度决定池子是否可维护、指标是否可信。
| 维度 | 指标 | 单位 | 统计对象 |
|---|---|---|---|
| 积压规模 | 池内存量条目数 | 条 | 统计截止日仍处于待评估、待排期状态的条目 |
| 积压规模 | 流入流出比 | 比值（无量纲） | 统计周期内新增条目数与关闭、合并、转入迭代条目数之比 |
| 条目老化 | 停留时长中位数 | 天 | 池内全部条目的创建至统计截止日时长 |
| 条目老化 | 超阈值条目占比 | 百分比 | 停留时长超过团队设定阈值的条目 |
| 状态准确性 | 状态异常条目占比 | 百分比 | 状态为进行中或待评审、但最近活动时间超过设定天数的条目 |
| 重复关联 | 重复与关联覆盖率 | 百分比 | 已标记重复、已建立父子或关联关系的条目占池内条目比例 |
| 分类覆盖 | 关键字段完整率 | 百分比 | 分类、责任人、来源等关键字段均已填写的条目占比 |
纳入统计的条目应满足：位于需求池所在项目或空间、状态属于池内状态集合、未被标记为已删除。排除项包括已转入迭代的条目、明确标记为废弃且已归档的条目、以及测试或演示用途的占位条目。排除规则要在评估说明中固定下来，中途变更会导致前后周期不可比。
数据口径：分子分母、时间窗与缺失值
口径的作用是让任何人拿到同一份数据都能算出同一个数。每个指标都要写明分子、分母、时间窗和取数来源，下面逐项给出。
| 指标 | 分子 | 分母 | 时间窗 |
|---|---|---|---|
| 池内存量条目数 | 统计截止日处于池内状态的条目数 | 无（计数指标） | 统计截止日时点 |
| 流入流出比 | 周期内新增条目数 | 周期内关闭、合并、转入迭代的条目数 | 最近一个完整统计周期，建议30天 |
| 停留时长中位数 | 按停留天数排序后的中间值 | 池内条目总数 | 创建日至统计截止日 |
| 超阈值条目占比 | 停留时长超过阈值的条目数 | 池内条目总数 | 创建日至统计截止日 |
| 状态异常条目占比 | 状态为进行中或待评审且最近活动时间超过设定天数的条目数 | 状态为进行中或待评审的条目总数 | 最近活动时间取最近一次状态变更或字段修改时间，观察窗建议14天 |
| 重复与关联覆盖率 | 已标记重复或已建立关联关系的条目数 | 池内条目总数 | 统计截止日时点 |
| 关键字段完整率 | 分类、责任人、来源字段均非空的条目数 | 池内条目总数 | 统计截止日时点 |
状态字段以需求工作项当前状态为准，最近活动时间取状态变更记录或字段修改记录中的最新时间。如果系统只保留创建时间和更新时间，可用更新时间作为代理，但要在评估说明中注明代理口径，且不同周期保持一致。
异常处理规则需要提前约定。分母为零时，比值类指标记为“不适用”，不记为0，避免把“没有数据”误读为“表现良好”。关键字段缺失的条目在计算分类覆盖时计入分母、不计入分子，不做剔除，否则会高估完整率。跨团队比较时，各团队应使用相同的状态集合、相同的停留阈值和相同的时间窗；条件不一致时只做各自纵向对比，不横向排名。
计算步骤：从取数到分档结论
完整评估按六步执行，每步都有明确产物，便于复核。
- 取数：导出池内条目清单，字段至少包含条目编号、当前状态、创建时间、最近活动时间、分类、责任人、来源、关联关系标记。产物为原始数据表。
- 清洗：按纳入与排除规则过滤条目，统一状态名称，处理空值与重复记录。产物为清洗后条目表，并记录剔除条数。
- 逐项计算：按上一节口径计算七个指标，每个指标保留计算过程与中间计数。产物为指标计算表。
- 归一化：把各指标换算为0到100的得分。占比类指标可直接用百分比；流入流出比以1为均衡点，高于1表示流入大于流出，可按偏离程度折算扣分；停留时长中位数按团队阈值折算。归一化公式要写进评估说明，保证下期可复算。
- 合成：五个维度可等权平均，也可按当前治理重点加权，权重之和为100%。合成得分保留一位小数。
- 分档与排序：按得分落入档位，再生成优先清理清单。清单排序建议依次比较：停留时长是否超阈值、状态是否异常、分类字段是否缺失、是否存在疑似重复。前两项靠前的条目优先处理，因为它们同时占用池子容量和评审注意力。
分档阈值应基于团队自身历史基线设定。建议先连续跑两到三个周期，记录各指标的实际分布，再取历史较好水平作为健康档下限、历史较差水平作为需治理档上限，中间为需关注档。没有基线时，可先用相对变化判断：本期得分较上期下降超过一定幅度即视为恶化。外部通用达标线在不同团队之间缺乏可比性，不宜直接套用。
评估流程依赖条目状态、字段和关联关系的完整记录。在ONES Project中，团队可以建立需求池并自定义需求状态与多种属性，用全局筛选和项目内筛选按多重条件定位待清理条目；报表与图表支持自定义数据范围和维度，可用于按周期呈现存量与流入流出变化。若反馈来自工单，ONES工单可将处理后的反馈转化为需求并整理进产品Backlog，使流入数据有统一来源。
算一遍：一个需求池的示例
以下为演示情景，数据为假设值，用于说明计算过程，不代表任何真实团队的表现。
假设某产品团队需求池在统计截止日共有200条待评估、待排期条目。最近30天新增40条，同期关闭12条、合并6条、转入迭代10条。条目停留时长中位数为45天，团队设定的停留阈值为60天，超过阈值的条目有52条。状态为进行中或待评审的条目共80条，其中最近14天无任何活动记录的有28条。已标记重复或已建立关联关系的条目有30条。分类、责任人、来源三项字段均填写的条目有140条。
| 指标 | 计算 | 结果 |
|---|---|---|
| 池内存量条目数 | 直接计数 | 200条 |
| 流入流出比 | 40 ÷（12+6+10） | 约1.43 |
| 停留时长中位数 | 排序取中间值 | 45天 |
| 超阈值条目占比 | 52 ÷ 200 | 26% |
| 状态异常条目占比 | 28 ÷ 80 | 35% |
| 重复与关联覆盖率 | 30 ÷ 200 | 15% |
| 关键字段完整率 | 140 ÷ 200 | 70% |
逐项看：流入流出比1.43说明新增速度明显快于清理速度，池子处于净增长状态；超阈值条目占比26%，约四分之一的条目已停留超过两个月；状态异常占比35%，说明相当一部分条目的状态没有随实际进展更新；关联覆盖率15%偏低，重复需求可能未被识别；字段完整率70%，有三成条目缺少分类或责任人，影响后续分派。
按等权归一化合成，该池子整体落入“需治理”档。优先清理清单的生成顺序为：先列出停留超过60天且状态异常的条目，这批条目既老化又状态失真，应优先确认是否仍然有效；再列出停留超过60天但字段完整的条目，安排评审决定关闭或排期；最后处理字段缺失的条目，补齐分类与责任人后再进入正常评审。示例中若停留超阈值且状态异常的条目有18条，这18条即构成本轮清理的第一批。
示例的口径说明：流入流出比的分母包含关闭、合并、转入迭代三类流出，不含标记废弃但未关闭的条目；状态异常以14天为观察窗，若团队评审节奏为双周，可调整为与评审周期一致；所有占比的分母均为池内条目总数或对应状态条目数，未做剔除。
解读与限制：指标能说明什么、不能说明什么
这组指标反映的是池子的运行状态：积压是否在扩大、条目是否积压过久、状态记录是否可信、条目之间是否建立了必要关联、字段是否足以支撑分派。它回答“池子是否需要治理、先清哪批”，不回答“哪条需求更值得做”。需求价值判断需要单独的价值评分或评审机制，健康度得分高的池子也可能装着大量低价值需求。
单指标不宜作为个人或团队的绩效依据。流入流出比受业务节奏影响，季度初集中提需求会推高比值；状态异常占比可能源于状态流转规则设计不合理，而非执行不到位；关联覆盖率低有时是因为条目本身独立、无需关联。把某一指标单独拿出来考核，容易诱导数据修饰，反而降低数据可信度。
数据质量不足时应降级使用。若状态历史或最近活动时间记录不完整，先只计算积压规模与条目老化两个维度，这两个维度对字段依赖较低；待分类、责任人等字段补齐、状态流转规则稳定后，再纳入状态准确性、重复关联与分类覆盖。降级期间应在评估说明中标注缺失维度，避免把不完整的结论当作完整判断。
评估结果需要与清理动作闭环。每轮评估后记录清理了多少条、关闭与合并各多少、清单中条目的实际处理率，下期评估时对照这些数字，才能判断治理是否见效。指标本身不产生改善，改善来自按清单执行的清理动作和随之调整的准入规则。
常见问题
团队刚开始做健康度评估，没有历史基线，分档阈值怎么定？
没有基线时先不要急着定绝对阈值，可以先用相对变化判断：连续跑两到三个周期，记录各指标的实际分布，本期得分较上期下降超过一定幅度即视为恶化。等积累了几个周期的数据，再取历史较好水平作为健康档下限、历史较差水平作为需治理档上限，中间为需关注档。
停留阈值可以先用团队评审节奏倒推，例如评审周期为双周，停留超过两个评审周期仍未处理的条目就值得关注。阈值一旦确定，在同一评估口径下保持稳定，中途变更会导致前后周期不可比。
状态准确性依赖最近活动时间，但系统记录不完整怎么办？
先确认可用的时间字段。如果系统只保留创建时间和更新时间，可以用更新时间作为最近活动时间的代理，但要在评估说明中注明这是代理口径，且各周期保持一致，避免口径漂移导致结果不可比。
若连更新时间也缺失严重，建议降级使用：先只计算积压规模与条目老化两个维度，这两个维度对字段依赖较低；待状态流转规则稳定、活动记录补齐后，再把状态准确性纳入评估，并在评估说明中标注缺失维度。
流入流出比的分母应该包含哪些流出方式？
分母应覆盖条目离开池子的主要路径，通常包括关闭、合并、转入迭代三类。标记废弃但未关闭的条目是否计入，需要团队提前约定并固定下来；如果计入，要在评估说明中写明，否则同一份数据不同人算出的比值会不一致。
分母为零时，比值记为“不适用”，不记为0。把“本期没有流出”误读为“表现良好”，会掩盖池子只进不出的真实状态。
多个团队的需求池能不能直接横向排名？
横向比较的前提是口径一致：相同的状态集合、相同的停留阈值、相同的时间窗。条件不一致时，建议只做各团队自身的纵向对比，观察趋势变化，不做跨团队排名。
即使口径统一，业务节奏差异也会影响结果，例如季度初集中提需求的团队流入流出比天然偏高。排名容易诱导数据修饰，用分档结论推动各自治理更稳妥。
评估做完之后，怎么判断治理是否真的见效？
每轮评估后记录清理动作的实际结果：清理了多少条、关闭与合并各多少、优先清理清单中条目的实际处理率。下期评估时对照这些数字，看存量是否下降、超阈值条目占比是否回落、状态异常占比是否改善。
指标本身不产生改善，改善来自按清单执行的清理动作，以及随之调整的准入规则。如果连续几期存量仍在净增长，需要回头检查新增条目的准入标准，而不只是加大清理力度。
