状态怎么做？实施团队数据分析：任务属性从0到1

去年 11 月，我复盘了一家做智能仓储系统交付的公司。他们有 137 名实施与交付人员，同时并行 40 多个项目。在一轮"流程精细化"改造里，团队把任务状态字段从 5 个扩到 14 个，理由是"颗粒度更细，管理更到位"。三个月后数据出来了：项目平均延期天数从 9.4 天涨到 16 天，项目周会时长从 90 分钟涨到 150 分钟，而状态字段的填写率从 78% 掉到 46%。这不是执行力问题，是设计问题。

状态字段是项目管理系统里最便宜、也最容易被误用的一个字段，它看起来只是几个下拉选项，实际上它决定了整个实施团队的数据能不能被分析。

一、核心结论：状态不是进度条，是交接契约

先把结论摆在最前面。我见过太多团队把"状态"当成"进度"的同义词，然后用一套状态字段去同时承载进度描述、阶段划分、风险标记和汇报口径，最后的结果一定是：状态数量膨胀、填写质量崩塌、报表不可用。

1. 状态的第一性目的是触发下一个动作

一条任务的状态发生变更，本质上应该意味着：某个人该动手了，或者某件事卡住了需要有人去推动。如果一个状态变更不能触发任何人的动作，它就不该存在。

举个具体例子。"开发中"改到"开发完成"，如果下游没有人因此收到通知、没有人开始测试，那么这个变更除了在周会上被念一遍，没有任何业务价值。反过来，"待客户输入"改到"执行中"，意味着客户已经把接口文档给了过来，实施顾问今天必须开始配置，这才是有信息量的状态。

我通常用一个很粗暴的测试题来筛状态：如果这个状态变更后，系统不通知任何人、也没有任何人的待办列表发生变化，那它就应该被删掉，或者降级为属性。

2. 状态数量应由"交接点数量"决定，而不是由"工作量粒度"决定

一个实施任务从创建到关闭，中间经过几次不同角色之间的交接，就应该有几个状态区间。一次交接 = 一次责任转移 = 一个状态边界。

智能仓储那个团队的问题就在这。他们 14 个状态里，有 6 个是同一个角色（实施顾问）内部的进度描述：需求梳理中、方案编写中、方案内部评审中、配置中、自测中、准备上线。这 6 个状态没有任何一次责任转移，所以它们既不能触发动作，也不能被用来分析瓶颈，只是把一个人的工作拆成了 6 个格子。

而真正的交接点，"实施顾问交给客户方 IT 做环境准备"、"客户业务人员做 UAT 确认"，反而没有独立状态，被塞进了"实施中"这个大桶里。

状态设计的核心公式（我在多个团队验证过）：
有效状态数 ≈ 责任交接点数量 + 1（关闭态）

常见错误做法：

有效状态数 = 我能想到的工作步骤数量

判断一个状态是否必要，问三个问题：

状态变更后，是否有明确的"下一责任人"？
该状态是否有明确的"退出条件"（而不是靠感觉）？
该状态是否会出现在交付看板或客户汇报里？
三个都答"否"，删掉。

3. 从 0 到 1 的正确顺序：角色 → 交接 → 状态 → 属性 → 报表

绝大多数团队是从"报表"倒推状态设计的，老板想看延期率，于是加一个"延期"状态；想看风险，于是加一个"高风险"状态。这是典型的本末倒置。

正确的顺序是：先定义参与交付的角色，再画出角色之间的交接地图，然后为每一次交接定义一个状态边界，接着为状态补充必要的分析属性，最后才是做报表。次序颠倒，报表一定是假的。

我参与过的改造里，凡是按这个顺序走的团队，状态字段通常收敛到 6-9 个，而且半年内不需要大改；凡是按报表倒推的，平均 4 个月就要重做一次状态字典。

二、背景与真实场景：实施团队的交付逻辑和研发团队完全不同

