任务状态流转要落地，先按任务从受理到关闭的真实环节定一组有限状态，再为每条流转写明触发动作、校验条件和退回路径，最后用停留时长与退回次数检验规则是否有效。本文给出一套可直接套用的状态定义表、流转规则清单和角色对照表，适合需要为单项任务建立执行闭环的团队参考。
要点总览（TL;DR）
- 状态按任务真实处理环节划分，六个状态（待受理、进行中、阻塞、待验收、已完成、已关闭）可覆盖多数单项任务，重开作为回流路径而非独立状态。
- 每条流转由具体动作触发，进入下一状态前校验必填字段、产出物和确认人；验收退回与重开必须填写原因并记录次数。
- 阻塞由执行方申报，逾期由时间规则判定，两者分开统计；管理者在阻塞超时、逾期无更新、退回次数达阈值时介入催办或升级。
- 工具承载分四层：状态与流转规则配置、流转前校验、变更记录留存、提醒与升级触发，配置后用一条真实任务试跑验证。
- 用状态停留时长、退回次数、孤立状态检查等指标检验流转是否跑通，并随执行情况收敛状态数量。
先定状态：一条任务需要几个状态
状态划分的依据是任务本身的处理环节，而不是参与部门的组织架构。一条任务从被接收、被处理、遇到阻碍、交付确认到最终归档，每个环节对应一个状态。按部门划分容易出现“设计部处理中”“开发部处理中”这类状态，状态数量随部门增加而膨胀，却看不出任务卡在哪一步、下一步该谁动。
对多数单项任务，六个状态足以覆盖完整闭环：待受理、进行中、阻塞、待验收、已完成、已关闭。重开不设为独立状态，而是从已完成或已关闭回到进行中的回流路径，这样状态集合保持稳定，回流次数单独记录即可。
状态数量的控制原则是：相邻两个状态必须能区分责任人和下一步动作。如果两个状态的责任人相同、下一步动作也相同，就合并；如果某个状态长期没有任务停留，说明它不承载真实环节，应删除。状态过多会让填写负担上升、统计口径分散，状态过少则无法暴露阻塞和待验收的积压。
每个状态必须写清四项内容：进入条件、责任人、必填产出、允许的下一步。缺任何一项，状态就会变成标签，而不是可执行的流转节点。下表是一份可直接填写使用的状态定义表。
| 状态名 | 进入条件 | 责任人 | 必填产出 | 允许流转 |
|---|---|---|---|---|
| 待受理 | 任务已提交，尚未指派执行人 | 任务发起人 | 任务描述、期望完成时间、验收标准 | 进行中、已关闭（撤销） |
| 进行中 | 已指派执行人并确认开始处理 | 执行人 | 处理计划或首次进展说明 | 阻塞、待验收 |
| 阻塞 | 执行人申报存在无法自行解除的阻碍 | 执行人（申报）、管理者（协调） | 阻塞原因、影响范围、期望支持 | 进行中、已关闭（终止） |
| 待验收 | 执行人提交交付物并申请验收 | 验收人 | 交付物、自检说明 | 已完成、进行中（退回） |
| 已完成 | 验收人确认交付物符合验收标准 | 验收人 | 验收结论 | 已关闭、进行中（重开） |
| 已关闭 | 任务归档，不再需要跟踪 | 任务发起人或管理者 | 关闭说明 | 进行中（重开） |
流转规则怎么写：触发、校验与退回
状态之间的移动必须由具体动作触发，而不是由人手动改一个字段。动作是“提交验收”“标记阻塞”“验收通过”这类可被记录的操作，状态变化是动作的结果。这样每次状态变更都能回答三个问题：谁做的、做了什么、当时满足什么条件。
进入下一状态前的校验项分三类：必填字段、产出物、确认人。必填字段保证信息完整，例如提交验收时交付物链接和自检说明不能为空；产出物保证交接有实物，例如验收通过必须附验收结论；确认人保证责任落地，例如关闭任务需要发起人或管理者确认。校验条件应尽量由系统自动检查，减少人工把关的遗漏。
验收退回和重开是两条容易失控的路径，需要单独规定。验收退回必须指定退回的目标状态（通常是进行中）、填写退回原因，并记录退回次数；重开同样要求填写原因，并累计重开次数。退回和重开的次数是判断任务质量与验收标准是否合理的重要数据，不能省略。
阻塞与逾期要分开处理。阻塞由执行方主动申报，表示任务无法按原计划推进，需要外部支持；逾期由时间规则自动判定，表示任务已超过约定完成时间但仍在推进。两者混为一谈会导致统计失真：阻塞任务被当成逾期考核，执行人就不愿如实申报阻塞。下表是一份流转规则清单的填写结构。
| 源状态 | 触发动作 | 目标状态 | 校验条件 | 操作角色 |
|---|---|---|---|---|
| 待受理 | 指派并开始处理 | 进行中 | 执行人已指定、完成时间已确认 | 任务发起人或管理者 |
| 进行中 | 标记阻塞 | 阻塞 | 阻塞原因、影响范围、期望支持已填写 | 执行人 |
| 阻塞 | 解除阻塞 | 进行中 | 解除说明已填写 | 执行人或管理者 |
| 进行中 | 提交验收 | 待验收 | 交付物、自检说明齐全 | 执行人 |
| 待验收 | 验收通过 | 已完成 | 验收结论已填写 | 验收人 |
| 待验收 | 验收退回 | 进行中 | 退回原因必填，退回次数加一 | 验收人 |
| 已完成 | 归档关闭 | 已关闭 | 关闭说明已填写 | 任务发起人或管理者 |
| 已完成/已关闭 | 重开 | 进行中 | 重开原因必填，重开次数加一 | 任务发起人或管理者 |
角色与交付物：谁在什么状态下做什么
状态空转的常见原因是同一状态多人负责，或者交接时没有留下可核对的产出。角色与状态应尽量一一对应：每个状态有且只有一个主责角色，其他角色只在特定条件下介入。
任务发起人负责待受理阶段的完整性，确保任务描述、期望时间和验收标准在指派前就绪；任务进入已关闭后，发起人负责确认归档。执行人是进行中和阻塞状态的主责人，负责推进处理、如实申报阻塞、提交验收材料。验收人在待验收状态做主责判断，给出通过或退回结论并写明理由。管理者的职责集中在阻塞协调、逾期催办和升级处理，不替代执行人推进日常任务。
交接时点必须留下产出，这是状态流转可追溯的基础。进行中转待验收时留下交付物和自检说明；进行中转阻塞时留下阻塞原因和期望支持；待验收转已完成时留下验收结论；验收退回时留下退回意见。没有产出的状态变更应被规则拦截。
管理者的介入条件要写清楚，避免两种极端：事事上报导致管理者成为瓶颈，或者无人上报导致阻塞长期沉淀。可操作的介入条件是：阻塞状态停留超过约定时长、任务逾期且无进展更新、同一任务退回次数达到阈值。触发任一条件时，管理者发起催办或升级协调，并在任务记录中留下处理意见。
| 角色 | 主责状态 | 关键交付物 | 介入条件 |
|---|---|---|---|
| 任务发起人 | 待受理、已关闭 | 任务描述、验收标准、关闭说明 | 任务被撤销或需要重开时 |
| 执行人 | 进行中、阻塞 | 进展说明、阻塞申报、交付物 | — |
| 验收人 | 待验收 | 验收结论、退回意见 | 交付物与验收标准存在偏差时 |
| 管理者 | 阻塞协调、逾期处理 | 催办记录、升级处理意见 | 阻塞超时、逾期无更新、退回次数达阈值 |
示例：一条需求任务的完整流转
以下为演示情景，用于说明规则如何串联，不代表任何具体团队的真实案例。某团队收到一条“补充数据导出功能说明文档”的任务。
第一步，发起人提交任务，填写文档范围、期望完成时间和验收标准（覆盖全部导出字段、附示例），任务处于待受理。第二步，管理者指派执行人并确认完成时间，任务进入进行中，执行人留下处理计划。第三步，执行人在编写过程中发现导出字段清单缺失，无法继续，于是标记阻塞，填写阻塞原因“字段清单未提供”、影响范围和期望支持，任务进入阻塞。第四步，阻塞停留超过约定时长，管理者收到提醒后协调数据负责人补齐清单，执行人填写解除说明，任务回到进行中。
第五步，执行人完成文档并提交验收，附文档链接和自检说明，任务进入待验收。第六步，验收人发现示例部分缺少一个边界场景，执行验收退回，填写退回原因，退回次数记为一次，任务回到进行中。第七步，执行人补充示例后再次提交验收，验收人确认通过并填写验收结论，任务进入已完成。第八步，发起人确认归档，填写关闭说明，任务进入已关闭。
这个示例中，每次状态变化都有触发动作、责任人和留下的记录；阻塞与逾期分开处理，催办由停留时长触发；退回原因和次数被完整记录。规则本身与任务类型无关，换成缺陷修复、活动筹备或采购申请，只需替换验收标准和交付物内容，状态集合与流转结构可以沿用。
用工具承载状态流转
规则确定后，靠人工记忆和口头提醒维持流转，执行一段时间就会走样。工具的作用是把状态、校验和提醒固化下来，让不符合规则的变更无法完成，让该介入的人及时收到通知。
配置思路分四层。第一层是状态与流转规则：按状态定义表建立状态集合，为每条流转配置允许的源状态和目标状态，禁止跨状态跳转。第二层是校验：把必填字段、产出物和确认人设置为流转的前置条件，条件不满足时动作不可提交。第三层是记录留存：状态变更历史、退回原因、重开次数、阻塞申报内容都应可查询，作为后续统计的依据。第四层是提醒与升级：阻塞停留超时、任务逾期、退回次数达阈值时自动通知对应角色，减少人工巡检。
ONES 的工作项能力可以承载上述配置：用工作项类型定义任务，用状态与流转规则约束变更路径，用字段必填和属性校验拦截不完整的提交，用变更历史保留每次状态变化的操作人与时间，并通过通知规则把阻塞、逾期和退回事件推送给相关角色。具体配置入口和字段名称以团队实际使用的版本为准，配置前建议先用一条真实任务试跑一遍完整流转。
工具配置的验收标准是：一条任务从待受理走到已关闭，全程不需要人工提醒状态该往哪走，退回和重开自动留下原因与次数，阻塞和逾期能被区分统计。达到这个状态，说明规则已经由工具承接，而不是停留在文档里。
完成检查：流转是否真的跑通
规则上线前，用下面这份清单逐项核对。每一项都应能给出明确的是或否，以及对应的证据。
- 状态定义覆盖了任务从受理到关闭的全部真实环节，没有长期无人停留的孤立状态，也没有两个状态责任人和下一步动作完全相同。
- 每条流转都有明确的触发动作、操作角色和校验条件，不存在可以随意跳转的路径。
- 退回、重开、阻塞、逾期四类情况都有对应的处理路径和记录字段，退回原因与重开次数可查询。
- 阻塞与逾期在统计口径上分开，阻塞由执行方申报，逾期由时间规则判定。
- 状态停留时长、退回次数、重开次数、阻塞时长可以按任务导出统计。
- 每个状态的主责角色唯一，交接产出在规则中被设为必填。
- 管理者的催办与升级有明确的触发条件，且条件与停留时长或次数挂钩。
- 已用至少一条真实任务完整跑通全部状态，并根据试跑结果修订过状态数量或校验条件。
试跑后常见的修订方向是收敛状态数量：把使用频率极低的状态合并，把校验过严导致流转受阻的字段改为选填并补充说明。状态流转机制的有效性最终体现在两个指标上：任务在阻塞和待验收状态的停留时长是否可控，退回与重开的次数是否随验收标准明确而下降。规则随执行情况迭代，比一次性设计一套复杂状态更可靠。
常见问题
团队规模小、任务类型单一，还需要六个状态吗？
可以按实际环节裁剪。状态数量的判断标准是相邻状态能否区分责任人和下一步动作：如果团队里验收与关闭由同一人在同一时点完成，待验收和已完成可以合并；如果任务很少出现需要外部支持的阻碍，阻塞状态可以暂时不设，遇到阻碍时直接由管理者协调。裁剪后仍需保留四项内容——进入条件、责任人、必填产出、允许的下一步，否则状态会退化成标签。团队扩大或任务类型增多后，再按需补回状态，比一开始就设计复杂状态更容易维护。
阻塞和逾期能不能合并成一个状态？
不建议合并。阻塞由执行方主动申报，表示任务无法按原计划推进、需要外部支持；逾期由时间规则自动判定，表示任务已超过约定完成时间但仍在推进。两者合并会带来两个问题：阻塞任务被计入逾期考核，执行人就不愿如实申报；逾期任务被误认为需要协调资源，管理者会把精力花错地方。分开处理后，阻塞时长和逾期数量可以分别统计，前者反映协作与资源问题，后者反映计划与执行节奏问题。
验收退回和重开有什么区别，记录时要注意什么？
验收退回发生在待验收状态，由验收人发起，任务回到进行中，说明交付物未达到验收标准；重开发生在已完成或已关闭状态，由任务发起人或管理者发起，说明任务在关闭后又出现新的处理需求。两者都要填写原因并累计次数，区别在于退回次数反映验收标准是否清晰、交付质量是否稳定，重开次数反映关闭判断是否草率。统计时分开计数，才能定位问题出在验收环节还是关闭环节。
规则刚上线，执行人嫌填写字段太多怎么办？
先区分哪些字段是流转校验必需的，哪些只是希望采集的信息。流转校验必需的字段（如提交验收时的交付物、退回时的原因）保留为必填，其余改为选填，避免因填写负担导致状态变更被绕过。试跑一轮后查看各字段的实际填写率：长期为空且无人使用的字段删除，经常补填说明的字段考虑改为必填。字段精简与规则有效性可以同时成立，关键是保留能支撑统计和责任追溯的最小集合。
怎么判断状态流转规则需要修订？
看三个信号：某个状态长期没有任务停留，说明它不承载真实环节；某条流转频繁被绕过或靠人工提醒才发生，说明触发动作或校验条件设计不合理；退回次数或重开次数持续偏高，说明验收标准或关闭判断需要收紧。出现任一信号时，先用几条真实任务复盘流转记录，再决定是合并状态、调整校验条件还是补充说明，修订后重新试跑一轮。
