状态怎么做？项目经理效率提升：任务属性从0到1

我带过一个有 11 个状态的研发看板，团队一共 14 个人，没有两个人的理解是相同的。有人认为「待联调」算开发中，有人认为算测试中；有人在需求变更后把卡片退回「已评审」，有人直接新建一张卡片。结果是周会上大家拿着同一块看板，讨论的却是三套不同的进度。那次诊断之后，我把「状态」这件事从「配置项」提升到了「协作协议」的高度，也让后续十几个团队的状态改造少走了很多弯路。

这篇文章讲的不是「怎么在工具里新建几个状态」，而是任务属性从 0 到 1 的设计过程：状态该有几个、每个状态代表什么决策点、谁有权改、改了以后如何度量，以及在不同规模的组织里应该怎么取舍。我会给出可直接照做的步骤、判断逻辑、真实的数据观察，以及一套完整的状态机定义示例。

一、核心结论：状态是决策点，不是进度条

先把结论放在最前面，后面所有内容都是围绕这几条展开的。

1. 状态描述的是「谁该行动」，不是「做完了多少」

一个状态的唯一职责，是回答「现在球在谁手上」。如果某个状态无法明确指向一个责任人或者一个待执行的决策，它就只是一个装饰。

「开发中 60%」这种表达，本质是把进度百分比塞进了状态字段。它的问题在于不可验证：60% 是开发自己估的，没有客观依据，也没有触发任何人的动作。而「待代码评审」就完全不同，它明确指向评审人，且评审人看到卡片躺在自己队列里不动，就是一个自然的催办信号。

2. 状态数量由决策点决定，不由工作环节决定

很多团队列状态的方式是「回忆一遍工作流程」：需求、设计、开发、联调、测试、回归、验收、发布。这看起来合理，其实是按「环节」切分。

正确的切法是按「决策点」切分。决策点的特征是：存在一个明确的判断，判断结果为「通过」则向前，为「不通过」则回退。设计评审是一个决策点，代码合并是一个决策点，验收签字是一个决策点。而「开发中」和「联调中」之间往往没有决策点，只是开发自己的心理分界线。

把环节当作状态，会让看板变成进度条；把决策点当作状态，看板才会变成协作工具。这是我在多个团队反复验证过的一条经验。

3. 状态的收益在 5 到 8 个之间达到峰值

状态不是越多越精细。每增加一个状态，团队就多一份认知负担、多一次误操作机会、多一条统计口径争议。我在下面这张图里放了一组来自 12 个团队的观察数据，可以看到状态数量和协作效率并不是线性正相关。

4. 状态是任务属性里最先该做的，也是最难改的

任务有几十个属性：标题、描述、负责人、优先级、所属迭代、标签、工时、截止时间、关联需求……如果只能先做一件事，我会选状态。

原因是状态处在协作的枢纽位置。优先级影响排序，标签影响筛选，工时影响统计，但只有状态直接影响「下一个人该不该动手」。

同时它也是最难改的。状态一旦被团队用顺手，改动就会牵动历史数据、报表口径、自动化规则和所有人的肌肉记忆。所以从 0 到 1 阶段就设计对，比运行两年后再重构，成本低一个数量级。

二、真实场景：一个 11 状态的看板是怎么拖垮周会的

1. 现场还原：同一块看板，三套进度

那是三年前，一家做企业级 SaaS 的公司，研发 14 人，产品 3 人，测试 2 人。他们的看板列是这样的：待评估、已评估、排期中、设计中、待评审、开发中、待联调、联调中、待测试、测试中、已上线。

我在现场做了一个小实验：让每个人用一句话解释「待联调」和「联调中」的区别。14 个人里，有 6 个人说不上来，4 个人给出了互不相同的定义，只有 2 个人（恰好是前后端各一位主力）能说清楚。

更麻烦的是回退路径。测试发现缺陷时，有人把卡片退回「开发中」，有人退回「待联调」，有人新建一张卡片挂在原卡片下。三种做法在报表里产生三种完全不同的结果，而周会上大家看的是同一张报表。

2. 三个可量化的症状

当时我记录了三个指标，都很朴素，但足够说明问题。

症状一：状态流转异常率高。所谓异常流转，指的是卡片在不经过中间状态的情况下跳跃，或者在一个状态里停留超过 5 个工作日不动。两周内 214 张卡片中，有 63 张存在异常流转，占比 29%。

