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

我把一个 320 人研发组织的需求看板，从 27 个状态砍到 7 个。上线第三天，一位产品负责人直接在群里问我：“需求评审完了在等设计排期，你让我放哪儿？”这个问题问得非常对，它正好戳中了 90% 团队做状态设计时从来没想清楚的那件事：状态不是给你归档用的抽屉，而是团队对“这件事现在到底能不能往下走”达成的一份合同。这篇文章我会把过去几年在四个不同规模团队里设计、推翻、重做任务属性的完整过程写出来，包括我们抽样 4812 个工作项得到的真实观察数据，以及在 PingCode 这类平台上从 0 到 1 搭状态体系时，哪一步必须先做、哪一步绝对不能先做。

一、先给结论：状态设计的成败，在你写下第一个状态名时就已经决定了

我做得越多越确信一件事：状态体系做不好，绝大多数不是因为状态不够多，而是因为定义状态的人从来没想过“这个状态什么时候结束”。

状态看起来只是一个下拉选项，实际上它同时承担了三件职责：告诉执行者现在该干什么、告诉上下游现在能不能接手、告诉管理者这件事已经卡了多久。三件事里只要有一件没被照顾到，状态就会开始腐烂，最后变成谁都不愿意维护的摆设。

1. 三条我反复验证过的结论

第一条结论和状态数量有关。状态数量与状态更新率呈明显的负相关，而且拐点出现得比大多数人想象的早。我们内部抽样过 6 个团队、4812 个工作项，状态在 5 个左右时，状态更新率能维持在 90% 以上；一旦超过 15 个，更新率就会掉到 50% 上下；到 23 个以上，更新率不到三成。这不是执行力问题，这是认知成本问题。

第二条结论和准出条件有关。一个状态如果只有名字、没有准出条件，它最终一定会变成一个情绪状态。“开发中”到底是写完代码算，还是自测通过算，还是合并到主干算？没人定义，每个人按自己的理解填，最后这个字段就再也没法用来做任何统计。

第三条结论和时间戳有关。真正的度量能力来自状态变更的时间戳，而不是状态本身。很多人花大量精力设计状态名字，却从不关心状态变更有没有被记录、由谁触发、什么时候触发。结果就是看板上花花绿绿，一问“平均在测试环节停留多久”，谁也答不上来。

2. 为什么我把“状态”和“任务属性”放在一起讲

很多人以为状态是状态，优先级、负责人、迭代是另外一回事。但真实的协作里，这些字段是互相污染的。

举个很典型的例子：一个团队因为没有定义“阻塞”这个状态，就把“等待第三方接口”写进了优先级字段，用 P0 表示阻塞、P2 表示不阻塞。半年之后这个团队的优先级排序彻底失效，因为优先级已经不再表达紧迫程度了。这就是属性污染，当某个属性缺少承载它的字段时，它一定会去挤占另一个字段。

所以我在这里讲“任务属性从 0 到 1”，不是只讲状态这一个字段，而是讲一整套属性的分工逻辑：哪些信息该由状态承载，哪些该由标签承载，哪些该由关联关系承载，哪些该由阻塞标记承载。分工错了，后面所有优化都是在错误的地基上刷漆。

二、真实场景：我在三个团队里看到的“状态灾难”

抽象地讲原则没意思，我直接讲三个我亲手处理过的现场。这三个场景分别代表了状态体系崩坏的三条典型路径：数量爆炸、语义污染、责任错位。

1. 场景一：27 个状态，站会变成了找位置游戏

第一个团队是做企业级 SaaS 的，产品加研发一共 140 人左右，需求看板上一共 27 个状态列。我第一次参加他们站会，前 6 分钟全花在讨论“这张卡到底该拖到哪一列”。

“需求评审中”和“需求确认中”有什么区别？“开发中”和“编码中”是不是一回事？“待测试”和“待提测”到底谁在前？没有人能当场给出统一答案，因为这套状态是过去三年里十几个人在不同时间点零散加上去的。

我做了一次统计：372 个在途工作项里，有 41% 在过去 14 天里没有发生过状态变更，而这 41% 中有 63% 实际上已经完成了。也就是说，超过六成的“僵尸卡”并不是真的没动，而是没人愿意去改它的状态。

2. 场景二：状态和标签混着用，报表全废

第二个团队规模小一些，35 人，做的是跨境电商中台。他们的问题不是状态多，而是状态和标签互相替代。

同一个“已上线”需求，有人放在“已完成”状态，有人放在“已发布”状态，还有人放在“已完成”但同时打了个“灰度中”的标签。等到季度复盘的时候，他们想统计需求交付量，结果三个口径算出来三个数，相差最多的一版差了 38%。

