需求池清理要先把判定规则定下来，再按固定节奏逐条处置存量需求：保留、合并、挂起或关闭，每条都写明理由和责任人，并通知提出方。清理的价值在于让需求池长期保持可决策状态，因此规则、角色和复查节奏需要一起固定，避免变成一次性的集中删改。
要点总览（TL;DR）
- 先由产品负责人批准一份准入与保留标准，明确保留、挂起、合并、关闭四类结论的判定条件和状态字段含义，作为本轮清理的唯一依据。
- 单轮清理按盘点、分组、逐条判定、合并重复、处置通知五步推进，每条需求都要留下结论、理由和判定人。
- 拍板权归产品负责人，需求管理人员负责组织盘点与记录，提出方补充信息并确认结论，研发或设计提供可行性与重复性判断。
- 清理节奏按需求流入速度和池子规模选择：两周一次小范围清理、按月清理或按季度全量复查，并用池子总量、超期未判定占比、重复率等指标观察效果。
- 需求池清理只维护需求集合，价值评分与排序归优先级评估，排期与跟踪归迭代管理。
清理前先定规则：需求池准入与保留标准
清理动作容易引起争议，原因通常是判定口径没有提前约定。开始逐条处理之前，产品负责人应先组织一次规则确认，把收录范围、保留条件、退出条件和状态含义写成一页文档，由产品负责人批准后作为本轮清理的唯一依据。规则一旦生效，本轮清理中不因个别需求临时改变口径；确需调整的，记录在规则修订区，下一轮生效。
收录范围与不收录内容
需求池只存放尚未进入迭代、仍待评估的产品需求。已经排入 Sprint Backlog 或已进入迭代的条目归迭代管理，清理时不改动其状态，只在需求池清单中标注去向，避免同一事项在两处被重复判定。以下内容不进入需求池：纯技术重构且无产品行为变化的内部任务、已明确拒绝且提出方已知悉的事项、运维故障单。边界写清楚，盘点时才能快速排除干扰项。
保留、挂起与关闭的判定条件
保留标准建议同时满足三条：与当前产品目标或季度方向相关；信息完整，包含明确提出方、业务场景和期望结果；在可预见的时间内具备评估条件。三条中缺一条，进入挂起或关闭分支。
- 挂起：方向相关但当前不具备评估条件，例如依赖的外部接口尚未就绪、提出方暂时无法补充场景细节。挂起需写明恢复条件和复查时间。
- 合并：与池内已有需求指向同一业务问题，仅表述或提出方不同。合并时指定一条主需求，其余条目关联到主需求并关闭。
- 关闭：长期无进展且提出方不再跟进、信息缺失到无法评估且多次催补无果、与已有需求实质重复且无新增信息、明确超出产品方向。关闭必须记录原因，便于日后追溯。
状态字段设计
状态字段是清理结论的载体，字段含义要在团队内统一，避免同一状态被不同人理解成不同意思。可参考下表设置：
| 状态 | 含义 | 进入条件 | 后续动作 |
|---|---|---|---|
| 待评估 | 已收录、尚未判定 | 通过准入检查进入需求池 | 等待本轮或下轮清理判定 |
| 已确认 | 判定保留，具备评估条件 | 满足保留三条标准 | 进入优先级评估环节 |
| 挂起 | 方向相关但暂不具备条件 | 写明恢复条件与复查时间 | 到期复查，恢复或转关闭 |
| 合并 | 并入主需求 | 已指定主需求并建立关联 | 随主需求一起评估 |
| 关闭 | 不再跟进 | 记录关闭原因与提出方确认情况 | 保留记录，可被重新提出 |
除状态外，建议补齐提出方、提出时间、最近更新时间、关联需求、判定理由、判定人六个字段。判定理由用一两句话写清依据哪条标准，这是后续复查和争议处理的关键材料。
清理执行步骤：从盘点、判定到处置落地
规则确定后，单轮清理按盘点、分组、逐条判定、合并处理、处置落地五步推进。每一步都有明确输入和输出，做完即留下可核对的记录。
第一步：盘点全量需求
输入是当前需求池的全部条目。动作是导出清单，补齐提出方、提出时间、当前状态、关联需求、最近一次沟通记录等字段。输出是一张字段完整的盘点表。完成标志是所有条目都有提出方和时间，缺失项单独标记为待补。借助 ONES Project 的需求池与自定义属性，可以把这些字段直接配置为需求工作项的属性，用筛选器按状态和提出时间快速拉出待清理范围（F1、F4）。
第二步：分组控制单次工作量
按产品模块、提出来源或时间批次分组，每组控制在一次会议能处理完的规模。分组的意义在于让判定人集中处理同类需求，减少上下文切换，也便于把同一模块的重复需求放在一起比对。输出是带组别标记的清理任务清单，每组指定一名判定人和一名记录人。
第三步：逐条判定并写明理由
对照准入与保留标准，对每条需求给出保留、合并、挂起或关闭的结论。判定时先看信息是否完整，再看方向是否相关，最后看是否与池内其他需求重复。理由按“依据哪条标准 + 具体事实”的格式书写，例如“挂起：依赖的支付网关接口计划下季度上线，提出方确认可等待”。完成标志是每条需求都有结论、理由和判定人，没有空白项。
第四步：合并重复需求
合并前先确认两条需求解决的是同一业务问题，而非表述相似。确认后指定信息最完整、提出方最明确的一条为主需求，其余条目状态改为合并并关联主需求，在原条目上注明“已并入某需求”。提出方各自保留通知记录，避免后续重复提出。对于功能复杂的主需求，可在 ONES 中用子工作项拆解，把需求、研发和测试环节串联起来（F3）。
第五步：处置落地与通知
状态更新完成后，由需求管理人员向关闭和挂起的提出方逐一通知，说明结论和理由，并告知重新提出的条件。通知内容应包含需求名称、结论、依据和后续可做的动作。完成标志是每条关闭或挂起需求都有通知记录，提出方有异议的进入争议清单，由产品负责人裁定。
角色与交付物：谁判定、谁确认、谁通知
清理需要四类角色参与，各自产出不同交付物。角色不清时，清理容易变成需求管理人员单方面改状态，既缺少拍板依据，也容易遗漏通知。
| 角色 | 主要职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 产品负责人 | 制定并批准判定标准，对争议需求做最终判定 | 准入与保留标准、争议裁定记录 | 清理启动前批准规则；判定阶段处理争议 |
| 需求管理人员或产品运营 | 组织盘点、维护清单、执行状态更新与通知 | 盘点表、清理记录、通知记录 | 向判定人交付分组清单；向提出方交付结论通知 |
| 提出方（业务、客户成功、内部团队） | 补充业务场景与期望结果，确认关闭或挂起 | 补充信息、确认回复 | 判定前补齐信息；处置后确认知悉 |
| 研发或设计代表 | 对技术可行性、重复性提供判断输入 | 可行性意见、重复性比对结论 | 逐条判定阶段提供输入 |
拍板权归产品负责人，这一点需要在清理启动时明确告知所有参与方。需求管理人员负责流程推进和记录完整，不单独决定关闭。研发和设计的意见作为判定输入，不替代产品负责人的方向判断。ONES 的多层级权限可按项目角色分配操作范围，让判定人与记录人各司其职（F5）。
示例：一轮需求池清理怎么走完
以下为演示情景，用于说明判定理由的写法，数据为示意。
某产品线积累约两百条待评估需求，其中近三成超过半年未更新。产品负责人先确认判定标准，需求管理人员导出全量清单，按订单、结算、报表三个模块分组，每组约六十条，安排两次判定会。
判定阶段出现三类典型情况。一条“支持批量导出对账单”的需求挂了八个月，提出方是已交接的客户成功同事，新接手人无法说明业务场景，判定为挂起，理由写明“提出方变更、场景信息缺失，待新负责人补充后复查”，复查时间定在下一季度。两条分别来自销售和客服的“订单列表增加筛选条件”需求，业务问题相同，指定销售侧条目为主需求，另一条合并并关联。一条“接入某小众物流商”的需求，与产品当前聚焦的头部物流商策略不符，判定关闭，理由写明“超出当前产品方向，提出方已知悉”。
通知按统一模板发送：需求名称、结论、依据、后续动作。关闭和挂起共四十余条，一周内完成通知，收到五条异议，其中两条补充了有效场景，经产品负责人裁定恢复为待评估。本轮产出包括更新后的需求池清单、判定记录和争议裁定记录；遗留问题是部分历史需求缺少提出方信息，需要在下一轮盘点前由各模块负责人补齐。
把清理变成常态：节奏、指标与完成检查
单轮清理结束后，需求池会随新需求流入重新膨胀。把清理纳入固定节奏，并用指标观察效果，才能避免下一轮又变成大扫除。
清理节奏的选择
节奏取决于需求流入速度和池子规模。需求每周大量流入、池子超过数百条的团队，可按迭代节奏每两周做一次小范围清理，每季度做一次全量复查；流入平稳的团队按月清理即可；需求来源分散、跨部门协作多的产品线，可按季度集中清理并配合月度抽查。节奏一旦确定，写入团队工作约定，指定需求管理人员负责发起。
跟踪指标
指标口径由团队自行约定并在清理记录中固定，便于跨轮对比。可跟踪四项：需求池总量，观察池子是否持续膨胀；超期未判定占比，即超过约定天数仍为待评估的条目比例；重复率，本轮合并条目占清理总量的比例；关闭后重新打开比例，反映关闭判定是否过严或通知是否到位。ONES 的报表支持自定义数据范围和维度，可用于呈现这些指标的走势（F6），具体口径仍需团队自行定义。
完成检查清单
- 判定标准覆盖了保留、挂起、合并、关闭四类常见情形，且经产品负责人批准。
- 每条需求都有结论、理由和判定人，无空白项。
- 关闭和挂起的提出方均已收到通知，异议已进入裁定流程。
- 状态字段取值一致，合并条目已关联主需求。
- 盘点表中缺失的提出方、时间等信息已标记并安排补齐。
- 本轮指标已记录，可与上一轮对比。
复查与规则迭代
每轮清理结束后留出半小时复盘：哪些判定引发了争议，哪些标准在实际执行中难以判断，通知方式是否有效。据此调整下一轮规则，例如把“信息完整”细化为必须包含业务场景和期望结果两项。规则调整同样由产品负责人批准，并在下一轮生效。
需要区分的是，需求池清理只负责需求集合的维护，判定保留后的价值评分与排序属于需求优先级评估，排入迭代后的排期与跟踪属于迭代管理。清理为这两个环节提供干净、可决策的输入，不替代它们的工作。在 ONES 中，工单收集的反馈可转化为需求并整理成产品 Backlog，配合自定义工作流让需求按既定状态流转（F2），清理结论则作为状态变更和字段记录沉淀下来，供下一轮复查直接调用。
常见问题
需求池清理应该多久做一次？
节奏取决于需求流入速度和池子规模。需求每周大量流入、池子已达数百条的团队，可以每两周做一次小范围清理，每季度做一次全量复查；流入平稳的团队按月清理即可；需求来源分散、跨部门协作多的产品线，可按季度集中清理并配合月度抽查。节奏确定后写入团队工作约定，指定需求管理人员负责发起，避免依赖临时提醒。
关闭的需求被提出方反对怎么办？
把异议单独记入争议清单，由产品负责人裁定，不在判定会上临时改口径。裁定前可请提出方补充业务场景、期望结果和影响范围；补充后具备评估条件的，恢复为待评估并进入下一轮判定。裁定结果和理由一并记录，作为下一轮规则复盘的输入。若同类异议反复出现，说明判定标准中相应条款需要细化。
挂起的需求如何避免被遗忘？
挂起时必须写明恢复条件和复查时间，两者缺一不可。复查时间到期后，由需求管理人员在当轮清理中逐条回看：条件已具备的恢复为待评估，提出方不再跟进或条件长期无法满足的转为关闭。挂起条目也计入池子总量和超期未判定占比的统计范围，避免挂起成为事实上的搁置。
历史需求缺少提出方或时间信息，还能清理吗？
可以清理，但先标记再判定。盘点时把缺失字段的条目标为待补，由各模块负责人限期补齐；补齐后按标准正常判定。确实无法追溯来源、也无法说明业务场景的条目，按信息缺失处理，记录原因后关闭，并在通知环节说明可重新提出的条件。缺失项数量本身也是盘点质量的观察点，可在下一轮清理前优先补齐。
清理结论在工具里怎么沉淀，方便下一轮复查？
关键是让结论变成可筛选、可追溯的字段，而不只是口头决定。可以把状态、判定理由、判定人、提出方、提出时间、关联需求配置为需求工作项的属性，用筛选器按状态和提出时间拉出待清理范围（F1、F4）；工单收集的反馈可转化为需求并整理成产品 Backlog，配合自定义工作流让需求按既定状态流转（F2）。下一轮复查时直接调用这些字段和记录，无需重新翻找沟通记录。