为什么研发团队那套状态设计经验，搬到实施团队身上经常失效？因为两者的交付物性质不同。研发交付的是"可运行的代码"，实施交付的是"客户环境里可用的一套系统"。后者有大量不可控的外部变量。

1. 实施团队交付的不是代码，是客户的"可运行状态"

研发团队的任务，做完就是做完了，合并到主干就算交付。实施团队的任务，做完只是"我们这边做完了"，还得等客户给数据、给权限、给测试人员、给上线窗口。所以实施任务有一半时间不在自己手里。

这意味着，实施团队的状态设计必须把"等待"显性化。而在研发语境下，"等待"通常被视为一种异常（比如 blocked），在实施语境下，等待是常态，是必须被测量的产能损耗。

2. 我做过一次时间构成采样，结果比很多人想象得极端

2023 年下半年，我用状态变更日志对一个 ERP 实施团队的 1,860 条任务做了时间归因。方法很简单：取每条任务每次状态变更的时间戳，算出在每个状态上停留的时长，再按状态归类求和。

结果是：真正由实施团队自己动手的时间，占总流转时长的 38.7%；等待客户方输入的时间占 34.2%；等待内部其他角色（开发、产品、运维）的时间占 17.5%；剩下的 9.6% 是任务创建后还没排期的空转时间。

换句话说，这个团队 60% 以上的任务时长不在自己控制范围内。如果你的系统里没有"待客户输入"这个状态，这 34.2% 就全部消失在"实施中"里，你永远看不到客户侧的拖延，也永远无法用数据去和客户谈排期。

3. 实施任务的三个结构性特征

• 强外部依赖：客户方 IT、客户方业务负责人、第三方系统供应商，任何一方卡住，任务就停摆。
• 责任人频繁切换：一条任务从售前移交到项目经理，再到实施顾问，再到客户业务，平均经手 3.2 个角色。
• 验收标准主观："客户觉得好用"很难量化，所以状态退出条件必须写成人能判断的客观条件，比如"客户方业务负责人完成 20 条标准用例签字"。

三、拆解七个常见误区

下面这七个误区，我在过去三年里至少见过五个出现在同一个团队。它们不是互相独立的，通常是一起出现、互相强化。

1. 用百分比进度代替状态

"这条任务完成了 60%。"这句话在实施场景里几乎没有信息量。60% 是谁判断的？剩下 40% 卡在谁那儿？明天会不会变成 55%？

百分比是一个连续变量，它天生适合汇报，不适合触发动作。我把百分比进度称为"最贵的伪状态"，它看起来给出了精确信息，实际上把问题从"卡在哪"偷换成了"还差多少"，而后者对推动交付毫无帮助。

我的建议很直接：实施类任务禁用百分比字段，只保留状态 + 退出条件。如果管理层坚持要看进度感知，用状态颜色和燃尽图替代，不要用百分比。

2. 状态名动词和形容词混用

看看这个真实的状态列表：待处理、进行中、已完成、需确认、有风险、待评审、开发完成、已上线。这里面有动词短语（待评审、待确认）、有形容词（有风险）、有名词（已完成）。

混用的后果是分类逻辑崩塌。一个任务到底该进"需确认"还是"有风险"？如果它既有风险又需要确认呢？填表人只能猜，猜的结果就是数据不可比。

正确的做法：状态只描述"谁在持有这条任务"，风险、优先级、阻塞原因一律作为独立属性。这样状态集合是互斥且完备的，属性集合可以叠加。

3. 状态与阶段、里程碑混用

"需求阶段"、"开发阶段"、"上线阶段"是项目级或子项目级的阶段，不是任务级状态。把它们塞进任务状态，会导致同一时刻一条任务既在"开发阶段"又处于"待客户确认"，语义打架。

我的判断标准：阶段是时间轴的切分，状态是责任归属的切分。二者维度不同，必须放在不同字段。任务可以有阶段属性（用于里程碑统计），也可以有状态（用于日常执行），但不能合并。

4. 有"阻塞"状态，却没有阻塞原因属性