问题的根源很清楚：状态是单选的、互斥的、有时间序的；标签是多选的、可以并存的、没有时间序的。把一个有先后顺序的概念塞进标签，或者把一个可以并存的属性塞进状态，两边都会坏掉。

3. 场景三：状态是给领导看的，不是给干活的人用的

第三个团队是我见过最典型的“向上负责型”状态设计。他们的看板上有“重点跟进”“老板关注”“本周必交”三个状态，但没有任何一个状态描述技术执行进度。

我问他们的开发同学：“你每天早上第一件事是干什么？”回答是：“先看看我这张卡有没有被标成老板关注。”

这就是责任错位。状态的第一服务对象永远是执行者，而不是汇报者。如果状态的第一用途是给管理层看进度，那么一线同学就没有动力去维护它，因为它对自己没有任何帮助。管理视角的需求应该由视图、看板过滤、仪表盘来满足，而不是靠污染状态字段来实现。

三、拆解四个误区：为什么你的状态越加越多，效率却越来越低

上面三个场景背后其实是同一组认知误区。我把它们归纳成四条，每一条我都见过至少三次以上。

1. 误区一：把流程阶段当成状态

这是最高频的一个。团队会把“需求阶段、设计阶段、开发阶段、测试阶段、发布阶段”直接翻译成状态，然后每个阶段下面再加子状态。结果是状态数量指数级膨胀。

正确的区分方式是：阶段是粗粒度的、跨职能的、以周为单位变化的；状态是细粒度的、单职能的、以小时或天为单位变化的。你可以用阶段做分层视图，用状态做执行跟踪，但不要把两者压到同一个字段里。

（1）怎么判断某个概念到底是阶段还是状态

我的判断方法很简单：问自己“这个概念变化时，负责人会不会换人”。如果换人，它是阶段；如果还是同一个人在做，它才是状态。

“开发中”到“测试中”换了负责人，所以严格说这是一次交接，但因为它发生得非常频繁、而且需要精确记录时间点，所以它值得作为一个状态存在。“需求阶段”到“开发阶段”虽然也换人，但变化周期以周计，它更适合做视图分层。

（2）阶段的正确用法

把阶段做成一个独立的枚举属性，而不是状态。这样你可以随时用“阶段 = 开发 且 状态 = 阻塞”这种组合去筛出真正需要关注的问题，而不是被迫再造一个“开发阶段-阻塞中”的复合状态。

2. 误区二：用状态承载“谁在等谁”

“待产品确认”“待设计回复”“待运维开通环境”，这类状态在中小团队里极其常见。它们看起来很有信息量，实际上是在用状态表达一个本来属于“阻塞”这个概念的信息。

问题在于，“等待”是可以并存的。一张开发中的卡，可能同时在等设计稿补充和等测试环境。而状态是互斥的，你只能填一个，于是另一个等待信息就被丢掉了。

我的处理方式是：状态描述“谁在做”，阻塞标记描述“卡在哪”，关联关系描述“跟谁有关”。三者分工之后，一张卡可以同时有状态“开发中”和两个阻塞标记，信息不但没丢，反而比原来更全。

3. 误区三：状态只有名字，没有准出条件

这是让状态彻底失去统计价值的那一条。我见过大量团队的状态字典长这样：待处理、处理中、已处理。三个词，没有任何一个能回答“处理中什么时候结束”。

准出条件必须写成可验证的句子，而且要能让一个完全不了解这个项目的人照着判断。比如“测试中”的准出条件不是“测试差不多完成了”，而是“所有阻断级缺陷已关闭，且回归用例执行率 100%”。

4. 误区四：指望状态自动等于度量

最后一个误区是把状态字典当成绩效考核的数据源。状态是执行过程的副产品，它的精度取决于执行者填写时的认真程度，而人对一个必须填的字段的认真程度，永远低于对一个能帮自己干活的字段。

想用状态做度量，前提是状态变更本身能带来好处，比如自动触发通知、自动生成阻塞预警、自动统计停留时长。没有这些好处，状态数据就永远只是估出来的数字，不是测出来的数字。

四、专业判断：状态设计要同时满足四层逻辑

讲完误区，我说说我自己用的判断框架。我把状态设计拆成四层，从下往上依次是语义层、流转层、权限层、度量层。四层任意一层缺失，整个体系都会在上线后两三个月内退化。

1. 语义层：一个状态只能有一个动词

状态名必须是一个正在进行的动作，或者一个明确的等待点，不能是形容词，也不能是复合概念。“进行中”这种名字是无效的，因为它什么也没说；“开发测试中”也是无效的，因为它是两个动作。