症状二：状态归属争议多。周会上平均每次消耗 18 分钟在「这个任务到底算不算完成」上，占整场会议 90 分钟的五分之一。

症状三：度量数据不可信。他们当时想统计「需求交付周期」，但发现从「已评估」到「已上线」的口径在不同迭代里都不一样，因为中间状态的取舍变了三次。最终交付周期只能靠人工回归，每月多花 12 个小时。

3. 谁在为状态买单

表面上看，买单的是项目经理，他要花时间澄清、对齐、修正报表。但真正的成本承担者是开发和测试。

开发每天要花 3 到 5 分钟处理卡片状态，一周就是 15 到 25 分钟。听起来不多，但状态带来的隐性成本是不确定感：我不确定这张卡该拖到哪一列，不确定拖错会不会被追问，不确定这个状态在别人眼里是什么意思。不确定感会让人倾向于少更新状态，而状态更新一稀疏，看板立刻失去意义。

三、拆解常见误区：为什么大多数状态设计一开始就是错的

1. 把状态当进度百分比用

「开发中 80%」是典型的进度伪装。它的危害不只是不准确，而是它把可判断的状态变成了不可判断的估计值。

状态本应是客观的：卡片有没有进入评审，评审有没有通过，都有明确事件。而百分比是主观的，且没有触发动作。当看板上一半的卡片都写着「开发中 80%」，项目经理依然不知道今天该催谁。

正确做法是把「进度」这个诉求交给别的属性：如果真需要百分比，用子任务完成度自动计算；如果需要判断风险，用截止时间和状态停留时长组合。

2. 认为状态越多，管理越精细

这是最普遍也最昂贵的误区。团队往往是「每出一次问题，就加一个状态」：出现联调扯皮，加「待联调」；出现测试打回，加「测试打回」；出现验收延期，加「待验收确认」。半年下来，状态攒到十几个。

每加一个状态，都是在给未来的自己增加一次对齐成本。而且新状态往往会稀释旧状态的约束力，原本「测试中」能覆盖的场景，现在被三个状态分担，每个状态的平均样本量都变小，度量反而更难做。

3. 所有工作项类型共用一套状态

需求、任务、缺陷、技术债、线上事故，这五类工作项的生命周期完全不同，却常常被塞进同一套状态里。

缺陷不需要「设计中」，需求不需要「复现中」。「已复现」对缺陷是关键的决策点，对需求则是无意义的环节。共用一套状态的后果是：每类工作项都带着一堆永远用不到的状态，实际有效状态被稀释。

合理的做法是按工作项类型定义独立的状态集，只在最粗的层面（待处理 / 进行中 / 已完成）保持口径统一。这样既能保住跨类型的报表能力，又能让每类工作项的状态都紧凑有用。

4. 把状态和看板列绑死

工具里通常允许「一列映射多个状态」或「一列只映射一个状态」。不少团队为了看起来整齐，强制一列对一状态，于是状态设计被看板布局绑架。

更隐蔽的问题是泳道。当团队按成员分泳道、按状态分列时，卡片移动会同时改变状态和归属，很容易误操作。看板列应该是状态的视图，而不是状态的定义。先定状态，再定列；允许一列里容纳两个语义相近的状态（比如「待评审」和「评审中」），看板会干净很多。

5. 只定义状态名，不定义进入和退出条件

「待评审」这三个字，如果没有配套的进入条件（必须指派评审人、必须附上设计文档链接）和退出条件（必须至少一位评审人通过），它就只是一块牌子。

我在一个团队里做过统计：定义了进入退出条件的状态，平均停留时长是 1.8 天；没定义的，平均停留 9.4 天，且方差极大。没有守门人的状态，最终都会变成垃圾回收站。

6. 改完状态不迁移历史数据

状态重构最常见的事故是：新流程上线了，老卡片还挂在已经被删除的旧状态上，或者被强制批量映射到某个默认值。结果是历史度量全部失真，团队对数据失去信任。

我的做法是：状态重构必须和迁移方案同一天发布。旧状态到新状态的映射表要逐条写清楚，允许出现「无法映射」的桶，并明确它的统计口径。

四、专业判断逻辑：状态设计的三层模型

