状态怎么做？项目成员入门指南：任务属性从0到1

我在 2021 年帮一家 280 人的智能硬件公司做研发流程诊断，第一件事就是把他们的电子看板截图打印出来贴满一整面墙。四块看板，最长的一个有 19 列，最短的也有 11 列。项目经理很自豪地说：“我们把颗粒度做得很细。”

但当我随机抽了 100 个任务，统计它们最近一次字段变更时间时，结果很难看：63% 的任务在过去 14 天里没有任何字段变更，31% 停留在“进行中”的任务实际已经停摆，而项目经理手里那份“本周进度汇报”显示的却是整体完成度 68%。这两组数字之间的鸿沟，就来自状态设计的失败。

这篇内容我想把“状态”这件事从 0 讲到 1。不是讲某个按钮在哪里点，而是讲一个项目成员真正该懂的东西：状态为什么存在、怎么设计、什么情况下该少用、什么情况下必须多加一层，以及当你的团队从 10 人长到 300 人时，状态和任务属性该怎么跟着变。

我会用我真实参与过的团队改造案例、看板审计数据和一些踩过的坑来说明。如果你现在正被“看板列太多没人动”“状态填了但没人看”“周报数字和实际对不上”这三个问题困扰，这篇内容应该能帮到你。

一、先给结论：状态是责任交接点，不是进度条

1. 一个状态存在的唯一理由

我判断一个状态该不该存在，只问一句话：它能不能回答“现在轮到谁了”？如果回答不了，这个状态就是装饰品。

“进行中”能回答，轮到开发负责人。“待验证”能回答，轮到测试或验收人。“待处理”能回答，轮到排期的人。但“完成 50%”回答不了任何问题，它只回答“做了多少”，不回答“下一步谁接手”。

这是状态和进度最本质的区别。进度回答“完成度”，状态回答“交接棒在谁手上”。把两者混为一谈，是绝大多数团队状态设计崩盘的根本原因。

2. 状态的第一性原理：谁在等谁

我更喜欢用“等待关系”来理解状态。一个任务从提出到完成，本质上是在几个人之间、几个角色之间被推来推去。状态就是这条传递链上的节点，每次状态变更都意味着一次责任转移。

按这个逻辑去检查你的看板：每一条状态迁移的边，都应该对应一次明确的责任交接。如果一条边上没有交接发生，那这条边不该存在；如果一次交接发生了却找不到对应的边，那说明你缺了一个状态。

我见过最典型的问题不是状态太少，而是交接口缺失。开发写完了代码，直接点“已完成”，测试根本不知道有东西要验；或者是测试验完了，卡在“测试通过”没人负责发布。这两个缺口，用增加状态是补不上的，得先把责任人和完成准则定清楚。

3. 任务属性的三类分层

讲状态之前，得先把“任务属性”这个更大的筐分清楚。我把任务属性分成三类，三类属性的管理逻辑完全不同，混在一起谈就会乱。

• 标识类属性：标题、编号、任务类型、所属项目/模块、关联需求。作用是“让人找到它”，几乎不需要日常维护。
• 协作类属性：状态、负责人、协作人、评审人、关联任务。作用是“让人知道轮到谁”，必须实时更新。
• 度量类属性：优先级、预估工时、截止日期、故事点、实际耗时。作用是“让人判断先做哪个、做得怎么样”，更新频率低于协作类。

很多团队的病根是：把度量类属性的精度要求，强加到了协作类属性上。要求成员每天更新预估剩余工时，却没人维护状态和负责人，结果数据既不实时也不准确。

4. 从 0 到 1 的最小可行状态集

如果让我给一个从没设计过状态的团队一个起点，我会给这五个：待处理、进行中、待验证、已完成、已取消。三个流转态 + 两个终态，覆盖 80% 的研发场景。

“阻塞”我建议不要做成状态，做成标记。原因很简单：阻塞不是一个阶段，它是一个附加条件。任务在“进行中”同时被阻塞，和任务单纯在“进行中”，责任主体是一样的，都是开发负责人。把阻塞做成状态，会导致任务从“进行中”离开又回来，流转数据被切断，统计周期就失真了。

二、背景与真实场景：状态爆炸是怎么发生的

1. 一块 19 列看板的现场