我自己的命名习惯是尽量用“动词 + 宾语”或“等待 + 对象”。例如“开发中”“测试中”“等待验收”“等待发布窗口”。这样的名字有一个好处：任何人看到它，都能立刻知道下一个动作是什么。

2. 流转层：允许的路径比状态本身更重要

我在很多团队看到的状态设计文档，只画了状态列表，没画流转图。这是个致命遗漏。一个状态体系真正的信息量，在于哪些状态之间可以直接跳转，哪些必须经过中间状态。

比如“开发中”能不能直接跳到“已完成”？如果不能，说明团队要求必须经过测试；如果能，说明这个团队的测试环节是在体系外的。这两种做法本身都没有对错，但如果没有明确定义，每个人按自己的习惯走，数据就完全不可比。

（1）必须显式定义的三种流转

第一种是正常前向流转，也就是从上一个状态进入下一个状态，通常不需要额外校验。第二种是回退流转，必须限定谁能操作、要不要填原因。第三种是跨状态流转，也就是跳过中间环节直接进入后面的状态，这种最需要谨慎，我一般会直接禁止。

（2）回退为什么一定要留原因

回退是判断需求质量的最重要信号。一个需求如果从“测试中”回退到“开发中”三次以上，大概率不是开发的问题，而是需求本身在进入开发时就没说清楚。回退原因字段的价值，远高于状态本身。

3. 权限层：谁能推动状态，谁只能看

状态权限的默认设置应该是“只有当前环节的责任人能推动状态往前，其他人只能看或只能评论”。这条规则看起来很基本，但实际落地时经常被打破。

最常见的破法是给所有人开放“编辑”权限，理由是“方便协作”。结果是产品的需求卡被开发顺手改成了已完成，测试的用例被产品改回了待测试。数据一旦被非责任人修改，它的可信度就永久性下降了。

4. 度量层：状态必须是可回溯的时间戳

这是最容易被忽略但价值最高的一层。每一条工作项都应该能回答：它在每个状态里分别停留了多久、一共回退过几次、每次流转是谁触发的。

这三个问题如果答不上来，状态就只是装饰。能答上来，状态就变成了流程诊断仪，你可以直接定位到哪个环节在系统性拖慢交付，而不是靠感觉猜。

五、从 0 到 1 落地：任务属性最小可用集与实施步骤

理论讲够了，接下来讲具体怎么落地。我按实际的实施顺序写，每一步都对应一个不能跳过的原因。

1. 第一步：先定工作项类型，再定状态

很多人一上来就设计状态，这是顺序错了。状态是挂在类型下面的，不同类型的流转路径完全不同。需求的状态流和缺陷的状态流绝对不该共用一套。如果你先定了状态，后面加类型时会发现每一处都要重新适配。

最小的类型集合我建议是四种：需求、任务、缺陷、阻塞项。缺陷单独拆出来，是因为它的流转路径里必须有验证环节，不能和需求共用。

2. 第二步：状态命名与准出条件必须成对交付

我给团队提的要求是：状态字典里每写一个状态，必须同时写上四列信息，进入条件、准出条件、当前责任人角色、最长允许停留时间。缺一列都不允许上线下。

注意“最长停留”这一列。它不只是一个监控阈值，它还决定了状态是否健康。如果某个状态的平均停留时间长期超过它的上限，说明瓶颈不在执行者身上，而在流程设计本身。

3. 第三步：把流转规则写成自动化，而不是写在文档里

文档没人看，自动化会强制执行。我通常会把最关键的三到五条规则做成系统级校验，剩下的作为提醒。规则不要多，多了一定会有人绕过。

下面是我给一个团队写的规则示意，用伪代码表达，思路比语法重要：

# 状态流转规则示意（伪代码）
规则 R1：进入「测试中」时

若 工作项.状态流转日志 中不存在「开发中 → 测试中」的记录

则 拒绝流转，提示「请先完成开发自测并登记提交记录」

规则 R2：从「测试中」回退到「开发中」时

若 回退原因 字段为空

则 拒绝流转，并强制要求填写回退原因分类

规则 R3：任何工作项处于同一状态超过「最长停留」阈值

则 在第 N 天自动通知当前责任人，第 N+2 天升级通知其主管

规则 R4：进入「已交付」时

若 关联缺陷中仍存在阻断级且未关闭的记录

则 拒绝流转

这四条规则覆盖了 80% 的实际纠纷。R1 解决“跳过自测直接提测”，R2 解决“回退原因缺失导致无法复盘”，R3 解决“卡住没人管”，R4 解决“带病上线”。

