需求池状态管理的核心，是让每个需求在任意时刻都有一个明确、互斥的处理阶段标识，团队据此判断下一步由谁做什么。具体做法包括：定义约6个状态并写明进入条件，规定允许的流转路径与触发动作，为每个状态指定负责人和交付物，再通过定期巡检维持状态可信。本文按这四步展开，并给出一条需求的完整流转示例和可逐项核对的检查清单。文中会结合ONES说明状态与流转规则如何在工具中承载。
要点总览（TL;DR）
- 状态集合控制在6个左右，每个状态写明含义、进入条件和责任角色，用“同一条需求能否给出一致判断”检验定义是否互斥。
- 流转规则要同时写清允许路径、触发动作和禁止跳转，状态变更时同步记录操作人、变更依据和关键字段。
- 每个状态指定唯一推进负责人和关键交付物，并设定建议停留时限，超时需求在巡检中单独处置。
- 用一条需求从待评估到已上线的完整过程串联规则，验收不通过、驳回、暂缓、重复等异常按预设路径处理。
- 每周轻量巡检、每月完整清理，通过状态分布、字段完整性和滞留处理判断机制是否达标。
先定状态：需求池需要哪几个状态
状态设计的第一个决定是数量。状态太少，无法区分“已确认但未排期”和“已排期但未开工”这类处理阶段不同的需求；状态太多，团队记不住，填写时凭感觉选，状态就失去可信度。对多数团队而言，6个左右是较实用的区间：覆盖从进入到关闭的主要阶段，每个状态都能对应一个明确的下一步动作。
状态之间要含义互斥。判断方法很简单：拿一条具体需求，问“它现在处于哪个状态”，如果两个人给出不同答案且都有道理，说明定义有重叠，需要合并或补充进入条件。状态名应描述处理阶段，避免使用“处理中”“跟进中”这类无法判断进展的表述。
下表是一套可直接采用的状态集合，团队可按业务调整名称，但建议保留“含义—进入条件—责任角色”三列，缺一列就容易在执行中产生歧义。
| 状态名 | 含义 | 进入条件 | 责任角色 |
|---|---|---|---|
| 待评估 | 需求已进入池子，尚未完成价值与可行性判断 | 提出人提交需求描述、来源与期望时间 | 产品负责人 |
| 已确认 | 需求成立，值得进入后续规划 | 完成评估，记录评估结论与目标用户 | 产品负责人 |
| 已排期 | 需求已确定进入某个迭代或时间窗口 | 排期结论明确，关联迭代或计划日期 | 产品负责人与研发负责人 |
| 开发中 | 研发已开始实现 | 关联开发任务，明确开发负责人 | 研发负责人 |
| 待验收 | 开发完成，等待验证 | 提交测试或验收说明，关联验收人 | 测试/验收人 |
| 已上线 | 通过验收并已交付使用 | 验收记录完整，上线时间明确 | 产品负责人 |
| 已关闭 | 需求终止，不再推进 | 记录关闭原因（驳回、重复、暂缓取消等） | 产品负责人 |
上表列出7个状态，其中“已关闭”是终止态，可与“已上线”并列作为两个出口。若团队规模较小、需求流转较快，可将“待验收”并入“开发中”的末段，把状态压到6个；若存在独立的需求评审环节，也可在“待评估”和“已确认”之间增加“评审中”。调整的依据是团队是否真的需要在该阶段做出不同决策，而非追求状态齐全。
状态流转规则与触发动作
状态定义解决“是什么”，流转规则解决“怎么走”。规则要写清三件事：哪些路径允许、由什么动作触发、变更时同步更新哪些字段。三者缺一，状态就会变成手工改标签，无法反映真实进展。
常规路径可按“待评估→已确认→已排期→开发中→待验收→已上线”单向推进。允许的例外路径需要单独列出，例如“待评估→已关闭”（评估后驳回）、“已确认→已关闭”（确认后因重复或取消而终止）、“待验收→开发中”（验收不通过退回修改）。禁止的跳转同样要写明，典型如“待评估→开发中”跳过确认与排期、“已排期→已上线”跳过开发与验收。禁止跳转的意义在于防止需求绕过关键决策点，而不是限制操作自由。
每个状态变更都应由一个具体动作触发，而不是由某人主观判断“差不多可以了”。常见触发动作包括：评估会形成结论后由待评估进入已确认；排期确认后进入已排期；开发任务创建并开始执行后进入开发中；验收通过并记录结果后进入已上线。触发动作与状态一一对应，团队才能追溯某条需求为何在某个时间点改变了阶段。
状态变更时必须同步更新的字段，建议至少包括：变更时间、操作人、变更依据（如评审记录、排期结论、验收记录链接）。对进入“已排期”的需求，要求填写迭代或计划日期；对进入“已关闭”的需求，要求填写关闭原因。这些字段是后续巡检和复盘的数据基础。
回退与重新打开需要单独规定。回退指在正常路径上退回上一状态，例如验收不通过退回开发中，应保留原验收记录并注明退回原因。重新打开指已关闭或已上线的需求再次被激活，应视为新的一轮处理，重新走评估或确认流程，并关联原需求，避免同一问题在池中重复出现却互不关联。规则确定后，可在ONES中通过自定义需求状态与工作流配置承载这些路径，让状态变更按设定流程执行，减少手工改标签带来的偏差。
角色分工与各状态的交付物
状态能否被推进，取决于每个状态是否有唯一负责人和明确交付物。没有负责人的状态，需求会在其中长期停留；没有交付物的状态，推进就缺少可核对的完成标志。
需求提出人负责提供初始信息：需求描述、来源、期望时间和使用场景。信息不足的需求可以进入待评估，但应在评估前补齐，否则评估结论缺乏依据。产品负责人是待评估、已确认、已排期和已关闭的主要推进者，负责给出评估结论、排期结果和关闭原因。研发负责人对开发中状态负责，确认开发任务已创建并有人承接。测试/验收人对验收结果负责，记录通过或不通过的结论。
停留时限用于发现异常。可为每个状态设定建议时限，例如待评估不超过两周、已确认待排期不超过一个排期周期、待验收不超过五个工作日。时限不是硬性考核，而是巡检时的提示信号：超时需求应被单独查看，判断是信息缺失、资源不足还是需求本身已失效。
| 状态 | 推进负责人 | 关键交付物 | 建议停留时限 |
|---|---|---|---|
| 待评估 | 产品负责人 | 评估结论（成立/驳回/需补充信息） | 两周 |
| 已确认 | 产品负责人 | 目标用户、价值说明、优先级判断 | 一个排期周期 |
| 已排期 | 产品负责人、研发负责人 | 迭代或计划日期、初步方案 | 至计划开始前 |
| 开发中 | 研发负责人 | 开发任务、进度说明 | 按任务计划 |
| 待验收 | 测试/验收人 | 验收记录、问题清单 | 五个工作日 |
| 已上线 | 产品负责人 | 上线时间、验收结论 | 不设，作为完成态 |
| 已关闭 | 产品负责人 | 关闭原因、关联需求（如重复） | 不设，作为终止态 |
交接时的信息要求同样重要。需求从产品负责人交给研发负责人时，应确保需求描述、验收标准和排期结论已写入需求记录，而不是只在会议口头说明。从研发交给验收时，应附上变更说明和自测结果。交接信息完整，接收方才能在不追问的情况下继续推进，状态变更也才有据可查。
一次完整的状态流转示例
以下为演示情景，用于说明前述规则如何落地，不代表特定团队的真实数据。
某业务方提出“订单列表支持按客户标签筛选”。初始信息包括：提出人、来源为客服反馈汇总、期望在下个季度内可用、使用场景为客服快速定位客户订单。需求进入待评估，负责人为产品负责人。
评估会上，产品负责人确认该需求与现有筛选能力可复用，目标用户明确，结论为成立，需求进入已确认，记录评估结论和目标用户。随后在排期讨论中，该需求被确定进入下一迭代，填写迭代名称和计划日期，状态变为已排期。研发负责人创建开发任务并指定开发人员后，状态进入开发中。
开发完成后提交验收，状态变为待验收，附自测说明。验收人发现标签为空时的展示逻辑不符合预期，验收不通过，需求退回开发中，保留验收记录并注明退回原因。修复后再次提交验收，通过并上线，状态变为已上线，记录上线时间和验收结论。
异常情况的处理同样遵循规则：若评估结论为不成立，需求直接进入已关闭并记录驳回原因；若评估成立但当期资源不足，可停留在已确认并标注暂缓，暂缓超过约定周期后在巡检中重新判断；若发现与池中已有需求重复，保留一条主需求，另一条进入已关闭并关联主需求，避免重复统计。关闭或上线的判定依据始终是记录中的结论和日期，而非口头确认。
日常维护与完成检查
状态管理建立后，需求池的可信度靠日常维护维持。建议每周进行一次轻量巡检，每月进行一次完整清理。周巡检关注新增需求和状态变更是否规范，月清理关注长期滞留需求和状态分布是否合理。
长期滞留需求的处置方式应提前约定：超过建议时限仍未推进的需求，由负责人在巡检中给出下一步结论——继续推进、补充信息、暂缓并设定复查时间，或关闭。处置结论要写回需求记录，不能只在巡检会上口头说明。
状态分布与流转记录的检查项包括：各状态需求数量是否与团队实际工作量匹配；是否存在大量需求集中在某一状态；状态变更是否都有操作人和变更依据；关闭需求是否都填写了原因；重复需求是否已关联。这些检查项可以直接从需求记录中抽取，不需要额外统计口径。
| 检查项 | 通过标准 |
|---|---|
| 状态定义 | 每个状态有含义、进入条件和负责人，团队能对同一条需求给出一致判断 |
| 流转规范 | 抽查的需求状态变更均有触发动作和变更记录，无禁止跳转 |
| 字段完整 | 已排期需求有排期信息，已关闭需求有原因，待验收需求有验收人 |
| 滞留处理 | 超时需求均有处置结论，无长期无人推进的需求 |
| 状态分布 | 各状态数量与团队实际处理节奏相符，无明显堆积或空转 |
判断状态管理是否达标，可以用一个简单测试：随机抽取若干需求，查看其当前状态和最近一次变更记录，若能在不询问他人的情况下说清“它为什么在这个状态、下一步由谁做什么”，说明机制有效。反之，若状态与记录对不上，或负责人需要临时回忆，则应回到状态定义和流转规则检查，而不是增加更多状态。ONES Project 支持建立需求池、自定义需求状态与属性，并可按实际场景配置工作流，适合将上述状态集合与流转规则固化到日常操作中；具体配置范围和权限需在实际环境中确认。
常见问题
团队规模较小，能不能把状态压缩到四五个？
可以。状态数量的依据是团队是否真的需要在该阶段做出不同决策。若需求流转快、验收与开发由同一批人衔接，可把“待验收”并入“开发中”的末段；若没有独立评审环节，“评审中”也不必单设。压缩后要检查两件事：合并后的状态是否仍能对应明确的下一步动作，以及原本由不同角色负责的环节是否还有唯一负责人。状态变少但责任不清，问题会从“选错状态”变成“没人推进”。
需求在“已确认”停留很久但一直排不上期，该怎么处理？
先区分原因再决定动作。若是信息不足，退回补充目标用户和价值说明；若是资源不足，标注暂缓并设定复查时间，到期在巡检中重新判断；若是需求本身已失效，直接关闭并记录原因。关键是让“已确认”不成为默认堆放区：每条长期停留的需求都应有处置结论写回记录，而不是继续留在池中等待。若大量需求集中在该状态，说明排期节奏与需求进入速度不匹配，需要从入口把关，而不是增加状态。
已关闭的需求后来又被业务方提起，是重新打开还是新建？
建议按新一轮处理：新建或重新激活一条需求，重新走评估与确认流程，并关联原需求记录。这样既保留历史结论，也避免旧记录中的评估依据被直接沿用。若原需求因重复而关闭，应关联主需求，后续跟进以主需求为准。重新打开时补充新的背景和期望时间，让评估基于当前情况，而不是几年前的判断。
状态变更记录需要记到什么程度才算够用？
最低要求是能回答三个问题：什么时候变的、谁操作的、依据是什么。依据可以是评审记录、排期结论、验收记录或关闭原因的链接与简述。对进入“已排期”的需求补充迭代或计划日期，对进入“已关闭”的需求补充关闭原因。记录的目的不是留档本身，而是让巡检和复盘时不必依赖当事人回忆。若抽查时发现状态与记录对不上，优先检查流转规则是否被绕过，而不是增加记录字段。
把状态规则配置到工具里，需要注意什么？
先由团队共识确定状态定义和流转规则，再配置到工具中，顺序反过来容易把工具默认模板当成管理方案。配置时重点关注：状态是否按设定路径流转、关键字段是否在对应节点要求填写、变更是否留下操作人和时间。ONES Project 支持建立需求池、自定义需求状态与属性，并可按实际场景配置工作流，可作为承载方式；具体配置范围和权限需在实际环境中确认。