这是最常见的"半成品设计"。团队加了一个"阻塞"状态，看起来很专业。但三个月后你问他们：阻塞最多的原因是什么？没人答得上来，因为状态只记录了"卡住了"，没有记录"为什么卡住"。

阻塞原因必须是一个受控的枚举属性，建议 6-8 个值，例如：等客户提供数据、等客户环境权限、等第三方接口、等内部开发排期、需求不明确、客户决策延迟。有了这个字段，"阻塞原因 TOP3"才能成为每周交付例会的固定议程。

5. 让研发、实施、售前共用一套状态

这三类工作的交接结构完全不同。研发有代码评审、联调、测试；实施有环境准备、客户确认、验收；售前有方案、报价、投标。强行统一，结果一定是状态名被设计得极其抽象（"处理中"、"进行中"、"已完成"），抽象到没有任何分析价值。

正确做法是：共享一套工作项类型框架和属性字典，但状态流按工作项类型分别配置。这也是我在选型时会重点看的点，工具是否支持按工作项类型配置独立状态流。

6. 状态只服务周会汇报，不服务数据回溯

很多团队的状态变更没有留痕，只有当前值。这意味着你只能看到"现在有多少任务在待确认"，看不到"上个月任务在待确认状态平均待了几天"。

状态的价值 80% 在变更日志里，20% 在当前值里。没有变更时间戳，状态就只是一个标签，不是数据。选系统时如果发现状态变更不记录时间戳和操作人，基本可以直接否决。

7. 客户可见状态和内部状态共用一套

内部需要精细（待客户输入、待内部验证、执行中），客户只需要知道"轮到谁了"。把内部状态直接暴露给客户，会造成两种伤害：一是客户看到"待内部验证"会误以为项目停滞；二是团队为了照顾客户情绪而隐瞒真实状态，导致数据失真。

解法是建立一层映射：内部状态 N 个，客户可见状态 3-4 个，通过映射表转换。内部数据保持真实，对外呈现保持简洁。

四、专业判断逻辑：状态从 0 到 1 的五步法

下面这套方法，我在 6 个不同规模的实施团队里用过，从 12 人的小团队到 300+ 人的交付中心。核心逻辑是一样的，只是属性的数量会随规模调整。

1. 第一步：画交接地图，而不是画流程图

流程图描述"事情怎么做"，交接地图描述"活交到谁手里"。后者才决定状态。

具体做法：找一张白纸，横向列出所有参与交付的角色，然后画箭头。每条箭头代表一次责任转移，箭头上写清楚：交出去的是什么（交付物）、接收方要满足什么条件才算接住了（接收条件）。

一个典型的实施交付交接地图大致是：售前 → 项目经理（交接物：合同与技术方案）→ 实施顾问（交接物：客户环境与需求确认单）→ 开发/配置（交接物：环境就绪证明）→ 实施顾问（交接物：配置完成包）→ 客户业务（交接物：UAT 测试用例）→ 项目经理（交接物：验收签字）。

数一数箭头数量，大概是 6-7 条。这就是你的状态数量下限。

2. 第二步：等待态与动作态成对出现

这是我认为最重要的一条设计原则，也是最容易被漏掉的一条。

每一次交接，其实包含两个阶段：上游已经交付，等待下游接收（等待态），以及下游已经开始处理（动作态）。很多团队只设计了动作态，"执行中"，导致"东西已经交出去了但对方还没接"这段时间无状态可放，只能继续挂在"执行中"里，责任归属就模糊了。

一个经过验证的实施任务状态集（7 个内部状态）：

注意这张表里有 3 个等待态：待客户输入、待内部验证、待客户验收。它们存在的唯一目的，就是让"不是我们的事"和"是我们的事"在数据上彻底分开。只有分开，你才能算出"客户侧平均响应时长"这个指标，并拿它去和客户沟通资源投入。

客户可见状态只需要 3 个，做一层映射即可：准备中 → "我方准备中"；待客户输入、待客户验收 → "等待您的确认"；其余内部状态 → "我方处理中"；已关闭 → "已完成"。

