需求池清理要解决的是需求越积越多、状态长期停滞、提出方不知道结果的问题。做法是建立一套周期性维护机制：先定准入与出池口径，再按状态和时效筛出待清理项，逐条判定为保留、合并、搁置或关闭并留痕，最后用检查清单确认本轮是否完成。本文给出判定口径表、操作步骤、角色分工、走查示例和完成检查清单。
要点总览（TL;DR）
- 清理前先定准入条件与四类处置口径（保留、合并、搁置、关闭），让每条需求的去留有统一依据，避免逐条处置变成个人偏好。
- 操作按筛选待清理清单、逐条判定、合并字段处理、理由记录与通知、更新状态并归档五步推进，每步都有明确输出和完成标志。
- 产品负责人定口径并确认合并与关闭，需求负责人执行筛选判定与同步结果，提出方补充信息并对处置结果确认或提出异议。
- 完成检查覆盖字段完整性、处置理由、复审时点、提出方知会和规则复盘五项，任一项不满足即视为本轮未完成。
清理前先定口径：哪些需求该进池、哪些该出池
清理的第一步是统一判定标准。没有口径，逐条处置就会变成个人偏好，同一类需求在不同人手里得到不同结论，清理结果也难以向提出方解释。口径应由产品负责人牵头制定，形成一份团队可查的表，并在每轮清理前确认是否仍然适用。
准入条件：需求进池需要满足什么
准入条件决定哪些记录有资格留在需求池中接受评估。建议至少覆盖三项：来源可追溯，即每条需求能对应到提出方或反馈渠道；关键字段完整，包括需求描述、提出方、提出时间、业务场景或目标；尚未被承接，即没有已经进入迭代或已转化为研发任务。字段不完整的记录不应直接关闭，而应先退回补充或归入待完善区，避免把信息缺失误判为无价值需求。
四类处置口径
每条需求在清理时只能落入以下四类之一，每类都要写明触发条件和记录要求。
| 处置类型 | 触发条件 | 必须记录的内容 |
|---|---|---|
| 保留 | 需求仍然有效，字段完整，具备后续评估或排期价值 | 保留理由、责任需求负责人、下次评估时点 |
| 合并 | 与池内另一条需求描述同一问题或目标高度重叠 | 主需求编号、被合并需求编号、合并理由、字段取舍说明 |
| 搁置 | 需求本身成立，但当前缺少资源、依赖条件或业务时机 | 搁置理由、触发重启的条件、复审时点 |
| 关闭 | 需求已失效、已被其他方案覆盖、重复且无独立价值，或长期无人推进且无业务依据 | 关闭理由、关闭人、是否已通知提出方 |
与迭代排期、优先级评估的边界
需求池清理处理的是需求集合本身的维护：状态是否准确、归属是否清晰、下一步动作是否明确。把某条需求排进哪个迭代、按什么价值模型打分排序，属于迭代规划和优先级评估的范畴，不在清理动作内完成。清理时可以标注“建议进入下轮评估”，但不替代评估会议。这样划分的好处是清理周期可以独立于迭代节奏运行，不必等到排期会议才处理积压。
需求池清理的操作步骤：从筛选到处置留痕
口径确定后，清理按固定顺序推进。每一步都应有明确的输入、动作、输出和完成标志，便于不同人接手时保持一致。
第一步：筛选待清理清单
输入是当前需求池全量记录。动作是按状态、停留时长和最近更新时间组合筛选：状态为待评估或已搁置超期的记录优先；提出后长期未更新、无责任人的记录纳入清单；最近刚更新且已有明确下一步的记录可以排除。输出是一份本轮待清理清单，完成标志是清单条目数与池内总量可以核对，且每条都注明了纳入原因。使用 ONES Project 的任务筛选器，可以通过多重条件在项目内快速定位这些记录，减少人工翻找。
第二步：逐条判定
判定按固定顺序进行，避免遗漏：先看是否重复，能合并的先合并；再看是否仍然成立，失效的直接关闭；再看是否具备推进条件，暂不具备的搁置；剩余的有效需求保留。每条判定都要落到四类处置之一，不允许出现“待定”状态长期悬挂。判定依据应引用需求描述、提出方反馈或已有承接情况，而不是仅凭印象。
第三步：合并重复需求时的字段处理
合并时确定一条主需求，其余作为被合并项关联到主需求下。主需求保留最完整的描述、最早的提出时间和全部提出方信息；被合并需求的原描述不删除，通过关联关系可回溯。若两条需求分别来自不同提出方，合并后应在主需求中记录全部来源，避免后续通知遗漏。ONES 支持用子工作项拆解复杂需求并关联研发与测试任务，合并后的主需求可以沿用这一方式承载拆分关系。
第四步：关闭或搁置的理由记录与通知
关闭和搁置是最容易引发争议的两类处置，理由必须具体到可复核。合格的理由写明事实依据，例如“与需求 #123 重复，功能范围已被覆盖”或“依赖的 upstream 接口本季度不开放，待接口上线后重启”。不合格的理由是“暂时不做”“优先级低”这类无法验证的表述。处置完成后，由需求负责人向提出方发出结果通知，说明处置结论和后续可能性；搁置项同时写入复审时点。
第五步：更新池内状态并归档本轮记录
所有判定完成后，统一更新需求状态与责任人字段，生成本轮清理记录，包含清理范围、处置数量分布、遗留问题和规则调整建议。完成标志是池内不存在无责任人、无状态、无下一步动作的有效需求。
角色与交付物：谁筛、谁判、谁确认
清理如果只由一个人完成，判定质量和提出方接受度都难以保证。建议按以下分工组织，每个角色在清理周期内都有明确交付物。
| 角色 | 主要职责 | 本轮交付物 |
|---|---|---|
| 产品负责人 | 制定和修订判定口径；确认合并、关闭等影响面较大的处置；主持复盘 | 判定口径表、处置确认记录、复盘结论 |
| 需求负责人 | 执行筛选与逐条判定；填写处置理由；向提出方同步结果 | 待清理清单、逐条处置记录、通知记录 |
| 提出方 | 补充需求信息；对处置结果确认或提出异议 | 信息补充说明、确认或异议反馈 |
判定结果的确认分两级：常规的保留与搁置由需求负责人判定后报产品负责人备案；合并与关闭由产品负责人确认后生效。提出方对处置有异议时，不直接推翻结论，而是由需求负责人补充信息、产品负责人复核，复核结论记入该需求的处置记录。异议处理时限建议在口径中一并约定，避免争议长期悬置。
在工具层面，ONES 工单可用于收集和整理来自各方的反馈，处理后将工单转化为需求并整理成产品 Backlog，使提出方的原始反馈与池内需求保持可追溯的对应关系；需求状态与属性可在项目中自定义，用于承载“已搁置”“已关闭”等清理结果。
示例：一次月度需求池清理的完整走查
以下为演示情景，用于说明判定与留痕的写法，不代表真实团队数据。
某产品团队每月第一个工作周执行需求池清理，本轮范围为池内全部 46 条待评估需求。需求负责人先用筛选条件取出超过 60 天未更新或状态为待评估的记录，得到 18 条待清理项。
逐条判定结果如下：需求 A 与需求 B 均指向“导出报表支持自定义字段”，判定合并，以提出时间更早、描述更完整的 A 为主需求，B 关联至 A 下，并在 A 中补充 B 的提出方；需求 C 描述的功能已由上一季度上线的模块覆盖，判定关闭，理由记录为“功能已由 3 月上线版本覆盖，提出方确认无需单独跟进”；需求 D 依赖的外部数据接口尚未开放，判定搁置，理由写明依赖条件和复审时点为下季度接口评审后；其余 14 条字段完整、仍具评估价值，判定保留，并各自指定需求负责人和下次评估时点。
清理后，池内待评估需求从 46 条降至 43 条，合并 2 条、关闭 1 条、搁置 1 条，全部处置均记录了理由和操作人。需求负责人向涉及的三位提出方发出结果通知，搁置项在通知中说明了重启条件。本轮清理记录归档，并在复盘中提出一条规则调整：将“提出后 30 天内未补充业务场景”的需求纳入下轮优先清理范围。
完成检查：清理是否做到位的核对项
清理结束不等于清理完成。用以下清单逐项核对，任一项不满足即视为本轮未完成，需在下一轮前补齐。
| 检查项 | 通过标准 |
|---|---|
| 字段完整性 | 池内每条有效需求均有描述、提出方、提出时间、责任人和当前状态 |
| 处置理由齐全 | 合并、搁置、关闭项均记录了具体理由和操作人，理由可复核 |
| 复审时点 | 所有搁置项写明了重启条件和复审时间；关闭项如需回访也已注明 |
| 提出方知会 | 被合并、搁置、关闭需求的提出方均已收到结果通知，异议已处理完毕 |
| 规则复盘 | 本轮清理中暴露的口径问题已记录，并明确是否修订判定口径表 |
除逐项核对外，还可以观察两个结果指标：池内无下一步动作的需求数量应趋近于零；本轮处置中因“信息不足”而无法判定的比例应逐轮下降，若持续偏高，说明准入条件执行不到位，需要回到口径层面调整。规则复盘不必每轮大改，但每轮都应留下“维持”或“修订”的明确结论，使清理机制随团队实际运行逐步收敛。
常见问题
需求池清理应该多久做一次，周期怎么定？
周期取决于需求进入池子的速度和团队处理能力，常见做法是按月或按双周执行。判断依据可以看两个信号：待评估需求的平均停留时长是否持续拉长，以及因信息不足无法判定的比例是否偏高。周期一旦确定，建议固定在日历上，与迭代排期会议分开运行，这样清理不必等到排期才处理积压。团队规模或需求来源变化较大时，可以临时增加一轮专项清理。
提出方不接受关闭结论，清理时怎么处理？
异议不直接推翻判定，而是走复核：需求负责人补充需求描述、业务场景或已有承接情况，产品负责人据此复核，复核结论写入该需求的处置记录。若复核后确认需求成立但当前不具备推进条件，可以改为搁置并写明重启条件与复审时点。建议在判定口径中一并约定异议处理时限，避免争议长期悬置影响下一轮清理。
合并重复需求后，原来提出方的信息会不会丢？
不会。合并时确定一条主需求，被合并项通过关联关系挂在主需求下，原描述保留可回溯。主需求中应记录全部提出方和来源渠道，通知时按合并后的来源清单逐一告知，避免遗漏。若两条需求分别包含不同的业务场景细节，把这些细节补充进主需求描述，而不是只保留其中一条。
搁置的需求什么时候重新拿出来评估？
搁置时必须同时写明两件事：重启的触发条件，例如依赖的接口上线、资源到位或业务节点到来；复审时点，即到哪个时间点无论条件是否满足都要重新看一次。复审时点可以按季度设置，到期由需求负责人确认条件是否变化，仍不满足则更新理由后继续搁置。缺少复审时点的搁置项，在完成检查中视为不合格。
清理和迭代排期、优先级评估是什么关系？
清理只处理需求集合本身的维护：状态是否准确、归属是否清晰、下一步动作是否明确。把需求排进哪个迭代、按什么模型打分排序，属于迭代规划和优先级评估的环节。清理时可以标注“建议进入下轮评估”，但不替代评估会议。这样划分让清理周期独立于迭代节奏，积压不必等到排期会议才处理。