讲完误区，说说我实际用的方法。我把它总结成三层：生命周期层、属性层、约束层。三层缺一层，状态就会退化。

1. 第一层：生命周期层，把决策点画成状态机

做法很简单：找一张白纸，把「待办」到「完成」之间所有需要人做判断的点写下来，每个点写成一个状态，并标注判断人是谁。

判断标准只有一条：如果这个状态没有人需要做判断，就删掉它。按这个标准，「开发中」和「联调中」通常会被合并成「开发中」，因为两者之间没有外部判断人。

合并之后的典型结果是 6 到 8 个状态。我常用的模板是：待规划 → 已就绪 → 进行中 → 待评审 → 评审中 → 待验收 → 已完成，外加一个「已阻塞」作为旁路状态。

2. 第二层：属性层，给状态加上「谁、何时、为何」

光有状态名不够，每个状态还要挂上三个属性：责任人、进入时间戳、进入原因。

责任人让「球在谁手上」变成可查询的事实。进入时间戳让停留时长可以被自动计算，不需要人工填工时。进入原因则用于回退场景，卡片从「评审中」退回「进行中」时，必须选一个原因（评审未通过 / 需求变更 / 技术方案调整），这些原因累积起来会变成非常有价值的过程改进输入。

这三个属性都不需要额外的人力投入，它们由状态变更事件自动生成。这是状态相对于其他任务属性的最大优势：数据采集是免费的副产品。

3. 第三层：约束层，用流转规则代替口头约定

约束层的核心是把「不能这样操作」写进工具里，而不是写在文档里。文档没人看，工具会拦住你。

我常用的约束有四类：进入条件校验、退出条件校验、回退路径限制、以及状态停留超时提醒。下面是一份可以直接落地的状态机定义示例，多数现代项目管理平台都支持类似的配置结构。

workflow:
name: 研发任务标准流程

item_type: task

states:

key: backlog

name: 待规划

category: todo

owner_role: 产品经理

timeout_hours: 168

key: ready

name: 已就绪

category: todo

owner_role: 项目经理

entry_guard:

需求已评审通过

负责人已指派

预估工作量已填写

timeout_hours: 72

key: in_progress

name: 进行中

category: doing

owner_role: 开发负责人

timeout_hours: 240

key: in_review

name: 待评审

category: doing

owner_role: 评审人

entry_guard:

已关联代码合并请求或设计文档链接

至少指定一位评审人

timeout_hours: 24

key: accepted

name: 待验收

category: doing

owner_role: 业务验收人

entry_guard:

测试用例执行通过率 100%

timeout_hours: 48

key: done

name: 已完成

category: done

owner_role: 项目经理

entry_guard:

验收人已确认

key: blocked

name: 已阻塞

category: doing

is_side_branch: true

entry_guard:

阻塞原因已填写

已指定解阻责任人

timeout_hours: 24

transitions:

from: backlog

to: ready

trigger: 需求评审通过

from: ready

to: in_progress

trigger: 开发开始

from: in_progress

to: in_review

trigger: 提交评审

from: in_review

to: in_progress

trigger: 评审未通过

require_reason: true

from: in_review

to: accepted

trigger: 评审通过

from: accepted

to: in_progress

trigger: 验收未通过

require_reason: true

from: accepted

to: done

trigger: 验收通过

from: "*"

to: blocked

trigger: 标记阻塞

require_reason: true

from: blocked

to: "*"

trigger: 解除阻塞

allowed_targets: [in_progress, in_review, accepted]

这份定义里有三个细节值得注意。第一，回退路径只有两条：评审未通过退回进行中，验收未通过退回进行中。回退路径越少，数据越干净。第二，「已阻塞」是旁路状态，可以从不限来源进入，解除后回到原路径的合法节点。第三，所有回退和阻塞都必须填原因，这是过程改进的数据来源。

4. 判断某个状态该不该保留的三个问题

当团队争论某个状态要不要加的时候，我会问三个问题，只要有任何一个答不上来，就说明这个状态不该存在。

1. 这个状态的责任人是谁？如果答案是「大家」，那就是没有人。
2. 进入这个状态需要满足什么条件？如果答案是「差不多做完了」，那它不可验证。
3. 退出这个状态的触发动作是什么？如果答案是「继续做」，那它就不是一个独立状态。

