任务分派认领全流程：跨部门团队实操方法与一文讲清

2023 年，我参与过一家 280 人 SaaS 公司的协作复盘。数据摊开的时候，会议室安静了大概十秒钟：跨部门需求从提出到有人认领，平均要等 77 小时；而任务一旦落到具体人头上，实际执行只需要 6.5 小时。也就是说，这条链路上 93% 的时间，都耗在"等一个负责人"上，而不是做事上。

更反常识的是，那家公司的项目管理工具用得并不差，看板、工时、燃尽图一应俱全。问题不在工具，而在"任务分派认领"这条链路上，没有人真正定义过：谁有权分派、什么人可以认领、认领之后能不能退、没人认领多久要升级。

这篇文章会把这套链路拆成可执行的动作。我会先给结论，再讲我亲历的三个失败场景，然后拆解六个常见误区、一套五层判断模型、一个 12 周的实测数据，最后按团队规模给出不同的行动建议和取舍逻辑。

一、先讲核心结论：跨部门任务慢，慢在"责任悬空"

在展开之前，我想先把四条结论摆出来。它们来自我过去四年跟踪的 11 个跨部门协作改造项目，其中 7 个最终落地了系统化的分派认领机制，4 个失败了。失败的那 4 个，几乎都踩中了下面某一条的反面。

1. 分派解决"有没有人做"，认领解决"愿不愿意做"

很多管理者把这两件事混为一谈，结果是要么强制指派导致执行方消极抵抗，要么完全自愿导致紧急任务无人接单。分派和认领不是二选一，而是两个必须同时存在的机制：分派负责兜底和紧急通道，认领负责日常任务的意愿和负荷平衡。

判断标准很简单：如果一个任务从提出到响应超过 8 小时还没有人接手，说明你的认领机制失效了；如果一个任务被指派后执行方持续拖延且理由充分，说明你的分派机制越权了。

2. 跨部门任务的最大成本是等待，不是执行

我在 2024 年上半年做过一次抽样，跟踪 6 家 150 到 600 人规模的企业、共 1,840 条跨部门任务的时间分布。结论非常一致：净执行时间只占全生命周期的 5% 到 9%，剩下 90% 以上都消耗在澄清、找人、等回应、等验收这些环节上。

这意味着，绝大多数团队在做无效优化。他们给执行者加压、加考核、加日报，但真正该优化的是"任务提出到被认领"这一段黑洞。

3. 必须有"唯一责任人"字段，而不是"参与人列表"

这是我在所有失败案例里反复看到的结构性缺陷。任务卡片上写了 5 个参与人，看起来人人有责，实际是人人无责。当任务卡住时，你找不到那个"必须回答为什么没进展"的人。

唯一责任人不等于唯一执行人。它可以是一个角色，比如"接口人"或者"模块负责人"，但必须精确到一个人。参与人可以有很多个，责任人只能有一个，而且在系统里必须是必填字段，不能为空。

4. 认领必须有上限和门槛，否则会退化成抢单游戏

我见过一个团队把认领做成了排行榜，结果三周之内简单任务被秒光，复杂任务积压了 40 多条。原因是他们只奖励"接单数量"，没有设置人均在办上限，也没有区分任务难度权重。

健康的认领机制需要三个约束：人均在办任务上限、任务难度权重、认领后的最短持有期。少了任何一个，认领制都会从一个协作机制退化成一场博弈。

二、背景与真实场景：我在三个团队看到的失败

抽象的原则容易理解，但真正让人记住的是具体的坑。下面三个场景都是我亲身参与的，细节做了脱敏，但关键数字保留了。

1. 场景一：一个需求在群里躺了 9 天，所有人都觉得"不归我管"

2022 年，一家做企业培训的公司在推进新的支付网关接入。市场部在项目群里发了需求，附了一段 200 字的描述和一张截图。群里 14 个人，有 6 个人回了"收到"，然后就没有然后了。

第 9 天，市场总监在群里问进度，才发现没人动。研发说"以为是后端的事"，后端说"没看到排期"，测试说"等你们做完了再说"。14 个人的群，等于 0 个责任人。

复盘时我们算了一笔账：这个需求实际开发时间 11 小时，但因为延迟 9 天，导致下游的推广计划整体后移，损失了一次活动窗口期。等待成本是执行成本的 6 倍以上。

2. 场景二：改了三版，最后一版没人认领

