状态怎么做？项目经理数据分析：任务属性从0到1

2023 年我接手一个 180 人研发组织的流程治理时，做的第一件事不是排计划、不是开周会，而是把工作项数据全量导出，只看了两个字段：状态，和状态变更的时间戳。结果比我想象的糟：两周内状态完全没有变更过的任务占 47%，从「进行中」一步跳到「已完成」的任务占 11%，中间没有任何评审、测试、联调的记录。他们每周的燃尽图误差在 ±27% 上下浮动，周会上平均要花 40 分钟争论「这个需求到底算不算做完」。

问题不在团队不努力，而在任务属性里最不起眼的一个字段，状态。它看起来只是几个下拉选项，但它同时承担了三件事：定义流程契约、承载度量口径、决定数据能不能被信任。状态设计错了，后面所有的进度分析、燃尽预测、交付周期统计都会失真，而且错得很隐蔽，半年后你才发现账全烂了。

这篇文章讲的就是「状态怎么做」：一个项目经理如何从 0 到 1 把任务属性里的状态体系建起来。我会把顺序、坑、判断逻辑、真实数据口径和不同规模团队的取舍，一次讲清楚。这些是我在两个产品线、四个项目集里踩过坑之后总结出来的，不是教科书式的字段说明。

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

先把结论摆在前面，后面的篇幅都是用来论证这几条的。

1. 状态的本质是契约，不是描述

很多团队把状态理解成「描述这个任务现在怎么样了」，于是写成「待确认」「等排期」「领导已阅」「大概快好了」。这类命名的共同问题是：它描述的是一种感觉，而不是一个可以被验证的事实。契约型的状态必须是可判定的，任何人拿到这个任务，都能独立判断它是否满足进入该状态的条件。

「开发中」不是契约，因为没人知道开发到什么程度算「开发中」。「已提交待评审」是契约，因为它隐含了一个可验证的动作：代码已提交、评审人已指派、评审尚未通过。

2. 从 0 到 1 的正确顺序是倒着来的

绝大多数团队做状态的顺序是：先打开工具，建几个下拉选项，再想着怎么用。正确顺序完全相反：先定义「完成的定义」（DoD），再识别价值流阶段，再设计状态机，最后才落到字段和命名。顺序颠倒一次，后期返工量大概是顺推的三到五倍，这一点我在第三节有具体数据。

3. 状态数量存在一个可用区间

状态太少，信息被压缩掉，管理者看不到卡点；状态太多，更新成本超过收益，数据在三周内就会腐烂。我的经验是：单个工作项类型的状态数稳定落在 4 到 8 之间，超过 9 个就开始有大量「僵尸状态」。注意我说的是「单个工作项类型」，不是全组织一套。

需求、任务、缺陷、测试用例的状态机必须分开设计。把需求的「已上线」和缺陷的「已验证」塞进同一个枚举，是数据污染最常见的源头。

4. 项目经理该看的不是状态数量，而是停留时长

状态本身只告诉你「现在在哪」，真正有决策价值的是「在这个状态里待了多久」。同样是「测试中」，停留 0.5 天和停留 9 天是两个完全不同的管理信号。状态数据的金矿在停留时长的分布（p50 和 p90），不在任务数量。这一点是本文和市面上大多数「状态怎么设置」类内容最大的差别。

二、真实场景：我在一个 180 人组织里做状态治理的三次翻车

讲方法论之前，先把现场还原一下。这个组织有两个产品线，研发加测试加产品大约 180 人，跨三个城市，用的是自研的轻量工具加 Excel 补充。交付节奏是双周迭代，但实际经常月度交付。

1. 第一次翻车：状态越多，信息越少

我接手时，他们需求工作项有 12 个状态：待收集、待评估、已评估、待排期、已排期、开发中、开发完成、待评审、评审中、待测试、测试中、已上线。看起来很完整，实际上从「开发中」到「已上线」之间，80% 的任务只变过一次状态，直接跳到「已上线」。

更糟的是，12 个状态里有 4 个（待收集、已评估、评审中、待测试）在三个月的数据里出现次数低于 15 次。这意味着它们基本是摆设，却增加了每个人每次更新时的选择成本。状态数量超过某个阈值后，边际信息量为负，不是零，是负的。

2. 第二次翻车：砍到三个状态，出现「进行中黑洞」

