状态怎么做？跨部门团队实操方法：任务属性从0到1

上个月我参与复盘一家工业设备 SaaS 公司的发布事故。上线前三天，项目经理拉出看板，所有需求都显示“已完成”，于是判定按期发布没问题。发布当天上午，测试负责人说：有 11 个需求根本没提测。开发负责人回答得更直接：我们填“已完成”，指的是代码写完了。

同一块看板，同一个状态，两个角色的理解差了一整个测试周期。这不是工具的问题，是状态定义的问题。这件事让我重新梳理了过去几年在十几家跨部门团队做流程落地的经验，也构成了这篇文章要讲的全部内容：状态到底该怎么做，尤其是任务属性从 0 到 1 的那一步，怎么迈才不返工。

我见过把状态做到 16 个、流程依然一团乱的团队，也见过只用 5 个状态、跨部门协作顺畅得让人羡慕的团队。差别不在数量，在于每个状态是否对应一次真实的责任交接。下面我会把结论、场景、误区、判断逻辑、实操步骤、数据观察和取舍条件全部摊开讲，你可以直接照着改自己团队的状态设计。

一、先说结论：状态是责任交接的契约，不是进度的形容词

大部分团队设计状态时的默认思路是“让老板一眼看出进度”，于是状态变成了形容词的堆砌：进行中、跟进中、处理中、待确认、基本完成、即将上线。这套东西在单团队内勉强能用，一旦跨部门就会崩，因为形容词没有判定标准。

我的核心结论是：状态的第一职责不是表达进度，而是标记责任的转移。每一条状态边，都应该对应“谁把什么东西交给了谁”。如果一个状态的存在，无法回答“谁欠谁什么”，它就应该被删掉。

1. 好状态集合要满足三个硬条件

第一个条件是互斥。任何一个工作项，在任意时刻只能落在一个状态里，不能同时“开发中”又“待测试”。听起来像废话，但我做过统计，在没做过状态治理的团队里，大约三成的工作项在字段上是可同时成立的，因为他们把“阶段”和“结论”混在了一个字段里。

第二个条件是可判定。判定权必须交给一个具体角色，而不是交给感觉。比如“已完成”到底由谁判定？如果由开发自己判定，它等于“编码完成”；如果由测试判定，它等于“验证通过”。同一个词，判定权不同，含义天差地别。你必须在状态定义里写清楚：谁有权把工作项推进到这个状态。

第三个条件是可回退且回退有痕。真实项目里状态一定会倒退，从“测试中”退回“开发中”是常态。很多团队因为不想看到回退，干脆不给回退路径，结果大家用“新建一个相似任务”绕过去，数据彻底失真。允许回退、但记录回退次数和原因，比禁止回退健康得多。

2. 一个反常识判断：状态越多，协作往往越差

很多管理者觉得状态越细，过程越透明。我的观察恰恰相反：在缺少准入准出条件的前提下，状态数量与协作误解率是正相关的。因为每增加一个状态，就增加一次“这个状态到底算不算做完”的解释成本，而解释成本最终会转化成例会上的扯皮时间。

我做过一组内部对比：把同一家公司的两个业务线拿出来，A 线用 6 个状态，B 线用 13 个状态，两个线的需求规模和人员配置接近。三个月里，A 线的跨部门例会上平均每场关于“这个到底算不算完成”的争论时间是 4 分钟，B 线是 17 分钟。B 线多出来的 9 个小时月度会议成本，换来的是更少的进度确定性。

3. 判断一段状态设计好坏，只需要问一个问题

我每次做流程诊断，都会拿着一张状态图问负责人一句话：“如果我明天离职，接手的人只看这张图，能不能在半小时内搞清楚每个状态该找谁、要什么、给什么？”

回答不上来，说明状态图表达的是流程的名字，而不是责任的结构。名字可以随口起，结构必须能对上人和物。这是我判断一套状态设计能不能上线的唯一门槛，比任何流程图规范都好用。

二、背景与真实场景：跨部门状态崩坏的三种典型形态

为什么单团队内能用，跨部门就崩？因为跨部门协作的本质是接口协作：开发、测试、产品、运维、实施、客户成功各自有自己的一套语言习惯，而状态是这些语言第一次发生碰撞的地方。碰撞一旦没有统一翻译，就会出现下面三种崩坏。

1. 同词不同义：一个“已完成”，四种理解

