需求池维护机制可以拆成四件事：收进来、判一遍、定期清、有出口。本文给出一份虚构团队的需求池维护机制填写示例，包含字段表、入库与分级规则、每周清理与月度评审节奏、角色分工和关闭条件，并逐项解释每条规则为什么这样写、换团队时哪些地方需要调整。
要点总览（TL;DR）
- 需求池维护机制由四张表构成：字段表定义记录什么，规则表定义入库、分级、状态流转与关闭条件，节奏表定义每周清理与每月评审，角色表定义谁负责哪一步。
- 示例用五个状态串起需求生命周期：待评估、已确认、排期候选、已排期、关闭，每个状态都写明进入与退出条件，避免需求停在半路无人处理。
- 关键规则各有明确用途：最近更新字段用于识别停滞需求，初审时限让每条提报都有回音，重复需求合并保留来源记录，关闭必填原因供后续复盘。
- 换团队时结构不变，调整评审频率、初审时限、优先级档位数量和参与角色即可；小团队可合并角色、精简字段，多业务线则需增加提出人代表席位。
- 机制只覆盖需求集合的收集、状态维护、定期清理与关闭；迭代排期归迭代管理，价值评分归优先级评估，重复需求的判定标准需团队自行定义。
示例目标：这份需求池维护机制要解决什么
先交代示例的假设情景。某公司有一条成熟产品线，同时承接内部业务部门提报和外部客户反馈，需求来源分散在群聊、邮件、工单和会议纪要里。团队规模、行业和预算不在本文设定范围内，以下角色、时限和频率均为演示用设定，标明为示例，不代表任何真实团队的做法或效果。
这个情景下，需求池常见的四类问题需要靠机制解决：
- 入口混乱：谁都能提，提法各不相同，产品负责人需要反复追问背景，评估启动慢。
- 状态停滞：需求进入池子后长期停在“待评估”，没人知道它卡在谁那里。
- 重复堆积：同一业务诉求被不同人多次提报，池子条数增长，实际待办没有增加。
- 无人清理：已实现、已放弃、长期无进展的需求混在一起，池子失去参考价值。
针对这四类问题，示例机制的产出物是四张表：字段表定义每条需求记录什么，规则表定义入库、分级、状态流转和关闭条件，节奏表定义每周与每月分别做什么，角色表定义谁对哪一步负责。四张表合起来构成一份可以直接照抄改写的机制文本。
完整示例：一份需求池维护机制填写样例
以下为示例团队的需求池维护机制全文。表格中的字段、时限和频率都可以按团队情况替换，结构保持不变。
表一：需求池字段表
| 字段 | 填写要求 | 必填/可选 | 用途 |
|---|---|---|---|
| 需求编号 | 系统生成，格式 REQ-年份-序号 | 必填 | 唯一标识，便于引用与合并 |
| 来源 | 内部业务部门 / 外部客户 / 运营反馈 / 其他 | 必填 | 区分反馈渠道，支撑来源分析 |
| 提出人 | 具体姓名与所属部门 | 必填 | 评估时回访、关闭时告知 |
| 业务场景 | 一两句话说明在什么业务动作中遇到什么问题 | 必填 | 判断需求真实性与影响范围 |
| 状态 | 按状态流转表取值 | 必填 | 反映需求当前所处环节 |
| 优先级档 | 高 / 中 / 低，评估后填写 | 必填（评估后） | 排序与排期候选的依据 |
| 负责人 | 当前处理该需求的产品人员 | 必填 | 明确停滞时找谁 |
| 最近更新 | 状态、优先级或负责人变化时自动或手动更新日期 | 必填 | 识别长期无进展的需求 |
| 关闭原因 | 重复合并 / 已实现 / 不做 / 长期无进展 | 关闭时必填 | 保留决策记录，供复盘使用 |
表二：入库、分级与状态流转规则
| 环节 | 规则 |
|---|---|
| 谁能提 | 内部员工均可提报；外部客户反馈由对接的客户成功或运营人员代为提报，并注明客户名称 |
| 提报格式 | 必须填写来源、提出人、业务场景三项；缺少业务场景的提报退回补充 |
| 谁初审 | 需求池管理员在每个工作日固定时段集中初审新提报 |
| 初审时限 | 新需求在提报后 2 个工作日内完成初审，给出“受理”或“退回补充”结论 |
| 分级 | 初审通过后由产品负责人按影响范围与紧急程度给出高/中/低三档，档位只作排序参考，具体排期在月度评审中确定 |
状态流转按以下五个状态执行，每个状态都有明确的进入与退出条件：
| 状态 | 进入条件 | 退出条件 |
|---|---|---|
| 待评估 | 初审受理，字段填写完整 | 产品负责人完成评估，给出优先级档，或判定为重复/不做 |
| 已确认 | 评估通过，业务场景与影响范围清楚 | 进入月度评审讨论排期，转为排期候选 |
| 排期候选 | 月度评审认为值得排期，但尚未分配迭代 | 被排入具体迭代，或评审后降级回已确认 |
| 已排期 | 已分配到具体迭代或版本 | 开发完成并验收，转为关闭（已实现） |
| 关闭 | 满足任一关闭条件 | —（归档，不再流转） |
表三：维护节奏表
| 节奏 | 参与人 | 输入 | 输出 |
|---|---|---|---|
| 每周清理会（30 分钟） | 需求池管理员、产品负责人 | 最近更新超过 14 天的需求清单、新提报未初审清单 | 停滞需求的处理结论：推进、降级或关闭；重复需求合并记录 |
| 每月池评审（60 分钟） | 需求池管理员、产品负责人、研发代表、业务提出人代表 | 已确认状态的需求清单、上月关闭需求汇总 | 排期候选名单、优先级档调整、关闭原因复盘要点 |
表四：角色分工表
| 角色 | 职责 |
|---|---|
| 需求池管理员 | 负责初审、字段完整性检查、组织每周清理会、维护状态准确性 |
| 业务提出人 | 按格式提报，补充业务场景，参与月度评审说明诉求背景 |
| 产品负责人 | 评估需求、给出优先级档、决定排期候选、确认关闭结论 |
| 研发代表 | 在月度评审中提供实现成本与依赖判断，参与排期候选讨论 |
关闭与归档规则
- 重复需求：保留最早一条作为主记录，其余标记为“重复合并”，在关闭原因中注明主记录编号，来源与提出人信息保留在原记录上。
- 长期无进展：最近更新超过 60 天且未进入排期候选的需求，在每周清理会上提出，由产品负责人决定继续保留或关闭。
- 已实现：开发完成并验收后关闭，关闭原因填“已实现”，关联对应的迭代或版本记录。
- 不做：评估后明确不做的需求，关闭原因填“不做”，并写一句判断依据，便于后续同类需求参考。
逐项解释：每条规则为什么这样写
“最近更新”字段是识别停滞的依据。需求池失去参考价值，往往因为没人知道哪些条目已经很久没动。把状态、优先级、负责人的变化都反映到最近更新日期上，每周清理会只需要按这个字段排序，就能拿到需要处理的清单，不必逐条翻看。
初审时限写死，是为了让池子有进有出。如果初审没有时限，新需求会一直堆在待评估状态，提出人得不到反馈，后续提报意愿下降。示例把时限定为 2 个工作日，并给出“受理”或“退回补充”两种明确结论，让每个提报都有回音。这个时限可以按团队提报量调整，关键是写成一个可检查的数字。
重复需求用合并而非删除，是为了保留来源与决策记录。同一诉求被多个部门提出，说明影响范围可能更大；直接删除会丢失这层信息。合并后保留主记录和原记录的来源、提出人，后续评估影响范围、复盘决策时都能追溯。
关闭必须填原因，是为复盘和优先级评估提供输入。“不做”的需求如果只关闭不记录依据，几个月后同类需求再次出现时又要重新评估一遍。关闭原因按四类固定取值，月度评审时可以汇总查看哪类关闭最多，判断是提报质量问题还是排期资源问题。
必填与可选的取舍。示例中来源、提出人、业务场景、状态、负责人、最近更新为必填，优先级档在评估后补填，关闭原因仅在关闭时必填。精简版可以去掉“来源”的细分选项，合并为“内部/外部”两类，但业务场景、状态、负责人、最近更新四项建议保留，它们分别支撑评估、流转、责任归属和清理四个动作。
在工具承载上，这类字段与状态可以在工作项中配置。ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性；ONES 工单可用于收集各方反馈并转化为需求，工作流可按实际场景自定义。示例中的字段表落地时，具体可配置的字段类型与状态流转方式需在实际环境中确认。
可迁移规律：换团队时改哪几处
这份示例可以复用的是四件套结构：字段表定义记录什么，规则表定义怎么进出，节奏表定义多久清一次，角色表定义谁负责。换团队时，结构不动，调整以下变量：
- 评审频率：提报量小的团队可以把每周清理会改为双周，月度评审保留；提报量大、来源多的团队可以增加一次周中快速分诊。
- 初审时限：示例的 2 个工作日适合有专人负责初审的团队；由产品负责人兼任初审时，可以放宽到 3 至 5 个工作日，但要写清楚。
- 优先级档位数量：三档适合需求类型相对集中的团队；多业务线并行时可以用四到五档，但档位含义要写成一句话定义，避免各人理解不同。
- 参与角色：小团队可以合并需求池管理员与产品负责人两个角色，研发代表在评审时按需参加；多业务线完整版则需要为每条业务线指定提出人代表。
小团队精简版与多业务线完整版的差异主要在字段和角色数量上。精简版保留编号、业务场景、状态、负责人、最近更新、关闭原因六个字段，角色合并为两人；完整版增加来源细分、优先级档、提出人部门等字段，并在月度评审中固定业务提出人代表席位。
规则落地时，建议先按示例跑两周再定稿。两周内记录三类情况：初审是否按时完成、每周清理会实际处理了多少条、关闭原因是否有人填不全。根据这些记录调整时限和频率，比一次写死更贴近团队实际节奏。
适用边界：这套机制覆盖什么、不覆盖什么
这套机制覆盖需求集合的收集、状态维护、定期清理与关闭，也就是从提报进入到关闭归档的完整生命周期管理。它回答的是“池子里有什么、每条处于什么状态、谁在负责、什么时候清理”这几个问题。
以下内容不属于本文范围：Sprint Backlog 的迭代排期与容量管理归迭代管理，本文只写到“已排期”状态为止；需求价值评分模型与优先级打分方法归需求优先级与价值评估，示例中的高/中/低三档只作排序参考，不构成评分方法；业务重复需求的判定标准本身也不在本文范围内，示例只给出合并动作和记录保留方式，具体什么算重复需要团队结合业务定义。
最后需要说明，本文的团队情景、角色设置、时限与频率均为虚构示例，用于演示机制写法，不代表任何真实团队的做法或效果。读者照填时应以自己团队的提报量、人员配置和评审习惯为准，先小范围试运行再定稿。
常见问题
需求池里的需求长期没人处理，机制上应该怎么兜底？
示例用两道关卡兜底。第一道是“最近更新”字段，状态、优先级或负责人任一变化都刷新日期，每周清理会按这个字段排序，超过 14 天未更新的条目自动进入处理清单。第二道是关闭条件，最近更新超过 60 天且未进入排期候选的需求，由产品负责人在清理会上决定继续保留还是关闭。两道关卡配合，池子里不会长期存在无人认领的条目。
如果团队提报量很小，清理频率可以放宽到双周，但“最近更新”字段建议保留，它是判断停滞的唯一客观依据。
重复需求合并后，原提出人的诉求怎么跟踪？
示例的做法是保留最早一条作为主记录，其余记录标记为“重复合并”，并在关闭原因中写明主记录编号。原记录的来源和提出人信息不删除，后续评估影响范围时可以回溯到所有提出方。
需要提醒的是，什么算重复属于业务判断，本文只给出合并动作和记录保留方式。团队应在机制里补一句判定口径，例如同一业务场景下的同一诉求算重复，避免管理员凭个人理解合并。
小团队没有专职需求池管理员，这套机制还能用吗？
可以用，做法是合并角色。示例中需求池管理员负责初审、字段检查和清理会组织，小团队可以把这些职责并入产品负责人，同时把初审时限从 2 个工作日放宽到 3 至 5 个工作日，并写进规则表。
字段也可以精简到六个：编号、业务场景、状态、负责人、最近更新、关闭原因。这六项分别支撑评估、流转、责任归属和清理，删减后机制仍能运转。参与角色合并后，月度评审可以改为按需召开，但关闭原因的填写要求建议保留。
机制刚落地时，怎么判断规则定得合不合适？
建议先按示例跑两周再定稿，期间记录三类情况：初审是否按时完成、每周清理会实际处理了多少条需求、关闭原因有没有人填不全。这三项分别对应入口效率、清理效果和记录质量。
根据记录调整时限和频率，比一次写死更贴近团队节奏。例如初审经常超时，说明时限偏紧或提报量超出预期；清理会处理量长期为零，说明频率过高或停滞判定阈值需要放宽。
需求池里的需求进入迭代后，还需要继续维护吗？
示例的机制写到“已排期”状态为止，需求分配到具体迭代或版本后，后续的排期调整、容量管理和任务拆解归迭代管理，不在需求池维护的范围内。需求池只保留一条指向迭代的记录，开发完成并验收后关闭，关闭原因填“已实现”并关联对应迭代。
这样划分的好处是池子始终反映“还没排期的需求集合”，评审时看到的是真实待办，不会被已进入开发的需求干扰。
