需求池状态流转表把每个状态的名称、含义、进入条件、责任角色和下一步去向写在同一张表里，团队据此统一口径，再把这套状态配置到管理工具中。本文提供三张可直接复制的空白表、字段填写说明、必填与选填对照，以及一条需求从进入池到关闭的完整填写示例，适合正在梳理需求池流程、准备配置工作项状态的团队使用。
要点总览（TL;DR）
- 需求池状态流转表用三张表承载：状态流转主表逐行定义状态，状态清单确认状态全集，流转规则表描述允许的跳转路径。
- 状态名称、状态含义、进入条件、责任角色、下一步去向是必填字段；停留时限、状态类型、是否允许回退等按团队需要补充。
- 状态数量建议控制在6–8个，进入条件写成可判断的客观标准，责任角色按职责填写而非具体人名。
- 配置到管理工具时按“先清单、再路径、后字段与权限”的顺序操作，配置完成后用一条真实需求走完全流程核对。
- 模板需要定期复核，重点检查状态名称与工具配置是否逐字一致、流转路径是否同步、回退路径是否单独记录。
可复制空白状态流转表
下面三张表构成模板主体。第一张是状态流转主表，逐行描述一个状态；第二张是状态清单，用于快速确认状态全集和顺序；第三张是流转规则表，描述状态之间允许的跳转。复制到文档或表格工具后，先填状态清单，再填主表，最后填流转规则，顺序与团队讨论流程一致。
表一：状态流转主表
| 序号 | 状态名称 | 状态含义 | 进入条件 | 责任角色 | 下一步去向 | 停留时限 | 备注 |
|---|---|---|---|---|---|---|---|
| 1 | |||||||
| 2 | |||||||
| 3 | |||||||
| 4 | |||||||
| 5 | |||||||
| 6 | |||||||
| 7 | |||||||
| 8 |
表二：状态清单
| 顺序 | 状态名称 | 状态类型 | 是否终态 | 对应工具状态 |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 4 | ||||
| 5 | ||||
| 6 | ||||
| 7 | ||||
| 8 |
表三：流转规则表
| 起始状态 | 目标状态 | 触发动作 | 操作角色 | 前置条件 | 是否允许回退 |
|---|---|---|---|---|---|
字段说明：每一列填什么
三张表的字段各有分工：主表回答“这个状态是什么、谁来负责”，清单回答“一共有哪些状态”，流转规则表回答“状态之间怎么走”。填写时保持同一状态在三张表中的名称完全一致，后续配置工具才能直接对应。
| 字段 | 所属表 | 填写口径 | 与其他字段的关系 |
|---|---|---|---|
| 状态名称 | 主表、清单、流转规则表 | 用2–4个字的动宾或名词短语，如“待评估”“开发中”，全团队统一叫法 | 三张表必须逐字一致，也是工具中配置的状态名 |
| 状态含义 | 主表 | 一句话说明该状态下需求处于什么阶段、团队在做什么 | 与进入条件配合，含义描述阶段，进入条件描述门槛 |
| 进入条件 | 主表 | 写成可判断的客观标准，如“已明确提出方与业务目标”“评审会已给出结论” | 对应流转规则表中的“前置条件” |
| 责任角色 | 主表 | 按职责填写，如产品负责人、需求评审组、研发负责人，不写具体人名 | 与流转规则表中的“操作角色”对应，人员变动不影响模板 |
| 下一步去向 | 主表 | 填写该状态正常情况下的下一个状态名称 | 是流转规则表的汇总视图，两者不能矛盾 |
| 停留时限 | 主表 | 该状态建议的最长停留时间，如“3个工作日”，无要求可留空 | 用于识别积压，不改变流转规则 |
| 状态类型 | 清单 | 标注为待处理、进行中、已完成或已关闭 | 用于工具中按类型统计和看板分组 |
| 是否终态 | 清单 | 填“是”或“否”，终态不再向下流转 | 终态在流转规则表中只作为目标状态出现 |
| 对应工具状态 | 清单 | 填写管理工具中实际配置的状态名称 | 与状态名称保持一致，作为配置核对依据 |
| 触发动作 | 流转规则表 | 说明通过什么操作完成流转，如“评审通过”“提交验收” | 与操作角色共同定义谁在什么条件下推动流转 |
| 是否允许回退 | 流转规则表 | 填“是”或“否”，允许回退时在备注中写明回退原因类型 | 回退路径也需要单独成行记录，不能只写“允许” |
字段之间存在明确的对应关系：主表的“下一步去向”应当能在流转规则表中找到对应行；流转规则表的“前置条件”应当与主表的“进入条件”表述一致；清单中的“对应工具状态”是模板与工具配置之间的核对锚点。填写完成后，用这三组对应关系做一次交叉检查，可以提前发现口径不一致的问题。
必填与选填：哪些字段不能空
最小可用版本只需要保证状态能被识别、被推动、被追责。以下五个字段构成必填集合：状态名称、状态含义、进入条件、责任角色、下一步去向。缺少任何一个，状态定义都会出现歧义——没有进入条件，状态切换靠感觉；没有责任角色，需求停在某处无人推进；没有下一步去向，流转路径无法配置到工具。
| 字段 | 必填/选填 | 原因或适用场景 |
|---|---|---|
| 状态名称 | 必填 | 状态的身份标识，工具配置和统计都依赖它 |
| 状态含义 | 必填 | 新成员理解状态的主要依据，避免同名不同义 |
| 进入条件 | 必填 | 决定状态切换是否成立的判断标准 |
| 责任角色 | 必填 | 明确该状态下由谁推动，防止需求停滞 |
| 下一步去向 | 必填 | 流转路径的基础，配置工具时直接使用 |
| 停留时限 | 选填 | 需求量大、需要识别积压时填写；流程简单的小团队可暂不设置 |
| 状态类型 | 选填 | 需要在工具中按类型分组统计或做看板泳道时填写 |
| 是否终态 | 选填 | 状态较多、存在多个关闭类状态时建议填写 |
| 对应工具状态 | 选填 | 进入工具配置阶段时填写，用于核对模板与工具是否一致 |
| 触发动作 | 选填 | 流转需要特定操作或审批时填写，简单流转可省略 |
| 操作角色 | 选填 | 流转权限需要与责任角色区分时填写 |
| 前置条件 | 选填 | 与进入条件重复时可省略，存在额外校验时补充 |
| 是否允许回退 | 选填 | 流程允许打回时填写，并单独记录回退路径 |
最小可用版本即主表五列加状态清单的状态名称列，适合刚建立需求池、状态数量在6个左右的团队。完整版本增加停留时限、状态类型、流转规则表全部字段，适合需求来源多、跨角色协作频繁、需要在工具中做统计和权限控制的团队。建议先按最小版本跑通一轮，再根据实际卡点补充选填字段，避免一开始就填满导致维护负担。
填写示例：一个需求从进入到关闭
以下示例为演示情景：某团队收到一条“报表导出支持按部门筛选”的需求，从提出到关闭经过八个状态。示例中的角色和时限仅用于说明填写方式，团队应按自身流程调整。
| 序号 | 状态名称 | 状态含义 | 进入条件 | 责任角色 | 下一步去向 | 停留时限 |
|---|---|---|---|---|---|---|
| 1 | 待收集 | 需求已记录，尚未整理 | 提出方通过工单、群聊或会议提出，并留下提出方与场景描述 | 需求提出方 | 待评估 | 2个工作日 |
| 2 | 待评估 | 产品在判断需求价值与可行性 | 已明确提出方、使用场景和期望结果 | 产品负责人 | 待规划 | 5个工作日 |
| 3 | 待规划 | 需求已通过评估，等待排入版本 | 评估结论为“值得做”，并记录优先级依据 | 产品负责人 | 已规划 | 不设 |
| 4 | 已规划 | 需求已进入某个版本或迭代范围 | 已关联版本或迭代，并明确负责人 | 产品负责人 | 开发中 | 不设 |
| 5 | 开发中 | 研发正在实现该需求 | 已完成需求评审，研发负责人确认排期 | 研发负责人 | 待验收 | 按排期 |
| 6 | 待验收 | 开发完成，等待产品与测试确认 | 研发提交提测说明，自测通过 | 测试负责人 | 已完成 | 3个工作日 |
| 7 | 已完成 | 验收通过，需求交付 | 产品验收通过，测试出具结论 | 产品负责人 | 已关闭 | 不设 |
| 8 | 已关闭 | 需求流程结束，不再流转 | 已完成交付，或评估后决定不做并记录原因 | 产品负责人 | 无 | 无 |
对应的流转规则示例：待收集→待评估由需求提出方或产品负责人触发，前置条件为场景描述完整；待评估→待规划由产品负责人触发，前置条件为评估结论已记录；待规划→已规划由产品负责人触发，前置条件为已关联版本；开发中→待验收由研发负责人触发，前置条件为提测说明已提交；待验收→已完成由产品负责人触发，前置条件为验收结论通过；待验收→开发中允许回退，回退原因需记录为缺陷或需求理解偏差。示例中“已关闭”同时承接“已完成”和“评估后不做”两条路径，团队若希望区分，可拆成“已完成”和“已拒绝”两个终态。
调整与维护：状态增减和工具配置
状态定义落地后需要随流程变化调整。判断是否增减状态的依据有三条：某个状态长期没有需求停留，说明它可以合并；某个状态频繁出现回退或争议，说明进入条件写得不够可判断；同一状态在不同团队有不同叫法，说明需要统一命名而不是新增状态。状态总数建议控制在6–8个，超过这个范围时，优先考虑用标签或属性表达细分差异，而不是继续增加状态。
配置到管理工具时，按“先清单、再路径、后字段与权限”的顺序操作。以ONES为例，ONES Project支持建立需求池、编写需求并自定义需求状态与多种属性；在敏捷研发场景中，还可以根据实际场景自定义工作流，让需求按既定路径流转。配置时把模板中的状态名称逐字录入工具，把流转规则表中的允许路径配置为状态间的流转关系，再为关键状态设置必填字段和操作权限。ONES Project提供产品、项目、任务多层级权限，可按组织架构、用户组、项目角色分配，适合把“谁能在哪个状态推动流转”落到角色上。配置完成后，用一条真实需求从待收集走到已关闭，核对每一步的状态名称、责任角色和必填项是否与模板一致。
维护方面，建议每季度或每次流程调整后复核一次模板，检查以下清单：
- 状态清单与工具中的状态名称是否逐字一致，有无新增未记录的状态；
- 每个状态的进入条件是否仍可判断，是否存在“基本完成”这类模糊表述；
- 责任角色是否仍对应现有岗位，人员调整后是否已更新；
- 流转规则表中的路径是否与工具配置一致，回退路径是否单独记录；
- 停留时限是否仍合理，长期超时的状态是否需要拆分或合并；
- 模板版本号与变更原因是否已记录，旧版本是否已归档。
每次调整后更新版本号和变更说明，并同步通知使用该需求池的团队。模板与工具配置脱节是常见问题，把“对应工具状态”一列作为核对项，可以在复核时快速发现差异。
常见问题
团队刚开始建需求池，状态应该设几个？
建议从6个左右起步，覆盖收集、评估、规划、开发、验收、关闭这条主链路。状态太少会让不同阶段的需求混在一起，难以判断卡在哪里；状态太多则增加维护和培训成本。可以先按最小可用版本运行一轮，观察哪些状态长期没有需求停留、哪些状态频繁引发争议，再决定合并或拆分。细分差异优先用标签或属性表达，例如需求来源、所属产品线，不必为每种差异新增状态。
进入条件写成什么样才算可判断？
可判断的标准是：换一个人来看，也能得出相同结论。例如“已明确提出方、使用场景和期望结果”比“需求描述清楚”更容易判断；“评审会已给出结论并记录优先级依据”比“评估差不多完成”更明确。填写时可以用一个简单测试：把这条进入条件交给不熟悉该需求的同事，看他能否据此判断需求是否满足条件。如果答案依赖个人经验，就需要继续细化。
需求被评估后决定不做，应该走哪个状态？
常见做法是设置一个独立的终态，例如“已拒绝”或“已关闭（不做）”，并在备注中记录不做的原因，如价值不足、与当前规划不符、重复需求等。这样既保留了决策记录，也避免“不做”的需求混在“已完成”里影响统计。如果团队需求量大、拒绝原因需要分类分析，可以进一步用属性字段记录原因类型。示例中的“已关闭”同时承接完成和拒绝两条路径，团队可按需要拆分。
状态定义配置到工具后，怎么确认没有走样？
配置完成后，挑一条真实需求从进入池走到关闭，逐步核对三件事：每一步的状态名称是否与模板逐字一致；推动流转的人是否与责任角色对应；必填字段是否在关键节点被要求填写。核对中发现差异，先判断是模板写得不清楚还是工具配置有遗漏，再同步修正两边。之后把“对应工具状态”一列作为日常核对项，每次复核模板时对照工具中的实际状态列表。
状态流转规则需要配置成强制限制吗？
取决于团队对流程纪律的要求。强制限制能防止跳过关键节点，例如未经评审直接进入开发，适合跨团队协作多、交接频繁的场景；限制过严也会带来操作负担，例如紧急需求需要临时绕行时缺少通道。折中做法是对关键节点设置强制流转和必填校验，对次要路径保留一定灵活性，并把例外情况记录在备注中。规则调整后同步更新模板和工具配置，避免文档与实际执行脱节。