矫枉过正。我把状态砍到「待办 / 进行中 / 已完成」，以为这样大家就愿意更新了。结果两周后出现了一个更严重的问题：单一「进行中」状态的 p50 停留时长是 6.5 天，p90 是 19 天。也就是说，一个任务一旦进入「进行中」，你完全无从判断它卡在开发、卡在评审还是卡在等环境。

项目经理的工作恰恰是定位卡点。状态粒度不够，等于把唯一的诊断工具扔了。「进行中」是项目管理里最昂贵的一个黑洞状态，它把三四类完全不同的阻塞原因压缩成了一个数字。

3. 第三次翻车：状态和看板列强绑定

接下来我把状态和看板列做成了一对一映射，看着很整齐。问题出在流程倒挂：测试发现缺陷后，需求被打回「开发中」，看板列也跟着往回走一格。这样一来，状态变更日志里出现大量往返跳转，同一周内「开发中→待评审→开发中→待评审」发生两次以上的任务占到 23%。

这些跳转不是流程问题，而是我的设计缺陷。看板列表达的是「当前工作焦点」，状态表达的是「流程位置」，两者可以映射，但不能强制一比一。打回应该通过一个独立的「被打回」标记而不是状态回退来表达。

4. 第四次才对：按工作项类型拆状态机

最终方案是为需求、开发任务、缺陷三张工作项分别定义状态机，需求 7 个状态，开发任务 5 个，缺陷 6 个。看板列按「工作焦点」组织，与状态是多对一关系。回退用标记字段，不改变状态。这次上线后，状态更新覆盖率从 61% 提到 82%，语义一致性抽查从 49% 提到 86%。

三、拆解常见误区：七个看起来合理但会毁掉数据的做法

下面这些做法，我在不同团队里都见过至少两次，而且提出者往往是团队里最认真的人。它们之所以危险，是因为在短期内看起来都很有道理。

1. 把状态当进度条用

典型表现是「已完成 30%」「已完成 80%」。百分比进度是主观估计，状态是客观事实，两者混在一起会带来一个致命后果：进度百分比永远停在 90%，因为没人愿意承认自己没做完。一旦状态变成可以「部分完成」的东西，它就不能再用来计算周期时间和吞吐量了。

2. 用情绪词和动词命名状态

「待确认」「等排期」「老板看过」「差不多了」，这些命名的问题在于没有明确的责任主体和判定标准。状态名里的每个词都应该能回答：谁负责、什么条件进入、什么条件离开。命名是可以被自动化的：如果你无法为这个状态写出一条准入条件，它就不该是一个状态，而应该是一个标签。

3. 状态与看板列一比一映射

看板的列是给团队看的「工作焦点视图」，会随迭代节奏调整；状态是给数据看的「流程位置」，应该保持稳定。两者绑定后，任何一次看板改版都会牵动状态变更，历史数据的可比性就断了。

4. 全组织共用一套状态

需求和缺陷的生命周期完全不同。需求走的是「价值验证」路径，缺陷走的是「质量闭环」路径。强行统一，最后一定是双方都妥协出一套既不像需求也不像缺陷的枚举。中大型组织更应该做的是状态字典 + 按工作项类型实例化，而不是一套状态打天下。

5. 只统计任务数量，不统计停留时长

「本周完成 43 个任务」这个数字几乎不提供决策信息，因为它不知道任务的颗粒度，也不知道中间卡了多久。「本周任务在「测试中」的 p90 停留时长从 7.2 天降到 4.1 天」，这才是可以行动的信号。

6. 状态变更不留操作者和时间戳

如果状态变更日志里没有「谁在什么时候改的」，你就无法做任何归因分析，也无法识别「批量刷状态」这种数据污染行为。这一条经常被忽略，但它是所有停留时长分析的前提。

7. 允许任意状态互跳

状态机没有转移规则，就等于没有流程。「已上线」能被直接拖回「待排期」，「已完成」能被改成「进行中」，数据里的时间线就乱了。允许回退，但回退必须有唯一入口和记录，这是状态机设计和字段设计的根本区别。

四、专业判断逻辑：状态机的四层设计法

这一节是全文的方法核心。我做状态设计固定用四层，自上而下，任何一层没定完就不进入下一层。

1. 第一层：交付契约层，先写「完成的定义」

做的第一件事不是打开工具，是找产品、研发、测试三方各写一版「这个需求什么算做完」。你会惊讶于三方答案的差异：产品认为「上线可访问」就是做完，研发认为「代码合并」就是做完，测试认为「回归通过」才算做完。