3. 第三步：定义最小属性集（4 必填 + 4 选填）

状态只解决"谁在持有"，属性才解决"为什么、多久、往哪去"。我建议的最小属性集如下。

必填属性（4 个）：

1. 负责人角色：枚举，实施顾问 / 开发 / 测试 / 客户方 IT / 客户方业务 / 项目经理。注意是"角色"不是"人"，因为人会被替换，角色不会。
2. 计划完成时间：只有同时存在负责人和计划完成时间，任务才允许离开"待排期"。
3. 阻塞原因：枚举，仅在标记为阻塞时必填。建议值：等客户数据、等客户权限、等第三方接口、等内部排期、需求待明确、客户决策延迟。
4. 客户可见性：布尔值，决定该任务是否出现在客户看板。默认关闭，由项目经理按需开启。

选填属性（4 个）：

1. 外部依赖方：文本或枚举，记录具体卡在哪家公司、哪个系统。
2. 环境标识：测试 / 预生产 / 生产。实施场景下这个字段非常重要，能避免上线事故。
3. 交付物类型：配置包 / 培训材料 / 数据迁移脚本 / 接口文档。用于统计工作量的结构分布。
4. 上游任务：任务链接。用于计算关键路径上的连锁延迟。

属性不是越多越好。我见过一个团队给任务加了 26 个自定义字段，结果填写率不到 30%，字段越多，数据越脏。判断一个属性该不该加，看它是否会出现在任何一份固定报表或例会纪要里。不会就不要加。

4. 第四步：状态与属性做正交校验

这一步是控制状态数量的关键。核心规则只有一句：同一条信息只能出现在一个地方，出现两次就是冗余。

常见冗余：既设了"待客户输入"状态，又设了"阻塞原因=等客户数据"属性。这就重复了。正确做法是：状态表达责任归属，阻塞原因只用于"执行中"状态下发生的意外卡顿。这样两者语义就不冲突了。

再比如：既设了"高优先级"状态，又有优先级属性，直接删掉状态。既设了"延期"状态，又有计划完成时间，直接删掉状态，用"未关闭且已超计划时间"计算即可。

我做过一个统计：一个从 14 个状态收敛到 7 个状态的团队，收敛动作里有 5 个靠的就是正交校验，也就是"把状态降级成属性"。

5. 第五步：把状态变更日志当成唯一数据源

状态设计完之后，真正产生分析价值的不是当前状态分布，而是状态变更日志。至少需要记录四个字段：任务 ID、原状态、新状态、变更时间戳（精确到分钟）、操作人。

有了这份日志，你能算出四类核心指标：

• 状态停留时长：每条任务在每个状态上待了多久，中位数比均值更可信（长尾会严重拉高均值）。
• 流速：每周通过各状态的任务数量，用于判断瓶颈位置。
• 回流率：从"待客户验收"退回"执行中"的比例，直接反映交付质量。
• 等待占比：任务在等待态的总时长 / 总流转时长，用于向管理层说明外部依赖的真实成本。

配置层面的写法大致如下（以 YAML 描述状态定义，用于校验规则配置）：

workflow: implementation_task
states:

key: backlog

name: 待排期

五、案例与数据观察：一个 137 人实施团队的 6 个月改造

回到开头那家智能仓储公司。它是我参与最深的一次状态改造，数据也比较完整，值得展开讲。

1. 改造前的基线（2023 年 9-11 月）

团队规模 137 人，其中实施顾问 74 人、开发 31 人、测试 18 人、项目经理 14 人。并行项目 42 个，月均新增任务 1,240 条。数据来源是该团队项目管理平台的导出记录加上我在 3 个月里参加的 11 次周会纪要。

• 状态字段 14 个，无退出条件文档化，填写率 46%。
• 无法回答"客户侧平均响应时长"，因为客户侧等待混在"实施中"。
• 项目平均延期 9.4 天后继续恶化到 16 天。
• 周会 90 分钟，其中约 55 分钟用于逐个询问任务进展。

