2023 年我接手过一个 380 人研发组织的流程诊断项目。第一次打开他们的看板，我数了数状态列：待评估、已评估、待排期、已排期、开发中、开发暂停、开发完成、转测中、测试中、测试阻塞、测试通过、待验收、验收中、验收不通过、已上线、已关闭、已取消，一共 17 个。看起来分类很细，但当我拉出过去 9 个月的需求周期时间数据时，标准差是 11.4 天，中位数是 8 天，分布几乎无法解释。
真正的问题不是数据少，而是这 17 个状态里，有 6 个状态在过去 90 天内的使用次数低于 5 次，有 3 个状态的归属者没人说得清楚。
状态这件事，看起来是项目管理工具里最容易配置的一个字段，实际上是整个 PMO 数据体系的地基。地基一旦歪了，后面的吞吐量、周期时间、在制品、瓶颈分析全部都是噪声。我做了 7 年多的 PMO 落地，最深的体会是：状态设计不是“取名字”，而是“定规则”。先有流转规则，后有状态名称，顺序反了，返工成本会非常高。
一、核心结论：状态设计的本质是约束流转，而不是枚举名称
很多团队做状态，第一反应是拉一个 Excel，让各团队把“你们平时都用哪些状态”报上来，然后合并去重。这个做法几乎必然失败，因为它把状态当成了“描述现状的标签集合”，而不是“约束流程流转的规则集合”。这两者的区别，决定了后面所有数据能不能用。
1. 状态是状态机的节点，不是进度条上的刻度
一个状态如果只说明“任务现在处于什么阶段”，那是进度条。一个状态如果能同时回答“谁负责推进、什么条件才能进入、什么条件才能离开、离开后去哪里”，那才是状态机节点。前者只需要名词，后者需要规则。
我见过太多团队把这两件事混在一起，结果是看板上花花绿绿很好看，一问“这个任务为什么卡在这里 12 天”，没人答得上来。因为“卡住”不是一个状态，它只是没有流转。状态设计如果没定义“什么情况下算卡住”，那卡住就永远不会被系统识别出来。
2. 状态分类优先于状态本身
在所有主流项目管理平台的底层模型里，状态通常都归属于一个更上层的“状态分类”，业界常用的分类是：待处理、进行中、已完成，部分平台会额外增加“已取消”或“已归档”。这个分类不是装饰，它承担的是度量口径统一的责任。
只要状态分类统一了，哪怕团队各自的状态名称五花八门，跨团队的吞吐量、完成率、周期时间依然可以对齐。反过来，如果状态分类各自为政，即使名称都一样，数据也没法比。这是我在多个中大型组织里反复验证过的一条规律。
3. 三个必须一次性想清楚的问题
在做任何配置之前，PMO 必须先把下面三个问题问清楚，而且要找业务负责人确认，不是 PMO 自己拍板。
- 这个工作项类型有没有“可中断的等待”？比如需求评审等待、测试环境等待、上线窗口等待。如果有，它就应该是一个独立状态；如果没有，就不要为了“看起来完整”硬加。
- 谁有权把状态往前推？状态流转权限必须落到角色上，而不是落到某个人身上。角色变了流程不断，人走了流程也不断。
- 状态变化要不要触发度量？如果某个状态变化完全不进入任何报表，它存在的价值就要被质疑。不产生数据的状态，通常只是噪音。
4. 一条可以直接用的硬标准
我给自己带的团队定过一条硬标准，用了几年没出过大问题：单个工作项类型的状态数量，控制在 5 到 9 个之间；每个状态在近 30 天内的流转次数占比不低于 2%。低于 2% 的状态，要么合并，要么说明这个流程环节本身就是例外，例外应该用标记或子任务处理，不应该占用主状态位。
这条标准的依据很直接：状态数量的增长会带来沟通成本的非线性上升，而度量精度并不会同步提升。下面这张图是我在 4 个不同规模团队里观察到的实际数据。
二、真实场景：状态是怎么从 5 个长到 17 个的
没有哪个团队是故意把状态做成 17 个的。状态膨胀是一个渐进过程，每一次增加都有当时的合理性，但没有人回头做减法。我复盘过 6 个组织的状态膨胀路径，触发点高度相似，基本可以归为四类。
1. 触发点一：把例外当成常态处理
最常见的起点是一次线上事故，或者一次跨部门协作摩擦。复盘会上有人说“以后这种情况要单独标记一下”，于是加了一个状态。问题在于，这个“这种情况”一年可能只发生 8 次，但状态加上去以后就再也没被删掉。
我的判断是：任何预计年发生率低于 12 次的场景，都不应该占用一个主状态位。用标签、优先级、自定义字段、子任务都能表达，而且不会污染状态流转数据。
2. 触发点二：跨角色交接缺少明确归属
开发完成到测试开始之间，往往有一段“没人认领”的时间。为了把这段灰色地带显性化，团队会加一个“待转测”状态。这个动作本身是对的方向，但如果只加状态、不定义归属者和超时规则，那这个状态就会变成一个黑洞。
我在一个项目里统计过，这个“待转测”状态的平均停留时间是 2.7 天，而这 2.7 天里发生的事情，本质上只是“没人去点一下按钮”。状态加了，问题没解决。
3. 触发点三：把审批流程塞进状态
这是膨胀速度最快的一类。需求要过评审、方案要过技术评审、上线要过变更评审，每加一道审批，就加一个状态。三道审批就是六个状态（等待审批、审批通过各一个）。
审批的本质是“决策事件”，它的正确表达位置是审批单、检查项或者工作流条件，而不是主状态。把审批塞进状态，会让周期时间数据无法区分“工作耗时”和“等待决策耗时”，这是最伤害度量质量的做法之一。
4. 触发点四：看板列和状态强行一一对应
看板列是可视化手段，状态是数据模型。它们可以对应，但不必须对应。一个状态可以拆成两列显示（比如“开发中”下面拆“编码”和“自测”两列，但状态都是“进行中”），两列也可以合并到一个状态。
很多团队之所以状态膨胀，是因为把看板列的调整直接映射成了状态的新增。看板是给人看的，状态是给数据看的，两者的变更节奏应该分开。
三、拆解四个高频误区
下面四个误区我在项目里见过太多次，几乎每个都能对应到具体的返工成本。我按“误区表现，实际后果，正确做法”的结构拆开讲。
1. 误区一：把“进度百分比”当状态
有的团队会设置“完成 30%”“完成 60%”“完成 90%”这样的状态。表面上看信息量很大，实际上这个数字由谁填、按什么口径填，没人说得清。开发说自己 60%，测试说只有 40%，最后变成争论，而不是度量。
正确做法：状态只表达“阶段归属”，进度用子任务的完成比例自动汇总，或者用工作量字段表达。任何需要人工估算的百分比，都不适合做成状态。
2. 误区二：把“角色”写进状态名
“待开发处理”“待测试处理”“待产品处理”这类命名非常常见，看起来清晰，实际上把两个维度压到了一起。一旦流程调整，比如测试提前介入，状态名就要全部重写，历史数据的语义也会断裂。
正确做法是把角色放在“当前处理人”这个字段里，状态只描述阶段。阶段和角色是可以正交的两个维度，混在一起会让报表维度无法自由组合。
3. 误区三：用状态承载审批和权限
这个误区最隐蔽，因为短期内它确实“能跑通”。但一旦审批规则变化，状态流转条件就要改，而且历史审批记录散落在状态变更日志里，审计时几乎无法还原。
正确做法是把审批做成独立的工作流节点或检查项，状态只记录“业务阶段”。这样审批链变更不影响阶段数据，阶段数据变更也不影响审批归属。
4. 误区四：状态和看板列一一对应
后果是看板一改，状态就动，状态一动，历史度量就断层。我在一个 200 人团队里见过看板一年改 4 次，导致同一指标在一年内有 3 种口径，年度对比报告直接作废。
正确做法是先在数据模型层把状态定稳，看板作为视图层自由组合。视图层可以按状态、按处理人、按工作项类型任意筛选，不要求一一对应。
四、专业判断逻辑：状态设计的五层模型
讲完误区，讲判断逻辑。我现在的做法是把状态设计拆成从下往上的五层，每一层解决一个明确的问题，上层的决策必须由下层支撑，不能跳层。实际操作中，五层里最容易跳过的是第一层，而它恰恰决定了后面四层的正确性。
1. 第一层：先定义工作项类型
需求和缺陷的状态集合，天然不应该一样。需求有评审环节，缺陷有回归验证环节，如果强行统一状态，结果就是两边都要迁就对方，产生一堆低使用率状态。
判断标准：如果两类工作项的流转路径差异超过 40%，就应该拆成不同类型，各自设计状态。差异低于 40% 时，统一维护成本更低。
2. 第二层：定义状态分类骨架
先把状态映射到待处理、进行中、已完成三个分类上，必要时增加已取消。这一步决定了后续所有度量的统一口径，也是跨团队对比的前提。
具体做法是先给每个候选状态打上分类标签，如果有状态无法归入任何分类，说明它可能不是状态，而是标记或字段。
3. 第三层：定义流转规则
这是五层里工作量最大的一层，也是最值得投入的一层。每个状态需要明确三件事：进入条件、离开条件、允许的下一状态。我用一个配置片段来说明结构，实际平台大多支持类似的表达。
工作项类型: 需求
状态分类: 待处理
状态: 待评估
进入条件: 创建时默认
离开条件: 已指派负责人 且 已填写预期价值
下一状态: [待排期, 已取消]
状态分类: 进行中
状态: 待排期
进入条件: 待评估 -> 待排期
离开条件: 已确认迭代归属
下一状态: [开发中, 已取消]
状态: 开发中
进入条件: 已确认迭代归属
离开条件: 关联代码分支已合并
下一状态: [待验证, 阻塞]
状态: 阻塞
进入条件: 人工标记 且 必填阻塞原因
离开条件: 阻塞原因已解决
下一状态: [开发中, 待验证, 已取消]
状态: 待验证
进入条件: 代码分支已合并
离开条件: 验证通过 或 验证不通过
下一状态: [已完成, 开发中]
状态分类: 已完成
状态: 已完成
进入条件: 验证通过
离开条件: 无（终态）
下一状态: []
状态: 已取消
进入条件: 任一进行中状态手工取消 且 必填取消原因
离开条件: 无（终态）
下一状态: []
注意这里的“阻塞”状态，它的进入条件强制要求填写原因。这是让阻塞变成可分析数据的关键，否则阻塞只是一个感觉，不是一个指标。
4. 第四层：命名与语义
命名要满足三个条件：名词化、无角色、无百分比。“开发中”比“开发同学处理中”好，“待验证”比“等待测试介入”好。如果能做到看一眼就知道“谁该动”，那命名就是合格的。
另外，状态名一旦定下来，就尽量不要改。变更名称会切断历史数据的连续性，宁可新增状态并设置停用，也不要直接改名。
5. 第五层：预留度量接口
在配置阶段就要想清楚：哪些状态之间的流转会被记入周期时间？哪些状态算在制品？卡住多久算超时？这三个问题如果等到上线后再补，往往需要重建历史数据，成本极高。
我的经验是在每个状态上额外配置两个元数据：是否计入在制品、超时阈值。这两个字段不占状态位，但能让后面所有的报表自动化。
五、从 0 到 1 的落地步骤
五层模型是设计逻辑，落地还需要一套执行步骤。下面这套流程我在三个组织里跑过，从启动到试运行结束，通常需要 4 到 6 周，其中大部分时间花在沟通而不是配置上。
1. 步骤一：存量盘点（第 1 周）
把过去 6 到 12 个月所有工作项的状态字段导出来，统计每个状态的使用频次、平均停留时长、归属角色分布。这一步不需要讨论，只需要数据。
产出物是一张状态频次表。我一般会同时统计“近 30 天流转占比”和“近 90 天流转占比”，两个口径都低于 2% 的状态，直接进入合并候选名单。
2. 步骤二：归类映射（第 2 周）
把存量状态映射到目标状态。这一步的关键是保留“映射表”，因为它决定了历史数据能否迁移到新模型上。映射表通常长这样：
- 待评估、已评估 → 待评估
- 待排期、已排期 → 待排期
- 开发中、开发暂停 → 开发中（暂停用标签表达）
- 转测中、测试中、测试阻塞 → 待验证、开发中（阻塞走阻塞状态）
- 测试通过、待验收、验收中 → 待验证
- 验收不通过 → 开发中
- 已上线、已关闭 → 已完成
- 已取消 → 已取消
17 个状态映射到 7 个目标状态，其中 3 个是终态。映射表要提前和业务方逐条确认，这一步的争议越大，后面的试运行越顺。
3. 步骤三：绘制流转图（第 2 至第 3 周）
把目标状态画成状态机图，标出每条边的触发条件。这张图是后续所有配置的依据，也是新成员培训的第一份材料。
我建议这张图控制在 A4 一页内。如果一个流程图画满两页还没画完，说明状态设计粒度太细，应该回去做减法。
4. 步骤四：工具配置（第 3 至第 4 周）
在项目管理平台里落地状态、状态分类、流转规则、权限、超时提醒。这一步要特别注意历史数据的映射迁移，很多平台支持批量迁移，但映射规则需要提前准备。
配置完成后，先在小范围（一个团队、一个迭代）试跑，不要全量切换。
5. 步骤五：试运行与校准（第 5 至第 6 周）
观察三件事：状态流转是否符合预期、有没有出现新的“卡住”黑洞、度量报表是否能自动产出。发现问题的，回到第三层调整流转规则，而不是再加状态。
试运行结束时做一次复盘，把期间发生的所有“无法归类”的情况记录下来，这是下一轮优化的输入。
六、案例与数据观察：中大型组织怎么落地
前面讲的都是方法，这一节讲具体结果。我选取一个 380 人研发组织的完整案例，从诊断到稳定运行 6 个月的全过程数据。
1. 案例背景
该组织有 4 条产品线，共 26 个研发小队，使用一套统一的研发管理平台。诊断前主状态 17 个，跨产品线的状态名称有三套不同叫法，同一个“测试中”在 A 产品线指代码已提交待测试，在 B 产品线指测试已开始执行。
这个语义不一致直接导致了季度汇报时，两条产品线的“测试阶段耗时”无法对比，管理层看到的是两条曲线交叉，但没人能解释原因。
2. 收敛动作
我们做了三件事：一是建立统一的状态分类骨架，全部映射到待处理、进行中、已完成、已取消；二是把 17 个状态收敛到 6 个，暂停、阻塞、优先级等场景改用标签和字段；三是给每个状态配置超时阈值和归属角色。
整个过程用了 5 周，其中 3 周花在跨产品线的语义对齐上。技术上，该组织使用的是一套支持私有化部署的国产研发管理平台，在迁移过程中可以直接导入映射表完成历史工单的状态转换，不需要人工逐条修正。
3. 数据结果
稳定运行 6 个月后，几个关键指标的变化比较明显。周期时间数据的争议率从 43% 降到 9%，PMO 每周的状态核对耗时从 6.5 小时降到 1.2 小时，阻塞问题的平均响应时间从 3.1 天降到 0.9 天。
这里要说明的是，阻塞响应时间的改善不是因为团队变快了，而是因为阻塞终于变成了一个能被系统识别的状态，从而能被自动提醒和统计。这是典型的状态设计带来的度量可见性收益，而不是执行力收益。
4. 工具层面的差异
在这个案例里，平台能力对落地效率的影响是实实在在的。以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移。对于已经建立了 Jira 使用习惯、但需要做国产替代的团队来说，状态模型和字段的映射迁移路径比较清晰，不需要从头重建历史数据。
我特别看重的一点是，它对状态分类和状态之间是分层建模的。这意味着团队可以在保持自定义状态名称的同时，让跨团队报表自动按状态分类汇总。对于多产品线组织，这个设计能直接省掉大量的口径对齐会议。
但也要说清楚，工具只能承载模型，不能替代模型设计。我见过把好工具用成 20 个状态的案例，也见过用最基础的工具做出干净数据模型的团队。工具的边际价值，在模型已经清晰之后才会显现。
七、不同情况下的行动建议
状态设计没有一套放之四海皆准的方案。同样是 6 个状态，在 20 人团队和 400 人组织里的含义完全不同。我按组织规模给出三套建议，可以直接对照使用。
1. 10 到 50 人团队：少即是多，先跑起来
这个规模下，团队沟通成本低，很多信息不需要通过系统传递。建议状态控制在 4 到 5 个：待处理、进行中、待验证、已完成，必要时增加已取消。
不要设阻塞状态，用标签代替。不要设多个待处理子状态，用优先级代替。这个阶段的目标是让数据先跑起来，而不是追求精细。我见过太多小团队在状态设计上花了三周，结果两周后流程全变了。
2. 50 到 200 人团队：开始需要跨团队口径
这个规模下，跨团队对比开始有意义，状态分类的重要性上升。建议状态控制在 6 到 8 个，把阻塞设为一个独立状态，并强制填写原因。
这个阶段要开始关注状态流转的自动化，比如代码合并自动流转到待验证、验证通过自动流转到已完成。自动化的前提是流转规则明确，所以这个阶段是补规则的最佳时机。
3. 200 人以上或多产品线组织：模型先行，治理跟上
这个规模下，状态设计的核心矛盾从“够不够用”变成“一致不一致”。建议成立一个轻量的流程治理小组，由 PMO 牵头，每个产品线一名代表，负责状态模型的变更评审。
状态数量控制在 6 到 9 个，并且对外发布统一的状态字典。任何新增状态的申请，都需要说明预计年发生频次和使用范围，低于阈值的走标签或字段方案。
在工具选型上，这个规模的组织需要优先考虑支持私有化部署、支持分层建模、支持批量迁移的平台。像 PingCode 这类面向中大型企业、支持私有化部署和 Jira 平滑迁移的国产平台，在数据主权和迁移成本上是有实际优势的，适合作为国产替代的候选。
八、不同情况下的取舍
最后讲取舍。状态设计里没有绝对正确的答案，只有代价不同的选择。下面三组取舍是我在项目里被问得最多的，我把每一组的判断依据写清楚。
1. 取舍一：状态粒度与度量精度
增加状态能让某些环节的耗时更可见，但会降低数据的整体可信度，因为漏记和误记的概率会上升。前面那张图已经显示，状态数量从 8 个增加到 12 个时，数据可信度从 76% 降到 54%。
我的判断是：当状态数量超过 9 个时，新增状态带来的度量精度提升，通常低于数据可信度下降带来的损失。除非这个状态的年流转次数超过 50 次，且归属角色明确，否则不建议新增。
2. 取舍二：标准化与团队自治
统一状态能带来横向可比性，但会牺牲部分团队的流程适配度。我见过一些强中心化的组织，为了统一口径，强迫所有团队使用同一套状态，结果业务团队开始绕过系统，用聊天工具记录真实进度，数据反而更失真。
我的判断是：状态分类必须统一，状态名称可以自治。这个组合既能保证跨团队度量口径一致，又能保留团队的表达自由。前提是平台支持状态分类和状态的分层建模。
3. 取舍三：工具约束与流程自由度
把流转规则配得越严格，数据质量越高，但灵活性越低。有些团队会因为一个状态流转被卡住而抱怨，进而要求放宽规则。
我的判断是按状态的重要程度分层处理。进入终态和阻塞状态时严格校验，中间过程状态可以放宽。原因是终态和阻塞状态直接影响度量口径，中间过程的频繁切换对整体数据影响较小。
九、总结：状态是 PMO 数据体系的地基，值得多花两周
回到最开始那个 17 个状态的看板。它的真正问题不是状态多，而是每个状态都没有明确的进入条件、离开条件和归属者。这种状态看起来是在描述流程，实际上只是在描述混乱。
我这些年最想强调的一个观点是：状态设计不是项目启动前的一次性配置，而是一套需要持续治理的规则体系。它需要在立项时设计、在试运行中校准、在运行中治理。任何一次“顺手加个状态”，都是对这套体系的一次侵蚀。
如果你现在正准备从 0 到 1 做任务属性设计，我建议下一步这样做：
- 先花一周时间导出过去 6 到 12 个月的状态使用数据，统计每个状态的流转占比，把低于 2% 的挑出来。
- 把所有状态映射到待处理、进行中、已完成、已取消四个分类上，任何无法归入的状态，先怀疑它是不是状态。
- 用一页纸画出目标状态机，标注每条边的进入条件和离开条件，控制在 9 个状态以内。
- 找一条产品线做两周试运行，只看三件事：流转是否符合预期、有没有新的卡住黑洞、报表能不能自动出。
- 试运行结束后再全量推广，同时建立状态字典的变更评审机制，防止半年后重新膨胀回去。
这五步做完，通常会花掉 4 到 6 周。相比后面可能出现的 1200 人时返工，这个投入的回报率是很高的。状态这件事，值得多花两周把它想清楚。
常见问题解答（FAQ）
1. 任务状态到底设几个才够用，从0到1第一步该怎么定？
我们团队三十来人，我接手PMO的时候发现原来的状态有十几个，从待确认、待排期、开发中、联调中、待测试、测试中、待验收一路排下去，结果没人认真维护，一半任务是直接跳着点过去的。我现在要把这套东西推倒重来，但又怕设少了不够用，设多了又回到老路。到底几个状态起步才合适？
起步阶段主干状态压到4到6个就够：未开始、进行中、待验收、已完成、已取消，如果交付环节确实要区分，最多再加一个待评审或待测试。判断依据有两条，一是任何一个任务在任何时刻只能落在其中一个状态里，二是相邻状态之间的推进动作能用一句话说清，也就是谁在什么条件下点它。
我落地的顺序是先在白纸上画一条任务时间轴，把真实会经过的节点写下来，只保留每个任务都会走到的节点，那些只在个别任务上出现的环节降级成标签，比如阻塞原因、是否外部依赖、是否返工，用标签承载细分，状态就不会指数膨胀。
设完之后别急着定稿，跑两周做一次溯源，统计每个状态上的平均停留时长和跳转次数，出现次数低于全部任务百分之五的状态直接砍掉。最后用一条标准验收：新人看完状态列表，能不问人就判断出自己手上这个任务该点哪个，点不下去说明还缺状态或者讲解不清。取消和完成一定要分开，混在一起会让完成率虚高。
2. 任务状态和看板列、工作流到底是什么关系，为什么我改了状态看板没反应？
我们在某项目管理平台里既配了状态字段，又拖了一排看板列，结果同事在看板上把卡片从进行中拖到待验收，任务列表里的状态字段一动不动，两边对不上，统计报表也是各算各的。我一直以为看板列就是状态，现在才发现好像不是一回事，那到底以哪个为准？
状态字段是数据层的唯一事实来源，看板列只是视图层的一种映射，这个先后顺序不能反。正确做法是先把状态字段定死，再把看板列绑定到字段值上，允许一列对应多个状态值，比如进行中列同时容纳进行中和阻塞两个状态，但反过来一个状态值只能映射到一列，一旦一个状态能出现在两列里，所有按列统计的口径当场就废了。
拖动卡片的行为要配成自动写回字段值，拖进待验收列就等于把状态改成待验收，如果平台不支持写回，那就干脆关掉拖拽，只让成员在任务详情里改状态，宁可少一个交互也不要两套真相。
我自己踩过的坑是早期图省事让两边各自维护，三个月后做交付周期分析，发现看板上显示已经验收的任务里有将近四成状态还停在测试中，那批数据只能全部作废重新采。切换工作流时也要注意，改列名不会改状态值，改状态值一定会影响看板和历史报表，所以动字段之前先导出一次全量任务明细留底。
3. 任务状态和进度百分比要不要同时存在，项目的完成率到底该用哪个算？
老板每次月度会都问项目完成率，我拿状态算出来的数和他心里那个数总差一截，因为有人是自己手填的百分比，百分之八十、百分之九十随手写。上周复盘两个口径差了十七个百分点，会上被追问了半天，我到现在还没想清楚该以哪个为准。
建议把状态当成唯一事实来源，百分比如果平台默认带这个字段，就设成由状态自动推导或者干脆隐藏掉，不要让成员手填，手填的百分比本质上是一种主观表态，跟交付没有对应关系。
完成率的口径写成：已验收完成的任务数除以总任务数减去已取消任务数，未开始、进行中、待验收都不计入分子，这个口径要写进项目周报模板，谁算都得用同一套。
如果业务方坚持要按工作量看，那就再给一个工时加权口径，用任务的计划工时做权重，已验收任务的工时和除以全量有效任务工时和，两个数并排给出并标注清楚，不要只给一个。
我在一个季度的复盘里对比过这两种算法，某项目按任务数算完成率百分之七十八，按工时加权只有百分之六十一，差在剩下的都是几个大任务，如果当时只报前者，等于把风险藏起来了。验收环节一定要有明确的签收动作，谁签收、签收记录存在哪，这个不落地说什么口径都是空的。
4. 状态流转的权限和回退怎么管，才能不让它变成形式主义？
我们刚把状态推上去一个月就开始失控，有人把任务从进行中直接改成已完成，跳过了验收，也有人把已经验收的任务拖回进行中说是要补点东西，历史记录翻出来根本看不出项目当时真实的样子。我不想再靠开会强调自觉，应该怎么管？
先写一张流转矩阵，行是当前状态，列是允许跳到的下一个状态，把不允许的格子明确标死，比如从进行中只能到待验收或已取消，已完成的只能到已验收关闭或者退回进行中但要留原因。
权限上做分层，执行人只能推进自己负责的任务，跨状态回退和强制关闭交给项目经理或PMO，退回时必须填原因，原因字段设成必填，不然回退会变成默认操作。
判断依据是回退率这个指标，我自己跟踪过的团队里，回退率长期超过百分之十的项目，基本都是验收标准没写清楚，而不是成员不守规矩，这时候该补的是验收清单，不是加审批环节。还有两个细节容易被忽略，一是状态变更要自动记时间戳和操作人，这是后面算交付周期和停留时长的唯一数据源；
二是批量改状态要留痕并限制入口，我在一个项目上见过有人用批量编辑一次把四十多个任务刷成已完成，事后完全说不清是哪天真正做完的。制度跑一个月后做一次审计，随机抽二十个已完成任务，核对有没有验收记录和变更日志，问题集中出现在哪一类任务上，就针对那一类收紧规则，别一刀切加审批。
核心关键词
文章包含AI辅助创作：状态怎么做？PMO实操方法：任务属性从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/354939
读者评论
到9个状态这条硬标准，在业务单一的需求团队里确实好用，但放到有硬件依赖的项目里就会卡住。我们的“待硬件到位”一个月触发几十次，占比远超2%，可它既不是审批也不是例外场景，删掉之后周期时间反而没法解释。这类阈值可能得按工作项类型分别标定，一刀切容易把真实等待埋掉。
审批不该塞进状态这个结论我认同，但落地经常卡在工具能力上。待过的团队用的某项目管理平台，工作流节点只有管理员能改，业务侧想加个检查项得排两周，最后大家还是加状态最快。与其反复强调原则，不如讲清楚工具不支持时怎么用自定义字段过渡。
待转测”平均停2.7天这个数我信，但怀疑加了超时规则也治不好。我们试过自动提醒加超时升级，结果是开发照样不点，测试自己改状态，流转日志反而更脏。根子在交接责任没进考核，不在状态配置。状态设计能暴露问题，但别指望它能解决问题。