去年我帮一家 300 多人的研发组织做流程复盘，会上出现了这样一幕：三个人对同一个需求的描述分别是"在做了""快好了""已经提交测试"。打开工具一看，状态字段写的是"进行中"。真实情况是，这个需求卡在前后端联调，后端说自己做完了，前端说接口还没对上，测试说根本没收到提测包，产品经理认为今天就能上线。一条状态，三个人的理解差了两周的工作量。
这不是个例。我在过去几年里接触过几十个研发团队，从十几人的创业小队到上千人的中大型组织，几乎每一家在"任务状态到底怎么设"这件事上都踩过坑。有的团队状态有 14 个，结果没人按规则流转；有的团队只有"待办 / 进行中 / 完成"三个状态，结果所有卡点都被埋在"进行中"里看不见；还有的团队状态定义得很漂亮，但属性字段一个没配，导致月度复盘时连"这个需求是谁提的、属于哪条产品线"都查不出来。
这篇文章我想把这件事拆到底：任务状态和任务属性从 0 到 1，到底该怎么设计。我不会给你一套万能模板，因为不存在。我会告诉你判断逻辑、常见误区、不同规模团队的取舍，以及我真实观察到的数据变化。
一、核心结论：状态不是进度条，是流程的压缩
先把结论放在前面，后面所有内容都是围绕这几条展开的。
第一条，状态是流程的压缩，不是进度的百分比。很多团队把状态当进度条用，设了"完成 30%""完成 60%""完成 90%"这种状态。这是根本性的错误。进度百分比是同一件事的不同完成度，而状态是流程中性质不同的阶段。开发中和测试中，不是"完成度不同"，而是责任主体变了、准入条件变了、产出物变了。把性质不同的阶段和程度不同的阶段混在一起，状态机就废了。
第二条，属性分三层，不要混着管。流程属性（决定任务在流程里怎么流动）、分类属性（决定任务属于谁、归到哪）、度量属性（决定复盘时能算出什么）。大部分团队只配了分类属性，然后在复盘时抱怨数据不够用。
第三条，每个状态必须回答三个问题。谁有权把它推进来？推进来的准入条件是什么？推进去之后触发什么动作？三个问题答不上来的状态，就是多余的。
第四条，状态数量有隐性上限。我给中大型研发团队做诊断时，观察到一个比较稳定的规律：状态超过 8 个之后，流转准确率会明显下滑。这不是审美问题，是认知负荷问题。
第五条，从 0 到 1 的正确顺序是：先画流程，再定状态，再配属性，最后落工具。反过来做的团队，90% 会在半年内重来一遍。
二、背景和真实场景：为什么研发团队一到"状态"就卡住
要理解状态设计为什么难，得先看清楚它难在哪里。我发现大部分团队的困境不是"不知道怎么设状态"，而是不同角色对状态的心智模型天然不一致。
1. 三个角色，三套状态心智
产品经理关心的状态是"这个需求有没有被承诺、什么时候能上线"。开发关心的状态是"我手上这个活能不能开工、依赖解决了没有"。测试关心的状态是"提测包到了没有、我能不能开始验证"。
这三套心智没有谁对谁错，但它们指向的是不同的切分点。产品经理希望状态里体现"排期确认"这个节点，开发希望体现"依赖就绪"这个节点，测试希望体现"可测"这个节点。如果状态设计只听取其中一方意见，另外两方就会用自己的方式"打补丁"，在标题里加前缀、在备注里写暗号、在群里口头同步。
我见过一个团队，状态字段形同虚设，因为所有人都在用任务标题的前缀来标记真实状态，比如"[联调中]""[待验收]""[已废弃]"。工具里的状态字段，反而成了一个装饰。
2. 状态混乱的三类成本
第一类成本是调度成本。管理者无法从看板上判断真实瓶颈在哪，只能靠问人。一个 80 人的研发团队，技术负责人每周花在"问进度"上的时间大约是 4 到 6 小时。这不是他能力问题，是工具没给他可读的信号。
第二类成本是协作成本。上下游之间的交接点不清晰，导致"我以为你会做"和"我以为你会通知我"反复发生。测试等开发、开发等设计、设计等确认，每一环都在等，但每一环都不知道自己在等。
第三类成本是复盘成本。一个迭代结束后想做复盘，发现算不出"需求平均在测试阶段停留多久""哪个环节返工最多"。因为状态定义里没有把环节切开，数据在源头上就丢失了。
3. 什么时机该做这件事
不是所有团队都需要一开始就认真设计状态。我的经验判断是，下面任意一条成立时，就该动手了：
- 团队规模超过 25 人，或者跨了 3 个以上职能小组，口头同步开始失效；
- 出现过两次以上因为状态理解不一致导致的交付事故；
- 月度或季度复盘时，发现算不出关键指标；
- 准备从某个工具迁移到另一个平台，正好借机会重构。
反过来，一个 8 人团队、一周一个迭代、创始人天天在场，这时候花两周设计一套 8 状态的状态机，是浪费。状态设计的复杂度应该匹配协作的复杂度。
三、拆解五个常见误区
这一节我讲的是我在真实项目里反复看到的错误。有些错误听起来很低级，但它之所以反复发生，是因为它背后有一套看似合理的推理。
1. 误区一：把状态当进度条
最典型的表现是设置"开发完成 50%""开发完成 80%"这类状态。推理是：这样管理者能看得更细。实际结果是：没有人能准确判断自己是 50% 还是 60%，于是所有人都在猜。
更严重的是，这种状态无法设置准入条件。什么叫"完成 50%"？无法验证，就无法约束，最后状态字段变成了填写者的主观感受。我建议的做法是，如果确实需要进度感知，用子任务完成度或工时燃尽来表达，而不是用状态。
2. 误区二：状态命名用动词
我见过"开发中""测试中""待评审""待确认"这类命名，也见过"开发""测试""评审""确认"这类命名。前者比后者好，但都不如用"阶段 + 状态"的复合命名清晰。
问题的核心在于，"测试中"这个词在中文里是歧义的：它可能指"正在被测试"，也可能指"正在测试别人的东西"。当团队里同时存在"测试工程师"和"测试环境"这些概念时，一个纯粹的动词或动名词状态名，会引入大量歧义。
我的建议是状态名尽量用名词化的阶段描述，比如"待提测""测试验证中""测试通过"，把主体和状态都表达清楚。
3. 误区三：属性字段越多越好
这是一个非常普遍的误区。团队在做流程规范化时，往往倾向于一次性把所有想得到的字段都加上：优先级、严重程度、需求来源、产品线、客户、版本、模块、关联需求、预估工时、实际工时、验收标准、影响范围……
结果是，字段填不满，数据反而更脏。因为一旦有人开始留空，后面的人就会觉得留空是可以接受的，整个字段的可信度就崩了。
我的判断标准很简单：一个属性字段，如果在过去两个迭代里没有产生过任何一次决策依据，就该删掉。属性不是用来"记录信息"的，是用来"支撑判断"的。
4. 误区四：状态流转权限人人都有
很多团队为了"不阻塞"，把状态流转权限开放给所有人。短期看效率高，长期看数据全废。因为状态流转本质上是一次责任交接，如果交接可以被任何人单方面完成，这个交接就没有约束力。
正确的做法是按状态定义责任主体：进入"测试验证中"只能由测试负责人操作，进入"已发布"只能由发布负责人操作。这不叫官僚，这叫接口清晰。
5. 误区五：先上工具，再想流程
这是最贵的一个误区。团队决定"我们要规范起来了"，于是先去采购或启用一个项目管理平台，然后花两周时间把工具里的默认状态改一改，就认为流程建好了。
结果通常是：工具里的状态和团队真实的工作流对不上，大家开始绕过流程。半年后推倒重来，还多了一堆历史脏数据要清理。
我的建议是，状态设计这件事，至少有一半工作量应该发生在打开工具之前。白板上画出流程图，比在工具里拖拽状态有效得多。
四、专业判断逻辑：状态机、属性、度量三件套
前面讲了问题和误区，这一节讲我实际使用的方法。核心是三个东西：状态机、属性体系、度量指标。它们不是并列的，而是有先后依赖的。
1. 状态机的四个要素
一个能被执行的研发任务状态机，必须把每个状态的四个要素写清楚。我通常用一个表格来定，团队一起过一遍，比读文档快得多。
| 要素 | 要回答的问题 | 典型错误 |
|---|---|---|
| 责任主体 | 谁有权把任务推进到这个状态 | 写成"团队"，实际没人负责 |
| 准入条件 | 满足什么条件才能推进 | 写成"做完了"，无法验证 |
| 产出物 | 推进时留下什么可检验的东西 | 无产出物，状态变成口头声明 |
| 下一跳 | 可以从这里流向哪些状态 | 允许任意跳转，等于没有流程 |
我把这套定义写成结构化的东西，放进团队文档里。下面是一个示例，你可以直接改成自己团队的格式：
{
"state": "待提测",
"owner": "开发负责人",
"entry_condition": [
"所有子任务状态为已完成",
"代码已合入主干且构建通过",
"自测用例执行完毕，通过率 100%"
],
"artifacts": ["构建号", "自测报告链接"],
"next_states": ["测试验证中", "已挂起"],
"auto_actions": ["通知测试负责人", "生成测试任务"]
}
注意 auto_actions 这一项。它是状态设计里最容易被忽略、但收益最高的一项。状态推进的价值不只是记录，更是触发下游动作。进入"待提测"自动生成测试任务并指派，比任何口头约定都可靠。
2. 属性分三层
我把任务属性分成三层，每层的目的不同，配置原则也不同。
（1）流程属性
决定任务在流程里怎么流动。典型的有：状态、阶段、阻塞标记、阻塞原因、优先级。这类属性的特点是直接影响下一步动作，所以必须配套准入条件和权限控制。
"阻塞原因"这个字段在国内团队里被严重低估。大部分团队只有"是否阻塞"的布尔值，没有阻塞原因枚举。结果复盘时只知道卡了，不知道卡在哪。我建议至少配 5 个枚举值：等依赖、等资源、等确认、等环境、等外部。
（2）分类属性
决定任务属于谁、归到哪。典型的有：所属产品线、所属模块、需求来源、负责人、所属迭代。这类属性的特点是用于筛选和聚合，配置关键在于枚举值的稳定性。
这里有个坑：很多团队把"所属模块"做成自由文本，结果半年后出现了"用户中心""用户模块""user-center""UC"四个写法。分类属性一律用受控枚举，不要用自由文本。
（3）度量属性
决定复盘时能算出什么。典型的有：预估工时、实际工时、缺陷密度、返工次数、首次响应时间。这类属性如果依赖人工填写，通常活不过三个月。
我的做法是，度量属性中至少有一半应该是系统自动产生的，比如状态变更时间戳、停留时长、变更次数，这些不需要人填，但能算出大量有价值的指标。
3. 度量指标必须挂回状态
这是我认为最关键的判断逻辑：如果你设计的状态支撑不了任何度量指标，那这些状态就是装饰。
设计状态之前，先问一句：我要用这些状态算出什么？常见的对应关系是这样的。
- "需求评审到排期确认"的时长 → 反映排期效率；
- "开发中到待提测"的时长 → 反映开发吞吐；
- "待提测到测试验证中"的时长 → 反映交接摩擦；
- "测试验证中到测试通过"的时长 → 反映质量水位；
- 状态回退次数 → 反映返工严重程度。
你会发现，这五个指标基本覆盖了研发流程诊断的主要维度。而它们能算出来的前提，就是状态里必须存在"排期确认""待提测""测试验证中""测试通过"这几个切分点。
4. 从 0 到 1 的四步落地
把上面这些东西组织成一个可执行的路径，我通常按四步走。
- 第一步，画真实流程。找产品、开发、测试各一位，各自画出"一个需求从提出到上线"经过哪些节点，然后把三张图叠在一起，标出分歧点。这一步通常需要 2 小时，但能暴露 80% 的问题。
- 第二步，定状态与准入条件。基于上一步的合并图，切出 5 到 8 个状态，每个状态写清责任主体、准入条件、产出物、下一跳。
- 第三步，配属性。先只配流程属性和最关键的 3 个分类属性，度量属性优先选系统自动产生的。宁少勿多。
- 第四步，落工具并设权限。把状态机配置到工具里，同时把状态流转权限按责任主体分配。然后跑三个迭代再回看。
第三步和第四步之间，我建议留一周时间做纸质或白板模拟：拿过去一个已完成的迭代，用新状态重新走一遍，看会不会卡住。这个过程能提前发现大量设计缺陷。
五、案例与数据观察：一个 300 人研发组织的状态重构
这一节我讲一个具体案例，包括数据变化和踩过的坑。
1. 背景与初始状态
这家公司大约 300 名研发人员，分成 6 个产品线小组，每个小组配产品、开发、测试。他们当时的任务状态有 11 个，分别是：待处理、已确认、设计中、开发中、自测中、待提测、测试中、测试通过、待发布、已发布、已取消。
听起来挺完整，但实际执行中出现了三个问题。
问题一是"已确认"和"设计中"之间没有清晰边界，导致同一个需求在两个小组里的状态不一致。问题二是"自测中"这个状态几乎没人用，因为开发习惯直接跳到"待提测"。问题三是状态流转权限全开放，测试人员可以自行把状态改成"测试通过"。
2. 重构后的状态机
重构时我们砍掉了"已确认"和"自测中"，合并了"测试中"的概念歧义，最终定为 7 个状态：
| 状态 | 责任主体 | 准入条件 | 关键产出物 |
|---|---|---|---|
| 待排期 | 产品负责人 | 需求已评审通过 | 需求文档定稿 |
| 已排期 | 开发负责人 | 已分配迭代与人力 | 任务拆分完成 |
| 开发中 | 开发负责人 | 任务已认领且有预估 | 分支与任务关联 |
| 待提测 | 开发负责人 | 构建通过且自测完成 | 构建号、自测记录 |
| 测试验证中 | 测试负责人 | 已领取提测包 | 测试用例执行记录 |
| 待发布 | 发布负责人 | 测试通过且无阻断缺陷 | 发布清单 |
| 已发布 | 发布负责人 | 生产环境验证通过 | 发布记录 |
注意这里的一个设计取舍：我们把"自测"从独立状态降级成了"待提测"的准入条件的一部分。因为"自测"本质上不是一个交接节点，它是开发者自己的内部状态，把它做成独立状态只会增加流转负担。
3. 数据观察
重构后跑了三个迭代，我记录了几个关键指标的变化。需要说明的是，这几个指标在重构前后都是可以算的，因为状态里保留了时间戳。
最显著的变化在"待提测"环节，从 4.1 天降到 1.3 天。原因是重构后"待提测"要求必须填写构建号，而且自动通知测试负责人。以前这个环节的等待是隐性的，没人知道一个任务已经躺在那里三天了。
状态回退率从 21% 降到 11%，主要来自两个改进：一是"待提测"的准入条件里加入了"自测用例通过率 100%"，二是"测试通过"不再由测试人员单独推进，需要同时附带测试报告链接。
4. 工具层面的选择
这家公司最终选择的落地平台是 PingCode。他们的评估过程我觉得有参考价值，简单说一下。
他们的核心诉求有三个：第一，需要状态机的准入条件能够配置成硬性校验，而不只是提示；第二，需要支持多产品线的状态模板复用，6 个小组不能各自为政，但也要允许局部差异；第三，需要数据能自己取出来做分析，不能只靠平台内置的报表。
他们最终选 PingCode 的原因，主要是它在状态流转规则配置和字段级权限上更贴近中大型组织的需求，同时 PingCode 支持私有化部署，这对他们有数据合规要求这一点是决定性的。另外他们之前用的是 Jira，PingCode 支持 Jira 平滑迁移，迁移过程中历史任务的状态映射可以自定义，这一点对保留历史数据的可用性很关键。
对于 100 人以上、有国产替代需求的研发组织，这是个值得放进备选清单的选项。当然，工具本身不解决流程问题，他们把状态机在白板上定了三轮，才动手配置。
六、不同情况下的行动建议
状态设计没有标准答案，但有清晰的匹配逻辑。我按团队规模和组织形态分成四类，给出具体建议。
1. 10 人以下的小团队
建议状态数：3 到 4 个。待办、进行中、已完成，如果需要，再加一个"阻塞"。
这个阶段不要设计复杂的状态机，因为沟通成本本来就低，一张看板就是全部流程。要重点做的是把"阻塞"这个状态用好，任何任务被标记为阻塞，必须填写阻塞原因，这是最小的数据纪律。
属性方面，只配三个：负责人、优先级、所属迭代。不要配工时，这个阶段的工时数据精度极低，统计出来反而误导决策。
2. 30 到 100 人的团队
建议状态数：5 到 7 个。这是最需要认真设计的区间，因为协作开始出现摩擦，但流程还没僵化。
我的推荐切分点是：待排期、已排期、开发中、待提测、测试验证中、已发布。如果需要，为紧急修复单独开一条轻量流程，但不要在主流程里加"热修复"状态。
这个规模要重点做两件事：一是把状态流转权限按角色收回来，二是在关键交接点设置自动通知。我观察下来，这两件事的投入产出比最高。
3. 100 人以上的中大型组织
建议状态数：7 到 8 个，并且允许产品线差异化。这个阶段的难点不是状态本身，而是多个产品线的状态定义如何既统一又可差异。
我的做法是分层：定义一套主干状态，所有产品线必须使用；再定义一套可选扩展状态，各产品线按需启用但必须登记。这样既保证了跨产品线的数据可比性，又保留了局部灵活性。
这个阶段一定要把状态机的配置能力作为工具选型的硬性条件。要能配置准入门槛、字段级权限、自动化触发，这三项缺一项，流程就会退化成"靠自觉"。
像 PingCode 这类面向中大型组织的平台，在这方面的支持相对完整，尤其是支持私有化部署，对于有内网要求、数据不能出园区的组织，这是绕不开的选项。同时支持从其他平台平滑迁移，意味着你不需要为了流程重构而放弃历史数据。
4. 跨产品线、跨地域的团队
这类团队额外要解决的是时区和语言带来的状态理解偏差。我的建议是状态名一律用中英双语定义，并且在状态描述里写清楚"这个状态意味着什么、不意味着什么"。
另外，跨地域团队一定要避免"状态流转靠即时通讯工具催"这种模式。所有状态变更都应该在平台上留痕，即时通讯工具只用来发通知，不用来做决策。
七、不同情况下的取舍
最后一节讲取舍。前面讲的都是"应该怎么做"，但现实中资源有限，必须做选择。我列出四组最常见的取舍。
1. 状态粒度 vs 维护成本
越细的状态确实能带来更精确的数据，但也带来更高的流转成本。每增加一个状态，就增加一次交接、一次填写、一次可能的误操作。
我的取舍原则是：只有当"两个阶段之间的差异会影响决策"时，才值得拆成两个状态。比如"开发中"和"待提测"值得拆，因为前者是开发的责任，后者是交接等待，两者的停留时长反映完全不同的问题。而"编码中"和"自测中"不值得拆，因为两者都是开发内部的事，拆开只会增加流转次数。
2. 自定义属性 vs 标准化
各团队总希望有自己的字段，但字段一多，跨团队的数据就聚不起来。
我的取舍原则是：流程属性和度量属性必须标准化，分类属性可以有限自定义。因为流程和度量数据要跨团队汇总，口径必须一致；分类属性是给各团队自己做筛选用的，允许一点差异不会伤筋动骨。
具体做法是给自定义属性设一个上限，比如每个团队最多 3 个，而且必须登记用途。这个限制不是为了管，是为了让团队自己想清楚"这个字段真的有用吗"。
3. 流程刚性 vs 执行弹性
准入条件设得越严格，数据质量越高，但团队抱怨越多。这是一个真实存在的张力。
我的做法是分级：把准入条件分成"阻断"和"提醒"两类，只有真正影响下游的条件才设为阻断。比如"待提测必须填写构建号"设为阻断，因为没有构建号测试无法开展；而"必须填写预估工时"设为提醒，因为漏填不会直接阻塞交付。
关键是让团队明白：阻断项不是流程在为难人，是下游真的需要这个东西。这个道理讲通了，抵触会小很多。
4. 工具迁移 vs 历史数据
如果你的团队正在从旧平台迁移，一定会面对这个取舍：是只迁移未完成的任务，还是把所有历史数据都带过去？
我的建议是看历史数据的使用场景。如果历史数据主要用于合规审计和排查问题，那就全量迁移，并且尽量保留原有的状态映射关系；如果历史数据基本不会再看，只迁移近两个季度的已完成任务即可。
这里有个实操细节：迁移时状态字段很难一一对应，因为旧状态和新状态的切分逻辑不同。我的做法是建立一张映射表，同时对无法映射的历史状态保留原始值在一个备注字段里，而不是强行归并。强行归并会让历史数据失去可解释性。
支持平滑迁移的平台通常会提供映射配置能力，这一点在选型时值得专门问一句。
结语
回到最开始那个问题：任务状态到底怎么做？
我的核心观点是，状态设计本质上是把团队已经存在的隐性流程显性化，而不是发明一套新流程。你做得好不好，判断标准不是状态列表有多漂亮，而是六个月后，团队能不能用这些状态算出关键指标，并用指标驱动改进。
另外一个我特别想强调的独特视角：状态的价值不在"记录发生了什么"，而在"触发应该发生什么"。一个只能被读取的状态是记录，一个能触发下游动作、能阻断不合规流转、能自动产生时间戳的状态，才是流程的一部分。设计的时候，多想想后者。
如果你现在就要动手，我给你一个最小行动清单：
- 这周内，找产品、开发、测试各一位，各自画出"一个需求从提出到上线"经过的节点，把三张图叠起来，标出分歧点；
- 下周内，基于合并图切出 5 到 8 个状态，每个状态写清责任主体、准入条件、产出物、下一跳；
- 再下周，配好流程属性和 3 个最关键的分类属性，度量属性优先选系统自动产生的；
- 然后，拿过去一个迭代的数据，用新状态重新走一遍，看会不会卡住；
- 最后，落到工具里，配好权限和自动化触发，跑满三个迭代再回看数据。
不要一次追求完美。状态设计是一个会持续迭代的东西，第一版只要能让团队对"现在到哪一步了"有一致理解，就已经成功了。
常见问题解答（FAQ）
1. 研发团队从0到1设计任务属性时，状态字段到底设几个才够用？
我们团队十几个人，之前用表格管需求，状态那一栏有人写“进行中”、有人写“开发中”、有人写“doing”，月底统计时完全对不上。现在想迁到某项目管理平台，我拿不准状态是设3个够用，还是照着网上模板抄七八个显得规范。
我的经验是首次落地不要超过5个，并且必须满足一个硬标准：每个状态都有明确的下一跳，而且一个外人看一眼就能判断卡在哪儿。具体做法是先只建“待处理 → 进行中 → 待验收 → 已完成”，再加一个终态“已取消/不做”，一共5个。
判断依据是状态的作用只有三件事：让站会知道谁卡住、让统计能算出周期时间、让流程知道下一步该找谁；超过5个之后，团队会在“待联调”和“待测试”之间反复挑，数据反而更脏。落地时给每个状态写一句可判定的话，比如“进行中=已认领且动了第一行代码或第一条配置”，不要靠感觉。
同时一定要保留状态变更的时间戳，后面算“进行中平均停留时长”才有依据。等你跑满一个月，如果发现某两个状态之间的流转占了全流程七成以上，再考虑把它们拆开，从0到1正确的长法是先薄后拆，而不是一上来抄一套齐全的。
2. 任务状态谁能改，是不是只有负责人能拖，怎么防止有人随手把卡片拖到已完成？
之前我们没有任何规则，测试同学为了让自己的看板干净，直接把别人的卡拖进“已完成”，结果版本复盘时才发现完成列里有三张根本没上线。我现在要重新定制度，但不确定管太严会不会被团队嫌麻烦。
做法是：状态的编辑权限跟着“角色+当前状态”走，而不是跟着人走。具体规则可以这样定：待处理→进行中，只有任务负责人或项目管理员能改；进行中→待验收，只有负责人能改；待验收→已完成，只有验收人（通常是测试或需求方）能改；任何状态→已取消，需要项目管理员。
判断依据是每一条流转背后都对应一个真实事件，认领、提测、验收通过、砍需求；如果改状态的人不是执行这个事件的人，状态就从事实记录变成了情绪表达。
落地手法上，别把这几条写成文档让新人自觉，要在某项目管理平台里配成状态流转校验（工具里通常叫工作流或流转规则），同时强制记录状态变更历史，谁在什么时候改的一目了然。另外别加“必须填备注才能改状态”这种硬门槛，实测只会催生一堆“已处理”“。
”的垃圾备注，改成只在跨阶段流转（进待验收、进已完成）时要求写一句真实说明，成本低且真的有用。
3. 看板的列和任务状态字段是一回事吗，能不能让一个任务同时出现在两列里？
我们看板上有“开发中”“联调中”两列，但状态字段里只有一个“进行中”，同事老问我到底以哪个为准。有人干脆把一个任务复制成两张卡分别放进两列，结果统计在制品数量时直接翻倍，我也说不清哪个数才是对的。
不是一回事，但必须一一对应，否则数据一定会打架。我的做法是：状态字段是唯一事实来源，看板列只是状态的一种视图。一列可以对应多个状态（比如“进行中”这一列里同时放“开发中”和“联调中”两个状态），但一个状态不能同时落在两列里，一个任务也永远只允许存在一张卡。
判断依据很直接：只要允许一卡两列，你在制品数量（WIP）就会被重复计数，后面算吞吐量、周期时间、流速全是错的，而这些指标恰恰是研发制度设计里最值钱的部分。还有一个可量化的调列口径：当某列长期堆超过“人数×1.5”的卡（比如6人团队某列常驻15张以上），说明这列混了太多状态，该拆；
如果某列一个月都没有卡经过，直接删掉，别为了对称留着。我自己踩过的坑就是一开始照着别人的模板做了九列，结果三列常年空白，看板看着很专业，其实没人看。
4. 状态字段上线后大家不爱更新，数据还是不准，这种情况怎么救？
我们推了一个月，站会上问“这张卡怎么还在进行中”，回答总是“昨天就提交了忘了改”。次数一多，我作为负责人也不好天天催，慢慢就变成数据是给领导看的，团队自己不用。我想知道是不是该加点考核，还是干脆放弃这个字段。
我的判断是：数据不准基本不是态度问题，而是“更新状态对他自己没好处”，所以别靠催，靠三件事。第一，让更新状态成为某个已有动作的副产品：把代码提交、分支合并、构建结果和任务编号挂钩，提交时自动流转状态；或者站会直接在屏幕上改，而不是会后各自补。
第二，把状态数据当成信息源而不是考核项，公开“进行中停留超过3天”的卡，但不排名、不扣分；一旦和绩效挂钩，大家就会挑最安全的状态填，数据只会更假。第三，设一个可量化的验收口径：连续两周随机抽查20张“已完成”的卡，与提交记录、验收记录对得上15张以上（也就是75%），就算达标；
低于这个数先别急着上报表，说明流程本身有断点，而不是人不行。最后一条经验：状态数量越少、名字越日常，更新率越高。我们砍到5个状态之后，抽查准确率从大概一半提到了八成多，靠的不是罚，是少让人做选择题。
核心关键词
文章包含AI辅助创作：状态怎么做？研发团队制度设计：任务属性从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/356855
读者评论
状态超过8个流转准确率下滑”这个观察我认同，但我们精简到6个之后，卡点全堆在备注里，反而更难查。后来发现真正的瓶颈不是数量，而是谁有权改状态。文章里权限那段写得太轻描淡写，我实操下来这条比状态数量重要得多，阻力也最大，尤其是有领导习惯直接拖动看板的时候。
数据那部分我保留意见。6个团队、3个迭代，样本小，而且都是能坐下来做复盘的组织，本身就带选择偏差。周会澄清议题从41%降到14%，也可能是状态简化后大家干脆懒得问了。方向我不否认，但这类前后对比数字当结论用，说服力有限，顶多算个方向性信号。
作为测试，图里“提测后等待测试资源19%”最扎心，但正文没往下展开。我们最大的痛是提测包不达标被打回，来回两三轮，责任和工时都算不清。要不要给“待提测”和“提测不通过”单独设状态，我们争了很久，最后只加一个，退回记录还是埋在备注里，复盘照旧算不出来。