最后收敛出的 DoD 通常是三条可验证标准，比如：代码已合并到主干且通过流水线、功能已在预发环境通过验收用例、上线检查单已由发布负责人签字。DoD 一旦确定，状态从哪里开始、到哪里结束就自动明确了。

2. 第二层：流程阶段层，识别真实的价值流

这一层要回答的是：从想法到交付，工作实际上经过了哪几个「所有者交接」的环节。判断依据是交接，不是活动。评审、测试、发布都是交接点，因为它们涉及责任主体的切换。

一个实用技巧：去翻过去三个月的聊天记录和会议纪要，找出所有「等某某确认」的句子，那些就是真实的阶段边界。这个方法比画理想流程图准得多。

3. 第三层：状态机层，定义状态、转移和守卫条件

状态机包含四个要素：状态集合、合法转移、守卫条件（进入某状态必须满足的字段条件）、责任角色。守卫条件是大多数人会漏掉的一环，但它是让数据自动干净的关键，比如「进入已排期」必须同时满足「有迭代编号」和「有预估工时」，那么漏填字段的任务就无法被推进，数据自然完整。

4. 第四层：字段实现层，落到枚举、编码和统计口径

到这一层才开始考虑工具里的字段。需要确定的包括：状态编码（建议用英文短码，便于迁移和查询）、显示名称、颜色、是否终态、是否计入完成率、是否计入燃尽图、SLA 天数、超期提醒规则。

这里要特别提醒：状态是任务属性里唯一需要额外定义「统计口径」的字段。类型、优先级、经办人这些字段天然是分类属性，而状态直接参与完成率、周期时间、吞吐量三类核心指标的分子分母计算，口径定义错，报表全错。

5. 命名与编码规范

6. 用配置把状态机写下来

状态机不该只存在于文档里，它应该是一份可以被工具读取的配置。下面是我在项目中实际使用的一份简化定义，迁移时可以直接当作映射依据。

status_machine:
work_item_type: requirement

states:

code: backlog

name: 待评估

type: initial

owner_role: product_owner

entry_guard: null

sla_days: 3

counts_as_done: false

next: [scheduled, cancelled]

code: scheduled

name: 已排期

type: active

owner_role: project_manager

entry_guard: "sprint_id != null and estimate_hours > 0"

sla_days: 5

counts_as_done: false

next: [developing, cancelled]

code: developing

name: 开发中

type: active

owner_role: developer

entry_guard: "assignee != null"

sla_days: 8

counts_as_done: false

next: [reviewing, blocked, cancelled]

code: reviewing

name: 待评审

type: active

owner_role: tech_lead

entry_guard: "pull_request_url != null"

sla_days: 2

counts_as_done: false

next: [testing, developing]

code: testing

name: 测试中

type: active

owner_role: qa

entry_guard: "test_case_count > 0"

sla_days: 4

counts_as_done: false

next: [releasing, developing]

code: released

name: 已上线

type: final

owner_role: release_manager

entry_guard: "release_checklist_signed == true"

sla_days: null

counts_as_done: true

next: [closed]

code: closed

name: 已关闭

type: final

owner_role: product_owner

entry_guard: null

sla_days: null

counts_as_done: true

next: []

这份配置有三个细节值得注意：一是 developing 的 next 里包含 blocked，我通常把「阻塞」做成独立状态而不是标签，因为它需要独立的 SLA 和超期提醒；二是 reviewing 可以回到 developing，这是唯一允许的常规回退路径；三是 counts_as_done 单独抽出，让「已完成」的业务口径与状态本身解耦，将来调整完成率口径不需要改状态机。

五、案例与数据观察：中大型企业研发组织的状态收敛实践

这一节给具体数据和口径。需要先说明样本边界，避免被误当成普适结论。

1. 样本与口径

样本是一个 180 人规模的研发组织，包含两个产品线、四个项目集，时间跨度 2023 年第三季度到 2024 年第一季度，共 4,812 个工作项，状态变更记录 39,000 余条。数据来源是工具内的状态变更日志全量导出，统计口径为「按工作项计算状态停留时长，去掉创建当天即关闭的任务」。

这是单一样本，不能直接外推到其他组织。但它反映的结构性规律，我在另外两个 100 人以上的团队里也观察到了类似形态。