这三个问题我在十几个团队用过，效果出奇地好，因为它把抽象的流程讨论变成了具体的事实核查。

5. 度量口径必须和状态同时定义

状态设计的最后一步是定义度量口径。我通常至少定义四个指标，且每个指标都要绑定具体状态。

• 前置时间：从「待规划」进入时间到「已完成」进入时间，衡量端到端交付速度。
• 在制品数量：处于「进行中」的卡片数，衡量并行度是否超载。
• 评审响应时长：从进入「待评审」到离开的平均时间，衡量评审环节的健康度。
• 回退率：从「评审中」或「待验收」退回「进行中」的比例，衡量交付质量。

这四个指标全部依赖状态的准确流转，反过来说，如果状态设计得不好，这四个指标一个都算不准。这也是我坚持先做状态、再做度量的原因。

五、案例与数据观察：在一个 140 人研发组织里把状态从 0 到 1 建起来

1. 为什么最后选了这个平台

讲完方法，讲一个完整落地的案例。这是一家做工业软件的公司，研发加测试约 140 人，分 4 条产品线。他们的痛点很典型：四条产品线各用一套状态，集团层面想看整体交付效率时，数据完全对不上。

选型阶段他们有三个硬约束。第一，必须支持私有化部署，因为涉及工业客户的图纸和参数数据，不能出内网。第二，必须支持从 Jira 平滑迁移，他们过去 6 年积累了两万多条历史工作项，迁移不能让数据断层。第三，要能按工作项类型分别定义状态集，而不是全局一套。综合这三点，他们最终选了 PingCode。

我在这里说清楚我的判断依据，而不是替谁做广告：在国产研发管理工具里，同时满足「私有化部署 + 支持 Jira 平滑迁移 + 中大型组织多产品线建模」这三条的选项并不多。PingCode 主要服务中大型企业及 100 人以上组织，这个定位和他们的规模正好匹配，所以成为了国产替代方案里的首选之一。

2. 从 0 到 1 的六个步骤

真正落地的过程比方法论枯燥得多，我按实际顺序记录下来。

1. 先做一轮状态盘点。把四条产品线的所有状态导出成表格，一共 37 个不同状态名。去重后合并同义项（比如「开发中」「编码中」「实现中」），剩下 21 个。
2. 按工作项类型分组。需求、任务、缺陷、技术债四类，分别确定各自需要的决策点。最终需求 7 个状态、任务 6 个、缺陷 5 个、技术债 4 个。
3. 画迁移映射表。21 个旧状态逐条映射到新状态，无法映射的进入「历史归档」桶，明确不纳入新报表口径。
4. 配置约束规则。给「待评审」「待验收」加上进入条件和超时提醒，把回退路径收紧到两条。
5. 跑两周灰度。先让两条产品线用新流程，另外两条保持旧流程，做横向对照。
6. 全量切换并锁定。切换后设置三个月的状态冻结期，期间任何人不得新增状态，变更需走流程委员会评审。

第三步的迁移映射表是整个项目里最关键、也最容易被低估的一环。我贴出其中一部分，供参考。

3. 上线六周后的数据观察

这个团队从切换完成开始记录，我拿到了六周的对照数据。需要说明的是，下面这些数字不是精细的因果实验，而是同一组织前后对照的观察值，中间混杂了流程宣贯和工具培训的影响，但方向性足够清晰。

最让我意外的不是交付周期缩短 24%，而是评审未通过回退率这个指标第一次被看见。在此之前，团队根本不知道有多少任务被打回过，因为打回这件事散落在三种不同的操作方式里。有了统一状态和必填原因之后，这个数字变成 14%，并且能看到原因分布：需求变更占 46%，技术方案调整占 31%，评审标准理解差异占 23%。

最后那一项直接推动了他们做评审标准清单，这完全是状态设计带来的衍生收益。

4. 一次失败尝试：我们曾经想加第 7 个状态

切换后第 7 周，测试同学提出希望增加一个「待回归」状态，理由是回归测试经常排队，而「待验收」不能反映这个等待。

我们试了一周，结果发现两个问题。第一，「待回归」和「待验收」的责任人不同，导致同一批卡片在两个队列里来回漂移。第二，原本就偏长的验收停留时长被拆成两段，报表上反而看不出总排队时间。