我在一家做企业服务的公司做过一次盲测。把同一个状态词“已完成”分别给产品、开发、测试、实施四个角色，让他们用一句话定义。得到的答案是：

• 产品经理：需求描述里的功能点我已经验收过一遍了。
• 开发工程师：代码合并进主干，本地自测通过。
• 测试工程师：用例执行完毕，没有阻塞级缺陷。
• 实施顾问：客户环境部署完，客户方对接人已知晓。

四个答案指向四个完全不同的物理事实，时间跨度可能相差两周以上。而当这四个人在同一个看板上看到满屏的“已完成”，他们会各自得出“项目快结束了”的结论。这不是沟通问题，是状态定义缺少“物理事实锚点”。

2. 状态跳变与回退：看板上的时间线全是断点

第二种崩坏是状态跳跃。典型表现是工作项从“待处理”直接跳到“已完成”，中间状态一次都没经过。很多管理者第一反应是“大家不认真更新”，但我追查过原因，八成是状态流转的操作成本高于记录收益。

举个具体场景：一个开发在晚上十点修完一个缺陷，想把它推到“待测试”，但系统要求他必须填写“修复版本号、影响模块、自测结论”三个字段才能流转。他选了“已完成”，因为那个状态的必填字段少。第二天测试看到的是“已完成”，就不会去测。

这类问题的根因在配置，不在人。状态机必须做到“想跳过就必须付代价”：关键状态设置必填校验和权限限制，让跳变在物理上不可行，而不是靠自觉。同时要给正常路径足够低的摩擦，否则大家总会找到绕过的方式。

3. 状态与物理事实脱节：看板绿油油，客户在骂人

第三种最危险。看板上一切正常，实际交付已经出问题。我遇到过一家公司的状态停留在“待客户确认”整整 23 天，因为没人规定这个状态的超时规则，负责人以为对方在走内部流程，客户以为对方在开发，双方都在等。

状态如果没有超时规则，就等于把不确定性藏进了系统里。我现在的做法是：任何状态只要进入“等待他人”的语义，就必须配一个默认停留时长，超时自动升级提醒到上一层管理者，而不是继续沉默。

三、五个最常见的状态设计误区

说完场景，我们把误区拆开。下面五条是我在做流程诊断时命中率最高的，你大概率能对上两三条。

1. 用状态描述进度百分比

典型代表是“开发 30%”“开发 70%”这类状态。问题在于，百分比是结果度量，不是状态。状态应该回答“现在在谁手里、卡在什么条件上”，而百分比回答不了任何可执行的问题。当一个人看到“70%”，他既不知道自己该做什么，也不知道该找谁。

如果你确实需要百分比，把它做成一个独立字段，由负责人手工维护，并且明确它只用于汇报，不参与任何流转判断。状态字段和进度字段必须分离，这是跨部门协作的底线。

2. 状态里混入“人”和“情绪”

“待确认”“跟进中”“协调中”“待反馈”这类状态，本质上描述的是某个人正在做的事，而不是工作项所处的位置。它们的问题是无法判定：什么叫“跟进中”？跟进了五分钟算，三天没动静也算。

我的处理方式是做一次翻译：“待确认”拆成“待产品确认需求边界”和“待客户确认验收结论”，两个状态，两个责任人，两个超时规则。翻译完你会发现，很多模糊状态其实是两个甚至三个真实交接点被压缩成了一个词。

3. 状态与角色权限不绑定

这是最容易被忽略的一条。状态定义写得再清楚，如果没有权限约束，它就只是建议。我在一家公司看到过测试人员直接把缺陷改回“开发中”并填写“已修复”的情况，不是恶意，是因为他手快点了错的下拉框，而系统允许。

正确做法是：每个状态至少要有一个“能进入”的角色白名单，和一个“能离开”的角色白名单。开发可以把任务推进到“待测试”，但不能把它推进到“已验收”；测试可以把任务推进到“已验收”，但不能把它退回“待开发”，退回必须走缺陷单。权限即规则，规则不落到权限上就是废纸。

4. 需求状态和任务状态混用一个字段

跨部门团队通常至少有两层工作项：需求（或用户故事）和任务（或子任务）。这两层的状态语义完全不同。需求的状态回答“这个东西能不能交付给客户”，任务的状态回答“这件事在我手里做完了没有”。

