项目阶段阶段状态教程：产品经理效率提升，避坑指南

2023 年我第一次看到一个横向要拖三次才能看完的项目看板时，脑子里冒出的第一个念头不是”这个团队管得真细”，而是”这个团队的项目经理，每周有多少时间花在拖动卡片上”。后来我拿到了那家公司的脱敏数据：46 人的研发团队，每周花在”这张卡片现在到底算什么状态”的沟通上，大约是 5.8 人时。折算到一年接近 300 人时，相当于一个人两个多月的工作量，全部消耗在状态对齐这件事上。

更麻烦的是，这 5.8 人时并没有换来更准确的信息。我抽查了那个看板上 30 张标记为”进行中”的卡片，真正在写代码的只有 9 张，其余 21 张分别卡在等接口、等环境、等评审、等测试资源上。状态在动，进度没动。

所以我一直认为，项目阶段和项目状态不是两个配置项，而是一套信息架构。它决定了你后面所有的报表、度量、复盘、资源调配能不能做。这篇文章基于我在 2021 到 2024 年间参与过的 9 个研发团队的脱敏观察，讲清楚阶段和状态该怎么设计、产品经理最容易掉进哪些坑、以及不同规模团队该怎么取舍。

一、核心结论：阶段是容器，状态是位置，两者不该被压成一张表

先把结论摆出来，后面再展开论证。如果你时间有限，只看这一节，也能拿到 80% 的决策价值。

1. 用三层结构取代”一个大状态机”

绝大多数团队的状态混乱，根源是把不同层级的信息压进了同一个状态字段。我的建议是拆成三层：项目状态（Project Status）、阶段状态（Phase Status）、工作项状态（Work Item Status）。

项目状态回答”这个项目整体是正常、有风险还是已阻塞”，通常 4 到 6 个就够，由产品负责人或项目经理维护。

阶段状态回答”当前处于哪个阶段、这个阶段内部的推进位置是什么”，这是我后面重点展开的部分。

工作项状态回答”单个需求、任务或缺陷在谁手里、下一步是什么”，颗粒度最细，由执行人维护。三层各自独立演进，通过阶段推进事件联动，而不是靠状态跳转硬拉在一起。

2. 状态的唯一价值是触发下一步动作

这是我做状态评审时最常用的一条判据：如果一个状态无法触发任何人的下一步动作，它就不该存在。

举个具体例子。某团队在测试阶段设置了”已提测”和”测试中”两个状态。听起来很合理，实际上这两个状态之间的切换完全依赖测试同学手动点一下，而测试同学一天可能只更新一次。结果是”已提测”里堆了 40 多张卡片，实际测试早就开始了。

这两个状态里，”已提测”不触发任何动作，”测试中”也不触发任何动作，真正的动作触发点是”测试资源分配”和”开始执行用例”。状态名换了，动作没换，信息量就是零。

3. 每个阶段的状态数量上限是 5 个

这个数字来自我做过的一次内部统计。我把 9 个团队的状态数量和”状态相关沟通时长”做了对照，发现状态数从 4 个增加到 7 个时，沟通时长上升约 60%；从 7 个增加到 12 个时，上升约 140%；超过 15 个之后，沟通时长不再显著上升，因为团队成员干脆放弃准确更新，改用口头同步，这时候状态数据已经失效了。

所以我的建议是：每个阶段 3 到 5 个状态，全项目阶段状态总数控制在 20 个以内。超过这个数，你得到的信息精度提升远小于维护成本。

4. 状态必须有准入条件和准出条件

只有状态名、没有准入准出条件，等于没有状态。这是我见过最多、也最容易被忽略的问题。

准出条件（Exit Criteria）尤其重要。它是状态机里唯一能防止”卡片往前拖但实际没做完”的东西。比如开发阶段的准出条件可以是”自测用例通过率不低于 95% 且接口契约已冻结”，测试阶段的准出条件可以是”阻断级缺陷为 0 且回归通过”。

没有准出条件，卡片就会在状态之间自由漂移，而漂移的成本最终由下游承担，测试同学接到的”已完成开发”的需求，可能还有三个接口没联调。

5. 报表口径必须在设计阶段就定死