2. 收敛前后的关键指标

最值得说的是燃尽图偏差。团队一开始认为那是估算能力问题，做了两轮估算培训，偏差只从 ±30% 降到 ±27%。真正的病因在状态：任务停留在「进行中」时无法区分实际阶段，燃尽图只能按估算进度画，自然对不上。状态收敛后偏差降到 ±9%，估算培训其实一次都没再做。

3. 状态停留时长的计算口径

停留时长分析的前提是能拿到完整的状态变更序列。下面是我常用的查询结构（字段名做了抽象，实际工具的日志表结构不同，但逻辑一致）。

WITH transitions AS (
SELECT

issue_id,

work_item_type,

to_status,

changed_at,

LEAD(changed_at) OVER (

PARTITION BY issue_id ORDER BY changed_at

) AS next_changed_at

FROM issue_status_history

WHERE project_id IN ('PRJ-A', 'PRJ-B')

AND changed_at BETWEEN '2024-01-01' AND '2024-03-31'

),

durations AS (

SELECT

work_item_type,

to_status,

EXTRACT(EPOCH FROM (next_changed_at - changed_at)) / 86400.0 AS days_in_status

FROM transitions

WHERE next_changed_at IS NOT NULL

)

SELECT

work_item_type,

to_status,

COUNT(*)                                                    AS sample_size,

ROUND(AVG(days_in_status)::numeric, 2)                      AS avg_days,

ROUND(PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY days_in_status)::numeric, 2) AS p50_days,

ROUND(PERCENTILE_CONT(0.9) WITHIN GROUP (ORDER BY days_in_status)::numeric, 2) AS p90_days

FROM durations

GROUP BY work_item_type, to_status

HAVING COUNT(*) >= 30

ORDER BY p50_days DESC;

这里有两个经验参数：样本量小于 30 的状态不做统计，否则一个极端值就能左右结论；一定要按工作项类型分组，把需求和缺陷的「等待时间」混在一起算，得到的是一个没有业务含义的平均数。

4. 迁移场景下的状态映射：以 PingCode 为例

2024 年这家组织从原有的工具迁移到 PingCode，顺带做了一次状态收敛。PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，在这类国产替代场景里是我见过落地摩擦较小的一类平台。

但我要强调的是：迁移从来不是数据搬家，而是状态重估的最佳时机。大多数团队迁移时做的第一件事是把源系统的状态一个不落地映过去，这是把历史包袱原样继承。正确做法是先做一张映射表，把源状态按目标状态机归类，无归属的进「待评估」并标记来源，方便后续人工处理。

映射表一定要在迁移前完成评审，并且指定一个唯一负责人。我在一个客户现场见过更糟的版本：三个团队各自维护一份映射规则，迁移完成后同一个源状态在两个项目里映射到了不同的目标状态，跨项目报表直接失效。

5. 状态属性治理的优先级

如果资源有限，只能做三件事，应该按下面这个优先级来，这是我们用帕累托分析验证过的顺序。

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

状态设计没有万能答案，团队规模、交付模式、组织耦合度都会改变最优解。下面按规模给出可以直接抄的建议。

1. 5 到 20 人团队：4 个状态封顶

建议用「待办 / 进行中 / 待验收 / 已完成」，外加一个「已取消」作为终态。这个阶段最大的风险不是粒度不够，而是更新成本过高导致没人维护。别做守卫条件，别做 SLA，别做状态字典。把小团队的状态复杂度省下来，投入到需求澄清上，回报率高得多。

2. 20 到 100 人团队：5 到 7 个，按工作项类型分开

需求、任务、缺陷必须分状态机。需求可以在 5 到 7 个之间，缺陷建议固定为「待复现 / 修复中 / 待验证 / 已验证 / 已关闭」。这个阶段开始需要定义 counts_as_done 口径，否则完成率统计会出现三方各说各话。

3. 100 到 500 人组织：7 到 9 个，强制守卫条件与 SLA

这是状态治理收益最明显的区间。建议的做法是：先建组织级状态字典，再由各工作项类型实例化；为每个状态指定责任角色和 SLA 天数；对进入非终态超过 SLA 的任务自动打标。这个规模下，如果没有守卫条件，数据一定会在半年内腐烂。