2. 改造动作（2024 年 1-2 月）

我们做了四件事，花了不到 6 周。

1. 状态收敛：14 个状态 → 7 个内部状态 + 3 个客户可见状态。删掉的 7 个里，5 个降级为属性，2 个识别为重复。
2. 补退出条件：每个状态写成一句客观可判定的话，写不出来的一律不算状态。
3. 补属性：新增 4 个必填 + 4 个选填属性，同时删掉原有的 11 个无效自定义字段。
4. 补埋点与视图：启用状态变更日志，并配置三张固定报表，等待态时长分布、阻塞原因 TOP5、状态停留时长帕累托。

3. 改造后的六个月数据（2024 年 3-8 月）

最有说服力的一个发现来自帕累托分析：全部等待时长里，68% 集中在"待客户输入"这一个状态上，而其中 71% 的具体原因是"等客户方环境权限"。这个结论直接推动他们把"环境权限清单"做成售前移交时的强制交付物，从源头减少了后续等待。

如果只看状态数量，你会以为这是一个关于"简化"的故事。其实不是。这是一个关于"把不可见的时间变成可见"的故事，状态缩减只是副产品。

4. 工具层怎么支撑这套设计

这个团队最后选的是 PingCode。我参与选型时最看重的不是功能数量，而是三件事能不能做到。

第一是按工作项类型配置独立状态流。实施任务、开发任务、缺陷的状态集合完全不同，必须能分开配置，否则又回到"一套状态打天下"的老路。PingCode 在这方面支持按工作项类型定义不同状态流，并且可以对每个状态设置必填属性校验，比如进入"待客户输入"时强制填写外部依赖方和计划完成时间，这就把前面说的"退出条件"落到了系统层。

第二是状态变更日志可导出、可分析。PingCode 保留了完整的状态变更历史，包括操作人和时间戳，可以通过报表或者开放 API 取出来做二次分析。前面提到的状态停留时长、流速、回流率，全部依赖这份日志。我在评估同类工具时，如果发现状态变更只留当前值不留历史，基本直接排除。

第三是私有化部署与迁移能力。这家公司的客户里有几家是制造业国企，要求实施团队在客户现场使用隔离网络，所以团队需要把管理平台私有化部署在自己的内网，再通过离线方式同步项目状态。PingCode 支持私有化部署，这对于服务中大型企业、100 人以上组织的交付团队来说是硬需求。

另外他们原本用的是 Jira，历史数据有 6 万多条工作项。迁移时最怕状态体系对不上，PingCode 支持 Jira 平滑迁移，我们在迁移时做了一次状态映射表，把 Jira 的 14 个历史状态映射到新的 7 个状态上，历史停留时长数据得以保留，避免了过去数据断档。对做国产替代的团队来说，这一点比界面好不好看重要得多。

5. 我们踩过的三个坑

第一个坑：等待态没有 SLA，变成了合法黑洞。上线第一个月，"待客户输入"平均停了 9.1 天，没人觉得有问题，因为状态里写着"在等客户"。后来我们给每个等待态配置了 SLA 小时数（待客户输入 72 小时、待客户验收 120 小时），超时自动提醒项目经理去推动，平均停留时长降到 4.3 天。

第二个坑：客户可见性默认打开，导致数据失真。初期我们让所有任务默认对客户可见，结果实施顾问开始回避把任务标成"待内部验证"，因为怕客户看到以为项目停滞。改成默认关闭、按需开启后，内部数据立刻变干净了。

第三个坑：属性加得太快。第一个月我们加了 17 个属性，第二个月就删到 8 个。教训是：属性要有"报表依据"才能加，先有报表需求，再有字段。

六、不同规模团队的行动建议

这套方法不能照搬。团队规模、项目并行度、客户类型不同，落地路径差异很大。下面按四种典型情况给建议。

1. 10 人以下的小型实施团队：砍到 4-5 个状态，别配属性