我通常会在状态模型评审的最后一页放一个问题：“这个状态字段，半年后我们要用它算哪个指标？”回答不上来的状态，要么删掉，要么补充用途说明。

原因很简单：状态字段一旦上线并跑了三个月数据，再改口径就要面对历史数据不一致的问题。很多团队做到一半发现”开发周期”算不出来，回头改状态，结果前三个迭代的数据直接作废。

二、背景与真实场景：我是怎么被状态问题教育了三次的

上面这些结论不是推演出来的，是被三次具体的失败现场教育出来的。我把这三个现场还原一下，你可以对照看看自己团队有没有类似症状。

1. 第一次：27 列看板，项目经理成了”拖卡片专员”

那是一家做企业采购 SaaS 的公司，46 人研发，三个产品线共用一个看板。看板列从”需求池、需求评审、待排期、已排期、开发中、接口联调、自测中、待提测、提测中、测试中、回归中、待修复、修复中、待验收、验收中、待上线、灰度中、待发布、已发布”往后还有 8 列，总计 27 列。

项目经理每天上午的第一件事，是把卡片往右拖。因为研发同学不习惯更新状态，只习惯在群里说一句”我做完了”。项目经理看到群消息，手动拖卡片。

这个模式的直接后果是：看板数据成了项目经理的个人记忆的投影，而不是团队真实状态。他休假一周，看板就停更一周。

2. 第二次：只有 4 个状态，却堆了 39 个标签

第二个团队走了另一个极端。他们的状态只有 4 个：待办、进行中、待验证、完成。听起来很清爽，但我打开标签列表时看到 39 个标签：`等接口`、`等设计稿`、`等测试环境`、`被阻塞`、`联调中`、`自测中`、`灰度观察`、`待产品确认`……

问题是，同一个”进行中”列里，躺着语义完全不同的卡片。一个卡片标着”等接口”，另一个标着”自测中”，但它们在看板上长得一模一样。

这个团队的度量同学告诉我，他写一个”当前阻塞任务数”的 SQL，要写 7 层 OR 条件去匹配标签名，而且标签名还有人写错别字。这就是典型的用标签替代状态，把结构化的信息塞进了非结构化的容器里。

3. 第三次：工具里的状态没人维护，进度只活在周报里

第三个团队的工具体系很完整，状态定义也很规范，有文档、有评审、有流程图。但工具里的状态没人更新。

我抽查了 12 个迭代的数据，发现有 7 个迭代里，超过 30% 的工作项从创建到关闭只经历过两次状态变更。实际进度全靠每周五的周报同步。

最典型的症状是：工具里的”完成度 80%”可以连续三周都是 80%。因为 80% 是人在周报里写的，不是从状态数据里算的。

4. 为什么产品经理最先被状态问题反噬

三个现场里，最痛苦的岗位都是产品经理。原因不难理解。

研发同学只需要看自己的任务队列，状态不准顶多影响他个人的工作排序。测试同学只看提测队列，状态不准会影响排期但影响有限。

但产品经理是需求从提出到上线的中间人。他必须能在任何时刻回答”这个需求现在到哪了”。这个问题往上要回给业务方和老板，往下要拆给研发和测试。状态不准，他要么靠记忆回答（迟早出错），要么每次都去群里问一圈（每周消耗数小时）。

所以状态模型这件事，产品经理不是”顺带参与”，而是第一责任人。工具配置可以交给效能团队，但状态语义的定义权必须在产品经理手里。

三、拆解六个常见误区

这一节我按”误区描述，为什么会这么想，实际后果”的结构来讲，方便你逐条对照自己的团队。

1. 误区一：状态越多，管理越精细

这是最普遍的认知偏差。状态数量和管理精度之间不是线性关系，而是先升后降的倒 U 型。在 3 到 5 个状态区间内，增加状态确实能提升信息区分度；超过 7 个之后，边际收益迅速下降；超过 12 到 15 个之后，团队会因为维护成本过高而放弃准确更新，信息质量反而低于只有 4 个状态时。

我见过一个极端案例：测试阶段设了 9 个状态。结果测试同学的做法是，卡片先进”测试中”，然后一次性跳到”已通过”，中间 7 个状态基本不用。这 7 个状态就是纯负担。

