需求池状态定义要解决的核心问题，是让每个人看到某个状态时能做出同样的判断。做法是把状态写成一张五列表：状态名称、含义、进入条件、责任角色、退出动作，其中进入条件必须对应可核对的证据，责任角色必须落到具体岗位。本文给出一套最小状态集和可直接填写的模板，并说明如何配置到管理工具中。状态定义可以落到 ONES 工作项状态与自定义工作流上，本文在流转配置部分说明衔接方式。
要点总览（TL;DR）
- 需求池状态定义用一张五列表落地：状态名称、含义、进入条件、责任角色、退出动作，进入条件必须对应可核对的证据。
- 起步建议七个状态：待提交、待评审、已确认、已排期、开发中、已交付、已关闭/暂缓，团队可按规模和需求量合并或增补。
- 责任角色写到岗位层面：需求提出人、产品经理、产品负责人、研发负责人、测试负责人，每个状态只有一个主责角色。
- 流转要写明允许路径与禁止跳转，关键流转设置必填项，配置到工具时状态名称与状态表保持一致。
- 上线后先试运行并抽样核对，状态定义变更需评审和版本记录，定期复查比一次定稿更重要。
需求池状态表：五列字段与最小状态集
状态表的作用是把口头约定变成可核对的规则。建议统一使用五列结构，团队填写和工具配置都以这张表为唯一口径。
| 状态名称 | 含义 | 进入条件 | 责任角色 | 退出动作 |
|---|---|---|---|---|
| 待提交 | 需求已被记录，信息尚未补齐 | （填写证据要求） | （填写岗位） | （填写推进动作） |
| 待评审 | 信息完整，等待评审 | |||
| 已确认 | 评审通过，纳入需求池 | |||
| 已排期 | 已确定进入某个迭代或版本 | |||
| 开发中 | 研发已开始处理 | |||
| 已交付 | 成果已提交验收 | |||
| 已关闭/暂缓 | 不再推进或延后处理 |
最小状态集建议为：待提交、待评审、已确认、已排期、开发中、已交付、已关闭/暂缓。这七个状态覆盖了需求从进入到退出的主要节点，含义边界清晰，适合多数团队起步使用。
进入条件的写法决定这张表是否可用。每条进入条件都应指向一个能被他人检查的证据，例如“需求描述中的背景、目标、验收标准三个字段均已填写”“评审会议留有结论记录且结论为通过”“迭代计划中已分配负责人和计划完成时间”。避免写“评估差不多”“信息基本清楚”这类依赖个人判断的表述，否则不同人会对同一状态给出不同结论。
状态数量应与团队规模和需求量匹配。人数少、需求来源单一的团队，可以把“待评审”和“已确认”合并为一个状态，减少流转环节；需求量大、跨团队协作多的组织，可以增加“待补充信息”这类中间状态，把信息补齐的动作单独标识出来，避免需求在评审环节反复退回。状态越多，维护成本越高，增加状态前先确认它对应一个独立的判断节点。
各状态进入条件与责任角色的逐项写法
下面按最小状态集逐项给出进入条件、责任角色和证据类型的写法参考。团队可在此基础上按自身流程调整，但每条条件都应保持可核对。
| 状态 | 进入条件 | 主责角色 | 配合角色 | 证据类型 |
|---|---|---|---|---|
| 待提交 | 需求已被记录，提出方、场景描述、期望结果三项已填写 | 需求提出人 | 产品经理（协助澄清） | 需求描述完整度 |
| 待评审 | 需求描述中的背景、目标、验收标准已填写完整，并指定了评审参与人 | 产品经理 | 需求提出人 | 需求描述完整度 |
| 已确认 | 评审已完成，留有评审结论记录，结论为通过或通过并附修改意见 | 产品负责人 | 需求评审组（研发、测试代表） | 评审记录 |
| 已排期 | 已确定目标迭代或版本，并分配了研发负责人和计划完成时间 | 产品负责人 | 研发负责人 | 排期结论 |
| 开发中 | 研发负责人已确认启动，需求已关联对应的研发任务 | 研发负责人 | 产品经理 | 任务关联记录 |
| 已交付 | 研发成果已提交，测试完成验证并留有验收结果 | 测试负责人 | 研发负责人、产品经理 | 验收结果 |
| 已关闭/暂缓 | 关闭需有明确结论（如重复、不做、已由其他需求覆盖）；暂缓需注明恢复条件和复查时间 | 产品负责人 | 需求提出人 | 结论记录 |
责任角色写到岗位或职责层面，不写“相关人员”。主责角色对该状态的进入负责，配合角色提供进入条件所需的材料。例如“待评审”的主责是产品经理，他负责确认描述字段完整并组织评审；“已确认”的主责是产品负责人，他负责给出评审结论。
关闭与暂缓需要区分清楚。关闭表示该需求不再推进，触发条件通常是评审判定为重复、与产品方向不符或已被其他需求覆盖，处理时应记录结论和依据。暂缓表示需求仍然有效但当前不推进，触发条件通常是资源不足、依赖未就绪或时机不成熟，处理时应写明恢复条件和复查时间，避免需求长期沉在池底无人处理。
状态流转规则与配置到管理工具的方法
状态之间按顺序推进，同时允许必要的退回。建议明确以下流转路径：待提交→待评审→已确认→已排期→开发中→已交付；已交付后可进入已关闭。退回路径包括：待评审退回待提交（信息不完整）、已确认退回待评审（评审结论需要复议）、开发中退回已排期（启动条件不满足）。禁止的跳转应写清楚，例如未评审的需求不得直接进入开发中，未排期的需求不得标记为开发中。
每次流转都应有触发动作和确认环节。进入“已确认”需要评审结论，进入“已排期”需要排期结论，进入“已交付”需要验收结果。谁有权推进某个状态，与上一节的责任角色表保持一致，工具配置时按角色分配操作权限。
配置到管理工具时，按以下要点逐项落地：
- 状态字段：按最小状态集建立状态选项，名称与状态表完全一致，避免工具里出现同义不同名的状态。
- 流转规则：配置允许的状态流转路径，限制跳转；对关键流转设置必填项，例如进入“已确认”时必填评审结论，进入“已交付”时必填验收结果。
- 权限设置：按岗位或项目角色分配状态变更权限，使主责角色能推进对应状态，其他角色只能查看或提交材料。
- 变更记录与通知：开启状态变更记录，保留操作人和时间；设置通知对象为下一环节的责任角色，减少需求停留在某状态无人跟进的情况。
ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，也支持按组织架构、用户组、项目角色分配多层级权限，可作为承载上述状态表的工具。在需求池管理场景中，ONES 支持自定义工作流以规范需求流转，并可将工单收集的反馈转化为需求、整理为产品 Backlog；对于功能复杂的需求，可用子工作项拆解并关联研发和测试任务。配置时以状态表为准逐项核对，具体配置入口和字段范围以实际版本为准。
填写示例：一条需求从提交到关闭的状态轨迹
以下为演示情景，用于说明状态表的使用方式，不代表真实项目数据。
某团队收到一条需求：客服希望订单列表页支持按退款状态筛选。角色分工为：客服专员作为需求提出人，产品经理负责评审组织，产品负责人给出评审结论，研发负责人和测试负责人分别承担开发与验收。
| 状态 | 进入时提交的证据 | 推进动作 |
|---|---|---|
| 待提交 | 客服专员填写提出方、使用场景、期望结果 | 产品经理补充验收标准后提交评审 |
| 待评审 | 背景、目标、验收标准三项完整，评审参与人已指定 | 产品经理组织评审，研发与测试代表参加 |
| 已确认 | 评审结论记录为通过，附一条修改意见（筛选条件需支持多选） | 产品负责人确认结论，需求进入池中待排期 |
| 已排期 | 排期结论：进入下一迭代，研发负责人已分配，计划完成时间已填写 | 研发负责人确认启动条件 |
| 开发中 | 需求已关联研发任务，研发负责人确认启动 | 研发完成开发，提交测试 |
| 已交付 | 测试完成验证，验收结果记录为通过 | 产品负责人确认交付，需求关闭 |
示例中发生过一次退回：评审时提出筛选条件需支持多选，需求从“已确认”退回“待评审”补充验收标准，补充完成后再次通过。这说明退回是正常流转的一部分，关键是退回时留下原因记录，便于后续追溯。
这个示例可迁移的规律是：每个状态的进入都对应一份可查的记录，推进动作由主责角色完成。适用边界在于，示例假设需求来源单一、评审参与人固定；如果团队需求来源多、评审组经常变化，需要在“待评审”状态中补充评审参与人的确认规则。
上线前的完成检查与维护机制
状态表定稿后，先做一轮完整性检查，再配置到工具中试运行。
- 状态表完整性：最小状态集是否覆盖需求从进入到退出的全部节点，是否存在两个状态含义重叠。
- 条件可核对性：逐条检查进入条件，确认每条都能指向一份记录或一个字段，没有主观判断表述。
- 角色明确性：每个状态是否都有唯一主责角色，配合角色是否写清，是否存在无人负责的状态。
- 流转规则一致性：允许路径与禁止跳转是否与状态表对应，关键流转的必填项是否已配置。
配置完成后先试运行一段时间，抽样核对状态与实际进展是否一致。抽样时重点看两类情况：长期停留在同一状态的需求，以及跳过中间状态直接推进的需求。前者可能说明进入条件过严或责任角色未跟进，后者可能说明流转限制未生效。
状态定义的变更应有评审和版本记录。新增或合并状态、调整进入条件、修改责任角色，都应经过产品负责人和相关角色确认，并在状态表中记录变更时间和原因，避免不同时期的需求按不同口径判断。
常见失效信号包括：大量需求长期停留在“待评审”、状态变更记录缺失操作人、同一需求在不同人描述中状态不一致。对应的纠正动作分别是：检查评审组织是否及时、开启变更记录、组织一次状态口径对齐并更新状态表。状态表是持续使用的管理工具，定期复查比一次定稿更重要。
常见问题
小团队需求少，七个状态能不能精简？
可以。人数少、需求来源单一的团队，可以把“待评审”和“已确认”合并为一个状态，评审通过即视为纳入需求池，减少一次流转操作。合并后要在状态含义里写清“评审通过”这一进入条件，避免合并后判断标准变模糊。精简的前提是每个保留的状态仍对应一个独立的判断节点，合并后不出现两个状态含义重叠。
需求被退回时，状态应该怎么处理？
退回按正常流转处理，不另设“退回”状态。信息不完整时从“待评审”退回“待提交”，评审结论需要复议时从“已确认”退回“待评审”，启动条件不满足时从“开发中”退回“已排期”。退回时留下原因记录，写清缺什么材料或哪条结论需要调整，便于下次进入同一状态时对照检查。
关闭和暂缓怎么区分，谁来拍板？
关闭表示需求不再推进，触发条件通常是评审判定为重复、与产品方向不符或已被其他需求覆盖；暂缓表示需求仍然有效但当前不推进，触发条件通常是资源不足、依赖未就绪或时机不成熟。两者都由产品负责人给出结论，暂缓还需注明恢复条件和复查时间，到期后重新评估，避免需求长期沉在池底。
状态表配置到工具后，怎么判断配置是否生效？
试运行一段时间后抽样核对，重点看两类情况：长期停留在同一状态的需求，以及跳过中间状态直接推进的需求。前者可能说明进入条件过严或责任角色未跟进，后者可能说明流转限制未生效。同时检查状态变更记录是否保留操作人和时间，通知是否送达下一环节的责任角色。
状态定义需要调整时，走什么流程？
新增或合并状态、调整进入条件、修改责任角色，都先由产品负责人和相关角色确认，再更新状态表并记录变更时间和原因，然后同步修改工具中的状态选项与流转规则。变更后对在途需求做一次口径对齐，避免同一时期的需求按新旧两套标准判断。
