需求池状态流转表把每个状态的名称、含义、进入条件、责任角色、出口动作和停留时限写在同一张表里，团队据此统一口径，再按表配置到管理工具。下面提供可直接复制的空白模板、逐列填写说明、必填规则和一条完整示例，适用于正在梳理需求池状态定义的产品与研发团队。
要点总览（TL;DR）
- 模板由状态定义表与状态流转关系表组成，前者写清每个状态是什么、谁负责、停留多久，后者写清状态之间通过什么动作连接。
- 状态定义表含九列：状态编号、状态名称、状态含义、进入条件、责任角色、允许的下一状态、触发动作、停留时限、备注。
- 主链路按“待收集—待评审—已确认—待排期—已排期—开发中—待验收—已完成”设置，另设“已搁置”“已关闭”两个分支状态。
- 状态名称、状态含义、进入条件、责任角色为必填；停留时限与备注选填，团队未约定时限时留空并在备注说明。
- 调整时先改状态定义表，再同步流转关系表，最后核对管理工具中的状态与工作流配置，保持两边一致。
可复制空白模板
模板由两张表组成：状态定义表负责写清每个状态是什么、由谁负责、停留多久；状态流转关系表负责写清状态之间通过什么动作连接。两张表配合使用，前者是状态字典，后者是流转路径。复制到文档或表格工具后，先填状态定义表，再据此补全流转关系表。
表一：状态定义表
| 状态编号 | 状态名称 | 状态含义 | 进入条件 | 责任角色 | 允许的下一状态 | 触发动作 | 停留时限 | 备注 |
|---|---|---|---|---|---|---|---|---|
| S01 | 待收集 | |||||||
| S02 | 待评审 | |||||||
| S03 | 已确认 | |||||||
| S04 | 待排期 | |||||||
| S05 | 已排期 | |||||||
| S06 | 开发中 | |||||||
| S07 | 待验收 | |||||||
| S08 | 已完成 | |||||||
| S09 | 已搁置 | |||||||
| S10 | 已关闭 |
主链路为 S01 至 S08，按“待收集—待评审—已确认—待排期—已排期—开发中—待验收—已完成”顺序推进；S09 已搁置、S10 已关闭为分支状态，可从主链路多个节点进入。团队状态更少时，可整行删除；需要增加时，在表尾续编号。
表二：状态流转关系表
| 从状态 | 触发动作 | 到状态 | 责任角色 |
|---|---|---|---|
| 待收集 | |||
| 待评审 | |||
| 已确认 | |||
| 待排期 | |||
| 已排期 | |||
| 开发中 | |||
| 待验收 | |||
| 已完成 | |||
| 已搁置 | |||
| 已关闭 |
一个状态可能对应多条流转记录，例如“待评审”既可流向“已确认”，也可流向“已搁置”或“已关闭”，此时按“从状态”分行填写，每行只描述一条流转路径。流转关系表填完后，应与状态定义表中“允许的下一状态”列逐条核对一致。
字段说明：每一列填什么
九列字段各有固定填写口径。统一口径的目的是让不同人填出的同一状态含义一致，也让后续配置到管理工具时能直接对应状态、角色和流转规则。
| 字段 | 填写口径 | 写法要求 |
|---|---|---|
| 状态编号 | 状态的唯一标识，按顺序编排 | 采用 S01、S02 这类固定格式，新增状态续编，不复用已删除编号 |
| 状态名称 | 状态在工具中显示的名称 | 用简短名词短语，如“待评审”，避免“评审阶段处理中”这类描述性长句 |
| 状态含义 | 该状态代表需求处于什么阶段 | 一句话说明，写清“需求正在等待什么”或“正在被谁处理” |
| 进入条件 | 需求满足什么条件才能进入该状态 | 写成可判断的条件，如“已提交需求描述且指定提出人”，避免“基本清楚”这类模糊表述 |
| 责任角色 | 在该状态中负责推动流转的角色 | 写角色而非人名，如“产品负责人”“需求提出人”，一个状态只指定一个主责角色 |
| 允许的下一状态 | 从该状态可以流转到的状态 | 列出全部合法去向，用顿号分隔；分支状态需写明可回到哪个主链路状态 |
| 触发动作 | 推动状态变化的具体动作 | 用动宾结构，如“完成评审会”“提交验收”，与流转关系表的触发动作保持一致 |
| 停留时限 | 需求在该状态建议停留的最长时间 | 写明确时间单位，如“3 个工作日”；无统一要求时留空并在备注说明 |
| 备注 | 补充说明或例外情况 | 记录特殊约定，如“紧急需求可跳过待排期”，不写与状态无关的内容 |
“允许的下一状态”和“触发动作”两列需要成对理解：下一状态回答“能去哪”，触发动作回答“做什么才能去”。填写时先确定去向，再为每条去向配一个可执行的动作，避免出现有去向却无动作、或有动作却无明确去向的情况。
必填与选填：哪些字段不能空
状态名称、状态含义、进入条件、责任角色四列必填，它们共同构成一个状态的最小定义。缺少任何一项，其他成员就无法判断需求该不该进入该状态、由谁推动，配置到管理工具后也容易出现状态空转。
| 字段 | 填写要求 | 空缺时的处理 |
|---|---|---|
| 状态编号 | 必填 | 按顺序补齐，不与已有编号重复 |
| 状态名称 | 必填 | 不得留空，名称需与工具中配置一致 |
| 状态含义 | 必填 | 不得留空，用一句话写清阶段定位 |
| 进入条件 | 必填 | 不得留空，条件需可判断 |
| 责任角色 | 必填 | 不得留空，写角色不写人名 |
| 允许的下一状态 | 主链路状态必填；终止状态填“无” | 分支状态需写明可返回的主链路状态，不能只写“视情况” |
| 触发动作 | 与下一状态配套填写 | 有下一状态时不得留空 |
| 停留时限 | 选填 | 团队暂未约定时限时可留空，在备注注明“暂不设时限” |
| 备注 | 选填 | 无特殊约定时留空 |
必填字段缺失时，该状态视为未定义完成，不进入评审和工具配置环节。实际操作中可由模板维护人统一检查：逐行核对四列必填项是否为空，再核对“允许的下一状态”与流转关系表是否一一对应。停留时限属于管理约定而非状态定义本身，团队尚未形成共识时留空比随意填写更稳妥。
填写示例：一条完整的需求状态流转记录
下面以“待评审”状态为例，展示各字段的填写结果。示例中的角色和时间仅为演示情景，团队应按自身分工替换。
| 字段 | 填写内容 |
|---|---|
| 状态编号 | S02 |
| 状态名称 | 待评审 |
| 状态含义 | 需求已提交，等待产品负责人组织评审，判断是否纳入需求池 |
| 进入条件 | 需求描述、提出人和使用场景已填写完整，且未被判定为重复需求 |
| 责任角色 | 产品负责人 |
| 允许的下一状态 | 已确认、已搁置、已关闭 |
| 触发动作 | 完成需求评审会并给出结论 |
| 停留时限 | 5 个工作日 |
| 备注 | 紧急需求可临时插入当次评审，仍需记录评审结论 |
这条记录对应流转关系表中的三行：待评审—完成评审并确认—已确认—产品负责人；待评审—评审后暂不推进—已搁置—产品负责人；待评审—评审判定无效—已关闭—产品负责人。三行共用同一个触发动作“完成需求评审会并给出结论”，区别在于结论不同导致去向不同。
对照字段说明可以检查一致性：状态名称是简短名词短语，进入条件写成可判断的条件，责任角色写的是角色而非具体人员，停留时限带明确单位。对照必填规则可以确认四列必填项均已填写，“允许的下一状态”列出了全部合法去向，分支去向也已覆盖。
调整与维护方法
模板落地后需要随团队流程变化调整。调整的原则是先改状态定义表，再同步流转关系表，最后核对管理工具配置，三步顺序执行可以避免表与工具不一致。
按团队流程裁剪状态数量
- 列出团队当前实际发生的需求处理环节，与模板主链路逐项对照。
- 对没有独立判断价值的相邻状态进行合并，例如团队规模较小、评审与确认在同一会议完成时，可将“待评审”和“已确认”合并为一个状态。
- 删除状态时同步删除流转关系表中以该状态为起点或终点的记录，并修正相邻状态的“允许的下一状态”。
- 裁剪后重新走一遍主链路，确认从“待收集”到“已完成”的每条路径仍然连通。
新增自定义状态的填写要求
新增状态需沿用九列结构，编号在现有最大值后续编，状态名称、含义、进入条件、责任角色四项必须填写完整，并在“允许的下一状态”中写明它从哪些状态进入、可以流向哪些状态。新增状态若属于分支，需注明可返回的主链路状态；若插入主链路，需同时修改前后两个状态的下一状态列和流转关系表。
状态变更的版本与通知
每次调整后更新模板版本号并记录变更内容，例如“新增 S11 待澄清，调整 S02 的下一状态”。变更记录与模板放在同一文档中，便于追溯。状态定义变化会影响所有使用该需求池的成员，调整完成后通过团队例会或需求池公告同步变更点，重点说明新增或删除的状态以及受影响的流转路径。
配置到管理工具时的核对要点
把表配置到管理工具时，按以下顺序核对：状态名称与工具中的状态选项逐字一致；每个状态的责任角色在工具中有对应的成员或角色字段承载；流转关系与工具中的工作流配置一致，特别是分支状态的可选去向；停留时限若要在工具中体现，需确认是否有对应的提醒或超时机制。ONES Project 支持建立需求池、规划迭代，并可编写需求、自定义需求状态与多种属性；使用 ONES 工单收集反馈并转化为需求时，也可根据实际场景自定义工作流。配置时以模板中的状态名称和流转关系为基准，逐项对照工具中的状态与工作流设置，发现差异先改模板再改配置，保持两边同源。状态数量上限、状态与工作流的绑定方式以及自动化触发规则，需在实际配置时以产品当前能力为准核对。
需求池状态流转表解决的是状态口径和流转路径的统一，排期执行、需求价值评分和重复需求合并属于相邻环节，可在状态定义稳定后另行处理。
常见问题
团队状态比模板少，可以直接删行吗？删除后要注意什么？
可以删行。删除状态时同步处理三处：状态定义表中删掉该行；流转关系表中删掉以该状态为起点或终点的记录；相邻状态的“允许的下一状态”列去掉对该状态的引用。删完后从“待收集”到“已完成”重新走一遍主链路，确认每条路径仍然连通，再更新模板版本号并通知使用该需求池的成员。
“待评审”和“已确认”能不能合并成一个状态？
可以，前提是团队在同一个会议上完成评审并当场给出结论，两个状态之间没有独立的等待期。合并后保留一个状态名称，进入条件写成“需求描述完整并进入评审议程”，责任角色仍是组织评审的人，允许的下一状态相应调整为“待排期、已搁置、已关闭”。如果评审结论需要跨部门确认、确认周期明显长于评审本身，建议保留两个状态，便于观察需求卡在哪一段。
停留时限填不出来，模板还能用吗？
能用。停留时限属于管理约定，不是状态定义的必要组成部分。团队尚未就各状态的合理停留时间形成共识时，该列留空，并在备注列写明“暂不设时限”。等积累一段时间的实际流转数据后，再按状态分别设定时限，比一开始凭感觉填数字更可靠。
把表配置到管理工具时，最容易出现哪些不一致？
常见差异有三类：状态名称与工具中的选项不完全一致，例如模板写“待评审”、工具里写“评审中”；分支状态的可选去向在工具工作流中没有全部放开；责任角色在工具中没有对应的成员字段或角色字段承载。核对时以模板为基准逐项对照，发现差异先改模板再改配置，避免两边各自演化。ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，使用 ONES 工单收集反馈并转化为需求时也可自定义工作流；状态数量上限、状态与工作流的绑定方式以及自动化触发规则，需在实际配置时以产品当前能力为准核对。
状态调整后，历史需求怎么处理？
先判断调整类型。合并状态时，把被合并状态下的存量需求批量迁移到保留状态，并在变更记录中注明迁移范围；新增状态时，存量需求默认留在原状态，只有满足新状态进入条件的才手动迁入；删除状态时，存量需求必须先迁出再删除，不能留下无状态的需求。迁移完成后抽查几条需求，确认其当前状态与流转关系表描述一致。