2. 误区二：阶段推进等于状态跳转

很多团队把”项目进入测试阶段”实现为”所有卡片状态改成测试中”。这会导致两个问题。

第一，阶段是项目级属性，状态是工作项级属性。项目进入测试阶段时，通常还有 20% 到 30% 的卡片没完成开发。强制批量改状态，等于抹掉了”哪些还没做完”这个信息。

第二，阶段推进是单向的、有明确时间点的；状态流转是双向的、连续发生的。把两者绑定，阶段就无法回退（回退一次要把几百张卡片改回去），状态也无法独立统计。

正确做法是：阶段作为独立字段存在，状态在自己的阶段内流转，两者通过”当前阶段”这个字段关联，而不是互相赋值。

3. 误区三：看板列就是状态列

这是工具使用层面的高频误区。看板列和状态字段的关系有两种设计：一是列即状态（列的集合等于状态集合），二是列是状态的视图（一列可以聚合多个状态，也可以一列拆成多列）。

我倾向于第二种，但要把控好边界。看板列应该按”谁在处理”来分，而不是按状态名来分。比如”开发中”和”自测中”通常是同一个人在推进，可以放在同一列的上下两个状态；而”待测试”和”测试中”涉及交接，应该分成两列。

把看板列直接等同于状态，最常见的结果是 WIP 失控，因为每一列都变成了一个可以放无限卡片的容器，没有人知道哪一列真正超载了。

4. 误区四：状态只能前进，不能回退

有些团队为了保证数据”好看”，把状态机设成单向的，卡片只能往前不能往后。实际结果是团队用别的方式绕过：新建一张卡片，或者干脆不改状态。

回退是真实存在的，关键是让回退可记录、可归因。我在后来的项目里统一加了 `rollback_count` 字段和回退原因枚举，结果发现一个很有价值的数据：回退次数达到 2 次及以上的需求，上线后缺陷密度是 0 次回退需求的 3.4 倍。

5. 误区五：工具自带的状态模板可以直接用

项目管理工具通常会预置一套状态模板，比如待办、进行中、已完成。这套模板的问题是它默认了”一个团队、一种流程、一个交付节奏”。

中大型组织的实际情况是：不同产品线阶段划分不同，不同团队交付节奏不同，甚至同一个团队里需求、缺陷、技术任务的状态流转规则都不同。直接套模板，团队会在两周内开始”创造性使用”，加标签、加自定义字段、在描述里写状态。

6. 误区六：状态变更不需要留痕

只记录”当前状态”，不记录”状态变更历史”，等于放弃了最有价值的一类数据。阶段停留时长、状态流转效率、返工次数、瓶颈环节识别，全部依赖变更历史。

我的经验是，只要状态变更历史完整，你可以算出至少 8 个管理指标；如果只有当前快照，你只能算出 2 个（存量分布和完成率）。这个投入产出比非常划算。

四、专业判断逻辑：从”谁看状态”倒推”设计什么”

这一节讲我实际使用的一套判断流程。它不依赖任何特定工具，你可以直接用在自己的项目上。

1. 第一步：列出所有状态消费者

在设计状态之前，先问一个问题：半年后，谁会看这个状态字段？我把消费者分成四类，每类的诉求不同。

第一类是执行者（研发、测试、设计），他们关心”我现在该做什么”，需要状态的下一步动作明确。

第二类是协调者（产品经理、项目经理、Scrum Master），他们关心”卡在哪、谁卡住、卡了多久”，需要状态变更历史和停留时长。

第三类是管理层（部门负责人、PMO），他们关心”整体吞吐、瓶颈在哪、能不能按期交付”，需要阶段级聚合数据。

第四类是外部（业务方、客户、合规审计），他们关心”能不能给一个可信的进度承诺”，需要稳定、不随内部流程变动而变动的口径。

如果某个状态对这四类消费者都没有价值，删掉它。

2. 第二步：为每个状态写出准入和准出条件

准入条件回答”什么情况下可以进入这个状态”，准出条件回答”满足什么条件才能离开”。我要求每条准出条件必须是可验证的，不能是”开发基本完成”这种主观描述。

