状态怎么做？项目经理制度设计：任务属性从0到1

去年冬天，我接手过一个 380 人规模研发组织的流程治理项目。第一次翻开他们的项目周报，有个数字让我停了很久：全部在办任务里，状态标记为「进行中」的占了 47%。我随机抽了 120 条「进行中」，其中 38 条的最后更新时间在 14 天以前，还有 11 条的任务负责人已经离职三个月。

更麻烦的是，当我把这个问题抛给他们的 PMO 负责人时，对方的回答是：「状态就是工具里默认那几个，从上线那天就这样，没人动过。」

那一刻我就知道，这不是执行力问题，也不是工具问题。这是一个从立项第一天起就没有被设计过的字段，被当成了报表装饰品。任务状态看起来只是看板上的一列卡片，实际上它是项目经理制度里最小的、也是最先崩掉的一环。这篇内容，我想把「任务属性从 0 到 1」这件事完整拆一遍，不是讲概念，是讲我在真实项目里怎么定、怎么改、怎么说服人。

一、核心结论：状态不是标签，是制度的最小可执行单元

我把结论放在最前面，因为大部分人在这件事上绕了太久。任务状态的设计目标不是「让看板好看」，而是让组织能够在不问人的前提下，判断一件事现在卡在哪、谁该动、下一步会发生什么。

1. 状态字段的本质是「谁、在什么条件下、能做什么」

一个状态如果只能回答「这件事目前处于哪个阶段」，它就是个标签，价值接近于零。真正有价值的状态，同时携带三件事：当前的责任人是谁、进入这个状态需要满足什么条件、离开这个状态允许去哪里。

我在给团队做状态设计培训时，常举一个例子：如果「已完成」这个状态允许任何人随时切换进去，也不需要任何交付物链接，那它实际上等于「我不想再看到这条任务了」。这样的状态在报表上很好看，在复盘会上会要命。

所以判断一个状态字段设计得好不好，最直接的方法是把每个状态单独拎出来问一句：进入它需要什么证据？谁有权限进入？进入后责任转移给了谁？三个问题里只要有一个答不上来，这个状态就是装饰品。

2. 好状态的三个验收标准：可观测、可追责、可预测

我把这三条当成硬标准，是因为它们分别对应了项目管理的三个真实痛点：看不清、找不到人、算不准。

• 可观测：任何人打开任务列表，不需要额外解释就能知道有多少事卡住了、卡了多久。这一条靠的是状态的互斥性和穷尽性，每个任务在任意时刻有且只有一个状态。
• 可追责：每个状态变更背后都能定位到一个人和一个时间点。这一条靠的是流转权限和操作日志，不是靠自觉。
• 可预测：用历史状态流转数据能够推算出交付概率。这一条最难，也是绝大多数团队完全没做到的，因为他们的状态数据本身就不可信。

这三条是有顺序的。可观测没做到，就不要谈可追责；可追责没做到，可预测就是自欺欺人。我见过不少团队直接跳到第三步，做了一堆燃尽图和累积流图，最后结论是「图表没什么用」，问题不在图表，在地基。

3. 状态数量的经验基线

关于「到底该设几个状态」，我的经验基线是这样：

注意「已拒绝」「不修复」这类终态。它们不是凑数的，它们承担着一个非常重要的功能：让「没做」这件事有地方可去。没有它们，所有被否决的事项都会烂在「待办」里，一年后你打开列表，看到的是几百条永远不会有人碰的任务。

二、背景：状态失控通常发生在三个真实场景里

我在过去两年里参与过 7 个流程治理项目，规模从 60 人到 1200 人。梳理下来，状态字段出问题几乎都逃不出三个场景，而且这三个场景往往同时出现。

1. 场景一：工具上线当天默认带出的状态模板

这是最普遍的一种。团队采购了某个项目管理平台，实施顾问按标准模板导入了一套状态，大家培训半天就开始用了。三个月后有人问「为什么要有『已提测』这个状态」，没人答得上来。

