需求池状态清单模板用于把“需求现在处于哪一步、由谁负责、下一步能去哪里”写成一张可执行的表。它包含状态清单表与状态流转表两张主表，适合正在统一状态定义、准备把规则配置到管理工具的团队。下文先给空白模板，再说明字段口径、必填取舍、完整示例和配置维护方法。
要点总览（TL;DR）
- 模板由三张表组成：状态清单表定义每个状态的含义、进入条件、责任角色和退出方向，状态流转表定义状态之间怎么走，字段对照表定义状态变化时要同步补哪些信息。
- 状态名称、编码、含义、进入条件、责任角色、退出方向、是否终态建议设为必填；状态数量控制在5至8个，每个状态对应一个明确责任角色和一个可核验进入条件。
- 终态要单独标注并定义回流规则，例如已关闭的需求重新提出时由谁发起、经过什么评审、回到哪个状态，同样写入流转表。
- 配置顺序固定为：先按状态编码建立状态，再按流转表配置允许路径，然后设置变更权限与字段联动，最后用真实需求走一遍全流程核对。
- 状态清单需要版本记录与定期复核，建议每季度检查长期停留的状态、从未使用的状态和回流规则是否仍符合业务实际。
可复制的需求池状态清单空白模板
模板由三张表组成：状态清单表定义每个状态本身，状态流转表定义状态之间怎么走，字段对照表定义状态变化时要同步补哪些信息。复制到表格工具后逐行填写即可，行数按团队实际状态数量增减。
表一：状态清单主表
| 状态名称 | 状态编码 | 含义 | 进入条件 | 责任角色 | 退出方向 | 是否终态 |
|---|---|---|---|---|---|---|
表二：状态流转关系表
| 当前状态 | 触发动作 | 目标状态 | 操作角色 |
|---|---|---|---|
表三：状态与需求字段对照表
| 状态 | 需同步填写的字段 | 填写责任角色 | 填写时机 |
|---|---|---|---|
每个字段填什么：状态清单字段说明
同一列在不同团队之间口径不一致，是状态表失效的常见原因。下表逐列给出定义与填写口径，填表时按此对齐。
| 字段 | 定义 | 填写口径 |
|---|---|---|
| 状态名称 | 给人看的状态标签 | 用动宾或名词短语，2至6个字，如“待评审”“开发中”；同一张表内不出现近义词，如“评审中”和“待评审”只保留一个 |
| 状态编码 | 给工具和报表用的唯一标识 | 统一用英文小写加下划线，如 pending_review、in_development；编码一经配置到工具不再随意改动，名称可改、编码保持稳定 |
| 含义 | 这个状态代表需求处于什么阶段 | 写一句判断标准，描述需求本身的状态，如“需求已提交，尚未完成评审排期” |
| 进入条件 | 满足什么条件才能进入该状态 | 写可核验的事实，如“评审会已给出结论并记录在需求文档中”；避免写“大家认为可以了”这类无法判断的表述 |
| 责任角色 | 该状态下推动需求前进的岗位 | 按职责填写，如“需求提出人”“产品负责人”“研发负责人”；不写具体人名，人员变动时只换人、不改表 |
| 退出方向 | 从该状态可以前往的状态 | 列出全部合法去向，如“待评审→评审通过/已关闭”；只有一个去向时也写明，便于配置流转规则 |
| 是否终态 | 该状态是否为流程终点 | 填“是”或“否”；终态需求不再自动流转，如需重新激活，走回流规则 |
| 触发动作 | 推动状态变化的具体操作 | 用“谁做了什么”描述，如“产品负责人完成评审并记录结论”；一个动作对应一条流转记录 |
| 操作角色 | 有权执行该触发动作的岗位 | 与责任角色对应，可多于一个，如“产品负责人、需求评审组” |
含义与进入条件的区别在于：含义回答“这个状态是什么”，进入条件回答“凭什么可以进来”。前者用于沟通和培训，后者用于评审和工具校验，两列都要写，不能互相替代。
必填与选填：哪些列不能空
状态清单的完整性直接影响工具配置能否落地。建议把状态名称、状态编码、含义、进入条件、责任角色、退出方向、是否终态设为必填，流转表的四列全部必填。空缺的后果很具体：缺进入条件，状态变更就靠口头判断；缺责任角色，需求会停在无人推动的状态；缺退出方向，工具里配不出完整流转。
| 列 | 必填/选填 | 空缺后果或补填场景 |
|---|---|---|
| 状态名称、状态编码 | 必填 | 无法在工具中建立状态，报表也无法统计 |
| 含义、进入条件 | 必填 | 状态判断依赖个人理解，评审时容易争议 |
| 责任角色 | 必填 | 需求停留时间变长，无法定位推动人 |
| 退出方向 | 必填 | 流转规则不完整，出现无法前进的状态 |
| 是否终态 | 必填 | 关闭类状态与进行中状态混淆，统计口径失真 |
| 触发动作、操作角色 | 必填 | 状态变更缺少授权依据 |
| 状态说明补充、备注 | 选填 | 状态涉及跨团队协作或历史遗留规则时补填，便于新人理解 |
| 关联文档链接 | 选填 | 进入条件依赖某份评审记录或方案文档时补填 |
状态数量建议控制在5至8个，覆盖收集、评审、排期、开发、验收、关闭的主链路。状态过少，团队无法区分关键节点；状态过多，每个状态的进入条件难以维护，流转表也会迅速膨胀。粒度取舍的标准是：每个状态是否对应一个明确的责任角色和一个可核验的进入条件，两者都说不清的状态应合并。
终态必须明确标注，并单独定义回流规则。例如“已关闭”的需求若因业务变化重新提出，应规定由谁发起、经过什么评审、回到哪个状态，这条回流同样写入流转表，不能留白。
填写示例：一套完整的需求池状态清单
以下示例为演示情景，展示一张覆盖从收集到关闭的完整状态表，团队可据此改写为自己的版本。
示例状态清单表
| 状态名称 | 状态编码 | 含义 | 进入条件 | 责任角色 | 退出方向 | 是否终态 |
|---|---|---|---|---|---|---|
| 待评审 | pending_review | 需求已提交，尚未完成评审 | 需求描述、提出人和业务背景已填写完整 | 需求提出人 | 评审中、已关闭 | 否 |
| 评审中 | in_review | 需求正在被评估价值和可行性 | 已安排评审，评审人已确认参加 | 产品负责人 | 已排期、已关闭 | 否 |
| 已排期 | scheduled | 需求通过评审，等待进入开发 | 评审结论为通过，且已确定目标迭代 | 产品负责人 | 开发中、已关闭 | 否 |
| 开发中 | in_development | 需求已进入研发实现 | 已指派研发负责人并建立关联任务 | 研发负责人 | 待验收、已关闭 | 否 |
| 待验收 | pending_acceptance | 开发完成，等待业务方确认 | 研发自测通过并提交验收说明 | 测试负责人 | 已完成、开发中 | 否 |
| 已完成 | done | 需求验收通过并交付 | 业务方确认验收结果并记录 | 产品负责人 | 无（终态） | 是 |
| 已关闭 | closed | 需求不再推进 | 评审否决、重复或业务取消，且记录原因 | 产品负责人 | 待评审（回流） | 是 |
示例流转表
| 当前状态 | 触发动作 | 目标状态 | 操作角色 |
|---|---|---|---|
| 待评审 | 产品负责人安排评审并通知评审人 | 评审中 | 产品负责人 |
| 待评审 | 提出人撤回或确认重复，记录原因 | 已关闭 | 需求提出人 |
| 评审中 | 评审通过并确定目标迭代 | 已排期 | 产品负责人 |
| 评审中 | 评审否决，记录结论 | 已关闭 | 产品负责人 |
| 已排期 | 研发负责人接单并建立关联任务 | 开发中 | 研发负责人 |
| 开发中 | 研发自测通过并提交验收说明 | 待验收 | 研发负责人 |
| 待验收 | 业务方确认验收通过 | 已完成 | 产品负责人 |
| 待验收 | 验收不通过，退回修改 | 开发中 | 测试负责人 |
| 已关闭 | 业务重新提出并经评审确认 | 待评审 | 产品负责人 |
示例中状态变更时同步填写的字段
| 状态 | 需同步填写的字段 | 填写责任角色 | 填写时机 |
|---|---|---|---|
| 待评审 | 需求描述、提出人、业务背景 | 需求提出人 | 提交需求时 |
| 评审中 | 评审人、评审时间 | 产品负责人 | 安排评审时 |
| 已排期 | 目标迭代、优先级、评审结论 | 产品负责人 | 评审通过后 |
| 开发中 | 研发负责人、关联任务 | 研发负责人 | 接单时 |
| 待验收 | 验收说明、测试结论 | 研发负责人 | 提交验收时 |
| 已完成 | 验收结果、完成时间 | 产品负责人 | 验收通过时 |
| 已关闭 | 关闭原因 | 产品负责人 | 关闭时 |
这张示例的关键在于每个状态都有唯一责任角色和可核验的进入条件，流转表中的每条记录都能在状态表的退出方向里找到对应。团队照此结构替换成自己的状态名称和角色即可。
把状态清单配置到管理工具并持续维护
配置顺序建议固定为：先定状态表，再配流转规则，最后配字段联动。顺序颠倒会导致工具里出现无法解释的状态或空字段。具体步骤如下。
- 在工具中按状态编码建立需求状态，名称与编码和清单表逐字一致。
- 按流转表配置状态之间的允许路径，只开放清单中列出的退出方向。
- 为每个状态设置变更权限，把操作角色对应到工具中的项目角色或用户组。
- 配置状态变更时需同步填写的字段，把必填字段设为进入该状态的前置条件。
- 用几条真实需求走一遍全流程，核对状态、字段和权限是否符合清单。
状态变更权限应与责任角色一一对应：谁负责推动该状态，谁就拥有该状态的变更操作权。状态增删改需要触发条件和评审方式，建议规定只有出现新的可核验进入条件、或现有状态长期无人使用时才调整，调整前由产品负责人发起、相关角色确认，并记录变更原因。
状态清单本身需要版本记录与定期复核。每次修改保留版本号和生效日期，建议每季度复核一次，重点检查长期停留的状态、从未被使用的状态以及回流规则是否仍符合业务实际。
在 ONES 中落地时，可先建立需求池，编写需求并自定义需求状态与多种属性，使状态名称与清单表一致；再根据实际场景自定义工作流，把流转表中的路径配置为需求规范化流转的规则。状态变更权限可借助产品、项目、任务多层级权限，按组织架构、用户组或项目角色分配，与清单中的操作角色对应。对于功能复杂的需求，可用子工作项拆解并关联研发和测试任务，让状态推进与任务完成情况保持同步；日常查看时通过筛选器按状态定位需求，核对是否有需求长期停留在某一状态。具体配置入口和可配置范围以团队实际使用的版本为准。
常见问题
团队刚开始统一需求池状态，应该先定几个状态？
建议从5至8个状态起步，覆盖收集、评审、排期、开发、验收、关闭的主链路。判断某个状态是否保留，看它是否对应一个明确的责任角色和一个可核验的进入条件；两者都说不清的状态先合并。状态定得少，后续补充和调整的成本低，也更容易让团队在工具里保持一致。
状态编码为什么不能随状态名称一起改？
状态编码是给工具和报表用的唯一标识，名称是给人看的标签。编码一旦配置到管理工具，报表统计、筛选条件和流转规则都会引用它；改名不影响历史数据，改编码则可能让已有记录对不上。因此名称可以随团队习惯调整，编码保持稳定，新增状态时再分配新编码。
需求被关闭后又重新提出，模板里怎么处理？
在状态清单表中把“已关闭”标注为终态，同时在流转表里补一条回流记录：当前状态为已关闭，触发动作写清由谁发起、经过什么评审，目标状态指向重新进入的起点（如待评审），操作角色填对应岗位。回流规则与正常流转一样需要可核验的触发条件，避免关闭状态被随意重新打开。
状态清单填好后，配置到工具时最容易漏掉什么？
常见遗漏有两处：一是只配了状态名称，没有按流转表限制允许路径，导致工具里出现清单之外的跳转；二是没有把必填字段设为进入某状态的前置条件，状态变了但信息没补。建议配置完成后用几条真实需求走一遍全流程，核对状态、字段和权限是否与清单一致。
状态清单需要多久复核一次，复核看什么？
建议每季度复核一次。重点看三类情况：长期停留无人推动的状态、从未被使用的状态、以及回流规则是否仍符合当前业务。每次修改保留版本号和生效日期，由产品负责人发起、相关角色确认，并记录变更原因，便于后续追溯。