回到开头那家硬件公司。我后来跟他们的一位资深开发聊，问他：“你每天移动几次任务卡片？”他想了想说，基本不动，除非项目经理在群里 @ 他。

我又问：“那你完成任务的时候，会一次性把卡片拖到底吗？”他说会，而且不只他一个人这么干。也就是说，看板上呈现的分布，是一种“批量补录”后的假象。你看到的不是实时状态，是每周五下午被人为拉齐的投影。

这就是状态爆炸的第一层代价：它不会让信息更丰富，只会让信息更不真实。

2. 状态爆炸的四个来源

我复盘过十几个团队，状态列从 5 个膨胀到 15 个以上，通常来自这四个来源，而且几乎都不是有意设计的。

1. 为一次事故加一列。线上出了个 bug，复盘结论是“缺了发布前检查环节”，于是加了一列“待发布确认”。半年后同类问题换个形态再出，再加一列。
2. 为一个人加一列。某位架构师说“代码我要先过一眼”，于是有了“待架构评审”。他调岗之后，这列还在，只是没人管。
3. 为汇报口径加一列。领导问“现在有多少在做”，团队答不上来，就在“进行中”后面又拆出“开发中”“联调中”“自测中”，试图让汇报更精确。
4. 照搬模板。从别处复制了一套配置，没人敢删，因为“删了万一以后要用呢”。

这四个来源有一个共同的错误假设：以为流程的问题可以靠增加状态解决。实际上状态只是描述流程的标签，它不能替代流程本身的约束。

3. 不同规模团队的真实差异

我经常被问：“我们团队 20 个人，到底几个状态合适？”这个问题没有单一答案，因为答案是跟着组织复杂度走的，不是跟着人数走的。

10 人以下的团队，沟通成本极低，抬头就能问，状态更多是给外部看进度的，3 到 4 个足够。30 到 100 人的单一产品线，跨职能协作开始出现，需要明确的交接点，5 到 7 个比较合适。

100 人以上、多产品线并行的组织，情况会变得不一样：状态要区分“工作流定义”和“项目内展示列”两个层次，否则每开一个新项目就要重新吵一次状态命名。这一点我后面会用它作为案例展开。

4. 为什么“填得越细”反而越不准

这背后有一个很朴素的机制：每次状态变更都是一次人工成本，而人的注意力是有限资源。当一次操作的成本低于收益时，人会主动做；当成本高于收益时，人会攒着批量做，或者干脆不做。

状态从 5 个增加到 12 个，看起来只是多了 7 次可能的点击，但成员需要额外判断的是“我现在到底属于哪个状态”。这个判断没有标准答案的时候，他会选择不判断。这就是为什么很多团队的看板，实际只有三种真实状态：没动、在动、被打回了。

三、拆解常见误区：五种把状态用坏的方式

1. 把状态当进度百分比

这是最普遍的一种。状态列表里出现“已完成 30%”“已完成 60%”，或者更常见的变体，用多个状态变相表达百分比：“开发中（一半）”“开发中（收尾）”。

问题不在于百分比本身不直观，而在于这个百分比是所有人的主观估计，且没有统一标尺。张三觉得写完主体逻辑就是 60%，李四觉得联调完才算 60%。两个人报出来的数字放在一起，管理者得到的是一个看起来精确、实际不可比的数。

我的做法是：进度百分比不进状态，进度量类属性。状态只回答交接，进度只放在有明确分母的地方（比如验收清单通过了几项、接口联调了几个）。没有分母的时候，宁可不报百分比。

2. 把状态当情绪标签

“遇到问题”“等别人回复”“待协调”“卡住了”，这些都不是状态，是求助信号。

把它们做成状态的后果是：任务一旦进入这些列，就不知道该由谁推动。因为“等别人回复”没有指明等谁，也没有规定等多久之后要升级。真正的解决办法是给这批卡片一个明确的负责人和超时升级规则，而不是给它们一列新的位置。

我的替代方案是：状态保持稳定，用一个“阻塞标记 + 阻塞原因 + 需要谁支持”的组合字段来表达。这样任务仍然停在“进行中”，责任主体不变，但所有需要关注的信息都被点亮了。

3. 状态只增不减

