需求池状态管理要解决的是需求池里“看不清、推不动、清不掉”的问题：需求进来后长期停在同一个状态，责任人不明确，评审记录缺失，池子越堆越大。本文给出一套可直接套用的状态集合、流转规则与角色分工，并按顺序说明从建表到跑通第一条需求的操作步骤，最后提供验收检查清单。文中会以ONES作为承载状态字段与流转记录的工作平台举例，帮助理解规则如何落到工具中。
要点总览（TL;DR）
- 需求池状态管理的核心是设一套互斥状态，每个状态都写明进入条件、退出条件、责任角色和必填字段，让团队看到状态就能判断下一步由谁做什么。
- 可直接套用的状态集合为待评估、已确认、已排期、开发中、已交付、已关闭；暂缓与拒绝作为已关闭下的原因字段记录，减少状态数量。
- 流转规则收敛为一条主链路，只保留待评估直接关闭、已交付退回开发中两类例外；确认评审和排期评审的结论要写入需求记录。
- 落地按五步执行：盘点需求统一字段、形成状态与流转文档、在工具中配置状态与必填校验、用一条真实需求走通全流程、发布规则并做角色说明。
- 用每周清理和月度复盘检查滞留需求、字段完整率和评审质量；状态长期不动、字段大面积空缺、评审只有结论没有依据，是机制失效的信号。
需求池状态怎么划分：一套可直接套用的状态集合
状态划分的起点是回答一个问题：看到这个状态，团队能否判断下一步该做什么、由谁做。能判断，状态就有存在价值；不能判断，就应合并或删除。基于这个标准，需求池可以先用六个互斥状态覆盖需求从进入到离开的全过程。
| 状态名 | 定义 | 进入条件 | 退出条件 | 责任角色 |
|---|---|---|---|---|
| 待评估 | 需求已提交，尚未完成价值与可行性判断 | 提出人提交需求，填写来源与基本背景 | 完成评审，给出确认、暂缓或拒绝结论 | 需求负责人 |
| 已确认 | 需求被认可值得做，但尚未确定交付时间 | 评审通过，业务价值说明与影响范围已补齐 | 进入排期决策，确定目标版本或时间窗 | 产品负责人 |
| 已排期 | 需求已确定交付时间窗，等待进入开发 | 排期评审通过，目标版本或时间窗字段已填写 | 开发任务启动，需求转入开发中 | 产品负责人 |
| 开发中 | 需求对应的研发工作已经开始 | 已关联研发任务并进入执行 | 研发完成并交付验收 | 研发负责人 |
| 已交付 | 需求成果已交付，等待验收或已验收 | 研发完成，交付物可被验证 | 验收通过后关闭；验收不通过退回开发中 | 需求负责人 |
| 已关闭 | 需求结束生命周期，含完成关闭、暂缓与拒绝 | 验收通过，或评审结论为暂缓、拒绝 | 无，如需重启则新建或重新激活并注明原因 | 产品负责人 |
状态互斥是这套方案的基本约束：同一需求在同一时刻只处于一个状态，状态字段只允许单选。这样任何一次池内盘点，按状态分组统计就能得到准确的需求分布，不会出现一条需求既算“已确认”又算“已排期”的情况。
状态数量需要控制。每增加一个状态，就多一组进入退出条件、多一次培训说明、多一处统计口径。判断是否新增状态，可以看它是否对应一个不同的责任角色或一个不同的决策动作；如果两个状态由同一角色在同一环节处理，通常合并即可。暂缓与拒绝不必单独设状态，作为“已关闭”下的关闭原因字段记录，既保留信息又减少状态数。
还要明确本文的边界：需求进入“已排期”之后，具体放在哪个迭代、迭代内如何排布，属于迭代管理的范围；需求值不值得做、优先级如何排序，属于优先级评估的范围。状态管理只负责让每条需求在池中处于可判断的位置，并把判断结果记录下来。
状态流转规则与角色分工：谁在什么条件下推动需求
状态表只定义了“在哪里”，流转规则要定义“怎么走、谁来推、带什么信息走”。允许的路径应当收敛为一条主链路：待评估→已确认→已排期→开发中→已交付→已关闭。同时允许两类例外：待评估可直接关闭（评审即拒绝），已交付可退回开发中（验收不通过）。除此之外的跳转应当禁止，例如待评估直接跳到已排期，意味着跳过了确认评审，价值依据没有留下记录。
| 流转动作 | 触发角色 | 前置条件 | 流转时必填 |
|---|---|---|---|
| 提交需求，进入待评估 | 需求提出人 | 说明需求背景与期望结果 | 来源、提出人、业务场景描述 |
| 待评估→已确认 | 需求负责人发起，评审组确认 | 完成确认评审 | 业务价值说明、影响范围、评审结论 |
| 待评估→已关闭 | 需求负责人 | 评审结论为拒绝或暂缓 | 关闭原因、结论说明 |
| 已确认→已排期 | 产品负责人 | 完成排期评审 | 目标版本或时间窗、排期依据 |
| 已排期→开发中 | 研发负责人 | 研发任务已建立并启动 | 关联研发任务、预计完成时间 |
| 开发中→已交付 | 研发负责人 | 交付物可验证 | 交付说明、验证方式 |
| 已交付→已关闭 | 需求负责人 | 验收通过 | 验收结论 |
| 已交付→开发中 | 需求负责人 | 验收不通过 | 不通过原因、待修复项 |
评审节点集中在两处。进入“已确认”前的确认评审，回答“这个需求值不值得做”，参与角色包括需求负责人和相关业务方；进入“已排期”前的排期评审，回答“什么时候做、和哪些需求争资源”，参与角色包括产品负责人和研发负责人。两次评审的结论都要写入需求记录，而不是只在会议上口头达成。
必填字段是流转规则的硬约束。来源、业务价值说明、影响范围、目标版本或时间窗这四类信息，分别对应“谁提的”“为什么做”“影响多大”“什么时候做”，缺任何一项，后续角色都无法独立判断。把这些字段设置为流转时的必填项，可以让规则不依赖个人记忆。
超时停留需要单独处理。可以为每个状态设定建议停留时限，例如待评估不超过两周、已确认不超过一个排期周期。超过时限的需求在每周清理时被标记出来，由责任角色给出下一步动作：推进、补充信息或关闭。清理动作本身要有记录，避免同一需求被反复标记却无人处理。
在工具承载上，ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，可以把上述状态集合和必填字段配置为需求工作项的字段；ONES 还可根据实际场景自定义工作流，促进需求规范化流转。对于功能复杂的需求，可利用子工作项进行拆解，并关联研发和测试任务，把需求、研发、测试环节串联起来。来自各方的反馈也可以通过工单收集，处理后再转化为需求进入池中。
需求池状态管理的操作步骤：从建表到跑通第一条需求
规则确定后，按以下五步执行。每一步都给出输入、动作、输出和完成标志，便于对照推进。
第一步：盘点现有需求，统一字段与去重口径。输入是当前散落在表格、聊天记录、工单中的全部需求。动作是逐条登记，统一来源、提出人、业务场景、期望结果等基础字段，并对明显重复的需求做合并标注。输出是一份字段统一的需求清单。完成标志是清单中每条需求都有来源和提出人，重复项已标注合并关系。
第二步：确定状态集合与流转规则并形成文档。输入是第一步的需求清单和本文第一、二节的状态表与流转表。动作是根据团队实际调整状态名称与责任角色，确认允许路径和禁止跳转，写成一份可查阅的规则文档。输出是状态定义表、流转规则说明和角色职责表。完成标志是文档中每个状态都有进入退出条件和责任人，每条允许路径都有触发角色。
第三步：在承载工具中配置状态字段与必填校验。输入是第二步的规则文档。动作是在需求工作项上建立单选状态字段，配置状态选项与流转路径，把关键字段设为流转必填，并建立按状态分组的视图便于盘点。输出是配置完成的需求池。完成标志是用测试需求验证：状态只能单选、非法跳转被阻止、必填字段缺失时无法完成流转。
第四步：选一条真实需求完整走一遍流程，记录卡点。输入是配置好的需求池和一条真实待处理需求。动作是由各角色按规则依次推动状态变化，记录每次流转的耗时、字段补充情况和评审结论。输出是一份首条需求的试运行记录。完成标志是需求走完从待评估到已关闭（或已排期）的完整路径，卡点已列出并有处理意见。
第五步：发布规则并组织一次角色说明。输入是规则文档和试运行记录。动作是向提出人、需求负责人、产品负责人、研发负责人分别说明其触发动作与必填责任，用试运行中的真实例子讲解。输出是发布通知和参会确认。完成标志是各角色能说出自己负责的流转动作和需要填写的字段。
示例：一条需求在状态池中的完整流转
以下为演示情景，用于说明状态、角色、字段和评审如何配合，不代表真实项目数据。
某业务方提出需求：“希望在报表页增加按客户维度导出。”提出人在工单中提交，填写来源为“客户成功团队转达”、业务场景为“季度对账需要按客户拆分数据”，需求进入待评估状态，责任人为需求负责人。
需求负责人在确认评审前补充业务价值说明：涉及三个重点客户的季度对账，当前需人工整理，每次约半天；影响范围为报表模块，不涉及数据结构变更。评审组确认需求值得做，结论写入需求记录，状态转为已确认。此时需求尚未确定交付时间。
排期评审中，产品负责人对照当前版本计划，判断该需求可放入下一版本，填写目标版本与排期依据，状态转为已排期。研发负责人建立研发任务并关联到该需求，任务启动后状态转为开发中。开发完成后，研发负责人填写交付说明与验证方式，状态转为已交付。
需求负责人组织验收，确认导出结果与对账口径一致，填写验收结论后关闭需求。假如验收发现导出字段缺失，则退回开发中并记录待修复项，修复后再次进入已交付。若排期评审时判断本季度资源不足，则需求保持已确认并标注复核时间，而不是长期挂在待评估。
这个例子体现的可迁移做法有三点：每次流转都有明确触发角色；关键评审结论写入需求记录而非停留在会议；状态变化与字段补充同步完成，使后来者能独立读懂这条需求走到了哪一步。
完成检查：需求池状态管理是否跑起来的验收项
机制是否落地，可以用下面这份清单逐项核对。每项都给出责任人与证据来源，避免检查停留在主观感受。
| 检查项 | 合格标准 | 责任人 | 证据来源 |
|---|---|---|---|
| 状态定义与流转规则有文档 | 文档可查阅，含状态定义、允许路径、角色职责 | 产品负责人 | 规则文档及版本记录 |
| 角色知晓规则 | 各角色能说出自己的触发动作与必填字段 | 需求负责人 | 培训记录或说明会签到 |
| 池内需求均有明确状态 | 不存在无状态或状态为空的需求 | 需求负责人 | 按状态分组的池内视图 |
| 无长期滞留需求 | 超过建议停留时限的需求已被标记并给出处理结论 | 需求负责人 | 每周清理记录 |
| 必填字段完整 | 来源、业务价值、影响范围、目标时间窗填写率达标 | 产品负责人 | 字段完整率统计 |
| 评审记录可查 | 确认评审与排期评审均有结论记录 | 评审组 | 需求记录中的评审结论 |
| 清理与复盘按时执行 | 每周清理、月度复盘有固定产出 | 产品负责人 | 清理纪要与复盘结论 |
常见失效信号值得单独留意：状态长期不动，说明流转缺少触发人或评审没有固定节奏；字段大面积空缺，说明必填约束没有配置或角色不清楚填写要求；评审流于形式，表现为评审结论只有“通过”二字、没有依据记录。出现这些信号时，优先回到流转规则和角色分工检查，而不是增加更多状态或字段。
检查频率上，每周清理关注滞留与字段完整，月度复盘关注状态分布变化和评审质量。ONES Project 支持全局筛选与项目内筛选，可利用多重条件快速定位所需内容，便于按状态、停留时间或字段缺失情况筛出待处理需求，作为清理与检查的操作入口。
常见问题
需求池状态设置多少个比较合适？
以“看到状态能否判断下一步动作和责任人”为标准取舍。本文给出的六个状态覆盖需求从进入到离开的全过程，多数团队可以直接使用。如果两个状态由同一角色在同一环节处理，通常合并即可。每增加一个状态，就多一组进入退出条件、多一次培训说明和多一处统计口径，维护成本会随之上升。
需求被暂缓或拒绝时，应该单独设一个状态吗？
可以不单独设状态。把暂缓与拒绝作为“已关闭”状态下的关闭原因字段记录，既能保留结论信息，又不会让状态列表变长。需要重启时，新建需求或重新激活并注明原因，避免一条需求在已关闭和待评估之间反复切换、丢失历史记录。
需求在某个状态停留过久，应该怎么处理？
先为每个状态设定建议停留时限，例如待评估不超过两周、已确认不超过一个排期周期。每周清理时把超时需求筛出来，由该状态的责任角色给出明确动作：推进、补充信息或关闭。清理动作要留下记录，避免同一需求被反复标记却无人处理。如果超时集中出现在某个状态，优先检查该环节的触发角色是否明确、评审是否有固定节奏。
状态流转的必填字段怎么定，才不会变成填表负担？
只保留后续角色独立判断所必需的信息：来源对应“谁提的”，业务价值说明对应“为什么做”，影响范围对应“影响多大”，目标版本或时间窗对应“什么时候做”。这四类字段在对应流转节点设为必填，其余信息按需补充。字段过多会让提出人在提交环节就放弃填写，反而降低数据质量。
在工具中配置状态和流转时，需要验证哪些点？
配置完成后至少验证三件事：状态字段只能单选，同一需求不会同时处于两个状态；规则中禁止的跳转无法完成，例如待评估不能直接进入已排期；关键字段缺失时流转被阻止。ONES Project 支持自定义需求状态与多种属性，并可根据实际场景自定义工作流，可用于承载上述配置。具体必填校验和超时提醒的配置方式，建议在实际环境中先行验证。
