需求池维护机制要解决的是需求越积越多、状态长期不动、没人说得清哪条该做的问题。本文按入口规则、状态流转、角色分工、评审与清理节奏四部分展开，给出可直接套用的字段清单、状态表、角色对照表和完成检查清单，帮助团队把需求池从“堆想法的地方”变成可持续运转的需求集合。
要点总览（TL;DR）
- 需求池维护机制由入口规则、状态流转、角色分工、评审与清理节奏四部分组成，缺任一部分都会导致积压、挂起或无人认领。
- 入口字段以支撑初筛为限，建议包含来源、提出人、业务场景、期望时间、影响范围；状态覆盖待评估、已确认、排期中、已转迭代、已关闭并写明流转条件。
- 角色分工坚持单一收口：需求池负责人统一登记与初筛，提出人负责说清场景，评审组给结论，开发负责人评估成本与排期。
- 评审会建议每周一次、存量清理每月一次，清理对象为长期无进展、重复和已失效需求，处理结果需留痕可查。
- 用入口字段完整率、状态更新及时性、清理周期和认领情况四项按月核对，不达标时回到对应环节调整。
需求池维护机制由哪几个部分组成
需求池维护机制是一套围绕需求集合持续运转的规则，由四个部分组成：入口规则决定什么信息齐全的需求才能进池，状态流转决定需求在池中如何移动，角色分工决定每个环节由谁负责，评审与清理节奏决定池子多久被检查一次。四部分缺一不可，只定字段不定节奏，池子会积压；只开评审会不定入口，会上讨论的多是信息不全的需求。
每一部分都对应一类典型的失控现象。入口规则缺失时，同一诉求被不同人重复录入，或者只留一句“客户想要某功能”，后续无法判断价值；状态流转缺失时，需求长期停在“待评估”，没人知道它卡在哪一步；角色分工缺失时，需求挂在池中无人认领，提出人反复追问却得不到答复；评审与清理节奏缺失时，已失效的需求和仍然有效的需求混在一起，评审会时间被低价值条目占满。
需要区分边界：需求池维护管的是需求条目的进出、状态和责任人，迭代计划管的是已确认需求在哪个周期交付，优先级评估管的是多条需求之间的排序依据。三者衔接但不互相替代，维护机制只需保证进入优先级评估和迭代计划的需求信息完整、状态准确。
| 组成部分 | 解决的问题 | 产出物 |
|---|---|---|
| 入口规则 | 重复录入、信息不全、来源不清 | 入口必填字段清单 |
| 状态流转 | 需求长期挂起、进度不可见 | 状态定义与流转条件表 |
| 角色分工 | 多头录入、无人认领、责任模糊 | 角色—动作—交付物对照表 |
| 评审与清理节奏 | 池子积压、失效需求占用评审资源 | 评审与清理节奏表 |
第一步：定需求入口字段与状态流转
入口规则的目标是让每一条进入需求池的需求都具备初筛所需的最小信息。字段不宜多，以能支撑“这条需求是否值得进一步评估”为限。建议的必填字段如下：
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 需求来源 | 客户、销售、内部团队、线上问题等，选其一并注明具体对象 | 判断需求覆盖范围和可信度 |
| 提出人 | 具体到人，便于后续澄清 | 评审时的信息补充入口 |
| 业务场景 | 描述用户在什么情况下遇到什么问题，避免只写功能名称 | 支撑价值判断和方案讨论 |
| 期望时间 | 提出方希望的时间点，注明是硬性约束还是期望 | 辅助排期判断 |
| 影响范围 | 涉及的用户群体、业务量或流程环节 | 辅助优先级评估 |
状态设计要覆盖需求在池中的完整生命周期。建议设置五个状态：待评估、已确认、排期中、已转迭代、已关闭。每个状态写明进入条件和离开条件，例如“待评估”在需求池负责人完成初筛后进入“已确认”，初筛判断为不做的直接进入“已关闭”并记录原因；“已确认”在评审组确认价值和大致时间窗口后进入“排期中”；“排期中”的需求被纳入某个迭代后进入“已转迭代”。状态变更时同步更新变更时间和操作人，便于追溯。
这一步的输入是原始需求，动作是登记与初筛，输出是带完整字段和明确状态的需求条目。完成标志是：任意一条池中需求都能回答“谁提的、什么场景、现在处于哪个状态、下一步由谁处理”。在工具承载上，ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，可将需求和相关任务规划至迭代并分配负责人，适合把上述字段和状态直接配置为工作项属性。
第二步：明确角色分工与各自交付物
角色分工的原则是单一收口：需求池只有一个负责人对池子的秩序负责，所有需求通过统一入口登记，避免多个渠道各自维护一份清单。提出人负责把需求说清楚，评审组负责判断做不做和大致什么时候做，开发负责人负责评估实现成本和交付安排。
| 角色 | 关键动作 | 交付物 |
|---|---|---|
| 需求池负责人（收口人） | 登记或审核入口信息、完成初筛、维护状态准确性、组织评审与清理 | 字段完整的需求条目、初筛结论、评审记录、清理记录 |
| 提出人 | 按入口字段描述需求、在评审中澄清场景、确认关闭原因 | 需求描述、补充说明 |
| 评审组 | 按固定节奏评审待评估和已确认需求，给出确认、暂缓或关闭结论 | 评审结论与理由 |
| 开发负责人 | 评估实现成本与依赖、确认可排期时间、承接转入迭代的需求 | 成本评估意见、排期确认 |
分工落地时有两个细节值得固定下来：一是登记动作只由需求池负责人或指定入口执行，其他角色通过提交需求而非直接建条目来参与；二是每条处于“已确认”及之后状态的需求必须有明确的责任人，没有责任人的需求在清理时优先处理。ONES Project 的产品、项目、任务多层级权限可按组织架构、用户组和项目角色分配，适合把收口人、评审组和开发负责人的操作范围区分开。
第三步：设定评审与清理节奏
评审与清理是让池子保持可用的关键动作。建议评审会每周一次，参与人为需求池负责人、评审组代表和开发负责人，议程固定为三项：过一遍新进入“待评估”的需求并给出初筛结论；讨论“已确认”需求中需要排期的条目；确认上周清理动作的执行结果。会议时长控制在固定范围内，避免变成逐条讨论方案的技术会。
清理动作可以每月执行一次，与周度评审分开。清理对象有三类：超过约定周期没有状态变化的需求、与已有需求重复的条目、业务场景已失效的需求。处理方式分别是：长期无进展的需求退回提出人确认是否仍然需要，确认后仍无进展的关闭；重复需求合并到主条目并注明关联；失效需求关闭并记录原因。所有清理结果保留状态更新记录，便于提出人查询。
| 动作 | 频率 | 参与人 | 处理内容 |
|---|---|---|---|
| 需求评审会 | 每周一次 | 需求池负责人、评审组代表、开发负责人 | 初筛新需求、确认待排期需求、核对上周清理结果 |
| 存量清理 | 每月一次 | 需求池负责人牵头，提出人配合确认 | 识别长期无进展、重复、失效需求并处理 |
| 状态巡检 | 每周随评审会进行 | 需求池负责人 | 检查状态与责任人是否准确、字段是否缺失 |
这一步的输入是池中存量需求，动作是评审与清理，输出是状态更新记录和清理结论。完成标志是：每次评审会后池中不存在状态与实际情况不符的条目，清理记录可查。ONES Project 的任务筛选器支持全局筛选与项目内筛选，可按状态、更新时间等条件快速筛出长期未更新的需求，作为清理会的输入清单。
示例：一个需求从进池到关闭的完整流转
以下为演示情景，用于说明各环节如何衔接。某销售同事反馈一家客户希望在报表页面增加按区域筛选的能力。销售作为提出人在统一入口提交需求，填写来源为“客户—某区域客户”、提出人为销售本人、业务场景为“客户每月按区域汇总数据时需要手工拆分报表”、期望时间为“下季度前”、影响范围为“该客户三个业务团队”。需求池负责人收到后完成初筛，判断场景描述清晰、影响范围可核实，将状态从“待评估”改为“已确认”，并指定产品经理为责任人。
周度评审会上，评审组确认该需求与另一条“报表支持多维度筛选”的需求高度重合，决定合并处理，将本条标记为重复并关联到主需求，状态改为“已关闭”，关闭原因记录为“与主需求合并”。销售在池中可以看到合并去向，后续跟进主需求即可。三个月后主需求转入迭代，状态变为“已转迭代”，开发负责人承接排期。
这个示例体现了两个清理规则触发点：一是重复识别在评审会上完成，避免两条需求各自占用评估资源；二是关闭动作保留了原因和关联条目，提出人不会觉得需求“消失”了。如果该需求在“已确认”状态停留超过约定周期仍无人推进，月度清理时会退回销售确认是否仍然需要，形成第二个触发点。
完成检查：机制是否真正运转
机制建立后，需要定期核对它是否在实际运转。以下检查项可按月执行，每项都给出通过标准和证据来源，便于逐条核对。
| 检查项 | 通过标准 | 证据来源 |
|---|---|---|
| 入口字段完整率 | 抽查的池中需求中，必填字段齐全的比例达到团队约定水平 | 需求条目详情、字段填写记录 |
| 状态更新及时性 | 状态变更与实际情况一致，不存在已排期但仍显示“待评估”的条目 | 状态变更时间与操作人记录 |
| 存量清理周期 | 按约定频率完成清理，长期无进展需求有处理结论 | 清理记录、关闭原因 |
| 角色认领情况 | “已确认”及之后状态的需求均有明确责任人 | 责任人字段、评审记录 |
发现不达标时，回到对应环节调整：字段完整率低，说明入口校验不严或字段过多，应收紧登记权限或精简字段；状态更新不及时，说明状态变更没有和实际动作绑定，应把状态更新写入评审会和转迭代的操作步骤；清理周期未执行，说明清理没有固定责任人和时间，应把清理列入需求池负责人的例行工作；认领率低，说明评审结论没有落到人，应在评审会上当场指定责任人。ONES Wiki 支持文档关联任务并插入工作项列表，可把评审纪要与池中需求条目关联，作为检查时的证据留存。
常见问题
需求池里的需求长期没人推进，应该由谁处理、怎么处理？
长期无进展的需求由需求池负责人牵头处理，提出人配合确认。具体做法是在月度清理时把超过约定周期没有状态变化的需求退回提出人，确认是否仍然需要：仍然需要的重新指定责任人和下一步动作，确认后仍无进展的关闭并记录原因。这类需求在清理清单中应优先于新需求处理，否则会持续占用评审时间。
多条需求内容重复，合并时要注意什么？
合并的关键是保留可追溯的去向。把重复条目合并到主需求后，在重复条目上记录关联的主需求并注明关闭原因，提出人能在池中看到自己的诉求去了哪里，后续跟进主需求即可。合并判断放在评审会上做，由评审组确认两条需求是否真的覆盖同一场景，避免把相似但范围不同的需求误合并。
团队规模小、没有专职需求池负责人，机制还能运转吗？
可以运转，但收口角色仍需明确到人。小团队常见做法是由产品经理兼任需求池负责人，登记、初筛和清理动作合并到每周固定的半小时内完成，评审会与迭代规划会合并召开。需要保留的是单一入口和状态更新这两个动作，频率和会议形式可以按团队节奏压缩。角色数量可以减少，责任归属不能空缺。
需求池维护和迭代计划、优先级评估怎么衔接？
三者各管一段。需求池维护保证条目信息完整、状态准确、责任明确；优先级评估决定多条已确认需求之间的排序；迭代计划决定已确认需求在哪个周期交付。维护机制的输出是干净可用的需求条目，进入评估和排期环节时不需要再回头补字段。边界清楚后，评审会只做确认与清理，方案讨论和排序放到对应环节。
机制运行一段时间后池子又开始积压，先查哪里？
先看完成检查中的四项指标。字段完整率下降，通常是入口校验放松或字段过多，应收紧登记权限或精简字段；状态更新不及时，说明状态变更没有和评审、转迭代动作绑定；清理周期未执行，说明清理缺少固定责任人和时间；认领率低，说明评审结论没有当场落到人。按指标定位到具体环节再调整，比整体重做机制更有效。