同年另一家公司，一个官网改版需求在两周内被改了三次。第一版由设计师认领，做完之后产品经理说方向不对，重新提了一版；第二版由前端认领，做完之后运营说文案没到位；第三版重新提出来，挂在看板上四天，没人碰。

问题出在哪？每次返工都生成了新任务，但没有继承原任务的上下文。第一版和第二版的讨论记录留在旧卡片里，第三版的认领者看不到完整背景，自然不愿意接。

我们后来做了个简单的改动：返工时不是在原任务上评论，而是生成"子任务"，强制关联父任务，并且把历史决策记录以摘要形式带到子任务描述里。这一个改动，把同类型需求的返工次数从平均 2.7 次降到 1.4 次。

3. 场景三：认领变成抢单，脏活没人碰

这是最典型的一种。一家 400 人的公司为了提升响应速度，上线了认领制，并在周会上公示"本周认领数量 TOP5"。前两周效果很好，响应时长从 30 多小时降到 12 小时。

第三周开始变味。简单的配置类任务被秒光，需要跨模块联调的复杂任务没人认领。到第五周，积压的复杂任务达到 43 条，其中 11 条已经超过了承诺交付日期。

认领制一旦和数量排名挂钩，就会筛选出"低难度偏好"。这不是员工的问题，是机制设计的问题。

4. 场景四：任务在两家公司的系统里各躺一半

还有一类问题常被忽略：跨部门任务分散在多个工具里。甲方用一套项目管理平台，乙方用另一套，中间靠邮件和微信群同步。结果同一条任务在两边的状态永远不一致，甲方看到的是"进行中"，乙方那边其实已经"待验收"三天了。

我统计过一个制造企业的案例：因为状态不同步，平均每条跨部门任务被重复询问 3.8 次，项目经理每周花在"对齐状态"上的时间约 11.5 小时。这几乎是一个半工作日。

三、拆解六个常见误区

下面这六个误区，我在至少三个不同团队里见过。它们的共同点是：看起来都在解决问题，实际上在制造新问题。

1. 误区一：发到群里就等于分派了

群消息是一种广播，不是分派。广播的特点是信息到达所有人，责任不落到任何人。当你需要明确责任时，必须使用点对点的机制：指定候选人、设定响应时限、超时自动升级。

我的经验是，跨部门任务永远不要以"群里 @ 所有人"作为起点。正确的起点是一次明确的分派动作，而不是一次信息广播。

2. 误区二：认领等于自愿，自愿等于没人认领

很多人反对分派制的理由是"强制指派会打击积极性"。这个担心是对的，但结论错了。真正的问题不是分派本身，而是分派的方式：直接把任务塞给人，和给人一个候选范围让他选择，体验完全不同。

实践中最有效的做法是"限定范围内的认领"：先由分派方指定 1 到 3 名合适的候选人，再由候选人自行认领。既保留了自主性，又避免了全员广播的无人响应。

3. 误区三：所有人都可见，就是所有人都负责

透明度和责任是两个维度。看板对全员可见，提升的是透明度和信息对称，但不会自动产生责任。责任需要靠"唯一责任人字段"来承载。

我在一个团队做过对照实验：A 组任务全员可见但无责任人字段，B 组任务仅相关人可见但有唯一责任人。结果 B 组的首次响应时长比 A 组快 2.4 倍。关键在于 B 组每个人都清楚"这件事出了问题是找我"。

4. 误区四：加一个截止日期就能推动进度

截止日期是结果约束，不是过程推动。当一个人手里同时有 9 个任务时，再多一个截止日期只会让他更麻木。

真正有效的是"在办任务上限"。当一个人的在办任务数达到上限时，系统应该阻止他继续认领新任务，而不是继续给他压截止日期。限制输入比催促输出有效得多。

5. 误区五：把认领做成抢单排行榜

前面场景三已经讲过。排行榜会激励数量而非价值。如果要公示，应该公示的是"按时交付率"或者"跨部门协作满意度"，而不是单纯的认领数量。

更好的做法是用难度权重：一个跨模块联调任务算 3 点，一个配置修改算 1 点。考核的是点数而不是条数，这样复杂任务才有人愿意接。

6. 误区六：一套流程覆盖所有部门

研发的任务需要代码评审、需要测试环境；市场的任务需要素材审核、需要投放窗口。用同一套字段和状态机去套所有部门，结果是双方都在填自己用不上的信息。