下面是我在多个项目里用过的一份阶段状态配置示意，你可以按自己的流程裁剪。

# 阶段状态定义（示意配置，可裁剪）
project_phases:

phase: 需求

states: [待评审, 评审中, 已确认, 已冻结]

exit_criteria: 需求文档评审通过 且 验收标准可量化

phase: 设计

states: [待设计, 设计中, 待评审, 已定稿]

exit_criteria: 技术方案评审通过 且 接口契约冻结

phase: 开发

states: [待开发, 开发中, 自测中, 已提测]

exit_criteria: 自测用例通过率 >= 95%

phase: 测试

states: [待测试, 测试中, 待修复, 回归中, 已通过]

exit_criteria: 阻断级缺陷为 0 且 回归全部通过

phase: 发布

states: [待发布, 灰度中, 全量发布, 已发布]

exit_criteria: 灰度观察 48 小时无 P1 故障

注意每个阶段的状态数是 4 到 5 个，全流程总共 21 个，其中真正高频使用的只有 9 个。低频状态的存在价值是兜底，不是日常流转。

3. 第三步：设计可逆的状态机

状态机必须允许回退，但回退要有约束。我的做法是三条规则。

规则一：回退必须选择原因，原因从固定枚举里选，不允许自由填写。原因枚举通常包括需求变更、设计缺陷、开发缺陷、环境问题、验收标准调整。

规则二：回退次数累加记录，不因为再次前进而清零。

规则三：跨阶段回退（比如从测试阶段退回开发阶段）需要额外确认人，通常是产品经理或技术负责人。

下面是我实际使用的工作项状态数据结构示意，重点是最后几个字段。

{
"work_item_id": "REQ-2041",

"phase": "测试",

"state": "回归中",

"state_owner": "qa.li",

"state_entered_at": "2024-03-11T09:20:00+08:00",

"rollback_count": 2,

"rollback_reasons": ["开发缺陷", "需求变更"],

"phase_entered_at": "2024-03-04T14:00:00+08:00"

}

4. 第四步：验证阶段与状态的正交性

正交性是我判断状态模型质量的核心指标。如果两个字段能互相推导出对方，它们就是冗余的。

检验方法很简单：随便取一条历史数据，问”知道阶段能不能推出状态”，再问”知道状态能不能推出阶段”。如果两个问题有一个答案是”能”，说明你把两层信息压在了一起，需要拆开。

常见的非正交情况有：”测试中”这个状态同时暗示了阶段是测试；”问题阶段”这个阶段名同时暗示了状态异常。这两种命名方式都会导致统计口径冲突。

5. 第五步：用数据反验状态设计

状态模型上线运行两到三个迭代后，我会做一次反验，主要看四个信号。

信号一：某些状态的卡片平均停留时长小于 4 小时。说明这个状态是过渡态，可以考虑合并。

信号二：某些状态的卡片数量长期为 0，或者长期超过总量的 40%。说明这个状态定义有问题，要么删掉要么拆分。

信号三：状态变更集中在固定时间点（比如每天下班前）。说明团队在”补状态”而不是”用状态”。

信号四：同一状态的停留时长方差极大。说明这个状态内部混杂了多种语义，需要细化。

五、具体案例与数据观察：一个 320 人组织的状态模型改造

前面讲的都是方法和判断。这一节我把一个完整的改造过程拆开，包括数据、方案、投入和结果。

1. 案例背景

这是一家 B 端企业服务公司，研发体系约 320 人，下分 6 个产品线、18 个 Scrum 团队。改造前的工具体系是自建加部分开源拼装，后来统一迁移到 PingCode 私有化部署环境。迁移的一个重要原因是他们需要支持 Jira 平滑迁移，同时有数据不出内网的合规要求。

改造的核心问题有两个：一是状态字段混乱，全公司统计”需求交付周期”时，六个产品线给出了六种口径；二是阶段和状态混在一起，导致阶段停留时长根本算不出来。

2. 改造前的关键数据

我把改造前的基线数据列出来，后面好做对比。这些数据来自工具导出和访谈测算，访谈部分标注了口径。