我们最终的做法是不加状态，而是给「待验收」加了子状态标签和排队时长看板。有问题的是可视化方式，不是状态模型本身。这件事让我更加确信：状态数量的问题，十次里有九次应该用别的属性解决。

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

1. 20 人以下团队：三个状态就够

这个规模组通常没有专职项目经理，沟通靠面对面。我的建议是只用「待处理 / 进行中 / 已完成」，最多加一个「已阻塞」。

不要急着配复杂流程，这个阶段的主要矛盾是需求优先级不清，而不是状态太粗。如果一定要加一个，加「已阻塞」的收益最高，因为它能让今天的站会立刻发现问题。

2. 20 到 100 人团队：五到七个状态，按决策点切

这是收益最明显的区间。团队已经大到无法靠口头同步，但还没到流程割裂的程度。建议按工作项类型分别定义状态集，并在关键节点加进入条件。

我推荐的最小可行配置是：待规划、已就绪、进行中、待评审、待验收、已完成，加上旁路状态已阻塞。这六个状态能覆盖绝大多数研发场景，且每个都能关联一个明确责任人。

3. 100 到 500 人团队：按产品线自治 + 集团口径统一

这个规模最大的挑战是「统一」和「灵活」的冲突。我的建议是双层设计：底层状态集由各产品线自主定义，顶层设立一组映射到统一语义的状态分类。

具体来说，每个状态都要打上分类标签（待办类 / 进行类 / 完成类 / 阻塞类），集团层报表只看分类，不看具体状态。这样产品线可以保留「待联调」这类个性化状态，而集团依然能算出统一的在制品数量和交付周期。

如果团队有私有化部署和数据不出内网的要求，选平台时要把这一条作为硬门槛先筛一遍。这也是前面那个 140 人组织最终选择 PingCode 这类支持私有化部署的国产平台的原因之一。

4. 500 人以上或多事业部：把状态当成受管控的配置项

到这个规模，状态变更本身的成本已经很高了。我的建议是设置状态冻结期和变更评审机制，任何新增状态都需要说明三件事：责任人是谁、进入条件是什么、对应的度量影响是什么。

同时要建立状态清单的版本管理。每次变更记录时间、原因、影响范围，这样当半年后发现某个指标变差时，能够回溯到是哪次状态调整导致的。

七、不同情况下的取舍

1. 精细度 vs 录入成本

这是最根本的一对矛盾。状态越细，看板信息越丰富，但每个成员每天花在更新状态上的时间就越多。

我的经验阈值是：如果一个人平均每天花在状态变更上的时间超过 3 分钟，就说明状态设计过细了。这个数字可以通过卡片的平均流转次数乘以单次操作耗时估算出来。

需要提醒的是，录入成本不只是操作时间，还包括判断成本。「这张卡现在算哪个状态」这个判断本身，在状态边界模糊时可能比操作本身更耗时。

2. 统一 vs 自治

统一口径的好处是报表能横向比较，坏处是产品线的特殊场景被抹平。自治的好处是贴合实际，坏处是集团层看不到全局。

我的判断是：200 人以下优先统一，200 人以上优先用分类层统一、具体状态自治。因为 200 人以下，横向比较的收益还不足以抵消对齐成本；超过 200 人之后，自治带来的执行力收益会超过口径统一的收益。

3. 强约束 vs 弱约束

强约束（进入条件校验、回退必填原因、超时强制提醒）能让数据质量快速提升，但也会带来摩擦。有的团队会因为「工具太烦」而绕过系统，用线下沟通替代。

我的做法是分级：核心决策点（评审、验收）用强约束，中间过程（进行中、已就绪）用弱约束。这样既保住了关键数据的质量，又不会让日常操作变得沉重。

4. 自建 vs 采购

有些团队会考虑自建一套状态流转系统。我的建议是慎之又慎。

自建的隐性成本主要在三个地方：状态变更的权限和审计、跨类型工作项的统一建模、以及历史数据的迁移和兼容。这三件事在需求文档里通常只占几行字，实际实现却常常占掉大半工期。

只有当业务流程极其特殊、市面方案完全无法覆盖时，自建才值得考虑。而且即便自建，也应该先用手工方式跑三个月，验证状态模型本身是对的，再投入开发。

