需求池清理要解决的是需求越积越多、状态失真、重复项难以识别的问题。本文给出一套可重复执行的做法：先确定清理范围与判定口径，再逐条完成保留、合并、细化、暂缓或关闭归档，随后更新字段并留下记录，最后用检查表确认清理是否到位。文中包含操作步骤、角色分工、季度清理示例和完成检查表，可直接用于组织一次清理。
要点总览（TL;DR）
- 清理前先写一页口径说明：明确本次清理的范围筛选条件、保留/合并/细化/暂缓/关闭五类判定规则，以及依赖的状态、来源、关联、负责人、更新时间等字段。
- 执行按五步推进：筛出待清理清单并冻结范围、逐条分类并处理重复与关联、保留项补齐字段与下一步、关闭项记录原因与暂缓项标注复查条件、更新状态并留存清理记录。
- 角色上由产品负责人主导判断并掌握关闭合并权限，需求提出方确认业务背景，研发负责人提供技术判断，需求池维护人负责字段更新、记录留存与遗留项跟踪。
- 清理结束用五项检查确认达标：清单覆盖、字段完整性、关联关系、记录完整性、遗留问题衔接；处理数量分布可作为下一轮口径调整的参考。
清理前先定口径：范围、判定标准与字段
清理最常见的失败方式是边清边改标准：前二十条按“三个月未更新就关闭”处理，后面又觉得可惜改成“半年”。因此清理开始前，应先把范围、判定规则和字段清单写成一份简短的口径说明，参与清理的人按同一份说明执行。口径说明不需要很长，一页以内即可，但要能回答“这条需求为什么被这样处理”。
确定清理范围
需求池通常混合了不同性质的内容：已进入迭代的需求、等待价值评估的需求、长期无人跟进的需求、来自客户或内部的零散想法。清理范围应明确本次处理哪个集合，常见做法是以“未进入迭代且状态为待评估/待细化”的需求为清理对象，已排期需求留在迭代管理中维护，价值评分工作单独进行。范围可以用筛选条件表达，例如状态、创建时间区间、所属产品线或来源渠道的组合，并记录筛选条件本身，便于下次复用。
去留判定口径
每条需求最终落到五类处理结果之一，触发条件需要在清理前写清楚。下表是一种可直接套用的口径，具体时间阈值可按团队节奏调整。
| 处理结果 | 触发条件 | 后续动作 |
|---|---|---|
| 保留 | 需求仍然有效，与当前产品方向一致，信息基本完整 | 补齐字段，标注下一步（进入评估、等待排期等） |
| 合并关联 | 与池内另一条需求描述同一问题，或存在上下游依赖 | 保留一条主需求，其余合并或建立关联并注明关系 |
| 细化 | 方向认可但描述不足以判断，缺少场景、用户或验收线索 | 指定细化责任人，设定补充信息的截止时间 |
| 暂缓 | 当前不做但未来可能重启，例如依赖外部条件或前置能力 | 标注复查条件与复查时间，移入暂缓视图 |
| 关闭归档 | 已实现、已失效、与方向不符或长期无价值信号 | 记录关闭原因，保留记录供追溯 |
需要区分两类“重复”：业务上描述同一用户问题的需求应合并；仅关键词相同但场景不同的需求不应合并，搜索关键词去重属于检索层面的处理，与需求池清理的判断不是一回事。
清理所需字段与周期
逐条判断依赖一组基础字段：状态、来源、关联需求、负责人、最近更新时间，必要时补充优先级、目标版本和关闭原因。字段缺失本身就是清理要处理的问题，清理前先确认这些字段在需求记录中可用。清理周期可以按月或按季度固定，也可以设置触发时机，例如池内待评估需求超过约定数量、版本规划前、季度复盘时。固定周期适合需求流入稳定的团队，触发式清理适合需求波动大的团队，两者也可以结合：固定周期做全量检查，触发时机做局部清理。
逐条清理的操作步骤
口径确定后进入执行。以下五步按顺序推进，每步都有明确输入和输出，避免清理变成“看一遍、改几个状态”的浏览。
第一步：筛出待清理清单
输入是清理口径中的范围条件，动作是按条件筛选或导出需求清单，输出是一份带唯一标识的待清理清单。清单应包含需求标题、状态、来源、负责人、最近更新时间和关联需求等列，便于逐条判断时不必反复打开详情。导出后冻结清单范围，清理过程中新增的需求归入下一轮，避免边清边进导致永远清不完。
第二步：逐条分类并处理重复与关联
输入是待清理清单和判定口径，动作是逐条阅读需求内容，对照五类结果做出判断。遇到疑似重复项时，先确认是否指向同一用户问题，再决定合并方向：保留信息更完整、来源更明确的一条作为主需求，其余记录合并去向。存在依赖关系的需求建立关联并注明关系类型，例如前置、替代或相关。输出是每条需求带有初步处理结论的清单，重复项和关联关系已标注。
第三步：保留项补齐字段并明确下一步
输入是判定为保留或细化的需求，动作是补齐负责人、优先级、目标版本、下一步动作等字段。下一步动作要具体到可执行，例如“本周内补充用户场景后提交评估”“等待某能力上线后重新评估”，避免只写“待定”。细化项需指定责任人和补充信息的截止时间，到期未补充的转入暂缓或关闭。输出是字段完整的保留项清单，每条都有明确的责任人和下一动作。
第四步：关闭归档记录原因，暂缓项标注复查条件
输入是判定为关闭或暂缓的需求，动作是填写关闭原因或复查条件。关闭原因应写明依据，例如“已在某版本实现”“需求提出方确认不再需要”“与当前产品方向不符”，便于日后追溯和回答提出方询问。暂缓项需写明复查条件与复查时间，例如“依赖的第三方接口开放后复查”“下季度规划时复查”。输出是带有原因和复查条件的关闭项、暂缓项记录。
第五步：更新状态并留存清理记录
输入是前四步的处理结论，动作是在需求管理工具中批量更新状态、字段和关联关系，并保存本次清理记录。清理记录至少包含清理时间、范围条件、处理数量分布（保留、合并、细化、暂缓、关闭各多少条）、遗留问题和下次清理时间。输出是更新后的需求池和一份清理记录。状态更新与记录留存应同步完成，只改状态不留记录，下次清理无法判断上次处理是否彻底。
当需求数量较多、关联关系复杂时，状态维护和关联处理容易出错。ONES 的需求管理支持为需求设置状态、负责人、优先级等字段，并可在需求之间建立关联关系，清理时按筛选条件生成待处理视图，处理结论直接落到字段和关联上，清理记录也可作为文档留存，便于下一轮清理对照。
角色分工与各环节交付物
清理如果只由一个人完成，判断容易偏向个人视角，关闭需求也缺少确认。合理的分工是：产品负责人主导判断，需求提出方提供业务背景，研发负责人确认技术相关结论，清理结果统一同步。
| 角色 | 职责边界 | 交付物 |
|---|---|---|
| 需求提出方 | 补充需求背景与使用场景，确认需求是否仍然需要 | 需求背景说明、对关闭或暂缓的确认意见 |
| 产品负责人 | 主导逐条判断，决定保留、合并、细化、暂缓或关闭，对口径执行负责 | 处理结论、合并方向、关闭原因 |
| 研发负责人 | 对涉及技术可行性、实现成本或已实现判断的需求提供意见 | 技术判断意见、已实现确认 |
| 需求池维护人 | 维护字段与状态，保存清理记录，跟踪细化项和暂缓项 | 更新后的需求池、清理记录、遗留问题清单 |
关闭和合并权限应集中在产品负责人，涉及客户承诺或合同义务的需求关闭前需经提出方确认；复核可以由产品负责人与研发负责人交叉进行，抽查一定比例的处理结论是否符合口径。各环节的交接方式建议固定：判断结论写入需求记录，细化项通过任务指派到人，清理记录在团队可见的文档中发布，清理结果在例会上同步给相关角色，重点说明关闭项和暂缓项的分布及原因。
示例：一次季度需求池清理怎么走
以下为演示情景，用于说明完整过程，数据为示例设定。
背景与范围。某产品团队每季度末清理一次需求池，本次范围是“状态为待评估、创建时间超过一个季度、未关联任何迭代”的需求，共筛出 86 条。清理口径沿用上季度版本，仅将暂缓项的复查时间统一调整为下季度规划前。
重复项合并。清单中有 7 条需求都提到“导出报表支持自定义字段”，经核对指向同一用户问题，保留描述最完整、附有客户场景的一条作为主需求，其余 6 条合并到主需求并注明来源，主需求补充了各来源提出的字段范围。另有 3 条需求存在依赖关系，分别建立“前置”“相关”关联。
保留与细化。判定保留的 32 条需求补齐了负责人和下一步动作，其中 11 条标注“进入下季度评估”。判定细化的 9 条需求指派了细化责任人，要求两周内补充用户场景和验收线索，到期未补充的转入暂缓。
暂缓与关闭。暂缓 14 条，逐条写明复查条件，例如“依赖的支付渠道接口开放后复查”。关闭 24 条，原因分布为：已在历史版本实现 9 条、提出方确认不再需要 8 条、与当前产品方向不符 5 条、长期无价值信号 2 条。关闭项均记录了原因和确认人。
结果与同步。清理后更新全部状态与字段，形成清理记录：处理 86 条，保留 32 条、合并 7 条、细化 9 条、暂缓 14 条、关闭 24 条，遗留问题 3 项（两条需求归属待确认、一条依赖关系待研发确认）。清理记录在团队文档发布，并在季度例会上同步关闭项和暂缓项的原因分布，遗留问题指定责任人在两周内闭环。
完成检查：判断本次清理是否达标
清理结束后，用下表逐项核对。每项检查都应有明确的通过标准，检查人可以是需求池维护人，复核由产品负责人完成。
| 检查项 | 通过标准 |
|---|---|
| 清单覆盖 | 范围内需求全部有处理结论，无未处理项；清理期间新增需求已记录并归入下一轮 |
| 字段完整性 | 保留项和细化项的负责人、优先级、下一步动作、最近更新时间均已填写 |
| 关联关系 | 重复项已合并到主需求并注明去向；有依赖关系的需求已建立关联并标注关系类型 |
| 记录完整性 | 关闭项均有原因和确认人；暂缓项均有复查条件和复查时间 |
| 遗留问题衔接 | 遗留问题已列出并指定责任人和闭环时间；下次清理时间与范围条件已确定 |
检查中发现的问题应当场修正或登记为遗留问题，不留在“下次再说”。清理记录中的处理数量分布可与上季度对比，若关闭项中“长期无价值信号”占比持续偏高，说明需求进入池子的门槛需要收紧；若细化项到期未补充的比例偏高，说明细化责任分配或截止时间设置需要调整。这些信号用于改进下一轮清理的口径，而不是评价个人。完成检查后，本次清理才算结束，下一轮按既定周期或触发条件启动。
常见问题
需求池清理应该多久做一次，固定周期和触发式清理怎么选？
固定周期适合需求流入比较稳定的团队，按月或按季度做全量检查，节奏可预期，也便于和版本规划、季度复盘对齐。触发式清理适合需求波动大的团队，在池内待评估需求超过约定数量、版本规划前或出现明显积压时启动局部清理。
两种方式可以结合：固定周期做全量清理，触发时机只清理某个产品线或某类来源的需求。无论选哪种，都要把周期或触发条件写进口径说明，并在清理记录中约定下次清理时间，避免清理间隔越拉越长。
清理时遇到两条需求描述相似，怎么判断该合并还是保留为两条？
判断依据是它们是否指向同一个用户问题，而不是标题或关键词是否相似。如果两条需求描述的是同一场景下同一类用户的同一诉求，只是措辞或来源不同，应合并：保留信息更完整、来源更明确的一条作为主需求，其余记录合并去向和来源。
如果关键词相同但使用场景、用户角色或验收标准不同，应保留为两条，必要时建立“相关”关联。搜索关键词去重属于检索层面的处理，与需求池里的业务重复判断是两件事，不要混用同一套规则。
关闭需求时提出方不同意怎么办？
涉及客户承诺或合同义务的需求，关闭前需要提出方确认，不能由产品负责人单方面决定。遇到分歧时，先把关闭依据写清楚，例如已在某个版本实现、与当前产品方向不符、长期没有价值信号，再请提出方补充业务背景和使用场景。
如果提出方坚持保留但当前确实不做，可以转为暂缓，写明复查条件和复查时间，并告知提出方后续在什么条件下会重新评估。这样既保留了记录，也避免需求在池内反复流转。
细化项到期没有补充信息，应该直接关闭还是继续等待？
建议在口径说明里提前约定处理方式，常见做法是到期未补充的转入暂缓或关闭，并记录原因。继续无限期等待会让细化项重新变成积压，清理效果打折。
如果需求方向仍然认可、只是责任人暂时没有时间，可以延长一次截止时间并注明新的责任人和日期，同时登记为遗留问题在下次清理时复查。关键是每次延期都有记录，而不是默认一直挂着。
清理记录要记到什么程度，才够下一轮清理使用？
清理记录至少包含清理时间、范围筛选条件、处理数量分布（保留、合并、细化、暂缓、关闭各多少条）、遗留问题及责任人、下次清理时间。关闭项的原因分布和暂缓项的复查条件也应能在需求记录中查到。
记录的作用是让下一轮清理能对照上一轮：范围条件可以直接复用，遗留问题可以逐项核对是否闭环，数量分布的变化可以提示口径是否需要调整。只更新状态不留记录，下一轮就难以判断上次处理是否彻底。