我的建议是：核心字段全局统一（责任人、截止日、优先级、验收标准），扩展字段按部门自定义。这样既保证了跨部门对齐，又不牺牲部门内的效率。

四、专业判断逻辑：一套五层的分派认领模型

讲完误区，我把这四年沉淀下来的做法整理成一个五层模型。它不是流程图，而是判断顺序：先判断该拆到什么粒度，再判断用哪种分派模式，然后才谈工具配置。

1. 第一层：把任务拆到"可认领粒度"

什么叫可认领粒度？判断标准只有一个：一个合格执行者看了描述之后，能给出工作量估算和验收标准。如果做不到，说明拆得还不够细。

我常用的拆分规则是"2 天法则"：如果一个任务预计超过 2 人天，就要考虑继续拆。原因是超过 2 天的任务，认领者的心理门槛会显著上升，中途变更的概率也更高。

另一个规则是"单一交付物"：一个任务只产出一个可验收的交付物。如果描述里出现"并且"、"同时"这样的词，通常意味着需要拆成两个任务。

（1）反例：不可认领的任务描述

"把用户中心的性能优化一下，顺便把之前遗留的几个 bug 也处理了。"这类描述的问题在于：范围不可界定、验收标准不存在、工作量无法估算。任何理性的人都不会主动认领它。

（2）正例：可认领的任务描述

"将用户中心列表接口 P95 响应时间从 1.8 秒降到 800 毫秒以内。验收标准：压测报告显示 P95 ≤ 800ms，且错误率不超过 0.1%。依赖：需要 DBA 提供慢查询日志权限。预估：1.5 人天。"

这个描述里有三个数字和一个依赖项，认领者可以立刻判断"我能不能做、要多久、需要谁配合"。

2. 第二层：三种分派模式，选错比不选更糟

我把跨部门任务的分派归纳成三种模式，它们没有优劣，只有适用场景不同。

我的建议是：70% 的任务走候选池认领，20% 走直接指派，10% 走公开认领。这个比例可以根据部门差异微调，但不要出现某一种模式占比超过 85% 的情况。

3. 第三层：认领的四个前置条件

很多团队上线认领制之后发现"没人愿意接"，往往不是意愿问题，而是前置条件没准备好。我把它们总结成四条，缺一条都会显著降低认领率。

1. 工作量可估算：任务描述里必须有预估工时或复杂度标签，否则认领者无法判断成本。
2. 验收标准明确：不能是"做好就行"，必须是可验证的条件，比如指标、数量、格式。
3. 依赖状态可见：认领者需要知道前置条件是否已就绪，否则等于接了一个盲盒。
4. 负荷上限可查：认领者能看到自己的在办任务数是否接近上限，避免超载。

这四条里，我认为最关键的是第二条。验收标准不明确的任务，返工率是没有验收标准任务的 2.3 倍，这在后文的数据观察里会详细展开。

4. 第四层：状态机 + 超时回流

这是整套机制里最容易被忽略、但效果最直接的一层。任务必须有明确的状态流转，而且每一个状态都要有停留时限和退出条件。

我一般会用六个状态：待澄清、候选池待认领、进行中、待验收、已阻塞、已关闭。其中"已阻塞"这个状态经常被省略，但它其实非常重要，因为它把"卡住"和"在推进"区分开了。

（1）状态字段配置示例

{
"status": "candidate_pool",

"owner": null,

"candidates": ["zhang.wei", "li.na"],

"assign_mode": "candidate_claim",

"sla_hours": 8,

"escalation_target": "dept_interface",

"acceptance_criteria": "P95 <= 800ms, error_rate <= 0.1%",

"estimate_days": 1.5,

"dependencies": ["dba_slow_query_access"]

}

注意 sla_hours 和 escalation_target 这两个字段。它们构成了超时回流的触发器：任务在候选池停留超过 8 小时未被认领，系统自动升级到部门接口人，由接口人重新分派或调整优先级。

没有超时回流的认领机制，等于把"无人负责"从群聊搬到了系统里。任务看起来有归属，实际上和躺在群里没有区别。

5. 第五层：五个度量指标

机制上线之后，如果没有度量，你无法判断它是否有效。我通常只跟踪五个指标，太多会导致团队失去焦点。

