任务状态流转要解决的是三件事配套：状态怎么定义、每次推进需要什么条件、由谁带着什么证据去推进。只改状态名，任务仍会被随意拖动；只定角色，没有准入条件，验收和关闭就会流于形式。本文面向单项任务的执行闭环，给出可直接套用的状态定义表、迁移规则、角色分工、完整示例和落地检查清单，并说明如何用工作项工具（如ONES）把规则固化下来。
要点总览（TL;DR）
- 用五个状态覆盖单项任务闭环：待受理、进行中、待验证、已完成、已关闭，每个状态写明进入条件、退出条件和负责人。
- 状态数量按团队规模与任务复杂度取舍，判断标准是两个状态之间是否存在不同的责任人或不同的准入证据，没有就合并。
- 流转规则按四步建立：梳理现状卡点、画迁移图、为每次迁移指定角色与证据、配置到工具试运行。
- 执行人提交完成说明与交付物，验收人给出验证结论，流程管理员维护规则并查看停留时长与返工情况。
- 规则上线后用检查清单定期核对，出现连续同类例外时修订规则，每次只调整一到两条并观察一个周期。
先定状态集合：一项任务需要几个状态
多数团队用五个状态就能覆盖单项任务的完整闭环：待受理、进行中、待验证、已完成、已关闭。状态的价值在于让每个参与者一眼判断“这项任务现在卡在谁那里、下一步该谁动”，因此每个状态都必须有明确的进入条件和退出条件，否则状态名只是标签。
下表给出推荐的最小状态集合，可直接作为团队的状态定义表使用。负责人一栏指该状态下对推进负主要责任的角色。
| 状态名 | 含义 | 进入条件 | 退出条件 | 负责人 |
|---|---|---|---|---|
| 待受理 | 任务已提出，尚未确认是否执行 | 任务已创建，含目标、背景、期望结果 | 受理人确认范围与优先级并指派执行人，或判定取消 | 任务提出人 / 受理人 |
| 进行中 | 执行人已开始处理 | 已指派执行人，执行人确认接受 | 执行人提交完成说明与交付物，转入待验证 | 执行人 |
| 待验证 | 交付物已提交，等待验收 | 完成说明、交付物、自测记录齐备 | 验收通过转已完成；不通过退回进行中并附问题说明 | 验收人 |
| 已完成 | 验收通过，交付结果被确认 | 验收人给出通过结论与验证记录 | 确认无后续事项后关闭 | 验收人 |
| 已关闭 | 任务终结，含正常关闭与取消 | 已完成状态确认，或经受理人判定取消/合并 | 终态，不再流转 | 流程管理员 / 受理人 |
状态数量应随团队规模和任务复杂度调整。人数少、任务同质化高的团队，可以把“待验证”并入“进行中”，由执行人自检后直接完成；跨团队协作、交付物需要第三方确认的场景，则应保留待验证，必要时增加“待受理”之后的“已排期”状态，用来区分“同意做”和“开始做”。判断标准是：如果两个状态之间不存在不同的责任人或不同的准入证据，就应合并。
需要特别注意的是，优先级（高/中/低）、阻塞原因（等待外部依赖、缺资料）、任务类型都不应做成状态。它们会与流转状态混在同一维度，导致看板列数膨胀、统计口径混乱。这些信息应作为独立字段存在，阻塞可以用“是否阻塞+阻塞原因”字段表达，优先级用单独的选择字段表达，状态只回答“流程走到哪一步”。
按步骤建立流转规则与角色分工
状态集合确定后，需要把“谁能把任务从哪个状态推到哪个状态、推之前要有什么”写成规则。以下四步按顺序执行，每步都给出输入、动作、输出和完成标志，便于逐项验收。
步骤一：梳理现有任务从创建到关闭的实际路径与卡点
输入是近一个月内已完成的若干任务及其沟通记录。动作是逐个还原任务真实走过的节点，记录每次状态变化的时间、操作人和当时缺少的信息，重点标记反复退回、长期停留、跳过确认的环节。输出是一份现状路径清单和卡点列表。完成标志是团队能对“最常见的三个卡点”达成一致，例如验收无人认领、完成标准不清、任务提出后长期无人受理。
步骤二：确定状态迁移图与允许的跳转、回退
输入是步骤一的卡点清单和S1的状态定义表。动作是画出允许的迁移路径，明确哪些跳转合法、哪些必须经过中间状态、哪些回退需要附原因。通常应禁止从“进行中”直接跳到“已完成”，也禁止从“待受理”直接关闭而不记录取消原因。输出是一张状态迁移图，标注正向路径和回退路径。完成标志是所有参与者能对着图说出“我这一步能推到哪、不能推到哪”。
步骤三：为每次迁移指定操作角色与所需证据
输入是迁移图和角色清单。动作是逐条填写迁移表：当前状态、目标状态、触发角色、所需证据。证据要具体到可核验的对象，例如完成说明、测试记录、验收结论、取消原因，避免写成“确认无误”这类无法检查的描述。输出是完整的状态迁移表。完成标志是每条迁移都有唯一触发角色和至少一项证据要求，不存在“任何人可随意变更”的条目。
| 当前状态 | 目标状态 | 触发角色 | 所需证据 |
|---|---|---|---|
| 待受理 | 进行中 | 受理人 | 已指派执行人，范围与优先级已确认 |
| 待受理 | 已关闭 | 受理人 | 取消原因（重复、不执行、合并至其他任务） |
| 进行中 | 待验证 | 执行人 | 完成说明、交付物、自测记录 |
| 待验证 | 已完成 | 验收人 | 验收结论与验证记录 |
| 待验证 | 进行中 | 验收人 | 不通过原因与待修问题清单 |
| 已完成 | 已关闭 | 流程管理员 / 验收人 | 无遗留事项确认 |
步骤四：把规则配置到看板或工作项字段并试运行
输入是状态迁移表和现用工具。动作是把状态配置为工作项的状态字段，按角色设置变更权限，把关键证据设为进入目标状态时的必填项，并选择一个小组试运行两到四周。输出是配置完成的工作项模板和试运行记录。完成标志是试运行期间没有出现绕过规则的操作，或每次绕过都被记录并纳入规则修订。
角色与交付物：谁推进、谁验收、谁关闭
状态被随意拖动，通常源于角色边界不清：执行人自己把任务改成已完成，或验收人未看交付物就关闭。明确四类角色的职责和各自交付物，是让流转规则真正生效的前提。
| 角色 | 主要职责 | 关键交付物 | 对应状态动作 |
|---|---|---|---|
| 任务提出人 | 说明任务目标、背景与期望结果，配合澄清需求 | 任务描述、验收期望 | 创建任务，进入待受理 |
| 执行人 | 按约定完成交付，提交可验证的结果 | 完成说明、交付物、自测记录 | 进行中 → 待验证 |
| 验收人 | 对照验收标准检查交付物，给出通过或不通过结论 | 验证记录、验收结论、退回问题清单 | 待验证 → 已完成 / 退回进行中 |
| 流程管理员 | 维护状态定义与迁移规则，检查流转数据，组织复盘 | 状态定义表、迁移规则、流转分析 | 已完成 → 已关闭，规则调整 |
验收人与执行人是否必须分离，取决于任务的风险和可验证性。涉及对外交付、合规要求、质量门禁的任务，应由独立验收人确认，避免自证合格；内部探索性任务、低风险的小改动，可以由执行人自检后完成，但应在任务中留下自检记录，便于事后追溯。判断条件是：如果交付结果出错的影响范围超出执行人本人，就值得设置独立验收。
每次交接都应留下对应交付物：执行人交接时提交完成说明和交付物，验收人退回时提交问题清单，关闭时记录关闭原因（正常完成、取消、合并）。状态变更记录建议保留变更前后状态、操作人、时间、变更说明四个字段，由工具自动记录，流程管理员定期抽查，避免依赖人工补记。
示例：一条缺陷修复任务的状态流转
以下示例演示状态、角色与证据如何配合，场景为测试过程中发现的一个功能缺陷，团队按前述五状态规则执行。
测试人员在执行测试用例时发现某功能在特定输入下报错，创建缺陷任务并填写复现步骤、预期结果和实际结果，任务进入待受理。研发负责人作为受理人确认该问题有效、影响范围明确，指派给对应模块的开发人员，任务转入进行中。
开发人员定位到原因并完成修复，提交完成说明（修改点、影响范围）和自测记录，将任务转为待验证。测试人员作为验收人按原复现步骤回归，同时检查相关功能是否受影响。若验证通过，填写验证记录并将任务转为已完成；若验证不通过，附上仍存在的问题和新的复现步骤，将任务退回进行中，开发人员据此继续修复，再次提交验证。
验证通过后，流程管理员或验收人确认无遗留事项，将任务关闭。若该缺陷在受理阶段被判定为重复问题，受理人应将其合并到已有任务，并在关闭原因中注明合并对象；若判定为设计如此、不予修复，则记录取消原因后关闭。整个过程中，每次状态变更都带有操作人、时间和说明，形成可回溯的流转记录。
用ONES承载状态流转的管理动作
规则确定后，需要工具把状态、权限和证据固定下来，减少口头约定带来的偏差。ONES可作为承载工作项状态与流转记录的工具，配置时围绕已确定的规则逐项落地。
首先把S1确定的状态集合配置为工作项的状字段，使看板列与状态定义一一对应，避免同一状态在不同团队有不同叫法。其次按角色分配状态变更权限，把关键证据设为进入目标状态时的必填项，例如转入待验证时必须填写完成说明，转入已完成时必须填写验收结论，让规则在操作层面生效。再次，利用状态停留时长和流转记录观察执行情况，识别长期停留在待验证或反复退回的任务，作为复盘依据。最后，把任务与所属需求、迭代关联起来，便于从需求或迭代视角查看任务整体进展。
在测试与缺陷场景中，ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联；未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转；并支持为不同用户组配置权限、为用例库和测试计划单独配置权限，以及自动生成测试报告和项目缺陷分布统计。这些能力可与前述缺陷流转示例配合使用，具体配置方式以实际产品界面为准。
完成检查：流转规则是否真的在运行
规则上线不等于规则生效，需要用可核验的检查项定期确认。下表给出检查清单，团队可按周或按迭代执行，每项指定负责人并记录结论。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 状态定义是否唯一且被团队理解 | 状态名称与含义在团队内只有一种解释，新成员能在入职一周内正确使用 | 流程管理员 |
| 是否存在跳过验收直接关闭的情况 | 抽查期内无“进行中”直接到“已完成/已关闭”的记录，或每次例外都有说明 | 流程管理员 / 验收人 |
| 状态停留时长是否被定期查看 | 每周或每迭代查看一次各状态平均停留时长，识别异常积压 | 流程管理员 |
| 返工情况是否被记录 | 退回进行中的任务附有明确问题说明，返工次数可统计 | 验收人 |
| 规则是否随实际情况调整 | 出现连续多次同类例外时，触发规则修订并记录变更原因 | 流程管理员 |
规则调整的触发条件应事先约定，例如某状态连续两个周期停留时长明显偏高、某类任务反复跳过同一环节、团队规模或协作方式发生变化。复盘节奏可与迭代回顾合并，每次只调整一到两条规则，调整后观察一个周期再评估，避免规则频繁变动导致团队无所适从。检查的目的在于让状态流转持续反映真实工作，而非增加额外负担。
常见问题
小团队任务少，五个状态是不是太多了？
可以精简。人数少、任务同质化高的团队，把“待验证”并入“进行中”，由执行人自检后直接完成即可，状态集合缩为四个。判断依据是责任人和证据是否真的不同：如果没有人专门做验收，也没有独立的验证记录，单独保留待验证只会增加一次无意义的拖动。反过来，跨团队协作或交付物需要第三方确认时，应保留待验证，必要时在待受理之后加“已排期”，区分“同意做”和“开始做”。
执行人自己验收自己的任务，什么情况下可以接受？
取决于交付结果出错时的影响范围。影响范围限于执行人本人、风险低、可快速回滚的内部改动，可以由执行人自检后完成，但要在任务中留下自检记录，便于事后追溯。涉及对外交付、合规要求或质量门禁的任务，应设置独立验收人，避免自证合格。团队可以把这条判断写进规则，明确哪类任务必须独立验收，减少每次临时争论。
任务长期停在“待验证”，应该怎么处理？
先看停留原因，再决定改规则还是改分工。常见原因有三类：验收人未明确、验收标准写得无法检查、验收人手上任务积压。对应处理是给待验证状态指定唯一验收人，把验收标准改成可核验的对象（如复现步骤、测试记录、验收结论），以及在检查清单中把待验证停留时长列为每周查看项。如果同一状态连续两个周期停留时长明显偏高，就触发规则修订，调整后观察一个周期再评估。
任务被取消或合并到其他任务，状态怎么记录？
取消和合并都走关闭，但关闭原因要写清楚。受理人在待受理阶段判定任务重复时，将其合并到已有任务，并在关闭原因中注明合并对象；判定为不执行时，记录取消原因后关闭。这样后续查看流转记录时，能区分“正常完成关闭”和“取消关闭”，统计完成率时口径才清晰。关闭原因建议作为进入已关闭状态时的必填项，避免只改状态不写说明。
规则配置到工具后，怎么确认它真的在运行？
用可核验的记录判断，不靠感觉。抽查是否存在从进行中直接跳到已完成或已关闭的记录，每次例外是否有说明；查看各状态平均停留时长，识别异常积压；统计退回进行中的任务是否附有明确问题说明。这些检查按周或按迭代执行，指定负责人并记录结论。检查发现连续多次同类例外时，说明规则与实际工作脱节，应修订规则而不是反复口头提醒。