把它们塞进同一个状态集合，就会出现“一个需求下面 6 个任务都完成了，需求却还在‘开发中’”的尴尬。因为需求需要等测试、等验收，而任务不需要。分层设计状态，是跨部门团队从 0 到 1 最不能省的一步。

5. 只设计状态，不设计治理

最后一条是元问题。大部分团队把状态当成一次性配置，配完就再也不看。但组织会变、角色会变、交付方式会变，一年前的状态集合，几乎不可能还适配今天的协作方式。

我的建议是给状态设计配一个最小治理机制：每季度看三个数字，状态跳变率、状态平均停留时长、状态回退次数。任何一个数字出现趋势性异常，就说明有状态定义已经和现实脱节了。状态不是配置项，是需要持续维护的资产。

四、专业判断逻辑：从“责任交接点”反推状态

前面讲的是不该做什么，接下来讲该怎么做。我的方法只有一条主线：不要从流程图出发设计状态，要从责任链出发反推状态。流程图是理想化的，责任链是真实发生的。

1. 第一步：把责任链画出来，而不是把流程图画出来

责任链的画法很简单，用一句话格式填：“A 把 X 交给 B，B 拿它做什么，产出 Y 交给 C。”一段跨部门交付通常能拆出 5 到 9 段这样的句子。

举个真实例子，某 B 端产品的需求交付责任链是这样：

1. 产品把需求描述交给开发，开发评估可行性并给出排期。
2. 开发把可运行版本交给测试，测试执行用例。
3. 测试把验证结论交给产品，产品做功能验收。
4. 产品把验收通过的需求交给实施，实施部署到客户环境。
5. 实施把上线结果交给客户成功，客户成功推进客户确认。

注意，这五段里没有一个字提到“状态”，但每一段的边界，天然就是一个状态节点。责任链是状态的原矿，流程图只是它的投影。

2. 第二步：把交接点翻译成状态，而不是把动作翻译成状态

这一步最容易出错。很多人会把“开发在写代码”翻译成一个状态“开发中”，实际上“开发中”不是交接点，它是一段持续过程。真正的交接点只有一个：开发把版本交出去的那一刻。

所以上面那条责任链，正确的状态集合应该是：

• 待评估（开发还没确认可行性，责任在产品）
• 待开发（已排期，责任在开发）
• 待测试（版本已交付，责任在测试）
• 待验收（测试已出结论，责任在产品）
• 待部署（验收通过，责任在实施）
• 待客户确认（已部署，责任在客户成功）
• 已关闭（客户确认或明确接受）

六个激活状态加一个终态，覆盖了全部五个交接点。你会发现，这里面没有“进行中”，因为“进行中”不是一个责任归属，它只是“某人在干活”的统称。如果你找不到这个状态的责任人是谁，就不要让它出现在状态集合里。

3. 第三步：为每个状态写准入条件和准出条件

状态定义只有名字是没有用的，必须配两个条件。准入条件回答“满足什么才能进入这个状态”，准出条件回答“满足什么才能离开”。这两个条件要写成可验证的句式，避免出现“基本完成”“大致确认”这类词。

以“待测试”为例，我通常这么写：

• 准入条件：代码已合并至主干；构建产物已生成且构建流水线通过；开发自测用例已执行并记录；提测说明已填写（含影响范围、回归建议、已知问题）。
• 准出条件：测试用例执行率 100%；阻塞级与严重级缺陷为 0；遗留缺陷已标注并得到产品确认；测试报告已归档。

写到这里你会发现一件事：条件写清楚之后，状态字段本身其实变得很轻，真正起作用的是那些必填字段和校验规则。状态是壳，准入准出条件才是肉。

4. 第四步：做减法，删掉所有不可判定的状态

做完前面三步，通常会得到 10 个以上的状态。这时候要做一轮冷酷的减法，判断标准只有一条：这个状态有没有独立的判定人，且判定动作会不会改变下一步的协作行为？

两个都答“是”的保留，答“否”的删掉或合并。我经手的案例里，一轮减法平均能砍掉 30% 到 40% 的状态，而协作清晰度反而提升，因为剩下的每个状态都对应一个真实动作。

五、从 0 到 1 的实操：六步落地法（含 PingCode 配置示例）