我印象最深的是一个 210 人的组织，他们的任务状态有 11 个：待办、待启动、进行中、开发中、已提测、测试中、已修复、待验收、验收中、已完成、已归档。我问项目经理：「一个任务从『开发中』到『已提测』，中间有没有可能回退？」对方想了想说：「经常回退，提测发现编译不过就退回去了。」

这就是典型的把「过程描述」当成了「状态」。状态的价值在于区分责任归属，不在于复述工作步骤。开发中和已提测，如果责任人都是同一个开发，那它就是同一个状态；如果「已提测」意味着责任转移到了测试，那它才配成为一个独立状态。

2. 场景二：把「阶段」和「状态」混在一张字段里

第二个高频问题，是把项目阶段、任务阶段、任务状态三件事塞进同一个下拉框。我在一个制造企业的数字化项目里见过这么一组值：立项、需求、设计、开发、UAT、上线、运维、暂停。

看起来挺合理，问题是当你需要统计「这个迭代有多少任务被阻塞」时，你根本无从下手，阻塞不在这八个值里的任何一个。「暂停」勉强算，但它同时包含了「等人」「等料」「等预算」三种完全不同的情况，对应三个不同的责任人。

我的判断很简单：阶段属于项目或迭代层级，状态属于工作项层级，两者不应该出现在同一个字段里。阶段是时间轴上的位置，状态是责任链上的位置，混在一起的结果是两个都说不清。

3. 场景三：状态谁都能改，改完没人知道

第三个场景往往被忽略，但它对数据的破坏力最大。在一个 400 人的研发组织里，我做过一次状态变更审计：抽查 200 条任务的 30 天内状态变更记录，其中 61 条是由非任务负责人修改的，包括产品经理、测试、甚至行政。

更关键的是，这些修改里只有 23% 附带了任何形式的说明。也就是说，近 80% 的状态变更在系统里是「无因变更」，你能看到状态变了，但不知道为什么变、凭什么变。

这样的数据拿去做什么都是错的。用它算交付周期，得到的是一个被随意操作过的数字；用它做复盘，讨论的是一堆无法还原现场的事件。

三、拆解六个常见误区

下面这六个误区，是我在实际项目里反复听到、也反复纠正过的。它们的共同点是：听起来都很合理，但用在真实团队里会持续制造噪音。

1. 误区一：状态越多越精细，越能反映真实进度

这是最顽固的一个。持这种观点的人通常会说：「我们的流程本来就复杂，五个状态根本描述不了。」

我的反驳方式是算一笔账。状态数量增加带来的是「更新成本」的线性上升和「数据可信度」的非线性下降。当状态从 5 个增加到 11 个，一个开发每天要在任务上多做 2-3 次状态切换判断；判断次数越多，随手点一个的概率就越高。最终你得到的是更细的字段和更粗的数据。

更实际的做法是：把「过程细节」交给评论区和检查项，把「责任转移点」留给状态。开发和联调都是开发在做，就都属于「进行中」；测试接手了，才进入「待验收」。

2. 误区二：把进度百分比当成状态

我曾经接手过一个项目，任务里有个「完成度」字段，值从 0% 到 100%，步长 5%。三个月后我做了一次分布统计：所有任务里，标记 80% 的占了 31%，标记 90% 的占了 24%。而这两个数字对应的任务，平均又花了 19 天才真正关闭。

这就是「90% 陷阱」，百分比是一个心理学字段，不是管理字段。任务越接近尾声，剩余工作量越难估算，人的乐观偏差也越严重。你看到的 90% 是感觉，不是事实。

状态比百分比好的地方在于它是离散的、可验证的。「待验收」这个状态可以附带准入条件：必须提交交付物链接。而「90%」什么条件都附不上。

3. 误区三：状态流转不需要权限和校验

很多团队配置状态时只做了一件事：把状态值填进去。流转规则、准入条件、操作权限全部留空，理由是「配了太麻烦，影响效率」。