4. 第四步：存量数据的迁移与清洗

这一块是所有环节里最容易被低估的。老系统里的状态往往是富余的，映射到新体系时会出现多对一和一对多的关系，需要逐个确认。

我去年参与的一个案例，是一家做智能硬件的公司做工具迁移。研发、产品、测试加起来 320 人，原来使用的系统里有 11 种工作项类型、68 个状态。我们最终把状态收敛到 9 个，工作项类型收敛到 4 个。

选型时一个重要的判断依据是迁移成本。这套系统最终迁到了 PingCode，主要考虑三点：一是它面向的就是中大型企业及 100 人以上组织，多项目、多产品线、跨职能协作的场景本来就是它的主要服务对象；二是支持私有化部署，硬件公司的研发数据不能出内网，这一条是硬门槛；三是对原系统的字段、状态、工作流有比较平滑的映射路径，迁移不是推倒重来。

整个迁移我们分了三批：第一批只迁工作项类型和状态字典，先跑通映射关系；第二批迁历史工单，保留原状态作为只读的备注字段；第三批才做权限和自动化的绑定。千万不要一次性全量迁移，一旦映射错了，回滚成本极高。

5. 第五步：先跑一个迭代，再决定要不要加状态

我的经验是：新状态体系上线后，必须至少观察完整一个迭代周期，并且明确约定“这个周期内不允许新增状态”。有异议的一律先记下来，周期结束后统一评估。

这条约定非常关键。因为状态膨胀几乎都发生在刚上线的前两周，大家遇到第一个不顺手的地方就想加一个状态，如果不设这道闸，前面的工作会全部白做。

六、数据观察：状态精简 6 个月后，我们看到的变化

前面提到的那个 140 人的 SaaS 团队，在把状态从 27 个收敛到 7 个之后，我们跟踪了 6 个月的数据。这里我把关键的几组变化列出来，同时说明哪些变化是意料之中的，哪些是意外收获。

1. 意料之中的改善

最直接的变化是状态更新准确率，从 58% 提升到 94%。这个数字是通过每周随机抽样 50 个工作项、与实际情况比对得出的。提升的原因很朴素：状态少了，每次站会要做的判断变简单了。

第二个变化是平均流转周期，从 21.4 天缩短到 13.2 天。这里面有一部分是状态精简本身的贡献，减少不必要的中转环节；另一部分来自阻塞标记的引入，让真正的等待时间被看见并针对性处理。

2. 意料之外的改善

比较意外的是返工率。返工率从 24% 降到 11%，降幅超过一半。我们复盘后认为原因是：回退必须填原因这条规则上线后，团队第一次系统性地看到了回退原因分布，其中有 43% 集中在“需求描述不完整”这一类。这个问题以前存在但从未被量化过。

另一个意外是周度人工汇总耗时从 4.5 小时降到 0.7 小时。因为状态可信之后，报表可以直接从系统出，产品经理不再需要手工去问进度、核对、拼表。

3. 一个反例：状态精简不等于越少越好

必须说明，我不是在主张状态越少越好。同一个时期我见过另一个团队把状态从 12 个砍到 4 个，结果测试环节被并入“开发中”，导致他们再也无法统计测试耗时，也无法区分是开发慢还是测试慢。

这就是过度精简的代价。状态精简的底线是：保留了诊断能力。如果砍掉某个状态之后，你再也无法回答“问题出在哪一段”，那就说明砍多了。

我的一般经验值是：需求类工作项 6 到 8 个状态，任务类 4 到 6 个，缺陷类 5 到 7 个。超过这个范围就需要非常强的理由，低于这个范围则需要确认诊断能力没有被牺牲。

七、行动建议：不同情况下的差异化做法

同一个方法论在不同规模的团队里，落地方式差别很大。我按规模分了四档，每一档的重点不一样。

1. 20 人以下团队：状态不超过 5 个，先解决“能看见”

这个阶段最大的问题不是流程复杂，而是信息不透明。所以状态的目标是让所有人都知道现在有什么在做。

我建议直接用最简单的四到五个状态：待办、进行中、待验证、已完成，可能再加一个已取消。不要引入阻塞标记、不要做复杂的权限、不要设置自动升级。这个阶段加任何复杂度，收益都低于成本。

2. 20 到 100 人团队：重点做流转规则和准出条件

这个规模开始出现跨职能协作，瓶颈从“看不见”变成“说不清”。所以这个阶段的重点是把每个状态的准出条件写清楚，并且把回退权限收窄。