逻辑讲完了，接下来是执行。这套六步法我在中大型团队用得最多，因为跨部门协作的复杂度主要出现在 100 人以上的组织里。PingCode 这类面向中大型企业、主要服务 100 人以上组织的研发管理平台，恰好把这个规模段的配置需求做得比较完整，我下面会结合它的配置方式讲，其他工具同样可以对照操作。

1. 第一步：收集口语状态词，而不是直接抄模板

不要一上来就打开模板库。先做一件事：把跨部门例会录音，或者让每个角色写下“过去一周你在群里说过的所有描述进度的词”。我做过一次，一个 40 人的项目组收集到 63 个口语状态词。

这 63 个词是真实语言，模板里的状态是规范语言。直接上规范语言，团队会看不懂；直接用真实语言，流程会失控。正确做法是把真实语言作为输入，用前面的责任链方法收敛成规范集合，然后在状态字段旁边挂一个“同义词说明”，让旧词能映射到新状态，过渡期至少保留一个季度。

2. 第二步：画责任链，标出所有交接点

这一步建议用白板做，不要用工具。把参与交付的每个角色列出来，逐段写“谁把什么交给谁”。写完一条就在交接点上贴一张便签。整个工作坊控制在 90 分钟内，超过这个时间说明参与的人太多，需要拆成两个场景分别做。

工作坊的产出物是一张责任链图加一批便签，这批便签就是候选状态。我会在这一步同步记录每个交接点的典型等待时长，因为它直接决定后面超时规则设多少。

3. 第三步：定义状态集合与准入准出条件

把便签收敛成状态，写出准入准出条件，明确每个状态的判定角色。这一步产出的文档我通常控制在一页以内，格式固定为：状态名、责任人、准入条件、准出条件、超时规则。

特别提醒一点：终态要区分“正常关闭”和“取消关闭”。很多团队只有一个“已关闭”，导致统计交付周期时把取消的需求也算进去了，数据严重失真。分开之后，你的周期统计才有意义。

4. 第四步：在工具里落地状态机与权限

这是最容易偷工减料的一步。工具配置的关键不是把状态名字敲进去，而是把规则变成系统约束。以 PingCode 为例，我通常会做四件事：

1. 按工作项类型分层配置状态集合，需求、任务、缺陷各自独立，不共用一套状态。
2. 配置状态流转规则，限制哪些角色可以从哪个状态推进到哪个状态，把跳变路径直接封死。
3. 为关键状态设置必填字段校验，比如进入“待测试”必须填提测说明和影响范围。
4. 配置超时提醒和自动升级，等待类状态超过阈值就通知上一层负责人。

如果你是从其他工具迁移过来的，状态映射是最耗时也最容易出错的环节。PingCode 支持从主流工具平滑迁移，我在实操中会先做一张映射表，把旧状态逐个对到新状态，把无法对应的状态单独列出来人工判断，避免迁移后出现一批“孤儿状态”。一个典型的映射表长这样：

这张表最有价值的地方不是映射本身，而是最后一行。很多旧状态其实不该被映射成状态，而该被降级成字段。“阻塞”“待确认”“有风险”都属于这一类，它们描述的是属性，不是位置。

5. 第五步：两周试点，只盯两个指标

不要全量铺开。选一个跨部门协作最密集、问题最明显的小组，跑两周。这两周里只盯两个指标：状态跳变率和状态回退次数。

状态跳变率高，说明必填校验或权限还不够严，有人在绕过；回退次数异常，要看是质量问题还是定义问题。我通常会在试点期每天花 15 分钟看一遍当天所有状态变更记录，把异常流转截图发到项目群里问一句“这条为什么这么走”。两周下来，规则里不合理的地方会暴露得非常彻底。

6. 第六步：固化规则并建立季度治理机制

试点结束后不要马上全公司推广，先做两件事。第一件是把试点期发现的问题回填到状态定义文档里，形成 V1.1 版本；第二件是搭一个最小的状态健康看板，包含状态跳变率、平均停留时长、回退次数三个指标。

这个看板的意义在于，它让状态治理从“一次性项目”变成“常规运营”。没有度量的状态设计，一定会在半年内腐化回原样。这是我做过的十几个案例里最稳定的一条规律。

六、数据观察：改造前后的量化对比

讲完方法，说结果。我在一家约 200 人的研发组织做过完整的状态改造，前后各观察了三个月。数据不一定能复制到所有团队，但趋势有参考价值。

1. 三个核心指标的变化