10 人以下，沟通靠吼就够了。这个阶段强行上完整状态体系，边际收益极低。建议只保留：待处理、执行中、待客户确认、已完成，再加一个阻塞标记。

关键提醒：这个阶段不要配自定义属性，尤其不要配阻塞原因枚举。人少，卡住了直接说一句就行，不需要落在系统里。过早引入结构化数据，只会让人抵触填报。

2. 30-100 人、多项目并行：上 7 状态 + 4 必填属性

这是最典型的实施团队规模，也是状态设计的"甜蜜区"。此时口头沟通已经无法覆盖，必须靠系统承载状态流转。

建议动作顺序：先做交接地图（半天工作坊）→ 定 7 状态和退出条件 → 只加 4 个必填属性 → 启用状态变更日志 → 做三张报表（等待态时长、阻塞原因 TOP5、状态停留帕累托）。整套动作 4-6 周可以跑通。

工具选型上，这个规模开始需要考虑私有化部署和权限隔离，因为客户数据敏感度上升。PingCode 支持私有化部署，适合这个区间里对数据合规有要求的中大型企业交付团队。

3. 100 人以上、多产品线交付：分层设计，不要一套状态打天下

100 人以上，通常已经有产品线差异。这个阶段要做的是"分层"：

• L1 层（管理层）：只看 4 个状态区间，待启动、进行中、待验收、已关闭。用于经营看板。
• L2 层（项目层）：7-9 个状态，按交接点划分，用于项目周会。
• L3 层（执行层）：角色内部可以再加子状态，但仅用于个人待办视图，不进入统计。

分层的关键是L3 的子状态不参与 L1 的统计口径，否则又会出现状态膨胀污染报表的问题。这个能力对工具是有要求的，需要系统支持状态分组或者状态映射。

4. 从 Jira 迁移的团队：先做状态映射表，再迁移数据

迁移最容易出的事故是状态体系对不上，导致历史数据断档。我的建议是分三步：

1. 导出原系统所有状态和每个状态下的工作项数量，列成表。
2. 为每个旧状态指定一个新状态作为映射目标，无法映射的归入"已关闭"或"待排期"。
3. 迁移后在新的系统里校验历史停留时长是否连续，特别关注跨状态时间戳是否断裂。

PingCode 支持 Jira 平滑迁移，可以保留工作项的状态历史与时间戳。对做国产替代的团队而言，这一点决定了迁移后还能不能继续做趋势分析，如果历史数据只是"搬过来了"但时间戳丢失，那等于从零开始积累数据。

七、不同情况下的取舍

状态设计没有"最优解"，只有"当前阶段的合理取舍"。下面五组取舍，是我在实战里反复遇到的。

1. 状态数量 vs 填报成本

多一个状态，就多一次判断成本。经验数据是：每增加 1 个状态，人均周填报耗时增加约 1.5-2 分钟。10 个状态以上的团队，填写率普遍跌破 70%。

取舍原则：只在"有明确交接"的地方加状态。等待态可以适当多，动作态要尽量少。因为等待态的分析价值远高于动作态，你更需要知道卡在哪，而不是同伴在忙什么。

2. 客户可见的简洁 vs 内部数据的真实

如果只能选一个，永远优先保证内部数据真实。客户看到的可以是一层映射，但内部状态不能为了好看而简化。一旦团队开始为了"客户观感"而修改状态，整个数据基础就废了。

实操建议：客户可见性默认关闭，由项目经理按任务粒度手动开启。开启的任务数占比控制在 30% 以内。

3. 自动化流转 vs 人工确认

自动化能降填报成本，但会引入数据失真。比如"客户验收后自动关闭任务"，看起来省事，但如果验收其实只是口头同意、书面签字没到，自动关闭就会掩盖风险。

我的判断标准是：涉及外部责任转移的状态变更，必须人工确认；纯内部的状态推进，可以自动化。比如"准备中 → 待客户输入"可以自动化（内部动作完成即触发），但"待客户验收 → 已关闭"必须由项目经理手动确认。