• 全公司状态字段总数：27 个（各产品线自定义，无统一标准）
• “需求交付周期”口径一致的产品线数量：1 个（6 个中）
• 状态相关周沟通时长：约 6.5 人时/周（按 18 个团队抽样访谈测算）
• 阶段停留时长可测率：0%（无阶段字段，无法统计）
• 返工归因可完成率：0%（无回退记录）
• 状态流转人工确认平均延迟：2.1 天

3. 改造方案：阶段 × 状态矩阵

方案核心是把原来的一维状态列表，改成”阶段 + 阶段内状态”的二维结构。全公司统一 6 个阶段：需求、设计、开发、测试、发布、运营观察。每个阶段内允许 3 到 5 个状态，由产品线在标准范围内自选，但不能超出。

统一了口径之后，再定义一个跨产品线通用的交付周期指标：从”需求阶段进入已确认状态”到”发布阶段进入已发布状态”的时间差。这个口径的好处是，两端都有明确的状态锚点，不需要人工判断。

4. 落地方式与迁移投入

落地分三步走。第一步统一阶段定义和统计口径，用了约 5 人天，主要是各产品线负责人对齐。第二步配置工具、迁移历史数据，用了约 8 人天。第三步做团队培训和两轮试点迭代，用了约 5 人天。合计约 18 人天。

迁移过程中比较关键的一点是历史数据映射。原有 27 个状态要映射到新模型的 18 个状态，其中有 5 个状态是多对一映射，需要逐一确认映射规则，避免历史统计出现断层。

5. 改造后的数据变化

改造后跑了 6 个迭代（约 3 个月），我拿到了这组对比数据。需要说明的是，同期该公司还调整了需求冻结策略，所以发布周期的改善不能全部归因于状态模型改造。

6. 我观察到的三个反直觉结论

结论一：状态数量减少后，信息量反而增加。状态从 27 个降到 18 个，但可算出的管理指标从 3 个增加到 11 个。原因是结构清晰之后，字段之间的关系变得可推断，而不是依赖某个特定状态存在。

结论二：团队最抵触的不是减少状态，而是增加准出条件。减少状态大家都能接受，但要求”提测前自测通过率不低于 95%”这类准出条件时，研发团队明显抵触。最后折中为前两个迭代先记录不强制，第三个迭代才开始强制执行。

结论三：阶段字段的价值高于状态字段。如果只能保留一个字段，我会保留阶段。因为阶段是所有跨团队沟通的通用语言，而状态是团队内部语言。管理层看阶段，团队看状态，这是最省力的分工。

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

状态模型没有唯一正确答案，只有匹配团队规模的答案。这一节我按团队规模和组织特征给出具体建议。

1. 10 人以下小团队：状态越少越好

这个阶段最重要的是交付速度，不是管理精度。我的建议是：阶段 3 到 4 个，每个阶段 2 到 3 个状态，全流程状态总数不超过 10 个。

具体做法：需求、开发、发布三个阶段即可。状态用”待办 / 进行中 / 待验证 / 完成”四个就够，不要加”已提测””联调中”这类中间状态。

这个阶段的团队通常用看板就够了，不需要阶段字段。因为所有人都知道当前在做什么，信息通过日常沟通传递的成本低于结构化记录的成本。

2. 10 到 50 人成长型团队：开始建阶段，但别建太细

团队规模超过 10 人后，沟通开始出现断层，”谁知道谁在做什么”成为问题。这时候应该引入阶段字段。

我的建议是 5 个阶段：需求、设计、开发、测试、发布。每个阶段 3 到 4 个状态，总数控制在 15 到 18 个。

这个阶段最需要建立的不是状态数量，而是准出条件。因为交接开始频繁，没有准出条件，质量问题会集中在下游爆发。

下面这张表是我常用的规模匹配参考，你可以直接对照。

3. 100 人以上中大型组织：优先解决口径问题，而不是流程问题

到了这个规模，最大的痛点不是”怎么流转”，而是”六个部门对同一个指标的理解不一样”。所以第一步应该是统一阶段定义和统计口径，第二步才是配置状态。