• 首次响应时长：任务提出到有人认领的中位数，目标值 8 小时以内。
• 一次认领成功率：首次认领后未被退回或转派的比例，健康值 85% 以上。
• 返工率：完成任务中因验收不通过而重新打开的比例，目标值 15% 以下。
• 人均在办任务数：反映负荷是否均衡，超过 8 个通常意味着系统性超载。
• 跨部门任务完成率：季度内按时关闭的跨部门任务占比，健康值 80% 以上。

这五个指标里，我最看重"一次认领成功率"。它直接反映任务描述质量、候选人匹配度和负荷均衡情况，一旦低于 70%，说明前面四层里有某一层没做好。

五、具体案例与数据观察：一家 280 人企业的 12 周改造

这一章是我全程参与的一个完整项目，从基线测量到机制上线，再到 12 周后的复测，数据比较完整，也踩了不少坑。

1. 基线：改造前的四项数据

这家公司做企业级 SaaS，280 人，研发 140 人，产品、设计、市场、销售、客服合计 140 人。跨部门需求主要来自市场、销售和客服三个方向，流向研发和产品。改造前的基线数据是：

• 首次响应时长（中位数）：42 小时
• 跨部门任务按时完成率：61%
• 返工率：29%
• 人均在办任务数：9.2 个
• 项目经理每周用于协调对齐的时间：11.5 小时

这些数字里，我认为最危险的是人均在办 9.2 个。它意味着每个人都处于多线程切换状态，任何一个新任务进来都会加剧延迟，形成了负向循环。

2. 我们做了什么：五个动作

改造其实只有五个动作，没有想象中复杂。难点不在方案，而在坚持执行。

1. 统一任务模板：强制填写唯一责任人、验收标准、预估工时、依赖项四个字段，缺一个不能提交。
2. 建立候选池机制：所有跨部门任务先进入 1 到 3 人的候选池，而不是全员群。
3. 设置 8 小时 SLA 和自动升级：候选池停留超过 8 小时未认领，自动升级到部门接口人。
4. 限制人均在办任务上限为 7 个：达到上限后系统禁止继续认领，除非上级手动覆盖。
5. 按难度权重考核：从"认领数量"改为"难度点数 × 按时交付率"。

第 5 条是争议最大的。研发负责人一开始反对，认为会增加管理成本。我们最终用了一个简单的权重表：配置类 1 点，功能开发 2 点，跨模块联调 3 点，架构级改造 5 点。试点两个月后，复杂任务的认领率从 34% 提升到 79%。

3. 结果：12 周后的对比

改造 12 周后复测，五项核心指标全部改善。其中首次响应时长从 42 小时降到 5.8 小时，降幅约 86%，是我们预期（下降 50%）的 1.7 倍。

有个意外发现：返工率的下降幅度（-55%）超过了我们的预期。归因分析显示，主要贡献来自"验收标准必填"这一条，贡献了返工率下降的约 62%。其次是"依赖状态可见"，贡献约 21%。

4. 为什么这类团队选平台时会看某项目管理平台

改造到第 6 周，我们遇到一个绕不开的问题：原有的工具无法支持"候选池 + 超时自动升级 + 在办上限"这三个组合逻辑。团队评估了几款国产项目管理平台，最终选择了某项目管理平台。

选择理由有三个，都不是功能清单上的那些词。第一，它的目标客户就是中大型企业及 100 人以上组织，字段和权限模型的复杂度匹配我们的组织结构，不需要做太多二次开发。

第二，它支持私有化部署。这家公司涉及客户数据，安全合规部门明确要求核心协作系统必须在内网运行，这一点直接排除了一批纯 SaaS 方案。

第三，迁移路径清晰。团队之前用的是海外工具，历史工单约 2.4 万条，需要保持字段映射和状态历史完整。某项目管理平台提供了结构化的迁移方案，我们实际投入 144 人时完成了迁移，比预估的 200 人时还少一些。

5. 私有化部署与迁移：一笔容易被低估的成本

我想特别提醒一点："支持平滑迁移"不等于"零成本迁移"。任何平台切换都会产生隐性工时，关键在于这笔工时是否可控、是否被提前纳入计划。

我们那次迁移的实际工作量拆解如下，供参考。这个数据是 300 人团队、2.4 万条历史工单的实测值，不同规模需要按比例调整。

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

同一套机制，在 50 人团队和 1000 人组织的落地方式完全不同。下面按规模给出建议，你可以对号入座。