改造前，这个组织用 14 个状态，跨 3 条产品线共用一套。改造后收敛到 7 个状态，需求、任务、缺陷分层设计。三个月后，三个指标的变化幅度都超出我的预期。

2. 十二周爬坡曲线：第三周才是最难的时候

有一点必须提醒：状态准确率不是上线当天就到位的。我记录了改造后 12 周的状态填写准确率（由抽样审计得出），第一周只有 68%，第二周升到 79%，然后第三周出现回落，掉到 74%。

原因是第二周大家还在“新鲜期”，第三周开始有紧急需求插进来，所有人第一反应都是先跳过流程干活。这个回落点如果没人管，改造基本就废了。我当时做的是在第三周加了一次全员同步，把跳变率最高的三条流转记录拿出来公开复盘，第四周之后曲线才稳定爬升。

3. 一个反例：把状态做到 14 个的团队后来怎么样了

同一年我见过另一个反向案例。一家做硬件配套软件的公司，管理层要求“过程完全透明”，把需求状态做到了 14 个，连“代码评审中”“单元测试中”“集成测试中”“回归测试中”都单独拆成状态。

结果三个月后，最活跃的三个状态占了全部流转记录量的 71%，其余 11 个状态合计不到 30%，其中 4 个状态在三个月里只被使用过个位数次。更麻烦的是，团队为了填这些状态，每个开发每天平均多花 12 分钟在流转操作上，一个月约 4 小时。这 4 小时换来的信息，管理层并没有真正使用。

状态数量应该由交接点数量决定，不是由管理层的安全感决定。这句话我在很多次复盘会上都说过，因为它几乎每次都能解释清楚“为什么流程越细越慢”。

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

状态设计没有通用答案，只有适配答案。下面按团队规模和协作形态分四类给建议，你可以直接对号入座。

1. 50 人以下、单产品线：状态越少越好

这个规模下，信息主要靠口头和即时通讯传递，工具状态的作用是留痕而不是协调。我的建议是控制在 4 到 5 个状态：待处理、进行中、待验证、已完成，加一个取消。不要做复杂的准入准出条件，只保留一个关键约束，把“已完成”的判定权交给验证方而不是执行方。

这个阶段最大的风险是过度设计。我见过 30 人团队配了 11 个状态加 4 层审批，最后所有人在群里同步进度，工具彻底闲置。人少的时候，状态的价值在于记录事实，不在于约束行为。

2. 100 到 500 人、多产品线：必须分层，必须绑权限

这是最需要状态治理的区间。跨部门的接口开始变多，口头同步失效，工具成为唯一可信源。我的建议是需求 6 到 8 个状态，任务 3 到 4 个状态，缺陷独立一套，并且严格绑定角色权限。

这个规模段也是私有化部署需求集中出现的地方。数据不能出内网、需要和内部账号体系打通、审计要求留存完整流转日志，这类诉求在 100 人以上的组织里非常普遍。PingCode 支持私有化部署，这一点在中大型企业选型时经常是关键决策项，因为状态流转日志本身就是审计材料的一部分。

如果你的团队之前用的是海外工具，迁移时特别注意一点：不要连旧状态一起搬过来。迁移是重新设计状态的最好时机，把旧工具积累的历史包袱一次性清掉，比沿用旧结构再慢慢改要省力得多。

3. 500 人以上或强合规行业：状态要可审计、可追溯

这个阶段状态设计的重心从“协作效率”转向“过程可追溯”。每个状态变更都要记录操作人、时间戳、变更原因，并且不可篡改。状态数量可以适度增加，但增加的每一个都必须有明确的合规依据，比如“待安全评审”“待合规确认”。

同时要建立状态字典的版本管理。规则变了，要能查到哪一天开始生效、影响哪些工作项。这一点在应对外部审计时非常重要，因为审计问的往往不是“现在什么规则”，而是“去年三月那条记录走的是什么规则”。

4. 从其他工具迁移过来的团队：先做减法，再做映射

迁移场景有个特殊风险：旧工具里的状态往往是历史沉积的产物，没人记得为什么会有。我的做法是先做一轮“使用率审计”，统计每个状态过去半年的流转次数，使用率低于 5% 的直接标记为候选删除，然后再做映射。

顺序不能颠倒。先映射再删，会把垃圾状态一起搬进新系统，之后再清理的成本要高得多。迁移是清理技术债的窗口期，错过就要等下一次。