工具选择上，中大型组织通常需要更强的权限分层、审计留痕、私有化部署能力。PingCode 这类面向中大型企业及 100 人以上组织的项目管理平台，在阶段与状态的字段建模、跨项目聚合报表、权限分层上相对成熟，同时支持私有化部署和 Jira 平滑迁移，对已有历史数据的组织比较友好。

需要强调的是，工具只解决”能不能配”，不解决”该不该这么配”。我见过太多组织把工具能力当成了流程设计的替代品，结果是把错误的流程配置得更完整、更自动化。

4. 多产品线或强合规行业：把留痕和可追溯放在第一位

金融、医疗、汽车电子这类行业，状态设计的第一目标是可追溯，第二目标才是效率。这种情况下，我的建议是：状态变更必须记录操作人、时间、原因；跨阶段回退必须双人确认；状态历史不可删除，只能追加。

代价是流程变重、更新变慢。所以在这些行业里，我会把状态数量压到最少，用留痕深度换状态广度。宁可 4 个状态配完整审计日志，也不要 12 个状态配零散记录。

5. 从其他工具迁移过来的团队：先映射，再优化

迁移时最容易犯的错误是边迁移边优化流程。这两件事同时做，会同时出问题。

我的建议是先做历史数据映射，把旧状态一对一或多对一映射到新模型，保证历史统计不断层；迁移完成、跑稳一到两个迭代后，再动流程优化。Jira 迁移的场景尤其如此，因为历史数据的字段关系往往比想象中复杂。

七、不同情况下的取舍

前面讲的都是”应该怎么做”。这一节讲必须做的取舍，因为每个建议都有代价。

1. 取舍一：精细度 vs 维护成本

这是最核心的一组取舍。状态精细度的收益是递减的，维护成本是递增的，两者必然在某个点交叉。

我的判断标准是：如果某个状态在过去两个迭代中，平均停留时长小于 4 小时，或者只有不到 5% 的卡片经过，就应该合并掉。反过来，如果某个状态的平均停留时长超过该阶段总时长的 40%，就应该拆分。

这组判断规则的好处是不依赖主观讨论，直接用数据说话。我在几个团队推行后，状态评审会的时间从平均 90 分钟降到 35 分钟，因为争论点从”我觉得应该加”变成了”数据支撑不支撑”。

2. 取舍二：强约束 vs 团队自治

强约束的好处是全公司口径统一，报表可以直接聚合；代价是产品线失去流程灵活性，可能被迫使用不适合自己的状态。

我的建议是分层约束：阶段定义全公司统一，不可自定义；阶段内的状态，在给定集合内允许产品线选择；状态的准入准出条件，允许产品线在标准基础上加严，不允许放宽。

这套规则的实际效果是：管理层能拿到统一报表，产品线保留了一定的流程调整空间，同时质量底线不被突破。

3. 取舍三：自动化 vs 灵活性

自动化能减少人工更新延迟，但会降低灵活度。比如设置”代码合并后自动流转到已提测”这样的规则，效率很高，但如果团队的实际提测标准包含人工检查，自动流转就会产生错误信息。

我的经验是：自动流转只用于有客观触发信号的状态变更，比如代码合并、构建成功、部署完成。凡是需要人工判断的（比如”测试是否通过”），不要自动化。

另外，自动化规则本身要有可见性。我见过团队配置了 40 多条自动流转规则，运行半年后没人说得清一条卡片为什么会自动跳状态。

4. 取舍四：统一口径 vs 部门差异

统一口径让跨部门数据可比，但会抹掉一些有价值的部门差异。比如测试团队可能希望区分”功能测试”和”性能测试”两种状态，但统一口径里没有这个区分。

我的做法是把差异放到扩展字段里，而不是塞进状态字段。状态保持统一，差异化需求用自定义属性承载。这样既能统一聚合，又不丢失部门级信息。

5. 取舍五：一次性重构 vs 渐进式演进

一次性重构的好处是结构干净、没有历史包袱；代价是迁移风险集中、团队需要一次性适应。渐进式演进风险低，但容易走形，最后变成”新旧两套并行”。