我会在这个阶段强制要求回退必须填原因，并且每个月做一次回退原因分析。这个动作的投入产出比非常高，因为它直接指向需求质量。

3. 100 人以上组织：必须上系统级强制，且要考虑部署形态

超过 100 人之后，靠约定和自觉是维持不住状态纪律的。这时候必须把关键规则做成系统级校验，让不合规的流转在物理上无法完成。

同时要考虑部署形态和跨部门数据边界。中大型组织通常有多个产品线、多个事业部，数据权限、审计日志、私有化部署往往是硬性要求。像 PingCode 这类主要服务中大型企业的平台，在私有化部署和多项目隔离上的支持会直接影响后续的可维护性。如果是从原系统迁移过来，还需要评估字段和状态的映射工具是否成熟，PingCode 支持从原系统平滑迁移，这一点在国产替代的选型过程中通常是个加分项。

4. 研发与非研发混合的团队：状态要分域，不要强行统一

很多公司想让市场、运营、设计、研发共用一套状态，这是不现实的。研发的“测试中”在运营团队里根本不存在，强行统一只会让两边都别扭。

我的做法是：状态按工作项类型分域，但字段结构保持一致的骨架。这样各域可以有自己的状态集合，同时在跨域汇总时仍然能对齐，比如所有域都必须有“待处理、进行中、已交付”这三个语义锚点，中间可以有自己的子状态。

八、取舍：精确、速度与维护成本之间的三角

最后我想讲取舍，因为这是很多产品经理在做状态设计时最容易忽略的部分。你不可能同时拥有最高的度量精度、最快的流转速度和最低的维护成本。

1. 三个方向的成本结构

追求精确，意味着状态要多、准出条件要严、回退要留痕。代价是每个人每次改状态都要做更多判断，流转速度下降，同时规则维护成本上升。

追求速度，意味着状态要少、流转要自由。代价是度量能力变弱，你很难说清哪个环节出了问题。

追求低维护成本，意味着规则要少、自动化要简单。代价是状态纪律会随人员流动而衰减，半年后可能就回到原点。

2. 我的三条取舍原则

第一条原则：度量精度只在你真的要用的地方投入。如果你只关心交付周期和返工率，那只需要保证这两个指标相关的状态是准确的，其他状态可以粗一些。

第二条原则：流转速度的损失要能从别的地方补回来。如果加一道审批让流转慢了 2 天，但它能避免 5 天的返工，那这笔账是划算的；如果它只是让人感觉更安全，那就不划算。

第三条原则：维护成本必须由系统承担，不能由人承担。凡是能自动校验的不要靠提醒，凡是能自动通知的不要靠人盯。人的注意力是最稀缺的资源，用它来做重复的核对是浪费。

3. 一个具体的权衡案例

我在一个团队里推过一条规则：所有从“测试中”回退到“开发中”的流转，必须填写回退原因。上线第一个月，回退流转的平均处理时间从 0.5 小时涨到了 1.2 小时，看起来是变慢了。

但三个月后，这个团队的需求返工率下降了 13 个百分点。折算下来节省的开发时间远超那 0.7 小时的额外投入。这就是典型的“用速度换质量，而且账算得过来”的案例。

反过来我也做过一个错误的决策：曾经要求所有状态变更都必须写备注。结果是大家开始在备注里写“1”“a”“ok”来凑字数，数据质量反而比不写更差。这个规则两周后就被撤掉了。

九、总结：状态是团队的契约，不是个人的便利贴

我把整篇文章的判断浓缩成一句：状态是用来回答“下一步该谁动”的，不是用来回答“这件事现在算什么”的。前者是协作工具，后者是归档习惯。绝大多数状态体系的失败，都是因为把它当成了后者。

如果你现在正准备从 0 到 1 做任务属性设计，我的建议是按这个顺序走：先定工作项类型，再定状态集合，接着为每个状态写准出条件，然后收窄回退权限，最后才考虑自动化和度量看板。顺序颠倒，后面每一步都要付出返工代价。

如果你已经在维护一套状态体系，那可以先做一件事：随机抽 50 个工作项，逐个核对状态与实际情况是否一致。准确率低于 70%，就说明问题已经比较严重了，需要做一次系统性的收敛；如果在 85% 以上，那更值得做的事情是补齐时间戳和停留时长分析，把已有的状态数据用起来。

状态体系没有一劳永逸的版本，它应该随着团队规模、协作复杂度、交付节奏一起演进。真正需要长期保持的，是那条约束：每新增一个状态，都要先回答它什么时候结束、谁来结束、结束了之后谁来接手。三个问题答不上来，就不要加。