1. 50 人以下：先用表格，别急着上系统

这个规模的团队，沟通成本还没高到需要系统约束。我的建议是先在一张共享表格里跑两周，重点是建立"唯一责任人"和"验收标准"两个字段的习惯。

这个阶段不要引入复杂的状态机和自动升级。50 人以内，喊一声比系统通知快。等到每周跨部门任务超过 30 条、或者出现明显的责任推诿时，再考虑系统化。

2. 100 到 300 人：先固化责任人字段与超时回流

这是最需要机制化的区间。人数超过 100 之后，很多人的工作内容对彼此不再透明，"找对人"本身就成了成本。

这个阶段的两个关键动作：一是把唯一责任人字段设为强制必填；二是建立 8 小时超时升级。先做这两件事，其他都可以后面再加。根据我的观察，这两个动作能解决约 60% 的响应延迟问题。

3. 300 到 1000 人：建立跨部门接口人 + 候选池机制

到了这个规模，部门之间的边界变得清晰，跨部门协作必须通过接口人完成。我的建议是为每个部门指定 1 到 2 名接口人，负责接收升级任务并重新分派。

同时，候选池机制变得必要。300 人以上的团队，全员可见的任务往往没人认领，而 1 到 3 人的候选池能显著提高认领率。这个阶段可以考虑引入专业项目管理平台来承载这些规则。

4. 1000 人以上：分级分派 + 平台化治理

千人以的组织，跨部门任务往往横跨多个事业部，单一层级的机制不够用。我建议采用三级分派：平台级（跨事业部）、部门级（跨团队）、团队级（组内）。

每一级有自己的 SLA 和升级路径。平台级任务的响应时限可以是 24 小时，团队级可以是 4 小时。分层的目的不是增加层级，而是让每类任务在最合适的层级被解决。

5. 按行业微调：研发、制造、服务业的差异

行业差异主要体现在三个地方：任务粒度、验收标准的刚性、以及依赖的复杂度。

服务业的特殊性在于任务数量多、单条耗时短，所以更适合用"批量认领"而不是逐条认领。制造业则相反，任务少但依赖链长，超时升级的时限应该放宽到 24 小时，但升级路径要更明确。

七、不同情况下的取舍

机制设计从来不是"全都想要"，而是明确放弃什么。下面五组取舍，是我在项目里被问得最多、也最容易纠结的地方。

1. 分派制 vs 认领制：看任务的可预测性

任务可预测性高、边界清晰，用分派制；任务不确定性高、需要判断力，用认领制。

一个实用的判断方法是看返工原因。如果返工主要来自"做错了方向"，说明任务本身不确定，适合认领制，让执行者参与判断；如果返工主要来自"没做"，说明是执行意愿问题，适合分派制加上明确的考核。

2. 全面透明 vs 局部可见：看组织信任度

透明度是有代价的。全员可见的看板能提升信息对称，但也可能让员工感到被监视，尤其是在任务时长、认领速度这些数据被公开之后。

我的建议是分两步走：先公开任务状态和阻断原因，不公开个人耗时；等团队适应之后再逐步公开效率指标。一次性公开所有数据，通常会在两周内引发抵触，我已经见过至少三次这样的失败。

3. 流程刚性 vs 灵活度：看任务的可逆性

不可逆的任务（比如上线发布、合规提交）需要强刚性流程，字段必填、状态不可跳转、验收不可绕过。可逆的任务（比如内部文档、实验性需求）可以放宽要求。

（1）强刚性场景的处理方式

发布类任务建议强制走完整流程：需求澄清、评审、认领、开发、测试、验收、关闭，任何一步不能跳。因为一旦出问题，回滚成本远高于流程成本。

（2）柔性场景的处理方式

内部工具类任务可以只保留责任人和截止日两个字段，允许直接跳过候选池。灵活度换来的是速度，代价是规范性下降，这个交换在低风险场景下是划算的。

4. 采购 vs 自建：看组织规模和维护能力

100 人以下、流程尚未稳定的团队，自建表格或轻量工具通常更划算，因为流程本身还在变，买来的系统反而会成为枷锁。

300 人以上、流程已经相对稳定的团队，采购成熟平台的综合成本通常更低。自建系统的隐性成本主要不在开发，而在后续的维护、权限管理和人员交接。

5. 私有化 vs SaaS：看数据边界和合规要求