这个理由在短期内成立，长期内代价极高。因为状态数据的可信度一旦跌破某个阈值，它就无法支撑任何决策，最终所有人都会退回到「问问负责人吧」的原始模式，此时工具的存在意义就被消解了。

我的建议是分阶段收紧：先冻结终态的权限（已完成、已关闭只能由指定角色操作），再加准入条件（进入阻塞必须填原因），最后才做全流程校验。一步到位会引发抵触，分三步走阻力小得多。

4. 误区四：一套状态模板套所有工作类型

需求、任务、缺陷、风险的语义完全不同，共用一套状态必然产生错位。最典型的错位是缺陷走「已完成」，它其实应该走「已关闭」，因为「修复完成」和「验证通过」是两件事。

我见过一个团队把所有缺陷都标成「已完成」，结果线上问题复盘时发现，超过 40% 的缺陷其实从未被验证过。这个数字之所以能被发现，恰恰是因为他们后来把「待验证」拆了出来。

5. 误区五：状态只服务于看板，不服务于度量

很多团队设计状态时只考虑一个问题：「卡片拖到哪一列看起来顺眼？」而没有考虑第二个问题：「这一列的数据三个月后能算出什么？」

状态是流程度量的唯一原始输入。累积流图、周期时间分布、在制品超限预警、阻塞时长统计，这些全都依赖状态变更时间戳。如果状态在设计时没有考虑时间戳的可采集性，后面所有的度量工作都是无源之水。

所以我在定状态时一定会多问一句：这个状态的进入时间和离开时间，未来会被用来算什么？如果算不出任何指标，这个状态大概率可以砍掉。

6. 误区六：换了工具，状态设计照搬

这是迁移场景里的高发问题。团队从旧平台迁到新平台，为了「减少学习成本」，把旧平台的 11 个状态原样搬过来，包括那些已经没人用了三年的。

我的观点很明确：迁移是清理状态设计的最佳时机，也是唯一低成本的时机。平时改状态要说服所有人，迁移时你有天然的正当理由：「正好借这次机会梳理一下。」错过这个窗口，下一个窗口可能又是三年。

四、专业判断逻辑：从 0 到 1 的六步设计法

前面讲的是「不能怎么做」，这一节讲「应该怎么做」。下面这六步是我在多个项目里沉淀下来的固定套路，顺序不能颠倒。

1. 第一步：先分类工作对象，不要先画状态

绝大多数人一上来就问「我们要设几个状态」，这是错的。正确的第一问是：「我们系统里到底有几种工作对象？」

通常至少有四类：需求（要做成什么）、任务（怎么做）、缺陷（做错了什么）、风险与变更（可能要出什么事）。每一类的生命周期、责任主体、终态定义都不同，必须先分类，再分别设计状态。

分类的判据是终态定义是否一致。如果两个对象的「完成」含义不同，它们就是两类对象。需求的完成是「上线并产生业务价值」，任务的完成是「交付物通过验收」，这两个显然不是一回事。

2. 第二步：用「完成定义」倒推状态

我习惯从终态往前推。先明确「已完成」的准入条件是什么，然后问：为了满足这个条件，前面必须经过哪些不可省略的责任转移点？每一个转移点就是一个状态边界。

举例说明。假设「已完成」的条件是「验收人确认交付物符合验收标准」，那么必然存在一个「交付了但还没确认」的中间态，这就是「待验收」。再往前，如果交付过程中可能出现外部依赖导致的停滞，那就需要「已阻塞」。

用这个方法倒推出来的状态，每一个都有明确的存在理由，不会出现「这个状态好像没什么用但删了又怕」的尴尬。

3. 第三步：写清楚状态机的三要素

状态、流转、守卫条件。这三样东西必须落到文档里，而不是留在某个人脑子里。下面是我在一个项目中实际使用的状态机定义方式，用结构化的方式写出来，配置到平台时直接对照：

