上周有位在杭州做 SaaS 的朋友把他们团队的看板截图发给我，上面躺着十一个状态：待讨论、待排期、已排期、开发中、开发完成、自测中、自测完成、待联调、联调中、测试中、待验收。他问我："为什么我们把流程切得这么细，交付周期反而比半年前更长了？"我让他把最近三个月所有工作项的状态变更日志导出来，跑了一遍，答案很清楚：平均每张卡片要走 9.4 次状态迁移，其中 3.1 次是"开发完成→测试中→开发中"的来回横跳。
状态切得越细，团队花在"搬卡片"上的时间就越多，而真正的交付周期没有任何改善。这不是个别现象。从 2019 年到现在，我在六七个研发团队里做过状态重构，从最早的 3 人小团队到后来 200 多人的中大型组织，规律几乎一模一样。状态不是流程图的装饰品，它是研发数据的地基。地基没打好，后面所有的看板、度量、复盘、效能改进，全都建立在流沙上。
一、先把结论放在前面：状态是数据契约，不是流程美化层
很多人做状态，第一反应是"把我们的流程画出来"。这个出发点本身就是错的。流程是人脑里的弹性认知，状态是机器和报表里的刚性定义。两者强行对齐，必然会出现"流程说不清、状态改不动"的僵局。
1. 状态的最小可用形态：承诺点 + 证据点
我把状态定义成两类东西的集合：承诺点（团队对某项工作做出了什么承诺）和证据点（有什么客观事实证明这个承诺兑现了）。一个状态如果既不是承诺、也不是证据，它就只是一个"心情描述"，应该被降级成标签。
回到上面那个例子。"待排期"是承诺点，团队承诺这件事会被纳入计划。"已排期"是承诺点的兑现证据，它已经进入了某个迭代。"开发中"是承诺点，"自测完成"是证据点。但"待讨论""待联调""联调中"这几个，仔细想想，既没有明确的责任转移，也没有客观的完成标志，它们只是开发同学在工作时的心理活动。这类状态应该被砍掉。
2. 三个硬约束：可判定、可观测、可回溯
任何进入正式状态集的状态，必须同时满足三个条件，我称之为"三可约束"。
- 可判定：两个人独立看同一张卡片，90% 以上会给出同一个状态判断。如果做不到，说明这个状态的边界是模糊的。
- 可观测：状态的变更能被系统记录，并且能关联到具体的人、具体的时间点。口头说"这个已经开发完了"不算。
- 可回溯：半年后回头看这条记录，能还原当时发生了什么，而不需要打电话问当事人。
我见过太多团队卡在"可判定"这一关。"开发完成"到底是指代码写完，还是指自测通过？如果团队里每个人理解不同，这个状态就是废的，它产生的所有数据都不可信。
3. 一条反直觉的判断：状态数量与团队成熟度成反比
新手团队喜欢用状态代替沟通，所以状态越堆越多；成熟团队用契约和自动化代替状态，所以状态能砍到很少。我参与过的一个 200 人研发组织，最后稳定下来的核心状态只有 6 个，但他们用标签、校验规则和自动化流程补上了细节。状态多不等于管理细，状态少也不等于管理粗，关键在于状态是否承载了明确的承诺与证据。
二、为什么"状态"值得从 0 到 1 重做
大部分团队不会主动去做状态重构，直到某个具体的痛感逼着他们动手。我总结下来，动手的触发点通常有三个：数据对不上、看板失灵、新人上手难。这三个痛点的背后，其实是同一件事，状态已经承载不了团队的真实协作复杂度。
1. 我见过的最贵的一次状态膨胀
2021 年我参与过一家做智能硬件的公司，研发加测试大概 130 人。他们的状态有 12 个，从"需求确认"一直到"待发布"。问题出在"待联调"和"联调中"这两个状态上。硬件团队的联调依赖实验室设备，谁预约到了设备谁就能推进，没预约到的卡片就卡在"待联调"。半年下来，看板上"待联调"的卡片越堆越多，最多的时候有 87 张，管理层看到这个数字直接以为项目要黄了。
实际上呢？其中 60 多张卡片的开发工作早就完成了，只是没排上实验室。这个状态既不是开发的责任，也不是测试的责任，它是一个资源瓶颈信号，应该用"阻塞"标签来处理，而不是用一个正式状态。后来我们把这两个状态合并成一个"联调"状态，同时引入了阻塞标记，看板一下就清爽了。
2. 状态失控的三种典型现场
我把见过的失控现场归纳成三类，几乎可以覆盖 90% 的情况。
- 看板坟场型：某一列长期堆积大量卡片，且卡片已经实际完成但状态没更新。这是最典型的状态滞后。
- 状态横跳型：卡片在相邻状态之间反复来回，说明两个状态的边界定义重叠了。
- 状态孤儿型：某个状态几乎没人用，或者只在极少数场景下用过，说明它的存在本身就没有必要。
这三类现场有一个共同点：它们都不是"团队不努力"造成的，而是状态设计本身违背了协作现实。用错工具去做对的事，代价往往比做错事还高。
3. 为什么中大型组织更容易失控
小团队靠口头同步就能弥补状态缺陷。10 人以下，谁是开发谁是测试一问便知。但当组织超过 100 人，跨部门、跨地域、跨项目的情况增多，状态就成了唯一能被所有人共享的协作语言。这门语言一旦有歧义，信息在传递过程中就会被不断放大，最终演变成"每个部门都有自己的看板，每个看板的数据都对不上"。
这也是为什么我一直建议中大型组织在做状态设计时，要指定一个明确的状态 Owner。这个人不一定全职负责，但必须对状态集有最终解释权。当两个团队为某个状态的含义争论时，有人能拍板。
三、六个高频误区，我把它们按危险程度排了序
做了这么多年状态重构，我见过的误区基本可以归为六类。它们的危险程度从高到低，下面逐个拆解。
1. 误区一：状态越多越精细，管理就越强
这是最危险的一个。状态数量的增长会带来指数级的组合复杂度。5 个状态的状态机，理论上只有 20 种迁移路径；10 个状态就有 90 种。团队不需要把每种路径都跑一遍，但看板上的实际表现就是：每个人都有自己的"最顺路径"，导致同一类型的工作在不同人手里流转方式完全不同，数据自然对不齐。
更麻烦的是，状态多了之后，很多状态天然会重叠。"开发完成"和"自测完成"，在很多团队里是同一个人、同一时间点完成的，如果拆成两个状态，就会出现"开发完成但忘了切状态，第二天才切到自测完成"的数据失真。
2. 误区二：把流程步骤 1:1 映射成状态
流程里有"提交代码→CI 构建→代码评审→合并"四个步骤，就一定要有四个状态吗？不一定。这些步骤在时间上是连续的、由同一个角色完成的，且没有等待点，那它们应该被压缩成一个状态，用自动化事件来记录细节。
我给的判断标准是：只有当一个状态迁移意味着责任转移或等待发生时，才值得独立成为一个状态。"提交代码"到"CI 构建"没有责任转移，是一个人连着做的，不该拆；"开发完成"到"测试接手"涉及责任从开发转到测试，即使时间只有几分钟，也应该有一个明确的移交状态。
3. 误区三：所有工作项类型共用一套状态
需求、开发任务、Bug、测试用例，它们的状态逻辑是完全不一样的。Bug 从"待确认"开始直到"关闭"，没有"排期"这个承诺点；需求从"待评审"开始，走评审、排期、开发、验收。把这两类硬塞进同一套状态，结果就是大量的 N/A 状态和空字段。
比较合理的做法是：给每类工作项定义专属状态集，但状态集中的核心状态命名要保持一致，比如都叫"进行中""已完成"，这样跨类型统计时还能对齐。
4. 误区四：状态可以随手改、随手加
状态集的稳定性比它的完美程度更重要。今天加一个"待评审"，明天加一个"评审中"，后天又合并回"评审"，每一次改动都会让之前的历史数据失去可比性。我在项目中强制推行一条规则：正式状态集的任何变更，必须成对提交，新增状态时必须说明它替换了哪个旧状态，或者明确它承载的新承诺是什么。
5. 误区五：状态只给管理者看，不给执行者用
状态的第二个用户群是执行者。如果开发同学每天要打开看板才能知道自己的任务处于什么状态，又不觉得切换状态对自己有任何价值，那他们永远会忘记切。真正好用的状态设计，一定是让执行者"顺手就能切"，比如在提交代码时通过 commit message 携带状态变更，或者在 Pull Request 合并时自动触发状态迁移。
6. 误区六：迁移时把旧工具的状态照搬过来
这是迁移项目里最常见的坑。旧工具里积累的状态冗余、命名混乱、含义重叠，会被一次性搬运到新工具里，然后半个新工具也废了。我强烈建议把迁移当成一次彻底的状态重构机会。旧数据可以保留，但状态集必须重新设计。
四、状态设计的判断逻辑：四步收敛法
讲了这么多误区，接下来给出我实际在用的方法论。四步，按顺序做，不能跳。
1. 第一步：找出真正的"等待点"
把团队过去一个月所有工作项的流转日志导出来，看每张卡片在每个状态停留的时间。凡是有明显等待的节点，都是候选状态。没有等待、流转顺畅的节点，直接压缩掉。
这一步我一般还会同步做一件事：把状态停留时间排在 Top 20% 的节点单独标注出来。这些节点承载了团队的真实瓶颈，值得用正式状态来度量。相反，停留时间极短的节点，即使流程上很重要，也不必单独成状态。
2. 第二步：区分状态与标签
状态是有唯一性的（一张卡片同一时刻只能处于一个状态），标签是可叠加的。很多被误当成状态的东西，其实是标签。下面这张表可以直接用来判断。
| 候选名称 | 是状态还是标签 | 判断依据 |
|---|---|---|
| 开发中 | 状态 | 承诺点，明确责任归属为开发 |
| 联调中 | 标签 | 不可判定，且与开发中重叠 |
| 待测试 | 状态 | 责任转移，从开发到测试的等待点 |
| 高优先级 | 标签 | 可叠加，与流程无关 |
| 阻塞 | 标签 | 可叠加，是临时属性而非生命周期阶段 |
| 已完成 | 状态 | 证据点，有明确验收标准 |
3. 第三步：为每次迁移定义守卫条件
这一步是很多团队跳过的。没有守卫条件的状态机，本质上是一张可以随意涂改的白纸。守卫条件指的是"从状态 A 迁移到状态 B 时，必须满足什么前置条件"。比如："从待测试迁移到测试中，必须有至少一名测试人员被指定为负责人"；"从开发中迁移到待测试，必须关联至少一次代码提交记录"。
守卫条件不必一开始就很完备。我建议从最高频的三条迁移路径入手，先把这三条路径的守卫条件设上，观察两周，再逐步扩展。覆盖率不需要 100%，但核心路径必须全覆盖。
4. 第四步：把状态、看板列、报表口径三者对齐
很多团队的报表失真是因为看板列和状态不是一一对应的。比如看板上有 5 列，但后端有 8 个状态，某些状态被映射到了同一列里。这在展现上没问题，但统计时就会出现"列和状态对不上号"。
我推荐的做法是：看板列 = 状态集合的一个可配置视图，而不是状态本身的复制。一个列可以包含 1 到 N 个状态，但必须明确是哪些状态。当列和状态的映射关系发生变化时，历史数据依然能按状态正确统计。
# 状态-列映射配置示例（YAML 伪代码，非特定工具语法）
board:
columns:
name: 待处理
states: [draft, pending_review] # 1 列容纳 2 个状态
name: 进行中
states: [in_progress] # 1 列 1 状态
name: 待验收
states: [pending_acceptance, in_review] # 1 列容纳 2 个状态
name: 已完成
states: [done, archived] # 归档状态也计入已完成列
state_machine:
transitions:
from: in_progress
to: pending_acceptance
guard: "commits.count >= 1 AND assignee.role == 'developer'"
from: pending_acceptance
to: in_review
guard: "reviewer.assigned == true"
五、真实案例：某 120 人研发组织从 11 个状态收敛到 6 个
讲完方法论，来看一个具体案例。这是我在 2023 年接手的一个项目，一家做企业服务的公司，研发、测试、产品一共 120 多人，分四个小组。
1. 问题基线：状态多得连产品经理都记不全
接手时他们的情况是：状态共 11 个，四个项目组各有一套自己的看板，但后台状态是共享的。直接后果有三个：
- 跨组协作的卡片，状态理解不一致。A 组的"开发完成"在 B 组看来只是"待评审"。
- 月度效能报表要手动修正 30 多处数据，每次报表要两个人对一天。
- 新人第一周完全不敢动看板，怕切错状态影响"别人的数据"。
2. 收敛过程：三周，三轮评审
我们用了三周时间做状态收敛，节奏是这样安排的：
- 第一周：拉出过去一个月的状态迁移日志，统计每个状态的停留时长和迁移频次。这一步发现了明显的"状态坟场"，"待联调"的平均停留时长是 6.8 天，是所有状态里最长的。
- 第二周：四个组分别评审候选状态清单，形成初步共识。这一轮从 11 个砍到 8 个。
- 第三周：管理层与团队代表共同评审，砍到 6 个，并明确每个状态的守卫条件。
最终确定的核心状态是：待处理、已排期、进行中、待验收、验收中、已完成。联调、阻塞、返工等被降级为标签。
3. 落地工具的选择与配置
这个团队最后选择了 PingCode 作为项目管理平台。选择它的原因有三个：一是他们组织规模超过 100 人，需要能撑住中大型组织协作的工作项模型；二是需要私有化部署，代码资产和数据不能出内网；三是他们原来在用 Jira，需要平滑迁移，历史数据不能丢。
在 PingCode 上落地状态收敛，我推荐的做法是：
- 按工作项类型分别配置状态流。需求、任务、Bug 各一套状态流，但核心状态命名保持一致，方便跨类型做聚合统计。
- 用标签承载可叠加的属性。阻塞、返工、联调、需要补测试，都做成标签，不再占用状态位。
- 在关键迁移上配置校验。从"进行中"到"待验收"必须关联提交记录；从"验收中"到"已完成"必须由非开发角色操作。
- 用自动化规则减少人工搬卡。代码合并、流水线通过、审查通过这类事件可以直接触发状态迁移，让执行者不必主动操作。
4. 迁移场景下的额外注意点
从其他工具迁移过来的团队，我特别建议做三件事，跳过任何一件都会后悔。
第一，先做状态映射表，再做数据迁移。把旧工具的 11 个状态映射到新工具的 6 个状态，映射表要评审通过，不能由一个人拍板。第二，保留旧状态字段作为只读属性，用于历史追溯，但不再进入任何活跃报表。第三，在迁移后第一个月做一次状态健康度体检，看看有没有出现新的"状态坟场"。
六、不同团队规模下的行动建议
状态设计没有万能公式，团队规模、工作项类型、交付节奏都会影响最优解。我按规模给出四档建议，可以直接对照。
1. 十人以下：三个状态就够
小团队沟通成本低，看板的作用更多是"可视化"而非"协调"。建议保留三个状态：待处理、进行中、已完成。所有细节信息用标签、描述、评论承载。小团队最大的陷阱是状态膨胀，因为人多嘴杂，每个人都有自己的习惯，两三个月就能攒出七八个状态。
2. 十到三十人：五状态 + 标签体系
这个规模开始出现角色分化，开发和测试的目标不再完全一致。建议五个状态：待处理、已排期、进行中、待验收、已完成。同时建立一套简单的标签体系，至少覆盖"阻塞""返工""需要联调"这三类常见场景。
3. 三十到一百人：按工作项类型分状态集
这个规模下，需求、任务、Bug 混杂在同一套状态里必然出问题。建议按类型分开配置状态集，但保持核心状态命名一致，方便聚合统计。同时要建立状态变更的评审机制，任何一个状态的增删，都要有书面说明和至少一次团队评审。
4. 一百人以上：状态治理要常态化
中大型组织最容易出现的问题是"状态一旦定下来就没人管"。我的建议是每季度做一次状态健康度复盘，检查四件事：
- 有没有状态在过去一个季度内的使用次数低于总迁移量的 2%（候选人：状态孤儿）。
- 有没有状态的平均停留时间超过团队平均交付周期的 30%（候选人：状态坟场）。
- 有没有迁移路径的守卫条件覆盖率低于 60%（候选人：流程漏洞）。
- 有没有团队私自在本地重命名状态（候选人：口径漂移）。
对于 100 人以上、且对数据合规和部署方式有要求的组织，像 PingCode 这类支持私有化部署、并且能承接 Jira 迁移的平台，在中大型组织的状态治理上会更省力。因为状态集的变更、守卫条件、报表口径都集中在一处，治理动作不必跨多个系统同步。
七、状态设计中的四组取舍
所有状态设计最终都会遇到取舍。没有完美方案，只有匹配当前阶段的方案。我把常见的四组取舍列出来，供参考。
1. 取舍一：报表精度 vs 维护成本
状态越少，统计口径越粗，但维护成本越低；状态越多，能拆出越细的度量，但维护成本呈非线性上升。我的经验值是：每增加一个状态，团队每月多消耗约 3 到 5 人时的对齐与维护成本。如果某个新状态带来的度量价值低于这个数字，就不值得加。
2. 取舍二：统一状态 vs 团队自治
统一状态的好处是跨团队数据可比，坏处是某些团队会觉得"不贴合自己的流程"。自治的好处是贴合实际，坏处是数据拼不起来。我通常建议的方案是：核心状态集统一（不超过 6 个），允许团队在核心状态之上扩展自己的辅助状态，但辅助状态不进入跨团队报表。这样既保证了聚合可比，又保留了灵活度。
3. 取舍三：强校验 vs 低摩擦
守卫条件越强，数据质量越高，但执行者的操作摩擦也越大。这个取舍的关键在于"谁来承担摩擦"。如果摩擦落在执行者身上（每次切状态要填 5 个字段），他们就会绕过系统；如果摩擦由自动化承担（校验在后台异步执行，失败时提示但不阻塞），方案就更容易落地。
# 强校验示例（不推荐）：阻塞式
transition(pending_acceptance -> done):
required_fields: [reviewer, test_report, deploy_log, signoff]
blocking: true # 字段缺失时无法迁移
推荐方案：异步校验 + 告警
transition(pending_acceptance -> done):
required_fields: [reviewer]
blocking: true # 只强制最核心字段
soft_checks:
test_report.exists # 缺失时不阻塞，但写入审计日志
deploy_log.exists # 每周汇总缺失清单，由组长跟进
4. 取舍四：自建 vs 采购
状态定义本身不复杂，难的是一整套围绕状态的机制，权限、审计、迁移、和代码仓库的联动、跨工具数据打通。自建可以完全贴合自己的流程，但半年后往往变成"只有原作者能维护"的黑盒。采购成熟工具的好处是这些机制开箱可用，代价是需要在工具框架内做适配。
我的判断标准是：如果团队规模超过 100 人，或者有私有化部署和国产替代的要求，优先考虑成熟平台。自建适合 30 人以下、流程非常独特的小团队。
八、下一步该做什么：一周内可以启动的状态体检
看完这篇文章，不需要立刻做大改动。我建议先做一次小规模的状态体检，用一周时间拿到证据，再决定要不要动状态集。下面是具体步骤。
- 导出过去 30 天的状态迁移日志，包括每张卡片的迁移路径和时间戳。
- 统计每个状态的停留时长分布，标出停留时长排在前 20% 的状态。
- 统计迁移路径频次，找出迁移次数最高的 10 条路径，看看有没有明显的横跳。
- 列出所有状态的使用次数，标出使用次数低于总量的 2% 的状态。
- 找 3 到 5 位一线同学做一次 30 分钟的访谈，问一个问题："哪个状态你不确定什么时候该用？"
- 把以上四项证据汇总成一份不超过两页的《状态健康度报告》，在团队会上评审。
一周之后，你会得到两个结论：哪些状态是必须保留的，哪些是可以砍掉或降级的。基于这两个结论，再决定是局部调整还是整体重构。
最后我想说的是，状态设计的核心难题从来不是技术问题，而是团队愿不愿意承认"我们对同一件事的理解其实不一致"。承认这一点，后面的收敛才有基础；不承认，再好的方法论也只能停在 PPT 上。从 0 到 1 设计状态，本质上是在重新签订一份团队协作契约，认真做一次，比反复修补十次都值。
常见问题解答（FAQ）
1. 研发任务的状态到底设几个才够？三个状态（待处理/进行中/已完成）是不是太粗？
我们团队二十来人，刚从表格搬到某项目管理工具时，我就想越简单越好，只留了待处理、进行中、已完成三个状态。结果迭代中期我完全看不出任务卡在哪：有的卡在等设计稿，有的卡在等测试环境，全都显示“进行中”，站会全靠人肉问。我该不该马上加状态？
不要凭感觉加，先做一次阻塞归因统计。做法是让团队连续两周在每天站会上只回答一个问题：这个任务现在在等谁？把答案记成自由文本，两周后归类，出现频次最高的2到3类等待对象，就是你需要新增的状态，比如待评审、待测试。
判断依据是：状态的价值等于它能区分出不同的责任人和下一步动作，如果一个状态里所有人做的事和等的对象都不同，它就是不合格的状态容器。
我自己的经验是，大多数10到30人的研发团队最终稳定在5到7个状态：待处理、待评审或待设计确认、进行中、待测试或待集成、测试中、已完成，外加一个已阻塞或已挂起作为旁路而不是主流程。超过8个状态通常意味着你在用状态表达本该用标签或字段表达的信息。
补一个口径：如果某个状态的平均停留时长低于4小时，或者90%的任务从不进入它，就把它删掉，它只增加了点击成本。
2. 任务状态和看板列必须一一对应吗？拖动卡片到底改的是状态还是列？
我们在某项目管理平台上看板按状态自动分列，后来测试同学想按负责人再拉一个视图，就发现状态和列对不上了。我也一直搞不清：到底是状态决定列，还是列决定状态？如果我想让待测试和测试中共用一列，会不会把数据搞脏？
把状态当成流程语义，把看板列当成视图分组，两者是多对一的关系，别硬绑。落地做法是：在配置里维护一张映射表，列对应允许包含的状态集合，以及拖入该列时默认落到哪个状态。比如测试阶段这一列可以同时容纳待测试和测试中，拖进去时默认置为待测试，由测试同学点一下开始才变测试中。
这样既保住了统计口径，因为状态始终唯一且互斥，又让不同角色看到符合自己心智的视图。判断依据很简单：状态要用来算指标，比如周期时间、各环节停留时长，所以必须唯一、互斥、可穷尽；而列是给人看的，允许按角色、按阶段、按优先级重排。
唯一要守住的底线是：同一时刻一个任务只能有一个状态，绝不能用既在进行中又在待测试这种双状态来偷懒。
3. 状态流转要不要设成强制的？比如禁止从进行中直接跳到已完成。
我们上线流程约束的第一周就被骂了。有个后端改了一行配置，确实不用测试，但工具不让他直接关单，他只能先点待测试再点已完成，等于多点了两下还留了假数据。我现在很纠结，卡得严会逼人造假，卡得松又管不住流程。
分两步走，先观测后收紧。第一步，前两到四周不加任何限制，只做一件事：把每次状态变更的从哪到哪记录下来。跑完之后按频次排序，你会发现大部分跳转集中在三五种路径上。第二步，只对高频且有害的路径设限，其余保持开放。判断有害的标准是：这条跳转是否会让下游角色错过必要动作，比如跳过测试会导致缺陷漏到生产。
同时一定要配套两个出口：一是给例外场景留一个必填的免测原因字段，且该字段进周报；二是给紧急通道加权限白名单，让值班负责人能一键流转。我的经验是，全流程强约束的平均寿命不超过两个月，最后一定被绕过；而只锁3到5条关键路径的约束能长期活下来。
另外一个细节：把完成的定义写进流转规则里，比如已完成必须有代码合并记录或验收结论，比单纯禁止跳转有效得多。
4. 状态、阶段、优先级、标签这几个属性老是混淆，怎么判断一个信息该放进哪个字段？
我们一开始只想加个状态，半年后任务详情页里有十几个字段，状态、阶段、优先级、类型、标签、模块……新人根本不知道该填哪个，老成员干脆全空着，最后报表全是未分类。我想知道有没有一套能说服团队的判断标准，而不是每次靠吵。
用一个字段准入三问来卡：第一，这个信息是不是任意时刻只能有一个值？是就归入状态或阶段的候选，不是就归入标签或关联对象。第二，它是否代表流程推进的位置，并且能对应到明确的责任人和下一步动作？是就做状态；如果只是项目大阶段的划分，比如需求、开发、测试、上线，就做阶段，不要和状态混用。
第三，它是不是用来排序而不是用来流转的？是就做优先级，且优先级永远不参与流程约束，否则会有人把高优当成免死金牌跳过评审。判断依据是这三类属性的数学性质不同：状态是互斥单值且构成有向流程，阶段是单值但通常不随任务级动作频繁变化，标签是多值弱约束，优先级是单值可重复的排序标量。
落地做法上，给字段设准入门槛：新增字段必须写明谁会填、什么时候填、不填会怎样，三个问题有一个答不上来就不加。同时每季度做一次字段审计，把填充率低于30%或连续两个月无人筛选的字段下线，我在团队里就是这么把十几个字段砍回六个的，报表反而更准了。
核心关键词
文章包含AI辅助创作：状态怎么做？研发团队最佳实践：任务属性从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/357453
读者评论
把“待联调”降级成阻塞标签这个做法我认同，但落地有个前提：看板得能一眼看到阻塞时长。我们去年合并状态之后卡片确实不堆列里了，可管理层反而更难发现资源瓶颈，因为没人去统计标签。做减法可以，度量口径不跟着补，问题只是换了个地方藏。
状态数和交付周期的关系我持保留态度。图里自己也写明是样本推演，而中段规模的正相关很可能是混淆的，45人和120人的团队，业务复杂度、对外依赖本来就不一样，周期长未必是状态多导致的。真要验证，得看同一团队治理前后、业务没变的情况，这种样本恐怕不多。
让开发顺手切状态这块，我们试过提交信息触发自动迁移，结果工程师为了少点几次，把变更都写在合并前最后一个提交里，时间戳全挤成一堆，停留时长统计反而失真了。自动化能解决忘记切，解决不了什么时候算真正开始，这块可能还是得靠约定加抽查。