我做过一次统计，在 14 个团队的看板里，有 9 个团队的状态列在近一年内只增加过，没有删除过。新增的理由大多是“上次出问题是因为没有这一步”，而删除从来没被讨论过。

这是个典型的组织惯性：增加状态的收益是显性的、当下的，删除状态的收益是隐性的、未来的。所以没人愿意承担删除的风险。

我的做法是给状态设“保质期”：新增一个状态时，同时记录它的设立原因和预计复查时间（比如三个月后）。到期没被用到的，进候选删除清单。上面那家硬件公司，19 列砍到 6 列之后，项目经理第一次能在周会上准确说出“本周卡在哪一步”的分布。

4. 用状态代替属性

“待前端”“待后端”“待设计”“待运维”，这是把“谁负责”这件事塞进了状态。

这么做短期看很直观，长期看必然崩。因为岗位上的人会变，你不可能为每一次人员变动新增一列；而且同一个任务在“待前端”和“待后端”之间来回切，流转记录会碎成一段一段，统计不出真实的等待时长。

“谁负责”属于协作类属性里的负责人字段，不属于状态。状态只表达“处在流程的哪个阶段”，阶段和角色应该解耦。阶段可以固定，角色可以通过字段灵活指定。

5. 迁移没有约束

我见过有团队的任务从“待处理”直接跳到“已完成”，中间什么都没做；也见过从“已完成”被拖回“待处理”重新来过。允许任意跳转最直接的后果是，所有基于状态的度量全部失效。

状态迁移应该是有向的。哪些迁移允许、哪些迁移需要审批、哪些迁移必须填写原因，这三件事一定要显式定义。特别是“打回”这种反向迁移，必须要求填写退回原因，否则你不知道该改什么。

四、专业判断逻辑：状态和属性该怎么定

1. 三问法：谁推动、谁验收、卡住去哪

这是我在现场最常用的工具，比任何模板都好用。设计任何一条状态之前，先回答三个问题。

1. 谁推动？任务进入这个状态之后，谁有义务让它继续往前走。必须是一个具体角色，不能是“大家”。
2. 谁验收？这个状态的退出条件是什么，由谁确认满足。没有验收人的状态，任务会永远停在那里。
3. 卡住去哪？如果在这里卡超过预期时间，升级给谁、走什么机制。这条最容易漏，但恰恰是状态能不能活起来的关键。

三问任何一个答不上来，这个状态就不该建。我宁愿团队少一个状态，也不愿多一个没人负责的状态。因为没人负责的状态会吸引一批停滞的任务，让看板失去预警能力。

2. 状态命名用动词还是名词

我的建议是：用“待 + 动作名词”或“动作进行式”来命名，避免用形容词。“待处理”“进行中”“待验证”“已完成”都是好名字，因为它们隐含了“谁在等”或“谁在做”。

“高质量”“重要”“紧急”是坏名字，它们是判断而不是位置。判断应该放在优先级字段里，位置应该放在状态里。

还有一个小细节值得注意：状态名里的“待”字很重要，它明确了“在等别人”。而“中”字明确了“我在做”。这两个字的选择，实际上是在帮成员建立心智模型。

3. 完成准则先于状态名

我给团队做状态设计的顺序永远是：先写清每个状态的退出条件，再给它起名字。反过来做，就会陷入“这个名字听起来挺好但没人知道什么时候该进”的困境。

以“待验证”为例，退出条件应该写成可检查的清单：代码已合并到集成分支、自测用例全部通过、相关接口文档已更新、验证环境已部署对应版本。这些条件可以被逐条打勾，而不是靠感觉判断“差不多了”。

这里有个反常识的经验：退出条件越具体，状态数量反而越少。因为很多原本需要单独建列的场景，在写成退出条件之后就自然地合并了。

4. 属性必要性打分：决策用途是唯一标准

怎么判断一个任务属性该不该保留？我的做法是让它过一个简单的评分：这个字段最近三个月，支撑了多少次具体决策？

具体说是三个维度打分（1 到 5 分）：是否有人基于它做过排序决策、是否有人基于它做过资源分配、是否有人基于它做过复盘归因。三项总分低于 6 分的字段，进入观察期。

我用这个办法在一个 200 人的团队里，把自定义字段从 31 个精简到 9 个。精简掉的那 22 个里，有 17 个在近三个月内被填写的比例低于 12%，属于事实上的死字段。每一个无人使用的字段，都在稀释真正有用的字段的信噪比。