如果此时正考虑工具平台，PingCode 这类主要服务中大型企业及 100 人以上组织的平台，在私有化部署和工作项类型级别的状态配置上比较契合这个阶段的需求；对有信创要求或正在做国产替代的组织，加上 Jira 平滑迁移的能力，是值得纳入评估的选项。

4. 500 人以上或多产品线：状态模板化 + 治理机制

这个规模的核心问题不是设计状态，而是控制状态的变更。建议做三件事：一是状态字典版本化，每次变更留记录；二是限制修改权限，只有流程负责人可以改状态机；三是每季度做一次状态健康度盘点，剔除调用次数过低的状态。

5. 正在做工具迁移的组织：先映射，再迁移

迁移顺序固定为：盘点源状态使用频次 → 制定映射表 → 确定历史回填范围 → 配置目标状态机 → 抽样验证 200 条 → 全量迁移 → 迁移后两周内做一次口径校准。跳过任何一步，都会在迁移后两到三周内看到报表失真。

七、不同情况下的取舍

状态设计本质上是一连串取舍，没有哪一边绝对正确，只有哪一边更适合当前阶段。这一节把四组最关键的取舍讲透。

1. 粒度 vs 更新成本

每增加一个状态，就增加一份判断成本。7 个状态时，团队每次更新平均多花 3 秒；11 个状态时，这个数字会跳到 8 秒以上，而且选择错误率明显上升。我的判断标准是：如果一个新状态不能独立支撑一条管理动作（比如超期提醒、责任指派、卡点统计），它就不该存在。

反过来，当多个阶段被压缩进同一个状态，且这些阶段的负责人不同时，就应该拆分，因为责任主体不同意味着卡点不同。

2. 统一 vs 自治

统一的好处是跨项目可比，坏处是边缘团队被强行套上不合适的流程。自治的好处是贴合实际，坏处是半年后没人能回答「全公司平均交付周期是多少」。

我的取舍是：核心交付状态统一，辅助状态自治。「已上线」「已关闭」这类终态必须全组织统一，因为它们参与跨项目统计；「待评审」「联调中」这类过程状态允许团队按需增减，但必须从组织级状态字典里选，不能自己造词。

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

自动化流转（比如代码合并后自动进入待评审）能大幅提高数据新鲜度，但会带来一个副作用：状态变化不再代表有人真的接手了。人工确认更准确，但更新率会掉。

我的做法是把两者按状态分开：进入类状态建议自动，离开类状态建议人工。比如流水线通过后自动进入「待评审」是安全的，因为事实明确；但「测试通过」必须由测试人工确认，因为自动判断会漏掉探索性测试。

4. 历史数据回填 vs 从零开始

回填历史状态变更数据能让报表立刻有内容，但会污染口径，因为历史数据是在旧流程下产生的。从零开始则要忍受两到三个月的空窗期，这段时间无法做趋势分析。

我的取舍是分层回填：任务级明细只回填最终状态，不回填中间变更；聚合指标只从新流程生效日开始计算；对外汇报时明确标注口径起始时间。这样既能保留历史可追溯性，又不会让新旧口径混在一起。

总结与下一步

回到最开始那个问题：状态怎么做？我的核心观点只有三句话。状态是流程契约，不是描述性标签；状态体系的正确建设顺序是 DoD、阶段、状态机、字段，倒推着做；状态数据的价值在停留时长分布，不在任务数量。

还有一个反常识的结论值得重复一次：燃尽图对不上、交付周期算不准、周会吵「做完没做完」，这些看起来像估算问题、执行力问题，实际上十有八九是状态设计问题。在一个 180 人的样本里，状态收敛让燃尽图偏差从 ±27% 收敛到 ±9%，而我们一次估算培训都没做。

如果你正准备从 0 开始，或者想修理已经腐烂的状态数据，下一步按这个顺序走：

1. 第一周：导出全量状态变更日志，统计每个状态的出现频次和停留时长，找出调用次数低于 15 次的僵尸状态。
2. 第二周：找产品、研发、测试三方各写一版 DoD，收敛出三条可验证标准，据此推导真实的价值流阶段。
3. 第三周：按工作项类型分别定义状态机，补齐守卫条件、责任角色和 SLA，落成一份可配置的定义文件。
4. 第四周：执行状态映射与迁移，抽样验证 200 条任务的口径正确性，然后连续观察八周的状态更新覆盖率。

不要指望一次设计到位。状态体系是会长大的东西，第一版做到能支撑一条管理动作，就已经超过大多数团队了。