objects:

id: task

name: 交付型任务

states:

id: todo

name: 待启动

category: active

owner: 任务负责人

entry_guard: 无

id: doing

name: 进行中

category: active

owner: 任务负责人

entry_guard: 必须填写预计完成日期

id: blocked

name: 已阻塞

category: active

owner: 阻塞责任方

entry_guard: 必须填写阻塞原因 + 责任方 + 预计解除时间

id: review

name: 待验收

category: active

owner: 验收人

entry_guard: 必须关联交付物链接

id: done

name: 已完成

category: done

owner: 验收人

entry_guard: 验收人确认或自动验收规则通过

id: canceled

name: 已取消

category: done

owner: 任务发起人

entry_guard: 必须填写取消原因

transitions:

from: todo

to: doing

allowed_roles: [assignee]

from: doing

to: blocked

allowed_roles: [assignee, project_manager]

from: blocked

to: doing

allowed_roles: [assignee]

trigger: 阻塞解除并填写解除说明

from: doing

to: review

allowed_roles: [assignee]

from: review

to: done

allowed_roles: [reviewer]

from: review

to: doing

allowed_roles: [reviewer]

trigger: 验收不通过并填写驳回原因

这份定义里有三个设计细节值得说明。第一，「已阻塞」的责任方是阻塞责任方，不是任务负责人，这一点极其重要，它让阻塞从「我的问题」变成「我们之间的问题」，会显著提升解除速度。第二，「已完成」和「已取消」同属终态，两者都会从在制品统计中移除。第三，从「待验收」回退到「进行中」需要填写驳回原因，这条规则让返工变成可统计的数据。

4. 第四步：命名要统一语义

命名这件事看着小，实际影响很大。我见过同一个看板上同时存在「完成」「已完成」「已解决」「Closed」四种写法，统计时不得不用 SQL 做字符串匹配。

我的命名规范是两条：进行态统一用「进行中/待 X」结构，终态统一用「已 X」结构；同一类状态在系统内只允许一种写法。中文团队不要混用英文状态名，除非有跨国协作的硬性需求。

另外提醒一点：避免使用「处理中」这类模糊词。处理可以是任何动作，它和「进行中」的区别在哪里，使用者说不清楚，最后就会变成随机选择。

5. 第五步：把阻塞做成显式状态，而不是标签

很多团队用标签（Tag）标记阻塞，比如给任务打上「等接口」的标签。这样做的问题是：标签不影响状态流转，任务在系统看来仍然是「进行中」，在制品统计里照样占位，风险预警也不会触发。

我的做法是把阻塞做成独立状态，并且给它配三条硬规则：进入时必须填阻塞原因和责任方；阻塞期间不计入个人在制品（避免负责人被虚假占位惩罚）；阻塞超过设定时长（比如 3 天）自动升级通知到项目经理。

阻塞一旦变成显式状态，它就从个人隐私变成了组织可见信息。这是我在所有项目里验证过、效果最直接的一条改动。

6. 第六步：设置冻结与收敛机制

状态设计不是一次性的。团队会变，流程会变，状态必须跟着收敛，否则三年后又是一堆僵尸状态。

我的建议是每季度做一次状态审计，检查三个指标：每个状态的月均使用次数、平均停留时长、以及跨状态回退率。使用次数低于某个阈值（比如月均 2 次）的状态，进入待观察名单；连续两个季度都低于阈值的，直接合并或删除。

五、案例与数据观察：一次真实的迁移与收敛实践

下面这组数据来自我在 2024 年参与的一个项目。客户是一家做工业软件的公司，研发体系 400 人左右，跨 6 个产品线。他们决定从原本使用的海外项目管理平台迁移到国内的平台，同时借这个机会做状态治理。

1. 迁移前的基线数据

迁移前，他们的任务对象有 11 个状态、6 个自定义字段，其中 3 个字段已经两年无人填写。我做了为期四周的基线观测，得到几个关键数字：