5. 流转数据要看哪几个指标

状态设计完之后，一定要用数据验证。我通常只看四个：状态停留时长中位数、逆向迁移占比、超期未更新率、交接等待时长。

前两个看流程质量，后两个看执行质量。特别是交接等待时长，它衡量的是“一个任务从上一个人手里交出去，到下一个人真正开始处理”之间的时间差。这个指标往往才是周期的主要构成部分，但大多数人只看“处理时长”。

我在一个案例里发现，某个团队的任务平均总周期是 11.4 天，其中实质处理时长只有 3.8 天，剩下的 7.6 天全在交接等待上。如果不把等待时间单独度量出来，优化方向会完全跑偏。

五、具体案例：一个 300 人组织的状态重构

1. 案例背景与初始问题

这家公司做企业级软件，研发加产品约 300 人，分成 5 条产品线。他们使用的就是 PingCode，配置了私有化部署，数据全在自己机房。这类中大型组织对数据主权和流程自主性的要求很高，私有化部署是他们选型的硬门槛。

他们的核心问题不是工具能力不够，而是配置失控。5 条产品线各自定义工作流，状态名从 8 个到 17 个不等。同一个“已完成”，在 A 产品线表示代码合并，在 B 产品线表示已经上线，在 C 产品线表示测试通过。集团层面想做交付度量时，数据完全对不上。

2. 重构的三步走法

我们花了六周，走了三步。

1. 第一步，建立统一的工作流方案。先收敛出一套 5 状态的标准流程，作为组织级方案发布，允许各产品线在此基础上增加差异状态，但不得修改标准状态的语义。
2. 第二步，做历史数据的状态映射。把 5 条产品线的 60 多个历史状态，逐一映射到标准状态上，一对多的合并、多对一的拆分都要写清楚。
3. 第三步，设置差异状态的审批与复查机制。新增差异状态需要说明用途和预计复查时间，避免再次失控。

这里最关键的是第二步。因为这家公司是从老系统迁到 PingCode 的，历史数据必须能平滑接上，否则统计口径会出现断层。PingCode 在 Jira 平滑迁移上有成熟方案，这次重构的状态映射也沿用了同样的思路：先建映射表，再导数据，最后做抽样校验。

3. 状态迁移映射表长什么样

映射表不能只写一对一，那是理想情况。真实数据里大量是一对多和多对一，必须显式标注合并策略，否则统计时会丢数据。

{
"migration_map": [

{ "source": "未开始",           "target": "待处理" },

{ "source": "已排期",           "target": "待处理" },

{ "source": "开发中",           "target": "进行中" },

{ "source": "开发中（一半）",    "target": "进行中" },

{ "source": "开发中（收尾）",    "target": "进行中" },

{ "source": "联调中",           "target": "进行中", "flag": "联调" },

{ "source": "等测试环境",       "target": "进行中", "flag": "阻塞", "blocked_by": "运维" },

{ "source": "测试中",           "target": "待验证" },

{ "source": "测试通过待发布",    "target": "待验证", "flag": "待发布" },

{ "source": "已上线",           "target": "已完成" },

{ "source": "已关闭",           "target": "已完成" },

{ "source": "需求取消",         "target": "已取消" },

{ "source": "重复提交",         "target": "已取消" }

],

"merge_rules": {

"一对多": "拆分为多个任务并通过关联字段绑定，保留父任务追溯关系",

"多对一": "合并到目标状态，原始状态名保留在历史记录字段中",

"校验口径": "迁移后按 5% 抽样，人工核对任务所属状态与流转链路是否合理"

}

}

这张表看着枯燥，但它决定了迁移之后你的历史数据能不能用。我见过太多团队迁移时只做了一对一映射，把找不到对应目标的状态一律塞进“待处理”，结果半年后做周期分析时发现数据完全失真。

4. 重构后的六项指标变化

重构完成后我们持续跟踪了三个月，六项指标的变化比较明显。

这里我想强调一点：重构后成员的操作次数下降了 58%，但数据质量反而提升了。这打破了很多管理者“填得越多越准”的直觉。真实情况是，填得少而确定，比填得多而模糊要准得多。