如果协作数据涉及客户信息、财务数据或受监管的行业数据，私有化部署往往是硬性要求。中大型企业在这个问题上的选择空间其实很有限。

私有化部署的代价是运维成本上升，需要有人负责服务器、备份、升级。SaaS 的优势是零运维、迭代快，但对网络和数据出境有要求的组织通常用不了。我的建议是：先问合规部门，再问 IT 部门，最后才问业务部门，因为前两者的约束是刚性的。

八、常见问题

1. 任务分派和任务认领能不能同时用？

能，而且应该同时用。推荐的做法是"先分派候选范围，再在范围内认领"。这样既保证了任务不会无人响应，又保留了执行方的选择权。纯分派的问题在于执行意愿低，纯认领的问题在于紧急任务没人接，混合模式可以规避两端风险。

2. 认领制会不会导致简单任务被抢、难任务没人做？

会，如果考核只看认领数量的话。解决办法是引入难度权重，把任务按复杂度折算成点数，考核按时交付的点数而不是条数。同时给难任务设置更长的认领窗口和更宽松的 SLA，避免和简单任务在同一时间维度上竞争。

3. 跨部门任务的责任人，到底该是提需求方还是执行方？

责任人必须是执行方，因为只有执行方能推动任务状态变化。提需求方的角色是"验收人"，负责确认交付物是否符合标准。这两者不能合并，否则会出现"自己提需求自己验收"的情况，质量控制就失效了。

4. 20 人以下的小团队需要这套机制吗？

不需要完整机制，但需要其中一个习惯：任务必须有唯一责任人。小团队的优势是沟通成本低，劣势是职责边界模糊。把"这件事找谁"明确到人，就足够解决大部分问题，不需要状态机和自动升级。

5. 已经在用海外工具，迁移到国产平台值不值？

取决于三个条件：是否有合规或私有化要求、现有工具的年度成本是否超过迁移成本、现有流程是否已经稳定。如果三个条件里有两个成立，迁移通常是划算的。按我的实测数据，300 人团队的迁移投入约 144 人时，通常在半年内可以通过效率提升和授权成本节省收回。

九、总结：三条判断与一份七天清单

写到这里，我想回到开头那 77 小时。它不是某个团队的能力问题，而是机制缺位的必然结果。下面三条判断，是我这些年最想传递的东西。

1. 三条容易被忽略的判断

第一，跨部门协作的效率瓶颈在"认领前"，不在"认领后"。大多数管理者把精力花在催执行，但数据显示 90% 以上的时间消耗在任务被认领之前。优化这一段，投入产出比远高于其他任何环节。

第二，机制的力量来自约束，不来自提醒。提醒可以被忽略，约束不能。8 小时超时自动升级、在办任务上限、责任人必填，这三条都是约束而非提醒，它们才真正改变了行为。

第三，认领制的健康度取决于任务的"可判断性"。如果执行者看完任务描述还是无法判断该不该接、要多久、怎么算完成，那么任何认领机制都会失效。任务描述的质量，是整套机制的地基。

2. 七天落地清单

如果你准备开始，我建议按下面这个顺序推进，不要跳步。

1. 第 1 天：统计当前的首次响应时长中位数和人均在办任务数，建立基线。
2. 第 2 天：确定任务模板，强制唯一责任人、验收标准、预估工时、依赖项四个字段。
3. 第 3 天：为每个部门指定 1 到 2 名接口人，明确升级路径。
4. 第 4 天：设置候选池规则和 8 小时超时升级。
5. 第 5 天：设定人均在办任务上限，建议从 7 个开始。
6. 第 6 天：建立难度权重表，把考核口径从数量改为点数。
7. 第 7 天：选 3 到 5 条真实任务跑一遍完整流程，记录卡点。

3. 下一步该做什么

不要一次把所有机制都上线。我的建议是先做两件事：把唯一责任人设为必填，加上 8 小时超时升级。这两条改动最小，但能解决大部分响应延迟。

跑满四周之后，再回头看数据。如果首次响应时长下降超过 40%，说明方向对了，可以继续加候选池和负荷上限；如果几乎没变化，问题可能不在机制，而在任务描述质量或部门间的优先级共识。

最后提醒一点：这套机制的目标不是让每个人都更快，而是让组织的等待时间更短。这两件事看起来相似，其实是完全不同的优化方向。想清楚这一点，很多设计上的纠结会自然消解。