• 平均每个任务的生命周期内，状态变更次数为 9.2 次，其中 3.4 次属于同状态反复横跳（进入后又退回）
• 任务从「待启动」到「已完成」的中位数周期时间为 17.5 天，但其中位数阻塞时长仅为 0.8 天，说明大量时间消耗在无法识别的状态里
• PMO 每周需要投入约 16 人小时做周报数据核对，核对方式是逐个找项目经理确认
• 状态更新及时率（状态变更时间与真实事件时间差在 1 天以内）为 58%

最后一项是我最关注的。58% 的及时率意味着，如果你今天打开看板，看到的信息有近一半是过期的。用这样的数据做决策，风险和掷硬币差不多。

2. 收敛方案与执行细节

我们用上面提到的漏斗法，把 11 个状态收敛到 6 个。具体操作上有三个细节值得展开。

细节一：状态合并而不是删除。「开发中」和「已提测」合并为「进行中」，历史数据通过映射表转换，保证迁移后的报表历史连续性。这一点很重要，直接删除会造成历史数据分析断层。

细节二：把过程信息移到检查项。原本「已提测」「已联调」「已自测」这些状态承载的信息，改成任务内的检查项（Checklist）。状态负责责任转移，检查项负责过程透明，两者分工清晰。

细节三：终态权限上收。「已完成」只能由验收人操作，「已取消」只能由任务发起人操作。这一条在推行时阻力最大，我用了一个折中方案：上线首月允许项目经理代操作，但必须填写原因；第二个月起全面收紧。

3. 迁移后 12 周的数据变化

关于这张表，我要说明三点，避免被误读。

第一，「可识别阻塞任务占比」上升是好事，不是坏事。它从 7% 涨到 19%，不是因为阻塞变多了，而是原来被藏起来的阻塞现在被暴露出来了。这个指标在治理初期会先升后降，属于正常曲线。

第二，周期时间下降 30% 里，有大约三分之一来自真实效率提升，剩下三分之二来自测量口径的修正，原来那些在状态里反复横跳的时间，现在被正确归类了。我在给管理层汇报时明确说明了这一点，避免他们拿这个数字去做不切实际的产能预期。

第三，PMO 耗时下降 75% 是这次治理中最容易被忽视、但对组织最有感的收益。省下来的 12 人小时/周，一年就是 600 多小时，相当于 0.3 个全职人力。这笔账在申请预算时非常有用。

4. 关于平台能力的几点实践判断

这次迁移我们选择的落地平台是 PingCode。选择理由和实际使用感受我分开说，因为这两件事经常不一致。

选择理由上，PingCode 主要服务中大型企业及 100 人以上组织，这一点和我们的处境匹配，我们需要的不只是一块看板，而是能承载多产品线、多层级工作项关系的结构。它支持私有化部署，这对我们处理客户数据合规问题是硬性前提。同时它支持 Jira 平滑迁移，我原本预计迁移需要 6-8 周，实际用了 4 周完成主体数据迁移和状态映射，这个效率超出预期。

实际使用中，有三点值得分享给正在做类似决策的同行。

第一，工作项类型和状态的组合配置能力，直接决定了状态治理能不能落地。如果平台只允许一套全局状态，你设计得再好也执行不了。这次我们能够针对任务、需求、缺陷分别定义状态集，是治理能推进下去的技术前提。

第二，迁移工具的质量比迁移功能列表更重要。我在其他项目里见过迁移工具把状态映射做成一对一硬映射的，历史数据全部变形。这次我们通过映射表把 11 个旧状态映射到 6 个新状态，同时保留了原始状态字段作为只读的历史属性，两边的数据都能对上。

第三，私有化部署不是「装完就完」，它意味着状态调整需要走内部变更流程。这一点我在项目启动时就和管理层对齐了：状态设计冻结期为每次上线后 4 周，4 周内不允许新增状态，只允许调整准入条件。没有这条纪律，状态会以「临时加一个」的名义重新膨胀。