八、取舍清单：什么情况下不该把状态做细

最后一部分讲取舍。前面所有内容都在讲怎么把状态做对，但更重要的是知道什么时候不该做。以下四种情况，我建议你主动放弃细化。

1. 探索性、方向未定的业务

如果一条业务线还在验证阶段，需求本身可能下周就被推翻，那么给它配 8 个状态就是浪费。这个阶段的正确做法是用两三个状态快速流转，把精力放在验证假设上。等到方向稳定、交付节奏可预测了，再补状态治理。

判断信号很简单：如果这条业务线的需求平均存活周期不到三周，就不要做精细状态。状态治理的收益建立在“流程会重复发生”的前提上。

2. 状态治理成本已经高于协作收益

这是一个动态判断。每次增加一个状态，你都要问：它带来的协作清晰度提升，能不能覆盖团队每天多花在流转上的时间？如果答案是“说不清”，那就不加。

我给一个粗略的经验阈值：如果新增状态的日均流转次数低于 2 次，或者日均停留时长超过 10 天，那它大概率不值得单独存在。前者的使用频率太低，后者的停留时间太长，都不足以支撑一个独立状态的管理成本。

3. 团队还没有稳定的角色边界

状态之所以能表达责任，前提是角色边界清晰。如果一个团队的测试和开发混着干、产品和实施是同一个人，那么按角色划分的状态就会失效。这种情况下先理角色，再理状态，顺序不能反。

我见过一个 20 人的团队硬套大厂状态模板，结果每个状态的责任人都是“大家”，最后所有人都不知道该谁推进。

4. 什么时候该停止扩展状态

给自己设一个停止信号：当新增状态带来的信息，已经可以被一个字段或标签表达时，就不要再加状态。“有风险”“被阻塞”“需要评审”都属于这一类，它们是属性，不是位置。

我现在做状态设计有一个默认上限：任何一层工作项的状态不超过 10 个。超过这个数，几乎一定是因为把属性和位置混在了一起。这时候要做的不是继续加状态，而是回头做一次属性剥离。

5. 状态改造的优先级排序建议

如果你现在就要动手，我建议按这个顺序推进，不要并行：

1. 先把“已完成”的判定权从执行方移到验证方，这一步零成本，收益最直接。
2. 再把等待类状态的超时规则补上，消除最长的那段隐性停留。
3. 然后处理跳变路径，用权限把关键流转锁死。
4. 最后才考虑增减状态数量，因为这一步的收益最慢、争议最大。
5. 全部完成后，搭一个含三个指标的健康看板，按季度复盘一次。

这五步下来，通常 6 到 8 周能看到明显变化。如果你的组织规模在 100 人以上、有私有化或数据合规要求，那么在选择承载这套状态机的平台时，把私有化部署能力和迁移路径的平滑度放在评估权重的前两位，会比单看功能列表更划算。PingCode 在这两点上是我在国产替代选型里推荐频率比较高的一个，主要服务中大型企业和 100 人以上组织，支持从主流工具平滑迁移，也能私有化部署，适合状态治理要长期跑下去的场景。

九、回到那个发布事故

回到开头那家工业设备 SaaS 公司。他们后来做的事情其实很简单：把“已完成”拆成“待测试”和“已验收”，前者由开发推进、后者由产品推进，并且在“待测试”上加了必填的提测说明。

就这三处改动，没有引入任何新工具，也没有增加任何审批环节。下一次发布前，项目经理看板上看到的是 11 个“待测试”，他当场就知道发布要推迟，而不是等到发布会当天才知道。

状态设计的价值从来不是让管理更好看，而是让坏消息提前被看见。这是我从十几轮流程改造里得到的最实在的结论：好的状态集合，是一套让问题无法被隐藏的结构。

如果你今天就想动手，我的建议是从一件事情开始：打开你团队现在的工作项，找出“已完成”这个状态，然后问三个问题，谁有权把它推进来？推进来的时候，物理上一定发生了什么？如果这个人明天离职，接手的人能不能凭现有记录判断它到底完成到哪一步？

三个问题里有任何一个答不上来，你就不需要继续往下设计了，先把这一个状态改清楚。跨部门协作的状态治理，从来不是靠一次性重构完成的，而是靠把每一个含糊的词，换成一次能被验证的交接。