上周三下午，一位管理 400 人研发体系的负责人把他们的项目看板投到大屏上，让我帮忙看看为什么交付总是延期。我数了一下，一个需求的状态有 13 个：待评审、评审中、待排期、已排期、开发中、开发完成、待提测、测试中、测试通过、待验收、验收中、已上线、已关闭。我问他一个问题：这 13 个状态里，哪几个是你真的会拿来做周报的？他沉默了大概十秒，说"其实就看三个"。这就是绝大多数团队状态设计的真相，你花了两个月定义了 13 个状态，最后真正被使用的只有 3 个，剩下 10 个只是让看板变长、让报表吵架、让新人不敢点鼠标。
这篇文章不讲状态的定义，也不抄某本敏捷书上的流程图。我要讲的是我这些年做过的、踩过的、翻过车的状态设计方法：一个任务属性，从零到一怎么长出来，怎么在三个月后还不变成一坨没人敢动的历史包袱。
一、先说结论：状态的本质是责任交接凭证，不是进度条
很多人把状态理解成"这件事做到哪一步了"。这个理解听起来自然，但它是错的，而且是状态失控的根源。进度是连续的，责任是离散的。状态要标记的不是"做了多少"，而是"东西现在在谁手上，下一步该谁接"。
1. 三条硬结论
结论一：状态数量由责任交接点决定，不由工作阶段决定。一个需求从想法到上线，工作阶段可能有二十个，但责任真正换手的地方通常只有四到六个。阶段是描述性的，交接点是约束性的。只保留交接点，状态才不会被写成一部长篇小说。
结论二：没有退出条件的状态等于没有状态。"测试中"这三个字本身不传递任何信息，除非你能回答"什么条件下它才能离开测试中"。如果答案是"测试人员觉得差不多了"，那这个状态就是一个人情字段，不是管理字段。
结论三：状态必须能被机器验证，至少能被规则校验。凡是只能靠人自觉维护的状态，三个月内一定失真。这不是人的问题，是设计的问题。你要让"跳状态"这件事在系统里变得很别扭，而不是靠周会上提醒大家注意规范。
2. 状态设计的最小公式
我一般用一句话概括状态设计：状态 = 责任主体 × 可验收交付物 × 退出条件。三者缺一，这个状态就不该存在。
举个例子。"开发中"的责任主体是开发工程师，可验收交付物是可运行的代码分支或合并请求，退出条件是代码合并且自测通过。"待验收"的责任主体是产品经理或业务方，可验收交付物是一份验收清单，退出条件是用例全部通过或明确打回。这两条写出来之后，你就不会再纠结要不要加一个"开发完成待提测中"这种中间态了。
3. 一个反常识判断：状态越少，观测精度反而越高
大多数人的直觉是反过来：状态越多，记录越细，数据越准。实际运行的结果恰恰相反。状态多了之后，成员会开始"就近选择"，不确定该选哪个，就选一个最安全的、不会被追问的。于是数据在源头就失真了，你再精细的报表也只是在放大噪声。
我在三个百人以上研发组织里反复验证过同一条曲线：状态数量在 4 到 7 个区间时，状态字段的填写准确率最高；超过 9 个之后，填写准确率明显下滑，而报表口径争议次数快速上升。这个规律我在下面章节会用具体数据展开。
二、为什么状态总做不好：三个真实场景
状态设计失败从来不是因为项目经理不努力，而是因为它在错误的时点、以错误的形式被引入。下面三个场景，是我在真实项目里见过的、出现频率最高的三种。
1. 场景一：把表格的列名当成了状态
很多团队的状态是这么来的：最早用 Excel 排期，横向拉了几列，"需求、设计、开发、测试、上线"。后来换到某项目管理工具，就把这五列原封不动变成了五个状态。
问题在于，Excel 的列是给人看排期的，它不承担交接语义。"设计"这一列里，可能同时躺着还没开始设计的、设计中反复改的、设计完了在等评审的三种东西。这三种东西的责任主体完全不同，但在状态上被压成了一格。结果就是所有人都在问"这个设计到底做完了没有"。
2. 场景二：每个团队自己加状态，月度报表对不上
第二个高频场景是扩张期的组织必然遇到的。公司从 80 人涨到 300 人，中间拆出五六个项目组。工具的管理员权限下放之后，每个组都开始加自己的状态。
A 组加了"待联调"，B 组加了"联调中"，C 组把联调归到"测试中"里，D 组干脆新加了一个"集成阶段"。到了月末，效能部门要统计"有多少需求卡在联调环节"，发现这四个组的数根本没法加总。
更麻烦的是，这件事没有坏人。每个组的加状态动作在当时都是合理的，只是没有人负责守住全局的口径。
3. 场景三：状态变成了政治工具
这个场景最隐蔽，也最伤。我见过一个团队，把"待验收"拆成了"待验收"和"验收中"，理由是"业务方老拖着不验，我们得把他们的锅显性化"。
拆完之后发生了两件事：第一，业务方看到"验收中"这个词，拒绝点进去，因为一点就等于承认自己在处理；第二，开发团队开始把还没准备好验收的东西提前推到"待验收"，好让自己的在制品看起来少一点。半年后这个团队的状态数据彻底失去了参考价值。
状态一旦被用来追责，它就不再是流程信号，而会退化成一种自保话术。这是状态设计里最需要警惕的一条。如果你的组织文化是"状态停留久了要挨批"，那么所有人都会学会让状态停在不挨批的地方。
三、八个常见误区
下面八个误区，几乎覆盖了我见过的 90% 的状态设计问题。你不一定全犯，但至少会中两个。
1. 误区一：状态越多越精细
"精细"的前提是准确。一个 15 个状态、填写准确率 60% 的看板，比一个 6 个状态、填写准确率 95% 的看板粗糙得多。因为前者的所有统计都在累积误差。
更实际的成本是：新成员上手期变长、跨组协作时要先对齐状态定义、每次流程微调都要重新培训。这些都是隐形的管理税。
2. 误区二：状态与进度百分比双轨并行
这是我个人最反对的一种设计：既有状态，又要求填"完成度 30%/60%/90%"。两套东西表达同一件事，必然出现矛盾。
一个需求状态是"开发中"，进度却已经填了 90%，你让报表怎么算？最后的结果是所有人只维护其中一个，通常是那个更容易被追问的。
3. 误区三：把"阻塞"做成状态
"阻塞"不是流程阶段，它是一种属性。一个需求可以在"开发中"被阻塞，也可以在"待测试"被阻塞。你把阻塞做成状态，就等于告诉团队：这个需求离开了正常流程。
正确的做法是把阻塞做成一个独立的标记字段或者任务链接，然后规定凡是标记阻塞的必须写明阻塞原因和解除责任人。这样你既保留了流程位置的准确性，又拿到了阻塞的完整数据。
顺便说一句，我在不少平台里看到默认就有"已阻塞"这个状态，这是初始配置的问题。工具给什么不等于你该用什么。
4. 误区四：状态命名动词、名词、形容词混用
你可以随便打开一个团队的看板，看状态名是不是这个味道："评审""评审中""已评审""评审完成""待评审"。这五个词在语义上高度重叠，但被当成五个不同状态用。
命名混乱的直接后果是新人根本不知道该怎么选，间接后果是统计口径永远说不清。我的建议是统一用一种句式，我通常推荐"待 X / X 中 / 已 X"三段式，一读就知道它在流程里的位置。
5. 误区五：所有工作项共用一套状态
需求和缺陷的天然交接点完全不同。需求要经过评审和验收，缺陷通常只需要"确认，修复，验证，关闭"。你让缺陷也走一遍"待排期、待验收"，就是在往流程里灌水。
任务（Task）更简单，通常三个状态就够。运营类事项又是另一套。用一套状态覆盖所有工作项类型，是状态膨胀最主要的来源之一。
6. 误区六：状态只做加法不做减法
很多团队每年年初优化流程，只加不减。三年下来，看板上躺着一堆 2022 年为了某个特殊项目加的状态，那个项目早就结束了。
我的做法是给每个状态加一个"复查日期"或者归属标记，每季度过一遍：过去一个季度有多少工作项进入过这个状态？如果是 0 或者个位数，直接下线，把历史数据归并到一个相邻状态。
7. 误区七：状态没有退出条件
这是最普遍、也最致命的一条。状态定义了，但没定义"什么情况下才能离开它"。于是"测试中"变成了一个黑洞，东西进去了，什么时候出来全凭感觉。
退出条件的写法有讲究。它必须是可验证的、客观的，比如"合并请求已合并且单元测试覆盖率不低于 70%"、"验收用例执行率 100% 且无未关闭的阻塞级缺陷"。凡是包含"确认无误""达到要求"这种词的退出条件，都等于没写。
8. 误区八：把状态当审批流
状态流转和审批是两件事。状态是流程位置，审批是权限决策。有些团队把"待审批"做成状态，结果是所有审批都变成了流程节点，一个需求走完要经过七八个人点头。
更合理的做法是：审批做成状态流转的前置校验规则，而不是状态本身。系统在校验不通过时拦住流转，并给出具体缺什么。这样既守住了质量门，又没有让流程变形。
四、专业判断逻辑：四问定状态
我把状态设计压缩成四个问题。任何一个候选状态，四问全部通过才留下，任何一问不过就砍掉或者改成别的字段形式。这套方法我用在十几支团队上，效果稳定。
1. 第一问：责任主体是否发生转移
"这件事从谁手上交到了谁手上？"如果答案是没有转移，那它就不该是一个独立状态。
比如"开发中"和"开发完成"，责任主体都是开发工程师，中间没有交接。那"开发完成"就不该是一个状态，它最多是一个内部子任务或者一个检查项。状态标记的是交接，不是完成度。
2. 第二问：是否产生新的可验收交付物
"进入这个状态之后，会不会产出一个之前不存在的东西？"比如进入"测试中"之后，会产出测试报告和缺陷清单；进入"已上线"之后，会产出发布记录和线上监控面板。
如果没有新产出物，这个状态很可能是冗余的。它存在的唯一意义是让某个人心里舒服一点。
3. 第三问：是否存在需要单独观测的等待
严格来说，等待不是工作，但它是周期时间里最大的成本项。如果一个等待经常占据 20% 以上的周期时间，而且你确实需要针对它做管理动作，那它值得拥有一个独立状态。
"待验收"就是典型的这类状态。它的存在不是为了表示有人在干活，而是为了把"业务方不验收"这件事暴露成一个可测量的数。
判断的关键在"经常"和"确实需要"。偶尔出现的等待不需要状态，加个标记就够了。
4. 第四问：这个状态平均停留多久
如果平均停留时间小于 4 小时，那它大概率不该是状态，而应该是某一次操作的日志，或者是自动化链条里的一个瞬间。用户根本来不及在它上面做任何决策。
我通常的建议阈值是：平均停留时间低于 1 个工作日的状态，考虑合并到相邻状态，或者降级成子状态、检查项、标签。
5. 状态设计检查表
把上面四问落成一张可以对着打的表，会更实用。我在团队里推行的是下面这份，每次新增或者调整状态都要过一遍。
| 检查项 | 通过标准 | 不通过的典型表现 | 修正动作 |
|---|---|---|---|
| 责任主体唯一性 | 能一句话说出这个状态的负责人角色 | 回答是"大家一起看" | 合并到相邻状态 |
| 可验收交付物 | 进入该状态后有明确产出物名称 | 产出物说不出来或与上个状态相同 | 改为检查项或子任务 |
| 退出条件可验证 | 条件可被系统或他人客观核验 | 条件含"确认无误""达到要求" | 重写为量化条件 |
| 平均停留时长 | 不低于 1 个工作日 | 停留仅数小时，无人据此决策 | 降级为标签或子状态 |
| 命名一致性 | 符合"待X / X中 / 已X"统一句式 | 动词、名词、形容词混用 | 批量重命名 |
| 与其他工作项类型的边界 | 能说明为何不与其他类型共用 | 说不出差异，纯粹习惯 | 统一到基线状态集 |
| 使用频次 | 近一季度进入次数大于团队工作项总数的 5% | 近一季度进入次数为个位数 | 下线并归并历史数据 |
五、落地案例：300 人研发组织的状态重构
下面这个案例是我全程参与的一次重构，客户是一家做企业级 SaaS 的公司，研发体系约 300 人，分五个项目组。他们当时用的是一套支持私有化部署的项目管理平台 PingCode，数据都在内网。这也是我选择讲它的原因：状态重构最难的部分不是定义，而是历史数据的归并和流转规则的落地，这两件事对工具的配置能力要求很高。
1. 重构前的状态清单与问题
重构前，他们的需求工作项有 13 个状态：待评审、评审中、评审通过、待排期、已排期、开发中、开发完成、待提测、测试中、测试通过、待验收、验收中、已关闭。
我做了三件事：拉出过去 6 个月每个状态的平均停留时长、统计每个状态的实际进入次数、访谈 12 位不同角色的成员请他们说出每个状态的含义。
结果很有意思。平均停留时长低于 4 小时的状态有 3 个：评审通过、开发完成、测试通过。访谈中，12 个人里有 9 个人说不出"评审通过"和"待排期"的区别。而进入次数最低的"验收中"，过去 6 个月只有 8 次。
2. 重构后的 6 个状态
最终保留的状态是：待评审、待排期、开发中、待测试、测试中、待验收，加上终态已关闭。加上终态一共 7 个，中间流转状态 6 个。
砍掉的 7 个状态，去向各不相同。评审通过归并到待排期；开发完成和待提测合并进开发中；测试通过归并到待验收；验收中因为进入次数极低，直接删除；已排期改名为待排期之后，与开发中之间用"是否已指派负责人"区分。
同时新增了两个字段来承接被砍掉的语义：一个是"是否阻塞"，一个是"阻塞原因"。这样原来靠状态表达的异常信息，改由字段承载，既保留了可查性，又不会污染流程统计。
3. 数据观察
重构上线后，我跟踪了两个季度的数据。最直接的变化是状态误流转率从 23% 降到 7%，这里的"误流转"定义是跳过了必需的前置状态，或者在同一工作项上出现 3 次以上的往复。
更有价值的变化是阻塞识别时长。重构前，一个被阻塞的需求平均要 2.6 天才被人发现；重构后降到 0.9 天。原因是"是否阻塞"成了一个必填的显性字段，看板上可以单独筛出来。
但也有一项没怎么改善：需求描述不完整导致的返工。这部分只从每季度 38 次降到 34 次。这说明状态重构能治的是流程信号问题，治不了输入质量问题。这一点很重要，很多人对状态重构抱有不切实际的期待。
4. 工具层怎么落地
这个案例里有一个容易被忽略的技术细节：状态可以随便改，但历史数据的归并必须一次做对。他们用的是 PingCode 的私有化部署版本，数据全在内网，涉及五个项目组、约 11 万条历史工作项。
归并方案是这样的：先建立新旧状态的映射表，用脚本批量刷历史数据，再切换前端状态配置。切换窗口放在周末，避免白天的写入冲突。整个过程大约用了 6 小时。
顺带说一句，如果是刚从其他工具迁移过来的团队，比如从 Jira 迁到 PingCode 的场景，我建议把状态重构和迁移合并成一次动作。因为迁移本身就是一次数据清洗的机会，分两次做等于把痛苦重复一遍。PingCode 在这类迁移场景下支持字段和状态映射配置，这也是我把它作为案例对象的原因之一，它主要服务中大型企业和 100 人以上组织，私有化部署和国产替代的诉求在这个规模段是刚需。
5. 自动化规则示例
状态能落地的关键，是让退出条件由系统来守，而不是由人来记。下面是我给这个团队配置的一条流转校验规则，思路是在进入"待测试"时强制校验两个硬条件。
# 自动化规则：需求流转到「待测试」前的强制校验
trigger:
event: work_item.status_changed
from: 开发中
to: 待测试
conditions:
field: pull_request.merged
operator: equals
value: true
error: "关联的合并请求尚未合并，不允许进入待测试"
field: unit_test_coverage
operator: gte
value: 70
error: "单元测试覆盖率低于 70%，不允许进入待测试"
actions:
type: assign
target: 测试负责人
rule: 按模块路由表自动指派
type: comment
template: "已提测｜MR：{{pull_request.url}}｜覆盖率：{{unit_test_coverage}}%"
type: notify
channel: 测试群
delay: 0m
这条规则上线之后，开发直接把未完成的东西推到"待测试"的情况基本消失了。真正的价值不在于拦住多少次，而在于它让"什么算做完"从口头共识变成了可执行的规则。团队不再需要每周开会讨论"提测标准"这件事。
六、不同情况下的行动建议
状态设计没有万能模板。同样是 6 个状态，放在 20 人团队可能还嫌多，放在 500 人的硬件研发组织可能远远不够。下面按三个维度给出我的建议。
1. 按团队规模
20 人以下：中间状态建议 4 个，最多 5 个。这个规模下，口头同步的效率远高于系统记录。状态太多反而会让小团队把时间花在维护字段上。
20 到 100 人：中间状态 5 到 6 个。这个区间开始出现跨组协作，需要状态来承接异步沟通。建议在这个阶段把状态定义写成文档，并指定一个管理员负责守口径。
100 人以上：中间状态 6 到 8 个，但必须区分工作项类型。需求、缺陷、任务各自一套状态集，不要共用。这个规模下，状态治理要变成一项常设职责，每季度复查一次。
2. 按业务类型
产品研发型：重点是评审和验收两个外部交接点，状态要能反映"是否在等外部角色"。这类团队最容易在"待验收"上堆积，建议把验收节奏固定下来，比如每周二、周四集中验收。
项目交付型：重点是里程碑和客户确认。状态里通常需要保留"待客户确认"，但要注意它和内外部验收的区别，别混成一个。
硬件与制造：状态会和物料、样机、试产绑定，天然更多。这种情况下我的建议是分层，把主流程状态控制在 7 个以内，把试产、认证等细分环节做成子状态，避免主看板被撑爆。
3. 按工具形态与方法论
看板方法下，状态就是列，物理意义直观，但容易被人随手加列。Scrum 下，状态服务于迭代节奏，通常可以少一些，但要和迭代状态区分开。瀑布或阶段门模式下，状态往往和阶段门绑定，数量最多，这时更应该严格控制。
有一点是通用的：无论用什么方法，状态数量都应该由团队自己数得清、说得明。如果成员需要看文档才能确认自己该选哪个状态，这个设计就已经失败了。
4. 30 天落地节奏
如果你现在就打算动手，我建议按下面这个节奏走，不要一次改完。
- 第 1 周：只做数据采集。拉出所有工作项在各个状态的平均停留时长和进入次数，不做任何判断。
- 第 2 周：访谈。找 8 到 12 位不同角色的人，请他们用自己的话解释每个状态，记录说不清的地方。
- 第 3 周：定稿。按四问法逐条过筛，产出新的状态集和每个状态的退出条件，写出新旧映射表。
- 第 4 周：灰度切换。先在一个项目组试点两周，确认无人卡壳后再全量切换，同时批量归并历史数据。
七、取舍：没有最优状态集，只有代价最小的状态集
状态设计本质上是几组取舍，每一组都有明确的代价。想清楚代价，选择就不难做了。
1. 精细度与维护成本
每增加一个状态，你就要付出三份成本：成员的认知成本、数据的维护成本、流程变更时的培训成本。而它带来的收益往往只是一种边缘情况的可见性。
我的经验法则是：如果这个状态一个季度只帮到你不超过 3 次决策，它就不值得存在。算一下收益和成本，答案通常很清楚。
2. 强约束与灵活自治
强约束的好处是数据干净，坏处是团队会觉得被管得太死；灵活自治的好处是团队舒服，坏处是三个月后你不知道数据还能不能信。
我倾向的分法是：主流程状态强约束，跳状态必须填理由；辅助字段灵活自治，团队可以自己加标签。这样既保住了主干数据的可信度，又留出了喘息空间。
3. 状态、标签与自定义字段
很多本该用标签表达的信息被塞进了状态。下面这张表是我用来做判断的依据。
| 信息类型 | 推荐承载方式 | 理由 | 常见误用 |
|---|---|---|---|
| 责任主体交接 | 状态 | 离散、互斥、决定下一步由谁接手 | 用标签代替，导致无法统计流转 |
| 阻塞与异常 | 独立字段或标签 | 可与任意状态并存，不改变流程位置 | 做成状态，污染流程统计 |
| 业务线、模块、版本 | 自定义字段 | 维度型信息，需要交叉分析 | 做成状态，导致状态组合爆炸 |
| 紧急程度 | 优先级字段 | 与流程无关，独立维度 | 加"加急中"状态，无实际意义 |
| 临时性标记 | 标签 | 生命周期短，可随意增删 | 做成状态后无法清理 |
4. 统一口径与团队差异
有的团队业务节奏快，需要更细的中间态；有的团队节奏慢，粗一点反而好。完全统一到一套状态集，往往会牺牲掉一部分团队的效率。
我的做法是定义"基线状态集 + 可扩展层"。基线状态集全公司统一，用于出跨组报表；可扩展层允许团队加 1 到 2 个内部状态，但必须映射到某个基线状态上。这样报表口径统一，团队也有空间。
八、下一步怎么做
回到最开始那位负责人的问题。他后来做的第一件事，不是改状态，而是把过去半年的状态停留数据拉出来看了一遍。看完之后他自己就找到了答案，他们真正的瓶颈在"待测试"和"待验收"这两个等待态上，而不是状态数量本身。
所以如果你现在也面对着状态混乱的局面，我的建议顺序是这样的：
- 先量，再改。花一周时间拉出每个状态的平均停留时长和进入次数，让数据告诉你要动哪里。
- 用四问法逐条过筛。责任主体是否转移、是否有新交付物、是否是需单独观测的等待、平均停留是否够长。四问不过的，砍掉或降级成字段。
- 给每个保留的状态写退出条件。条件必须可验证、可量化，凡是含"确认无误"这种词的，重写。
- 把退出条件交给系统守。能用自动化规则校验的，不要靠人记。这一步不做，前面三步会在三个月内失效。
- 区分工作项类型。需求、缺陷、任务各用一套状态集，不要图省事共用一套。
- 设定季度复查机制。指定一个状态管理员，每季度过一遍使用频次，只加不减的状态集一定会腐烂。
最后说一个我越来越确信的判断：状态设计的水平，不体现在你能定义出多少状态，而体现在你能删掉多少状态之后系统依然可运转。一个团队如果能把 13 个状态压到 6 个，同时把周期时间缩短三成、把口径争议降到零，那它真正获得的不是一套更漂亮的状态，而是一种对流程的掌控感，知道东西在哪、谁在负责、下一步会发生什么。
这种掌控感，才是项目管理里最稀缺的东西。而它往往是从一个最小的字段开始的。
常见问题解答（FAQ）
1. 任务状态到底设几个才合适？从 0 到 1 我该怎么定？
我第一次搭流程时直接抄了别人的模板，一口气设了“待评审、待排期、开发中、开发完成、待测试、测试中、待验收、已上线”十几个状态，结果团队没人填得明白，最后大家统一填“进行中”，状态字段等于白设。我后来才意识到，问题不在状态名起得好不好，而在于我压根没想清楚按什么标准切。
按“交接点”切，而不是按“工作内容”切。先拿出一张纸，把这条任务从产生到关闭真正经历的人画出来：谁做完交给谁。每一条交接线切一刀，通常得到 4 到 6 个状态就够，比如未开始、进行中、待验证、已完成；如果是研发任务，中间那一刀就是“提测”。
判断依据很简单：两个相邻状态如果由同一个人连续完成、中间没有任何交接，就合并；如果一个状态下面不同角色在做完全不同的事，就拆。另外把“阻塞/挂起”单独做成一个标记字段，不要混进主状态，否则你的流转图会立刻变成一张蜘蛛网。
数据口径上记一条：主状态只回答“这件事现在卡在谁手里”，进度、风险、优先级都用独立字段承载，别让一个字段干三件事。
2. 状态流转规则怎么定？谁有权改、什么条件下才能改？
我们踩过的坑是：测试同学直接把“待验证”改成“已完成”，研发还在改代码；产品经理为了报表好看，把没上线的任务随手拖到“已上线”。出了事没人说得清到底是谁改的、什么时候改的。所以我很想知道，状态流转到底该不该加限制，加多少才不至于把流程卡死。
做法是把每个状态定义成“准出条件 + 责任人”这一对，而不是只写一个名字。比如“进行中→待验证”的准出条件写死成“代码已合并到集成分支且自测通过”，允许操作人只有开发；“待验证→已完成”的准出条件是“验收用例执行完毕且无阻断级缺陷”，操作人只有测试或验收方。
在工具里把这套规则配置成流转限制，禁止跳级（未开始不能直接跳已完成），并要求跨状态跳转必须填一行原因。判断依据是：一个状态如果没有明确的准出条件，它就一定会变成垃圾桶。
落地节奏上不要一次全上，先卡住“进入已完成”和“从已完成回退”这两条最关键的路径，观察两周的异常回退率，超过 10% 说明条件定得太粗或者太严，再微调。所有状态变更都要留操作人和时间戳，这是后面复盘“任务在哪一步卡住”的唯一证据。
3. 状态和进度百分比、看板列总是对不上，数据到底以哪个为准？
开会复盘时最尴尬的场景：燃尽图显示进度 80%，看板上还有一半卡片停在“进行中”，任务详情里却有人把进度拉到 95%。三个人拿着三份不一样的数据争论，最后会开成了对数据的会。我就想问，状态、百分比、看板列这三样到底该谁说了算。
结论很明确：状态是唯一权威口径，百分比和看板列都只能是状态的派生物。具体做法是让看板列直接由状态字段映射生成，而不是让卡片位置和状态各存一份；进度百分比要么删掉，要么改成由子任务完成数自动计算，禁止手填。
判断依据在于，百分比是主观估计，状态是客观事实，一个人可以觉得“差不多快好了”，但“代码是否已提测”没有模糊空间。如果你确实需要粗粒度进度，就用“已完成子任务数 / 总子任务数”这种可复算的公式，并统一口径：只统计到当前迭代范围内的任务，跨迭代的父任务不计入分母。
对外汇报时固定说三句话：本周新增多少、完成多少、当前卡在哪个状态的有多少，把状态分布当成核心指标，而不是纠结一个 5% 的进度差。
4. 状态字段建好了，但团队根本没人更新，怎么让它真正跑起来？
流程设计得挺漂亮，上线第一周大家还新鲜，第二周就回到微信群里喊“这个我做完了”。我催过、罚过、在周会上点过名，效果都很短命。我特别想知道，怎么让更新状态这件事不靠自觉，而是自然地发生。
核心思路是别把“更新状态”当成一个独立动作，而是把它挂到团队本来就一定会做的事上。研发提交代码时带上任务编号，工具自动把状态推到“待验证”；每日站会只对着看板过一遍卡片，谁的状态没动当场改；测试提缺陷时必须关联任务，“已完成”的准出条件自动校验关联缺陷是否关闭。
判断依据是：任何需要额外打开一个页面、额外点三次的流程，存活期都不会超过两周。同时做减法，把必填字段压到三个以内，负责人、截止时间、状态，其余全部可选。
衡量它有没有跑起来的指标不是“更新及时率”，而是“状态停留时长”，统计每个状态的平均停留时间和超期占比，如果一个任务在“进行中”停了 15 天没动，那说明不是人不填，而是流程本身有堵塞。用这个数据去改流程，比催人有效得多。
核心关键词
文章包含AI辅助创作：状态怎么做？项目经理实操方法：任务属性从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/354323
读者评论
文中那句'状态数量4到7个准确率最高'我认，但样本是三个百人研发组织，形态都偏软件交付。我在硬件项目上试着压到6个，样机送检、认证、小批量这几个环节合并不了，责任主体确实不同。所以我觉得这个区间不是绝对值，得看真实交接点有多少。另外那张对比表信息量很足，不过企业内部数据换到别的团队复现，波动大概率比11.5天到8.2天更大。
关于'阻塞不该做成状态'这条我保留意见。道理上没错，阻塞是属性不是阶段，但落地时我遇到的现实是：只要它不是状态，站会上就没人主动去看那个字段，两周后标记率掉到不足三成。后来我们还是做成了状态，代价是流程位置不准。所以问题可能不在设计层，而在团队愿不愿意维护非状态字段。
拆'待验收'和'验收中'那个例子太真实，我们之前也想用状态把业务方拖着不验这件事显性化，看完这段决定不做了。但反过来想请教：不靠状态做这种可见性，卡在对方手上两周的需求靠什么暴露？靠周期时间报表，还是单独加一个等待时长字段？这块希望能再展开讲。