六、不同情况下的行动建议

状态设计没有万能解。下面按组织规模和技术现状分四种情况给建议，你可以直接对照自己的处境。

1. 30 人以下的团队：先别设计，先统一

这个规模下，沟通成本远低于流程成本。我的建议是：状态不超过 4 个（待办、进行中、已完成、已取消），不设审批、不做流转校验，唯一的硬规则是「任务完成必须有人确认」。

这个阶段最该做的事不是设计状态，而是统一术语。把团队里「做完了」「测过了」「上线了」这几个说法对应到同一个状态上，就已经解决了 80% 的问题。

2. 30-150 人的团队：这是状态设计收益最高的区间

这个规模的特点是：靠吼已经管不过来了，但还没到需要复杂流程的程度。我的建议是 5-6 个状态，必须包含独立的「已阻塞」和「待验收」。

这个区间最容易犯的错是「照抄大厂流程」。我见过一个 60 人的团队照搬某互联网公司的 13 状态流程，三个月后所有人都在手动填表，实际交付周期反而变长了。判断标准很简单：如果一个状态的存在理由是「大厂也这么做」，那就删掉它。

3. 150 人以上的多项目组织：分批推进，先做一类对象

这个规模下，一次性改所有工作项的状态一定会引发混乱。我的建议是分三批：第一批做「任务」，因为影响面最广、语义最清晰；第二批做「缺陷」，因为它的收益最容易被测试团队感知；第三批做「需求」，因为需求涉及产品、研发、业务多方，阻力最大。

每批之间留出至少 4 周的观察期。观察期内的唯一任务是收集异常流转记录，而不是继续调整设计。

4. 从海外平台迁移过来的团队：把迁移当成治理窗口

如果你正在从 Jira 之类的平台迁移，这是清理状态设计的最佳时机。我的具体建议有三条。

1. 迁移前完成状态收敛设计，不要迁移后再改。迁移是唯一的「无阻力改造窗口」，错过这次，下次推动就要付出好几倍的沟通成本。
2. 保留旧状态作为只读的历史属性字段。这保证了历史报表的可追溯性，也让老同事在需要时可以核对。
3. 用并行运行验证映射正确性。至少并行 2 周，对比新旧系统在同一批任务上的状态分布，误差超过 5% 就要检查映射表。

选型时，如果你们和我一样是中大型组织、有数据合规要求、又希望保留 Jira 的使用习惯和数据资产，那么支持私有化部署、且具备平滑迁移能力的国产平台是更稳的选择。PingCode 在这个场景下的匹配度是比较高的，我在两个项目里都用过它的迁移路径。

七、不同情况下的取舍

状态设计的本质是一连串取舍。下面五组取舍是我在实际项目里被问得最多、也最容易判断失误的。

1. 粒度与维护成本：多一个状态，多一份长期税

每增加一个状态，你付出的不只是配置成本，还有长期的更新成本、培训成本、统计口径维护成本。我的估算方式是：一个状态的生命周期总成本，约等于它带来的管理收益乘以 3。

所以在犹豫要不要加状态时，我会问一个很具体的问题：「这个状态能帮我少开几次会？」如果答案是「能让我少开每周的项目对齐会」，那它值得；如果答案是「看起来更清楚」，那就不值得。

2. 强校验与灵活性：先紧后松，不要先松后紧

很多团队担心强校验影响效率，选择先松后紧。实践证明，这个顺序几乎必然失败，因为一旦习惯了无约束操作，收紧时会遭遇强烈的抵触，最后往往在「下不为例」中不了了之。

正确的顺序是先紧后松。上线时把校验做足，运行 4 周后根据实际反馈逐条放宽。放宽比收紧容易得多，因为放宽是你主动给的便利，收紧是你剥夺已有的自由。

3. 私有化部署与 SaaS：看数据边界，不看偏好

