需求池状态清单模板用来把“需求现在处于什么阶段、谁能推进、下一步去哪”写成团队共用的表格。它包含两张表：状态清单表按状态名称、状态含义、进入条件、责任角色、下一步去向五列定义每个状态；状态流转表说明当前状态可以流转到哪些状态、由什么动作触发、由谁操作。适合正在统一需求池口径、准备把状态配置到管理工具的团队直接复制填写。
要点总览（TL;DR）
- 模板由两张表组成：状态清单表按“状态名称—状态含义—进入条件—责任角色—下一步去向”定义每个状态，状态流转表说明当前状态可流转到哪些状态、由什么动作触发、由谁操作。
- 状态数量建议控制在5–8个，先覆盖“收集—评审—排期—实现—验收—关闭”主干；命名统一采用动作导向或结果导向，避免“待评审”与“评审中”并存。
- 状态名称、状态含义、进入条件、责任角色、下一步去向、触发动作建议列为必填；操作角色和序号可在小团队先省略，出现多角色协作时再补。
- 进入条件要写成可判定的完成动作或信息齐备条件，责任角色按“谁有权推进到该状态”界定，一个状态只设一个主责角色。
- 配置到管理工具时状态名称和流转规则逐字照搬清单，并定期评审状态使用情况，同步更新清单、流转表和工具配置三处。
可复制空白状态清单模板
下面两张表可以直接复制到文档或表格工具中填写。建议先填状态清单表，确认状态名称和顺序稳定后，再填状态流转表，因为流转表里的“当前状态”和“可流转到”都要引用状态清单中的名称。
表一：状态清单空白表
| 序号 | 状态名称 | 状态含义 | 进入条件 | 责任角色 | 下一步去向 |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 | |||||
| 4 | |||||
| 5 | |||||
| 6 | |||||
| 7 | |||||
| 8 |
表二：状态流转空白表
| 序号 | 当前状态 | 可流转到 | 触发动作 | 操作角色 |
|---|---|---|---|---|
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 4 | ||||
| 5 | ||||
| 6 | ||||
| 7 | ||||
| 8 |
填写前的准备提示
- 状态数量建议控制在5–8个，先覆盖“收集—评审—排期—实现—验收—关闭”这条主干，再按团队实际需要增加分支状态。
- 命名规则先定一种：要么用动作导向（如“待评审”“待排期”），要么用结果导向（如“已评审”“已排期”），全表统一，避免两种混用。
- 填写前把参与角色列出来，例如需求提出人、产品负责人、研发负责人、测试负责人，后面“责任角色”一列只从这份名单里选。
- 两张表的状态名称必须逐字一致，流转表中出现清单外的名称，说明定义还没对齐。
字段说明：每一列填什么
同一份模板由不同人填写，最容易出现的问题是同一个状态写出不同含义、进入条件写成模糊描述。下面逐列说明填写口径，团队可以把这张说明表作为填表时的对照依据。
| 字段 | 填写口径 | 合格示例 | 不合格示例 |
|---|---|---|---|
| 状态名称 | 用2–6个字表达一个阶段，全表采用同一种命名规则，一个阶段只对应一个名称 | 待评审、已排期、开发中、待验收 | “评审相关”“处理一下”，或“待评审”与“评审中”并存 |
| 状态含义 | 一句话说明该状态下需求处于什么阶段、团队正在对它做什么 | 需求已提交，等待产品负责人组织评审 | “需求在流程中”这类无法判断阶段的描述 |
| 进入条件 | 写成可判定的完成动作或信息齐备条件，别人看完能判断“满足还是不满足” | 已补充需求背景、目标用户和验收标准，并指定产品负责人 | “资料比较完整”“大家觉得可以了” |
| 责任角色 | 填写有权把需求推进到该状态的角色，一个状态只设一个主责角色 | 产品负责人 | “相关同事”“谁有空谁处理” |
| 下一步去向 | 填写该状态正常情况下的下一个状态，与流转表保持一致 | 待评审 → 已排期 | 留空，或写“视情况而定” |
| 触发动作 | 写清楚是什么动作导致状态变化，例如评审通过、排期确认、验收签字 | 评审会通过并记录结论 | “推进一下”“更新状态” |
| 操作角色 | 填写实际执行这次状态变更的人或角色，可以与责任角色相同，也可以是被授权的协作角色 | 产品负责人或评审主持人 | 不写，默认任何人都能改 |
“责任角色”和“操作角色”容易混。前者回答“这个阶段谁负责”，后者回答“这次状态变更由谁点”。小团队里两者常常是同一人，团队规模变大、出现评审主持人或项目协调人时，就需要分开填写。
必填与选填：哪些列不能空
模板的所有列都建议填写，但落地初期可以分层：先保证能配置到工具、能判断流转的字段填满，其余字段在运行一两轮后补齐。下面按必填和选填区分，并说明原因。
| 字段 | 必填/选填 | 原因与适用场景 |
|---|---|---|
| 状态名称 | 必填 | 工具中的状态项直接引用这一列，缺失就无法配置 |
| 状态含义 | 必填 | 新成员和跨角色协作时靠它理解阶段，缺失会导致同名状态各自理解 |
| 进入条件 | 必填 | 决定需求能否进入该状态，是评审和交接的判断依据 |
| 责任角色 | 必填 | 没有主责角色，状态会长期停留无人推进 |
| 下一步去向 | 必填 | 流转表的主干路径由它确定，缺失会导致流转路径断点 |
| 触发动作 | 必填 | 工具配置流转规则时需要对应动作，缺失会让状态变更缺少依据 |
| 操作角色 | 选填 | 小团队可先默认由责任角色操作；出现多角色协作、需要权限区分时再补 |
| 序号 | 选填 | 仅用于排序和引用，状态名称稳定后可省略 |
最小可用配置可以只保留六个状态：待评审、已排期、开发中、待验收、已上线、已关闭，对应流转路径为一条主线加必要的回退。三人以下的小团队可以进一步合并“待评审”和“已排期”，由产品负责人一人承担评审与排期；十人以上、需求来源分散的团队，建议保留“待评审”与“已排期”的区分，并在“待评审”前增加“待补充信息”，把信息不全的需求挡在评审之外。状态越多，维护成本越高，扩展前先确认现有状态确实无法承载。
填写示例：一套完整的需求池状态清单
以下示例为演示情景：一个约十五人的产品研发团队，需求来自客户反馈、销售转达和内部运营三类渠道，团队准备把状态配置到管理工具中。示例中的角色和状态数量可按实际情况调整，字段结构与前面的空白表一一对应。
填好的状态清单表
| 序号 | 状态名称 | 状态含义 | 进入条件 | 责任角色 | 下一步去向 |
|---|---|---|---|---|---|
| 1 | 待补充信息 | 需求已记录，但背景、目标用户或验收标准尚不完整 | 需求已录入需求池，且缺少至少一项必填信息 | 需求提出人 | 待评审 |
| 2 | 待评审 | 需求信息齐全，等待产品负责人组织评审 | 已补充需求背景、目标用户和验收标准，并指定产品负责人 | 产品负责人 | 已排期或已关闭 |
| 3 | 已排期 | 评审通过，已进入排期计划，等待开发启动 | 评审会通过并记录结论，已确认目标版本或时间窗口 | 产品负责人 | 开发中 |
| 4 | 开发中 | 研发已启动，需求进入实现阶段 | 已指定研发负责人并创建对应开发任务 | 研发负责人 | 待验收 |
| 5 | 待验收 | 开发完成，等待产品与测试确认结果 | 开发任务完成，已提交可验证的版本或环境 | 测试负责人 | 已上线或开发中 |
| 6 | 已上线 | 需求已发布，进入效果观察期 | 验收通过并完成发布记录 | 产品负责人 | 已关闭 |
| 7 | 已关闭 | 需求结束，不再推进 | 已上线并完成效果确认，或评审决定不做的结论已记录 | 产品负责人 | 无 |
填好的状态流转表
| 序号 | 当前状态 | 可流转到 | 触发动作 | 操作角色 |
|---|---|---|---|---|
| 1 | 待补充信息 | 待评审 | 补齐必填信息并提交评审 | 需求提出人 |
| 2 | 待评审 | 已排期 | 评审会通过并记录结论 | 产品负责人 |
| 3 | 待评审 | 已关闭 | 评审决定不做，记录原因 | 产品负责人 |
| 4 | 已排期 | 开发中 | 研发负责人确认启动并创建开发任务 | 研发负责人 |
| 5 | 开发中 | 待验收 | 开发完成并提交可验证版本 | 研发负责人 |
| 6 | 待验收 | 已上线 | 验收通过并完成发布记录 | 测试负责人 |
| 7 | 待验收 | 开发中 | 验收发现缺陷，退回修改 | 测试负责人 |
| 8 | 已上线 | 已关闭 | 效果确认完成，记录结论 | 产品负责人 |
示例中每个状态的进入条件都对应一个可检查的动作：信息补齐、评审结论记录、任务创建、版本提交、验收通过。责任角色按阶段落在具体岗位上，需求提出人只负责把信息补全，产品负责人负责评审、排期和关闭，研发负责人和测试负责人分别负责实现与验收。回退路径只保留“待验收退回开发中”一条，避免流转表过于复杂。
调整与维护：状态清单怎么随团队变化更新
状态清单在初次配置后需要定期维护，否则容易出现工具里状态越加越多、清单与实际流转对不上的情况。维护的核心是让清单、流转表和管理工具配置三处保持一致。
新增、合并、废弃状态的处理步骤
- 提出变更：由产品负责人或需求池管理员记录变更原因，例如现有状态无法区分某类需求的处理阶段。
- 评估影响：确认新增状态会影响哪些流转路径、哪些角色需要获得操作权限，以及工具中是否已有需求停留在待调整的状态上。
- 更新清单：在状态清单表中新增或修改行，同步更新状态流转表的对应路径，保持名称逐字一致。
- 迁移存量：把工具中停留在旧状态的需求批量调整到新状态，并记录调整时间和操作人。
- 通知相关角色：说明新状态的进入条件和操作角色，必要时在评审会上演示一次完整流转。
状态变更时同步更新管理工具配置的检查点
- 工具中的状态名称与清单完全一致，没有清单外的临时状态。
- 流转规则与流转表一致，包括回退路径和关闭路径。
- 各状态的操作权限已分配给对应角色，避免所有人都能改动关键状态。
- 存量需求已迁移到新状态，没有需求停留在已废弃状态上。
- 需求列表、看板或报表中的分组方式已按新状态调整。
把清单配置到管理工具时，状态名称和流转规则应逐字照搬，工具内不再单独起名。以 ONES 为例，ONES Project 支持建立需求池、编写需求并自定义需求状态与多种属性，团队可以把上面两张表的状态名称和流转路径对应配置进去；ONES 也支持根据实际场景自定义工作流，让需求按清单定义的路径流转。需求来源分散、需要先收集反馈再转成需求的团队，可以用 ONES 工单收集和整理各方反馈，处理后将工单转化为需求，进入需求池。状态级权限可按产品、项目、任务多层级分配，具体配置入口和可配置范围以团队实际使用的版本为准。
定期评审状态清单的节奏与责任人
建议每个季度或每个版本周期结束时评审一次状态清单，由需求池管理员发起，产品负责人、研发负责人和测试负责人参加。评审内容只看三件事：是否有状态长期没有需求进入、是否有需求在某个状态停留时间明显偏长、流转表中是否存在从未被使用的路径。评审结论记录在清单的变更说明中，便于追溯。
常见维护误区
- 状态膨胀：每遇到一种特殊情况就新增状态，导致状态数量超过十个，团队反而记不住。优先考虑用标签或属性区分，而不是新增状态。
- 同义状态并存：“待评审”和“评审中”、“已排期”和“计划中”同时存在，需求被随意放置。合并时保留使用频率高的名称，另一个废弃并迁移存量。
- 只改清单不改工具：清单更新后工具配置未同步，成员在工具里看到的状态与文档不一致，最终以工具为准，清单失去作用。
- 责任角色空缺：新增状态时没有指定主责角色，需求进入后无人推进，停留时间被拉长。
常见问题
团队刚开始建需求池，状态设几个比较合适？
可以先从六个状态起步：待评审、已排期、开发中、待验收、已上线、已关闭，形成一条主线加必要的回退路径。三人以下的小团队可以把“待评审”和“已排期”合并，由产品负责人一人承担评审与排期；十人以上、需求来源分散的团队，建议保留两者区分，并在“待评审”前增加“待补充信息”，把信息不全的需求挡在评审之外。状态数量增加会带来维护成本，扩展前先确认现有状态确实无法承载。
需求在“待验收”被退回，状态应该怎么处理？
在流转表中为“待验收”增加一条回到“开发中”的回退路径，触发动作写清楚，例如“验收发现缺陷，退回修改”，操作角色填测试负责人。回退路径不宜过多，保留必要的一两条即可，否则流转表会变得难以执行。退回时建议在需求记录中注明缺陷或未通过项，方便研发负责人判断修改范围。
状态清单和工具里的工作流配置对不上怎么办？
先以清单为准核对工具中的状态名称和流转规则，逐项检查是否存在清单外的临时状态、缺失的回退路径或权限未分配的情况。确认差异后，把工具中停留在旧状态的需求迁移到新状态，并记录调整时间和操作人。以 ONES 为例，ONES Project 支持自定义需求状态与多种属性，也支持根据实际场景自定义工作流，团队可以把清单中的状态名称和流转路径对应配置进去；具体配置入口和可配置范围以实际使用的版本为准。
需求来源很多，工单和需求池怎么衔接？
可以让反馈先进入工单，由处理人判断是否值得转为需求，再转入需求池并进入“待补充信息”或“待评审”。这样需求池里保留的是经过初步筛选的需求，状态清单也不必为“来源待确认”单独设状态。使用 ONES 的团队可以用 ONES 工单收集和整理各方反馈，处理后将工单转化为需求，进入需求池；工单与需求之间的字段映射需要按团队实际情况配置。
状态清单需要多久评审一次，谁来负责？
建议每个季度或每个版本周期结束时评审一次，由需求池管理员发起，产品负责人、研发负责人和测试负责人参加。评审重点看三件事：是否有状态长期没有需求进入、是否有需求在某个状态停留时间明显偏长、流转表中是否存在从未被使用的路径。评审结论记录在清单的变更说明中，便于后续追溯。
