任务状态流转要解决三个问题：状态怎么定义、每次变化要满足什么条件、由谁负责推动。本文聚焦单项任务从创建到验收关闭的执行闭环，给出一套可直接套用的状态集合、迁移规则、角色分工与提醒升级机制，并用一张任务卡演示完整过程。ONES 可作为承载任务状态与流转记录的工具方向，具体能力以实际配置为准。
要点总览（TL;DR）
- 单项任务用六个互斥状态覆盖完整生命周期：待处理、进行中、阻塞、待验收、已完成、已重开，每个状态都要写明进入条件。
- 把状态图升级为迁移矩阵，逐条规定触发动作、操作人和必填字段，缺字段就无法完成流转。
- 任务负责人推进与上报阻塞，验收人给出通过或退回结论，项目管理者处理升级并抽查状态真实性。
- 提醒只对需要动作的节点发送，逾期和长期阻塞按两级升级，同一任务对同一对象每天最多催办一次。
- 用10至20个真实任务抽样核对流转记录，能还原完整路径且责任人与交付物可追溯，才算机制跑通。
先定状态：单项任务需要哪几个状态
状态设计的起点是让每个状态都有明确的进入条件，而不是先追求数量。对大多数执行类任务，六个状态足以覆盖完整生命周期：待处理、进行中、阻塞、待验收、已完成、已重开。状态之间互斥，任一时刻任务只处于一个状态。
| 状态 | 含义 | 进入条件 |
|---|---|---|
| 待处理 | 任务已创建并分配，尚未开始 | 任务信息完整，负责人已明确 |
| 进行中 | 负责人已开始执行 | 负责人确认接手，计划完成时间已填 |
| 阻塞 | 因外部依赖或资源问题无法推进 | 填写阻塞原因、影响范围与期望解除时间 |
| 待验收 | 交付物已提交，等待验收人确认 | 完成说明与交付物已附上 |
| 已完成 | 验收通过，任务关闭 | 验收人给出通过结论 |
| 已重开 | 验收未通过或完成后发现问题，需继续处理 | 填写退回原因与需补充的内容 |
控制状态数量的原则有两条：一是每个状态对应一种可观察的工作处境，而不是一种心情或优先级；二是新增状态前先确认现有状态无法表达该处境。常见膨胀来源是把“紧急”“待排期”“部分完成”做成状态，这些更适合用字段或标签表达。状态图按正常路径与退回路径分开绘制：正常路径为待处理→进行中→待验收→已完成；退回路径为待验收→已重开→进行中，以及已完成→已重开。阻塞是进行中的旁路，解除后回到进行中。画图时把每个箭头旁标注触发动作，这张图就是后续迁移规则的底稿。
流转规则：每次状态变化要满足什么条件
状态图只说明“可以怎么走”，迁移矩阵要说明“满足什么才能走”。把每条允许的迁移写成一行，明确触发动作、操作人和必填字段，状态变更就从个人习惯变成可执行规则。
| 迁移 | 触发动作 | 操作人 | 必填字段 |
|---|---|---|---|
| 待处理→进行中 | 确认接手并开始 | 任务负责人 | 计划完成时间 |
| 进行中→阻塞 | 上报阻塞 | 任务负责人 | 阻塞原因、影响范围、期望解除时间 |
| 阻塞→进行中 | 阻塞解除 | 任务负责人 | 解除说明 |
| 进行中→待验收 | 提交验收 | 任务负责人 | 完成说明、交付物 |
| 待验收→已完成 | 验收通过 | 验收人 | 验收结论 |
| 待验收→已重开 | 验收退回 | 验收人 | 退回原因、需补充内容 |
| 已完成→已重开 | 发现遗留问题 | 验收人或项目管理者 | 问题描述、重开原因 |
| 已重开→进行中 | 重新开始处理 | 任务负责人 | 处理计划 |
完成标准要在提交验收前就写清楚，避免验收时临时加码。可用的判定方式是：交付物清单逐项对照、验收人按预设标准给出通过或退回结论、退回必须写明具体缺口。验收退回与重开的区别在于触发时点：退回发生在待验收阶段，重开发生在任务已完成后。两者都要求留下原因记录，重开的任务重新进入进行中，再次走完提交与验收流程。规则落地时建议把必填字段做成系统校验，缺字段则无法完成迁移，这比事后检查更可靠。
角色与交付物：谁改状态、谁验收、谁升级
状态由单人随意改动，流转就会失真。把关键动作分配给固定角色，并规定每个节点的交付物，状态才有可信度。
| 角色 | 主要动作 | 关键交付物 |
|---|---|---|
| 任务负责人 | 接手任务、推进执行、上报阻塞、提交验收 | 完成说明、交付物、阻塞记录 |
| 协作者 | 提供输入、配合完成子项 | 协作产出、反馈意见 |
| 验收人 | 按标准验收、给出通过或退回结论 | 验收结论、退回原因 |
| 项目管理者 | 处理升级、协调资源、抽查状态真实性 | 升级处理记录、协调结论 |
阻塞上报的第一责任人是任务负责人，上报后由项目管理者判断是否需要跨团队协调；逾期升级由项目管理者发起，向任务负责人的直接上级或资源所属方通报。状态变更记录要包含变更前后状态、操作人、时间和必填字段内容，保证任何一次流转都能回溯。记录的价值在复盘和争议处理时体现：当任务延期原因说不清时，阻塞记录和退回原因就是判断依据。
提醒、催办与逾期升级怎么设置
提醒机制的目标是让状态及时更新，减少人工追问。设置时按时间节点分层，避免所有任务同一频率推送。
- 临期提醒：计划完成时间前1至2个工作日提醒任务负责人，待验收任务同时提醒验收人。
- 逾期提醒：超过计划完成时间当天提醒负责人，次日仍未更新则抄送项目管理者。
- 阻塞上报：阻塞状态持续超过约定时限（如2个工作日）自动升级至项目管理者。
- 催办频次：同一任务对同一对象每天最多一次，升级通知单独计算，避免重复打扰。
避免提醒泛滥的原则是只对“需要动作”的节点发提醒：状态停滞、临近截止、验收超时。已完成任务不再推送，长期阻塞任务改为周度汇总而非每日提醒。升级层级建议不超过两级，第一级到项目管理者，第二级到资源所属方负责人，层级过多会让响应责任分散。
示例：一张任务卡走完整个状态流转
以下为演示情景，用于说明流转过程，不代表真实项目数据。
任务“完成季度数据报表模板”创建后进入待处理，负责人确认接手并填写计划完成时间，状态转为进行中。执行到第三天发现缺少上季度原始数据，负责人将状态改为阻塞，填写阻塞原因“缺少原始数据”、影响范围“报表无法生成”、期望解除时间“两个工作日内”，系统按规则向项目管理者发出升级提醒。数据补齐后负责人填写解除说明，状态回到进行中。
交付物完成后，负责人附上模板文件与完成说明，提交验收，状态转为待验收。验收人对照验收标准检查，发现口径说明缺失，给出退回结论并写明需补充内容，状态转为已重开。负责人补充口径说明后重新进入进行中，再次提交验收。验收人确认通过，填写验收结论，状态转为已完成。整个过程的状态变更、必填字段和操作人均留有记录，可直接用于复盘。
完成检查：状态流转是否真的跑通
机制是否可执行，用一张清单逐项核对，再抽一批真实任务验证。
- 状态定义互斥且覆盖完整：任一任务在任何时刻都能归入且仅归入一个状态。
- 每条迁移都有责任人和必填字段，缺字段无法完成流转。
- 提醒与升级发出后有人响应，响应记录可查。
- 验收退回与重开均有原因记录，重开任务再次走完验收流程。
- 状态变更记录完整，包含操作人、时间与字段内容。
抽样验证方法：选取近一个月内10至20个真实任务，逐个核对状态变更记录与必填字段是否齐全，统计阻塞任务的平均解除时长、验收退回率和逾期任务占比。若出现大量任务长期停留在进行中、阻塞无记录或验收结论缺失，说明规则未被真正执行，需要回到迁移矩阵检查校验是否生效、角色是否清晰。检查通过的标准是：随机抽取的任务都能还原出完整的流转路径，且每个节点的责任人和交付物可追溯。
常见问题
小团队任务量不大，六个状态是否太多，可以精简吗？
可以精简，但精简的前提是保留验收环节。任务量小、交付物简单的团队可先合并为待处理、进行中、待验收、已完成四个状态，阻塞用字段或标签标记，重开通过退回待验收表达。随着任务复杂度和协作人数上升，再把阻塞和重开独立成状态。判断标准是：任一任务在任何时刻都能归入且仅归入一个状态，且退回原因有地方记录。
任务长期停在“进行中”，负责人说一直在做，怎么判断状态是否真实？
先看有没有可核对的中间产出。可以在迁移规则里要求进行中的任务定期更新进展说明或附上阶段性交付物，项目管理者抽查时对照这些记录判断。若任务已超过计划完成时间仍未提交验收，按逾期规则升级，由负责人说明剩余工作量和预计完成时间。状态失真的根源通常是迁移没有必填字段校验，补上校验比反复追问更有效。
验收人和任务负责人是同一人时，验收环节还有意义吗？
仍有意义，但需要把验收标准前置。负责人自验收时，提交验收前必须逐项对照事先写好的完成标准，并留下验收结论记录。对关键任务建议指定独立验收人，至少由项目管理者抽查。验收退回与重开的记录同样要保留，这样复盘时能看出标准是否被认真执行。
阻塞任务升级到项目管理者后仍无法解决，下一步怎么处理？
按两级升级设计，第二级到资源所属方负责人，由其在约定时限内给出资源调配或调整计划的结论。升级时要带上阻塞原因、影响范围、期望解除时间和已尝试的协调动作，便于对方判断。若两级都无法解除，应把任务计划完成时间正式调整并记录原因，避免任务以阻塞状态长期挂起而无人处理。
任务完成后发现遗留问题，应该重开原任务还是新建任务？
看问题与原交付物的关系。属于原交付物缺陷或验收遗漏的，重开原任务，保留完整流转记录，便于追溯责任和统计退回率；属于新增需求或范围外工作的，新建任务并关联原任务。重开时填写问题描述和重开原因，任务重新进入进行中，再次走完提交与验收流程。