4. 标准字段 vs 定制属性

定制属性解决当下问题，但会带来长期的维护成本和迁移成本。我在一个客户那里见过 47 个自定义字段，最后没人说得清哪个还在用。

取舍原则：标准字段能覆盖的，绝不定制；定制字段必须有对应报表；新增定制字段必须同时指定"谁负责维护、多久清理一次"。

5. 私有化部署 vs SaaS

对服务中大型企业、100 人以上组织的交付团队来说，私有化部署往往不是"要不要"的问题，而是"客户让不让用 SaaS"的问题。PingCode 支持私有化部署，同时支持从 Jira 平滑迁移，这两点组合起来，对正在做国产替代的团队是比较实际的选项。

6. 一张取舍速查表

八、三个我被问得最多的问题

1. 状态是不是越少越好？

不是。状态太少的典型症状是"客户侧等待被隐藏"，团队看起来效率很高，实际交付周期很长。我见过只用 4 个状态的团队，报表干净漂亮，但完全解释不了为什么项目总延期。

正确判断标准不是数量，而是是否覆盖了全部交接点。交接点是 7 个，状态就该是 7 个左右；交接点是 5 个，硬凑 12 个状态就是浪费。

2. 团队抵触填状态怎么办？

抵触通常来自两个原因：一是填了没人看，二是字段太多。解法是反过来的：先用数据解决一个他们真实痛点，再要求填。

那个 137 人团队的做法是先跑出"客户侧平均响应时长 4.3 天"这个数据，然后在一次客户例会上直接展示，客户当场答应增加对接人。实施顾问立刻感受到"填状态能帮我推动客户"，抵触情绪两周内就消解了。这比发十份填报规范都管用。

3. 状态设计多久需要重构一次？

我的经验值是 18-24 个月。触发重构的信号有三个：状态填写率连续两个月低于 70%；出现 3 个以上"新人看不懂"的状态名；等待态时长数据连续三个月没有变化（说明数据已经失真）。

出现任意一个，就该坐下来重新画一遍交接地图了。注意是画交接地图，不是改状态名，改名字解决不了结构问题。

九、总结与下一步

回到最开始的那句话：状态字段是项目管理系统里最便宜、也最容易做错的字段。它便宜到所有人都觉得不值得专门设计，它重要到一旦做错，后面所有的交付数据分析都是空中楼阁。

我在这篇文章里想传达的独特观点只有三条。

第一，状态的定义单位不是"工作步骤"，而是"责任交接点"。这一步想通了，状态数量自然收敛。实施团队真正需要的不是更细的进度，而是更清楚的"现在轮到谁"。

第二，等待态的价值远高于动作态。实施交付里超过六成时间不在团队自己手里，如果不把等待显性化、可测量化，你永远只能优化那不到四成的时间，而且很可能是错的四成。

第三，状态变更日志才是真正的数据资产，状态字段本身不是。所以选工具的时候，问的第一个问题不该是"界面好不好看"，而是"状态变更有没有时间戳、能不能导出、能不能做趋势分析"。

下一步怎么做，我建议按这个顺序，一周之内就能启动。

1. 今天：导出你现在的状态列表，数一数数量，标注每个状态的责任人是谁。标不出责任人的，先记下来，它们大概率是冗余状态。
2. 本周内：拉半天工作坊，把交付流程里的角色列出来，画一遍交接地图。数箭头，不要数步骤。
3. 下周：把交接箭头数量和你当前的状态数量做对比。差得越多，说明改的空间越大。
4. 两周内：为新状态集写退出条件。写不出客观条件的，降级为属性或者直接删掉。
5. 一个月内：启用状态变更日志，跑出第一份"状态停留时长"报表。哪怕只有一个月的数据，也比没有强。

最后提醒一句：不要一次性改完。我在那个 137 人团队身上学到的最大教训是，状态体系是可以迭代的，但团队对填报的耐心只有一次。宁可先上 7 个状态跑三个月，也不要一上来就上 14 个状态赌一把。