5. 关于规模化配置的一点经验

300 人规模的组织和 30 人团队，在状态配置上最大的差别是：前者需要区分“组织级工作流方案”和“项目级展示视图”两个层次。

组织级方案定义状态的语义和迁移规则，是全公司的公共语言；项目级视图决定这个项目组要看哪些列、怎么排序、怎么分组。前者要稳，后者要活。很多团队把这两层合在一起，结果要么是组织级僵化到项目组没法用，要么是项目组各自为政导致数据没法汇总。

在 PingCode 的配置里，工作流方案可以跨项目复用，这对多产品线组织的价值很直接，新增项目时不用从零开始吵状态命名。它支持私有化部署，也支持从 Jira 平滑迁移，对于需要统一治理又要保留项目灵活度的中大型组织，这套机制是比较贴合的。

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

1. 10 人以下小团队：先定三个，别急着细

这个阶段我的建议非常明确：用“待处理 / 进行中 / 已完成”三个状态起步，最多加一个“待验证”。不要设计自定义字段，不要做多级审批。

理由是这个阶段团队的沟通带宽充足，任何状态看不出来的信息，喊一声就解决了。此阶段增加状态带来的信息增益极低，但对新人的学习成本很高。

这一阶段真正该做的是把任务标题写清楚、把负责人指定清楚。我见过太多小团队，状态设计得比大公司还复杂，结果每天花在维护看板上的时间比写代码还多。

2. 30 到 100 人的单一产品线：把交接点补全

这个阶段会出现一个典型症状：开发和测试之间的交接，靠的是口头通知或群消息。结果就是测试资源被临时打断，开发以为已经交出去了，测试以为还没轮到。

我的建议是补齐“待验证”这个状态，并且明确规定：任务进入“待验证”必须满足一组可检查的退出条件，进入之后由测试或验收人负责推进。

同时建议增加一个轻量的“打回”机制，任务从“待验证”退回“进行中”时必须填写原因。这个机制跑三个月，你就能拿到一份真实的缺陷来源分布。

3. 100 人以上多产品线组织：分层治理

这个规模下，我的建议是把状态治理拆成两层，并且明确各层的决策权限。

组织级负责统一状态语义、迁移规则、终态定义；项目级负责选择展示列、排序方式、是否启用差异状态。差异状态需要说明用途和复查时间。

这套机制在 PingCode 这类支持工作流方案复用的平台上是比较容易落地的，因为标准方案可以跨项目继承，差异部分在项目内单独维护，两边不冲突。对于 100 人以上的组织，选型时建议重点考察“工作流方案能不能跨项目复用”和“差异是否可控”，这比功能数量重要得多。

4. 强合规或交付型团队：拆出独立的验收状态

硬件、金融、医疗、政企交付类团队，往往有外部审计或合同验收要求。这类团队我建议在标准流程之外，单独拆出“待验收”和“验收中”两个状态，并且把验收人设为独立角色。

但要注意，这两个状态必须和“待验证”区分开：待验证是内部质量确认，待验收是外部或合同层面的确认。两者责任主体不同、退出条件不同，混在一起会导致内部的测试责任和外部的交付责任分不清。

七、不同情况下的取舍

1. 精细化与填报成本之间的取舍

这是最根本的一组取舍。我的判断标准是：当一次额外填报能支撑一次具体决策时，这个成本值得付；当它只是为了“以后可能会看”时，不值得。

具体怎么判断？我会问三个问题：谁会在什么场景下看这个数据？看到之后会做什么不同的事？如果这件事不做会有什么后果？三个问题答不上来两个，这个字段就先不加。

我在前面的案例里把自定义字段从 31 个砍到 9 个，砍掉的字段没有一个被重新加回来。这说明大部分“以后可能会看”的数据，其实永远不会被看。

2. 统一状态方案与项目自治之间的取舍

统一的收益是数据可比、新人上手快、跨团队协作顺畅；代价是项目组可能觉得“不符合我们的实际情况”。自治的收益是灵活、贴合；代价是组织级数据永远对不上。

我的建议是在 100 人以下优先自治，在 100 人以上优先统一语义、放开展示。因为规模越大，跨团队数据对齐的价值就越高，而单个项目的展示偏好其实并不值得为此牺牲全局可比性。