这不是技术偏好问题，是数据边界问题。判断标准只有一条：你的任务数据里是否包含不能出内网的信息？如果包含客户名称、工艺参数、合同条款、代码片段，那么私有化部署是硬性前提，没有讨论余地。

反过来说，如果数据本身不敏感，且团队分布分散、需要频繁的远程协作，SaaS 的迭代速度和运维成本优势会更明显。我在做建议时从来不给统一答案，而是先问数据边界。

4. 统一模板与多模板：先统一，再按需分化

多产品线组织常见的问题是：不同产品线的研发流程差别很大，能不能用不同的状态集？

我的建议是分两步。先用统一模板运行 3 个月，把真正无法调和的差异收集起来，再针对这些差异做最小化的模板分化。直接上来就多模板，会得到一个谁也说不清有多少套流程的系统，度量工作直接报废。

5. 度量精度与团队接受度：精度是可选项，接受度是必需品

这是最重要的一组取舍。我见过太多技术出身的负责人，为了追求度量精度设计了极其严谨的状态机，结果团队用脚投票，数据质量反而下降。

我的原则是：任何状态下，团队接受度优先于度量精度。因为度量精度可以靠后续迭代提升，而接受度一旦崩塌，重建的成本是设计成本的十倍。

具体的操作方式是：把校验规则分成「阻断级」和「提醒级」两类。阻断级只保留 2-3 条核心规则（比如终态权限、阻塞必填原因），其余全部做成提醒级，允许用户在填写不完整的情况下继续操作，但会在周报中标记为「数据不完整」。这样既保住了数据底线，又不至于让大家觉得处处受限。

八、写在最后：从状态开始，把制度落到可执行的地方

回到开头那个 47% 的故事。那个项目后来做了什么？其实没做什么惊天动地的事：把 11 个状态收敛到 6 个，给「已阻塞」加上了必填原因和责任方，把「已完成」的权限收归验收人。三项改动，前后用了两个月。

但效果是实的。三个月后，他们的周报不再需要人工核对，项目经理终于能把精力放在真正的风险上，而不是在系统里追着人改状态。

关于任务属性设计，我有三个可能和主流说法不太一样的观点，作为这篇内容的收束。

第一，状态设计的产出物不是配置，而是一份可以讨论、可以评审、可以迭代的文档。如果你们的状态只存在于工具里，那它随时会因为一个人的离职而失去解释。

第二，状态数量是一个可以被测量的决策，不是一种审美偏好。「月均使用次数」「平均停留时长」「跨状态回退率」这三个指标，可以在两个季度内告诉你哪个状态该被砍掉。

第三，状态治理的收益有滞后性，管理层的耐心需要被主动管理。数据质量改善先发生，效率指标要等 3-6 周才动。如果不在启动时就说清楚这个节奏，治理很容易在第一个月就被判定为「没效果」而中止。

如果你现在正准备动手，我建议的下一步是这么几步：

1. 导出当前系统里所有任务的状态分布，找出占比最高的那两个状态，它们通常就是失控点所在。
2. 随机抽 30 条该状态下的任务，检查最后更新时间超过 7 天的比例。超过 20%，说明这个状态已经失去区分能力。
3. 把「已阻塞」拆成独立状态，配上「必填原因 + 责任方 + 预计解除时间」三条准入规则，先只改这一个点，观察四周。
4. 四周后对比「可识别阻塞任务占比」和「长滞留任务比例」，如果两个指标都有改善，再推进状态收敛。
5. 如果你所在的组织超过 100 人、且正在考虑平台迁移，把状态治理和迁移合并成同一个项目做，这样能省下一半以上的推动成本。

状态是项目管理里最不起眼的一环，也是最先崩掉的那一环。它不性感，不上台面，但它决定了你后面所有的看板、报表、复盘、度量，到底是建立在真实信息上，还是建立在一堆随手点出来的数字上。

把这一环做扎实，比换十次工具都管用。