八、落地检查清单与度量闭环

1. 上线前必须回答的十个问题

这是我每次做状态设计都会过一遍的清单。任何一个问题答不上来，都不要急着上线。

1. 每个状态的责任人是否唯一且明确？
2. 每个状态的进入条件是否可客观验证？
3. 存在的回退路径一共有几条？是否都能说清楚？
4. 回退是否需要填写原因？原因选项是否覆盖了主要场景？
5. 是否按工作项类型分别定义了状态集？
6. 旧状态到新状态的映射表是否逐条确认？无法映射的数据如何处理？
7. 四个核心度量指标（前置时间、在制品数量、评审响应时长、回退率）是否都能从这个状态模型里算出来？
8. 状态停留超时的阈值是多少？超时后触发什么动作？
9. 改状态的权限归谁？变更流程是什么？
10. 有没有设置冻结期？多久之后允许第一次复盘调整？

2. 上线后前四周的观察节奏

状态上线不是终点，前四周的观察才是决定它能否活下来的关键。

第一周重点看误操作。让每个成员记录自己最常犹豫的那次状态变更，一周后汇总，通常会暴露出两到三处边界模糊的地方。

第二周重点看异常流转。用工具把跳状态、长期停滞的卡片筛出来，逐条看原因。这一周的数据最有价值，因为它直接告诉你哪条流转规则不贴合实际。

第三周重点看超时。如果某个状态的超时提醒被大量触发，要么是阈值定得不合理，要么是这个状态本身就是瓶颈。

第四周做第一次复盘，但只允许做减法，不允许加状态。这个约束很重要，它防止团队回到「一出问题就加状态」的老路。

3. 用状态数据反哺流程改进

状态真正产生复利，是在它开始指导流程改进之后。我通常固定看三张表。

第一张是状态停留时长分布。看中位数和 P90 的差距，差距大说明流程不稳定，某些卡片被长期卡住。

第二张是回退原因帕累托图。通常前两个原因会占到 60% 到 70%，集中解决这两个，收益最大。前面那个团队就是靠这张图发现了需求变更占回退原因的近一半，从而推动建立了变更评估机制。

第三张是在制品数量与交付周期的关系。这两条曲线通常会在某个点之后同时变差，那个点就是团队的合理并行度上限。

九、结语：状态是团队认知的最小公约数

回到最开始那块 11 个状态的看板。它的问题不在于状态多，而在于没有人认真问过每个状态存在的理由。它们是历史遗留、是某次扯皮的产物、是某人临时加上的补丁，唯独不是一次有意识的设计。

我对这件事的核心判断是：状态是团队认知的最小公约数。它比需求文档更坚固，比流程规范更日常，比会议纪要更持久。一个设计良好的状态模型，能让 100 多人在没有日常沟通的情况下，依然准确知道每个任务此刻该由谁推动。

反过来，一个设计糟糕的状态模型，会让每一次协作都从「我们先对齐一下这个词是什么意思」开始，这种成本在报表上看不见，但在每个成员的每一天里都在发生。

关于任务属性从 0 到 1，我的建议是按这个顺序推进：

1. 先做状态盘点，把所有在用的状态名列出来，合并同义项，通常第一步就能砍掉三分之一。
2. 再定决策点，用「责任人是谁、进入条件是什么、退出动作是什么」三问筛掉伪状态，把数量压到 5 到 8 个。
3. 然后加约束，给关键节点配进入条件和回退原因，其余保持轻量。
4. 最后接度量，定义前置时间、在制品数量、评审响应时长、回退率四个指标，每周看一次趋势。

如果你们组织已经在 100 人以上、有多条产品线、还叠加了私有化部署或从 Jira 迁移的历史包袱，那就把选型当成状态设计的一部分来考虑。像 PingCode 这类面向中大型企业、支持私有化部署和 Jira 平滑迁移的国产平台，能让状态建模和迁移映射这两件最费劲的事少踩很多坑，这也是它在国产替代场景里被优先考虑的原因。

最后留一个可立即执行的行动：明天花 30 分钟，把你团队当前看板上的所有状态抄下来，给每个状态填三个空，责任人、进入条件、退出动作。填不出来的那些，就是下次复盘最该讨论的候选删除项。做完这一步，你就已经从「有状态」走到了「有状态设计」。