我的建议取决于团队规模。50 人以下、工具使用深度不高的团队，可以一次性重构。100 人以上、历史数据量大的组织，建议分两步：先做字段层重构和映射，跑两个迭代，再做流程层优化。

八、常见问题快答

这一节整理我在培训和咨询中被问得最多的五个问题，直接给答案。

1. 状态和标签到底该怎么分工？

判断标准很简单：需要用它做统计和筛选的，做成状态；只是临时备注的，用标签。

比如”被阻塞”如果不是所有卡片都可能出现的通用属性，就不该做成状态，而应该做成一个布尔字段加阻塞原因。同理，”等接口”如果只是个别情况，用标签；如果超过 20% 的卡片都会经历，就应该做成状态。

2. 阶段和迭代是一回事吗？

不是。迭代是时间盒，阶段是工作性质。一个迭代里可能同时存在开发阶段和测试阶段的卡片；一个阶段也可能横跨两个迭代。

把两者混用，最典型的后果是”迭代结束但阶段没结束”时，报表不知道该按哪个口径结算。我的做法是两个字段都保留，互相独立，需要交叉分析时做关联查询。

3. 需求、缺陷、技术任务应该共用一套状态吗？

不建议完全共用。它们的流转逻辑不同：需求是”提出，评审，开发，测试，发布”，缺陷是”发现，确认，修复，验证，关闭”，技术任务是”排期，执行，完成”。

但阶段字段可以共用，因为它们最终都要落到同一套交付阶段里。所以我的结构是：阶段统一，状态按工作项类型分别定义。

4. 团队不更新状态怎么办？

先别急着培训，先检查三件事：状态数量是不是超过 10 个；状态更新是不是需要点很多次；状态更新对个人有没有明显收益。

我的经验是，这三件事解决之后，更新率自然上升。如果还不行，再加一条：把状态数据接入团队自己的迭代看板，让不更新状态的人看到自己的任务排序是错的。用个人收益驱动，比用制度约束有效得多。

5. 历史数据要不要迁移？

取决于你要不要做趋势分析。如果只需要看当前状态和最近两个迭代的数据，可以不迁移历史，但要在报表上明确标注”数据起始时间”，避免误读。

如果要分析半年以上的交付周期趋势，就必须迁移，而且要先做字段映射校验。我在多个项目里见过迁移后数据断层的情况，通常都不是迁移工具的问题，而是旧状态到新状态的映射规则没确认清楚。

九、总结与下一步

回到最初那个 27 列看板的场景。我后来问那位项目经理，为什么要设这么多状态。他说：”每个状态都对应一个我需要知道的情况。”

这句话其实点出了核心矛盾：状态设计不是”我想知道什么”，而是”什么信息必须被结构化”。你想知道的信息可以有很多，但能长期维护的结构化信息是有限的。状态模型的本质，是在这个约束下做取舍。

这篇文章里我给出的几个核心判断，可以再收一次：阶段是容器，状态是位置，两者必须正交；每个阶段 3 到 5 个状态，全流程不超过 20 个；每个状态必须有可验证的准出条件；回退必须可记录、可归因；报表口径必须在设计阶段定死。

如果你现在就准备动手，我的建议是按这个顺序推进。

1. 先用一周时间，导出你们当前所有状态字段和过去两个迭代的流转数据，统计每个状态的实际使用率。
2. 按”停留时长小于 4 小时”和”经过比例低于 5%”两条规则，标出可以合并的状态。
3. 把阶段字段从状态字段里拆出来，逐一检验两者是否正交。
4. 为保留下来的每个状态写准出条件，要求可验证、可自动判断。
5. 加上回退次数和回退原因两个字段，先记录不强制归因。
6. 跑两个迭代后，用本文第四节的五个信号做一次反验，再决定是否需要二次调整。

如果你所在的是 100 人以上的中大型组织，并且同时有私有化部署和 Jira 历史数据迁移的需求，可以优先评估 PingCode 这类支持字段深度建模和迁移能力的平台，把状态模型一次性建对，比后面反复调整要省力得多。

最后提醒一句：状态模型是给人用的，不是给报表用的。任何一次状态调整，都应该先能回答”团队成员因此少做了哪件事”。回答不出来，就别改。