还有一个折中做法值得考虑：把状态分成“核心状态”（必须统一）和“扩展状态”（项目可自定），核心状态用于组织级度量，扩展状态仅用于项目内部流转展示。

3. 私有化部署与 SaaS 之间的取舍

这组取舍在 100 人以上的组织里几乎一定会遇到。私有化部署的收益是数据主权、内网访问、可深度定制、满足合规要求；代价是运维成本、升级节奏慢、需要自有 IT 能力。

SaaS 的收益是开箱即用、迭代快、免运维；代价是数据在外部、定制空间受限、部分行业可能不满足合规要求。这里没有标准答案，但有一点需要提醒：私有化部署的隐性成本主要在升级和故障响应上，评估时要把这部分人力算进去，不能只算服务器成本。

4. 迁移与重建之间的取舍

很多团队在做工具切换时都会纠结：是把历史数据搬过去，还是干脆新开一套重新开始。

我的经验是：如果历史数据要用于趋势分析或合规审计，必须迁移；如果只是存档备查，可以只做归档不迁入主流程。迁移的成本主要不在数据搬运，而在状态映射和校验，这部分工作量经常被低估。

需要平滑迁移的场景，建议优先选择有成熟迁移方案的平台。比如 PingCode 支持从 Jira 平滑迁移，在状态映射、字段对应、附件与评论保留这些环节都有现成机制，能显著降低迁移过程中的口径断层风险。但即便工具有支持，映射表本身仍然必须由业务方来定，这件事没有工具能替代你完成。

八、从 0 到 1 的行动清单

1. 第一周：先做审计，别急着改

把你当前的看板列出来，逐列问三个问题：谁负责推进、退出条件是什么、卡住之后升级给谁。三个都答上来的保留，答不上来的进观察清单。

同时统计一下每个状态的停留时长和逆向迁移占比。这两个数字能立刻告诉你，哪几个状态是真正的瓶颈，哪几个只是装饰。

2. 第二周：砍到最小可用集

根据审计结果，把状态收敛到 5 到 7 个。把“阻塞”“紧急”“待前端”这类信息从状态里挪出去，改成标记或字段。砍的时候要有心理准备，一定会有人反对，理由通常是“万一以后要用”。这时候回问他一句话：过去三个月，这个状态被用到过几次？

3. 第三周：写清退出条件

给每个保留下来的状态写清退出条件，要写成可以逐条打勾的形式，而不是“差不多了”“基本完成”这种模糊表述。退出条件写完之后，再回头检查一遍状态名是否还合适。

这一步做完，你会发现有些状态可以进一步合并。这是正常现象，说明你之前的状态划分是基于角色而不是基于流程阶段。

4. 第四周开始：跑数据，持续复查

改造完成之后不要就此结束。我的建议是连续跟踪三个月，看四个指标：状态停留时长中位数、逆向迁移占比、超期未更新率、交接等待时长。

这四个指标里，交接等待时长最能说明问题。如果它在总周期里的占比超过 40%，说明你的问题不在个人效率上，而在交接机制上，这时候再优化状态名已经没用了，得去看排期和交接规则。

5. 三个可以立刻用上的判断原则

• 状态只回答“轮到谁”，不回答“做了多少”。所有百分比、进度感、完成度的表达，都往度量类属性里放。
• 每个状态都必须有唯一责任主体。找不到责任主体的状态，无论看起来多有道理，都不该建。
• 状态数量的上限由交接点数量决定，不由流程细节决定。一次真实的责任交接才对应一条状态边，其他的都只是描述。

回到最开始那家 280 人的公司。他们的看板从 19 列收到 6 列之后，最大的变化不是效率数字，而是周会时间从 90 分钟压到 35 分钟。项目经理说了一句话我记到现在：“以前我们要花一半时间讨论卡片为什么没动，现在直接讨论下一步该谁动。”

这大概是状态这件事最朴素的价值：它不让你管得更多，而是让你一眼看出谁该动。

如果你现在正准备从 0 开始设计状态，我的建议是先从你手上正在做的三个真实任务开始，用“谁推动、谁验收、卡住去哪”这三问过一遍。三个任务都过不了，就先别急着改整个看板，把这三个改对，比画一整套漂亮流程图有用得多。