认领最佳实践：项目负责人任务分派协同管理，常见问题

去年下半年，我在一家 300 人规模的智能硬件公司做研发效能顾问。他们的项目管理负责人老周跟我说了一句让我印象很深的话：“我们上了认领制，结果两周之后待认领池里躺了 47 个任务，其中 12 个躺了超过 10 天；可同时，三个资深工程师每人手上压着 6 个任务在做。”他问我：认领制是不是根本不适合我们？我的回答是：不是认领制不适合，是你们把“认领”当成了“取消分派”。任务认领（Claim / Self-assignment）从来不是把项目负责人从流程里删掉，而是把项目负责人的工作从“每天找人派活”迁移到“设计规则、暴露容量、清理瓶颈”。

这篇内容我会把我这些年在中大型研发组织里踩过的坑、观察到的数据、以及被验证有效的规则，尽可能具体地写出来。

一、先给结论：认领不是取消分派，而是把分派规则化

我在做顾问和效能诊断的这几年里，见过认领制跑得非常好的团队，也见过上线三周就退回人工指派的团队。两者的差别几乎不在“员工自驱力”，而在规则设计的完整度。下面这五条是我反复验证后愿意写进方案里的核心结论。

1. 认领解决的是“匹配效率”，不是“管理责任”

人工指派的问题在于：项目负责人需要同时知道 20 个人的技能栈、当前负载、成长诉求、休假计划，然后做一次匹配。当团队超过 15 人、任务超过 30 个时，这个匹配质量会急剧下降，典型表现是“老周凭印象派活”。认领机制的价值，是把一次高频、低质量、强依赖个人记忆的匹配，换成一次低频、高质量、可复盘的规则设计。

但责任的转移只发生在执行层，不发生在结果层。任务谁做可以自选，交付是否准时、依赖是否打通、验收是否通过，依然是项目负责人的责任。很多认领失败的组织，恰恰是把这两层责任一起丢掉了。

2. 认领制成立有三个前提，缺一个就会退化

我把这三个前提总结为“可独立、可判定、可看见”。第一，任务本身可以独立交付，不依赖某个特定的人才能推进；第二，验收标准可以被第三方判定，不依赖认领人自己解释“我做完了”；第三，团队每个人的当前容量是公开可见的，不靠猜。

缺“可独立”，认领就变成抢单，认领人只挑能快速关掉的任务；缺“可判定”，认领就变成摆烂，谁认领谁定义完成；缺“可看见”，认领就变成内卷，手快的人做三倍工作量，手慢的人被贴上“不主动”的标签。

3. 大多数认领失败是设计问题，不是态度问题

我们对积压未认领任务做过归因分析，结论很集中：排在第一位的原因是“验收标准不清晰”，占 31%；第二位是“任务颗粒度过大（超过 5 人日）”，占 24%。这两项加起来超过一半。而“员工不想干”这类态度类原因，实际占比不到一成。

也就是说，当一个 40 人以上的研发组织出现大面积任务无人认领时，先去看任务卡片的写法，而不是先开动员会。动员会能解决一次，改卡片模板能解决一年。

4. 混合模式在多数中大型组织里比纯认领更稳

我在 100 人以上的组织里，几乎没有见过纯认领长期跑通的案例。原因很现实：中大型组织一定有合规任务、运维任务、跨团队依赖任务，这些任务天然不满足“可独立、可判定、可看见”三前提。强行让它们进认领池，结果就是长期滞留。

可落地的做法是“认领优先 + 超时兜底指派”：任务进入认领池后，在设定窗口内（我通常建议 24 到 48 小时）允许自由认领；超过窗口仍无人认领，系统自动指派给预设的角色负责人。这个机制既保留了自选带来的匹配优势，又保住了交付的确定性下限。

5. 认领必须配四个指标，否则无法复盘

没有指标的认领制，会在三个月内变成“谁嗓门大谁定规则”。我在方案里固定放四个指标：认领覆盖率（被认领任务 / 进入池任务）、认领响应时长（任务入池到被认领的中位时间）、认领后返工率（认领任务被验收打回的比例）、认领分布离散度（用基尼系数衡量任务是否集中在少数人手上）。

四个指标各有指向：覆盖率看规则是否可用，响应时长看池子的活跃度，返工率看验收标准质量，离散度看公平性。任何一项长期偏离，都能直接定位到具体要改的东西。

二、真实场景：认领制为什么在中大型组织里突然变得重要

认领不是新概念，开源社区和看板方法里用了很多年。但它在最近三五年被中大型研发组织大量引入，背后有几个非常具体的变化。

1. 从“单项目”到“多项目并行”带来的调度爆炸

十年前一个 100 人的研发中心可能同时在跑 2 到 3 个项目；现在同样规模的组织，同时活跃的需求流可能有 15 到 30 条，覆盖主版本、定制交付、线上问题、技术债、合规整改。项目负责人面对的不再是“把 20 个任务分给 10 个人”，而是“把 200 个任务在 10 个小组之间来回调度”。

这种复杂度下，中心化指派的边际成本会指数级上升。我做过一个粗略测算：在一个 40 人的研发团队里，项目负责人每天花在“看谁闲、谁忙、该派给谁”上的时间大约是 1.5 到 2.5 小时，占其有效工作时间的 25% 到 35%。这些时间基本不产生交付价值，只产生协调价值。

2. 矩阵式组织让“一个负责人管所有人”失效

现在很多中大型组织是矩阵结构：工程师同时属于技术线和项目线，一个人可能同时参与 3 个项目。这时候项目负责人其实没有行政权力去指派任务，只有协调权。认领制在这种结构下的价值，是把“协调权不足”的问题，转化为“规则公开、任务公开、容量公开”的问题。

我见过一个很典型的现象：同一个工程师，在 A 项目里因为 A 负责人资历深，任务被优先派给他；在 B 项目里因为 B 负责人不熟，任务就一直排不上。认领制配合公开的容量看板，可以让这种“靠关系排序”的问题暴露出来。

3. 工具侧的支撑成熟，让认领从理念变成可执行的机制

认领制早年的最大障碍是工具跟不上：任务池可见性差、认领动作没有记录、WIP 无法自动限制、数据无法统计。现在主流研发管理平台基本都具备待办池、看板、WIP 限制、任务卡模板、字段校验、自动化规则这些能力，认领才真正具备了工程化落地的条件。

顺带说一句，我下面会用 PingCode 举一个具体例子，不是因为它功能最全，而是因为它的待办池、迭代看板、自动化规则和私有化部署能力，正好覆盖了中大型组织做认领改造时最需要的那几块。

4. 三类最适合认领的真实场景

不是所有任务都适合认领。我梳理下来，跑得最顺的是这三类。

第一类：平台型团队的日常运维与优化任务。比如接口性能优化、告警治理、日志规范整改、依赖升级。这类任务数量多、颗粒度小、技能门槛分散、交付标准明确，认领的匹配效率远高于指派。

第二类：版本迭代中的中等颗粒度需求。单个需求在 2 到 5 人日之间，有明确的原型稿和验收标准，团队成员对业务模块有基本覆盖能力。这类任务认领后，认领人往往比指派人有更强的完成意愿。

第三类：跨团队专项任务的“自愿报名制”。比如某次线上故障的复盘整改、某个技术专项的攻坚。这类任务不适合强制指派，因为强制指派的人投入度不够；但也不适合完全放开，因为需要保证有人兜底。

三、拆解八个常见误区：认领制最容易在哪里翻车

下面这八个误区，是我在实际复盘里出现过至少两次以上的。我按出现频率排序，并且给出对应的判断方法和修正动作。

1. 把认领当成放权：项目负责人从流程里消失了

这是最常见的第一个坑。上线认领制之后，项目负责人不再每天派活，于是逐渐退出了日常节奏：不看池子、不看 WIP、不看依赖。两三周后，池子开始积压，团队开始互相推诿，负责人再回来时已经失去了对节奏的判断力。

正确的做法是：认领上线后，项目负责人的工作内容变了，但工作量没有变。原来花 2 小时派活，现在应该花 1.5 小时看容量偏差、清依赖、处理超时未认领的任务、准备下一次复盘。

2. 默认认领天然公平：忽略了“挑肥拣瘦”的结构性偏差

认领的自由度一定会被人的偏好利用。我们统计过某团队一个迭代周期内的任务池分布与实际认领分布，结果非常有说服力：高复杂度任务（大于 5 人日）在池子里占 22%，但实际只被认领了 11%；低复杂度任务（小于 2 人日）在池子里占 37%，却占了 51% 的认领量。

这不是道德问题，是激励结构问题。如果绩效、评价、曝光都更偏爱“快速关闭任务”，理性人就会优先认领小任务。解法不是靠批评，而是靠规则：设置难度标签配额、要求每人每迭代至少认领一个高复杂度任务、或者对高复杂度任务给出更长的交付窗口。

3. 任务颗粒度不设上限：大任务无人问津

一个持续 8 人日的任务放在认领池里，几乎必然长期滞留。原因是认领人的心理成本：一旦认领，接下来两周基本被锁死，遇到更高优先级的插入任务时无法抽身。所以大任务的“认领摩擦”远高于小任务。

我的经验值是：进入认领池的单个任务，工作量上限应控制在 5 人日以内，理想区间是 1 到 3 人日。超过 5 人日的任务必须拆分，拆不动的说明它本质上是一个需要项目负责人协调的专项，不应该走认领。

4. 只开放认领、不设 WIP 上限：局部最优变成全局最差

没有任何约束的认领池，会鼓励手快的人疯狂认领。我们做过一组对照观察：当每人 WIP 上限从 2 逐步放宽到 6 时，认领响应时长从 2.6 小时降到 0.7 小时，看起来效率大幅提升；但任务平均交付周期从 7.9 天涨到 15.7 天，几乎翻了一倍。

这就是典型的局部最优陷阱：抢单变快了，但每个人都在多任务并行切换，实际吞吐下降。中大型组织里我通常建议 WIP 上限设在 2 到 3 之间，并且在工具层面做硬约束，而不是靠自觉。

5. 认领完就不管依赖：认领人变成“卡住的认领人”

认领制把“谁做”这个问题解决了，但没有自动解决“什么时候能做”。我见过大量任务在认领后进入长期阻塞状态：认领人要等上游接口、要等设计稿、要等测试环境、要等第三方账号。任务在系统里显示“进行中”，实际上人在等。

有效的做法是在任务卡片上强制填“依赖项”，并且把依赖项的状态纳入每日站会。项目负责人的关键动作不是问“你做完了吗”，而是问“你被什么挡住了”。

6. 把认领数据直接拿去做绩效

这是最危险的一个坑。一旦认领数量、认领速度被直接纳入绩效，团队会立刻学会策略性行为：只认领容易的、认领后拖延交付时间记录、抢在别人之前点一下认领再慢慢做。数据会变得非常漂亮，但交付质量毫无改善。

认领数据的正确用法是诊断团队容量和任务设计质量，而不是评价个人。如果一定要和评价挂钩，挂钩的应该是“认领后的交付结果”而非“认领动作本身”。

7. 没有兜底机制：合规任务、运维任务长期无人认领

任何一个中大型组织都有一定比例的任务是“必须有人做，但没人愿意主动认领”的：安全合规整改、老旧模块维护、线上值班、文档补齐。这些任务在纯认领制下会无限滞留。必须设计兜底：要么按角色轮值，要么设定超时自动指派规则，要么明确这类任务不走认领池、直接指派。

8. 忽略新人门槛：新人不敢认领，被进一步边缘化

认领制对新人其实不友好。新人面对一个公开的任务池，第一反应往往是“我不确定能不能做”，于是长期不认领；结果就是任务都流向资深工程师，新人继续做边缘工作，能力差距被进一步放大。

我通常建议给新人设一个过渡期：前两个迭代由导师带着认领，或者专门划出一批“带教任务”标注适用级别，让新人能在低风险下完成第一次认领。

四、专业判断逻辑：什么情况下该用认领，怎么用

很多人问我“我们团队适不适合认领制”，这个问题本身太粗。更准确的问法是：我们的任务类型、团队结构、管理容忍度，匹配到认领制的哪一档。我一般用五个维度做判断。

1. 五维适用性评估框架

这五个维度是：任务独立性（任务能否不依赖特定人完成）、验收标准清晰度（第三方能否判定完成）、团队自驱度（成员是否愿意主动承担）、容量可见性（负载是否公开透明）、管理者容忍度（负责人是否接受失去直接控制权）。

每个维度我按 1 到 10 打分，加权后得出适用性结论。需要强调的是，五个维度里最容易被人忽略、但对成败影响最大的是“管理者容忍度”。如果项目负责人内心其实接受不了“任务被谁认领由规则决定”，那么再完美的设计也会在执行中被一点点收回。

2. 认领落地的三要素：可见池、颗粒度、约束

不管团队规模多大，认领要跑起来都靠这三件事。可见池是前提，所有人必须能在同一个界面看到同一批任务，包括描述、验收标准、依赖、预估、优先级。颗粒度是基础，1 到 3 人日的最佳区间，5 人日为上限。约束是保障，包括 WIP 上限、认领窗口、难度配额、兜底规则。

三要素里最容易做错的是约束。可见池和颗粒度是“让认领能发生”，约束是“让认领不发散”。我在方案里会把这部分写成可直接执行的配置，下面是一个示例结构：

claim_policy:
backlog_visible: true # 认领池对全员可见

task_size_limit_days: 5 # 单人日上限，超过必须拆分

task_size_ideal_days: [1, 3] # 理想区间

wip_limit_per_person: 3 # 个人并行任务硬上限

claim_window_hours: 24 # 超过窗口未认领触发兜底

difficulty_quota:

high_complexity_per_iteration: 1 # 每人每迭代至少认领 1 个高复杂度任务

required_fields: # 缺字段不允许入池

acceptance_criteria

dependencies

estimate_days

fallback:

mode: auto_assign

target: role_owner # 超时指派给角色负责人

metrics:

claim_coverage_rate

claim_response_time_median

rework_rate_after_claim

claim_distribution_gini

3. 项目负责人的角色重构：从分派者到四类角色

认领制上线后，项目负责人不是没事干了，而是换了四件事做。第一，规则设计者：定义池子规则、颗粒度标准、WIP 约束、兜底策略。第二，容量调度者：关注整体容量的分布偏差，而不是单个任务的归属。第三，瓶颈清障者：处理依赖、权限、环境、跨团队协调这些“结构性阻塞”。第四，复盘主持人：每周看指标，定位规则问题并迭代。

这四件事里，我认为瓶颈清障者的价值最高，也最容易被忽略。因为认领制把“谁做”透明化了，反而让“为什么做不动”变得更容易被掩盖，大家都在忙，但忙的是等待。

4. 认领健康度的判断标准

我通常给项目负责人一个五秒钟能看完的健康度看板，只有四个数：认领覆盖率、认领响应中位时长、认领分布基尼系数、认领后返工率。四个数各自有健康区间，任何一项连续两周偏离区间，就说明规则需要调。

这样做的好处是把管理动作从“每天盯人”变成“每周看偏差”。项目负责人不需要知道每个任务归谁，只需要知道系统是否在健康区间内运行。

五、案例与数据观察：一个 400 人研发组织的认领改造实录

下面这个案例我认为比较有代表性，因为它同时具备几个中大型组织的典型特征：400 人研发规模、矩阵式结构、多项目并行、强私有化要求、原本使用海外工具。

1. 改造前的状态

这家公司是做金融科技系统交付的，研发团队约 400 人，分 12 个研发小组。他们原本用一款海外项目管理工具做任务流转，主要问题是：任务全部由各小组的项目负责人人工指派；跨组任务靠着群聊协调；容量信息分散在十几个表格里；私有化部署和信创合规要求无法满足。

一个很典型的场景是：某个跨组任务在 A 组负责人那里等了两天没派出去，B 组负责人以为 A 组在做。类似情况每周发生三到五次。

2. 工具选型与迁移

他们最终选择了 PingCode。选它的原因很直接：PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，能把数据和代码留在自己的机房里；同时提供了相对成熟的 Jira 平滑迁移能力，历史任务、状态流转、字段映射可以批量处理，不需要手工重建几千条任务。

对我做方案来说，更关键的是它同时具备待办池、迭代看板、任务卡字段校验、自动化规则和效能数据看板这几块能力，这些正好对应我前面讲的“可见池、颗粒度、约束、指标”四件事。如果工具只能做看板不能做字段校验和自动化，规则就只能靠人盯，撑不过三个月。

3. 三个阶段推进

第一阶段是可见化，用了 3 周。把 12 个组的任务全部收敛到统一的任务池，补齐验收标准、依赖项、预估人日三个必填字段。这一步的阻力不小，因为很多老任务根本没有验收标准，只能由各组长带着补。

第二阶段是规则化，用了 5 周。先在 3 个平台型小组试点认领制，任务颗粒度上限设为 5 人日，个人 WIP 上限设为 3，认领窗口 24 小时，超时自动指派给角色负责人。试点两周后，认领覆盖率稳定在 68% 到 75%，没有出现大面积积压。

第三阶段是指标化，用了 4 周。把四个健康度指标做进数据看板，每周五由项目负责人花 30 分钟看偏差。同时给每个迭代加了难度配额：每人每迭代至少认领一个高复杂度任务。

4. 12 周的数据演进

上线后的第 2 周是最难看的：认领覆盖率只有 41%，认领后返工率高达 24%。原因是大量任务的验收标准是临时补的，质量不高，认领人做完之后被打回。第 4 周开始，各组长批量修订了任务卡模板，返工率开始下降。

到第 12 周，认领覆盖率稳定在 81%，返工率降到 10%，比改造前的指派模式还低了 1 个百分点。这说明返工率高的根本原因从来不是认领，而是任务定义质量；认领只是把这个老问题暴露得更早、更明显。

5. 改造投入的真实成本

我把这个项目的投入做了折算，总人力大约 150 人天，分散在 12 周里。具体构成是：规则设计与评审 32 人天，工具配置与看板改造 18 人天，培训与试点支持 26 人天，数据看板搭建 14 人天，以及持续复盘与调优 60 人天。

这个数字对 400 人组织来说不算高，但需要强调的是最后一项：持续复盘与调优占了 40%。很多组织在前四项做完之后就停了，结果三到六个月后规则失效。认领制的维护成本是长期的，这一点在做预算时必须说清楚。

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

认领制的落地路径和团队规模、组织结构强相关。我按四个规模区间给出建议，每个区间都有对应的重点和禁区。

1. 20 人以下的小团队：不要上认领制

这个规模的团队，沟通成本极低，一句话就能完成调度。认领制引入的规则、字段、流程成本，远大于它节省的匹配成本。我看到过 12 人团队硬上认领制，最后的结果是每天多花 20 分钟维护任务卡，交付没有任何改善。

如果确实想引入，建议只做一件事：把任务池公开。让大家看到有哪些活要干，指派动作仍然由负责人完成。这一步能带来认知透明度，成本几乎为零。

2. 20 到 100 人：走“认领优先 + 轻量兜底”

这个区间是认领制最容易见效的。团队已经超过一个人的认知边界，但还没到需要复杂治理的程度。建议的做法是：先选 1 到 2 个平台型或工具型小组试点，颗粒度上限 5 人日，WIP 上限 3，认领窗口 48 小时，超时由组长指派。

指标只做两个就够了：认领覆盖率和认领响应中位时长。跑满两个迭代后再决定是否扩大。

3. 100 到 500 人：必须做规则化和指标化

这个规模是 PingCode 这一类平台最典型的服务区间。到这个体量，认领制不能靠“约定俗成”，必须有明文规则和系统约束。四个健康度指标、难度配额、依赖项强制填写、超时自动指派，这几项都是必须的。

同时要处理矩阵组织带来的一个特殊问题：同一个人可能属于多个项目的认领池。这时候需要设置跨池容量上限，否则一个人会在三个池子里各认领三个任务，实际负载超载。跨池 WIP 上限应该按人计算，而不是按池计算。

4. 500 人以上：认领只是整体效能体系的一块

到这个规模，单纯优化认领环节的边际收益会明显下降。真正决定效能的是需求流动效率、跨团队依赖治理、环境与工具链的自动化水平。认领应该被定位成“任务分派层的机制”，而不是“效能提升的主要抓手”。

这个阶段建议做的是：把认领数据接入整体的效能度量体系，用认领分布离散度去反推资源分配是否合理，用认领响应时长去反推任务定义质量，而不是孤立地盯认领覆盖率。

5. 无论什么规模，前两周一定要做的三件事

第一，把入池标准写下来并强制执行，缺验收标准、缺依赖项、缺预估的任务不允许进池。第二，把兜底规则设好并公开，让所有人知道超时会发生什么。第三，第一个迭代结束就开一次复盘，只讨论规则问题，不讨论人的问题。

七、不同情况下的取舍

认领制的落地过程里，有一批取舍是绕不过去的，而且没有标准答案。我把我在实际项目里做过的取舍判断写出来，供参考。

1. 认领 vs 指派：不是二选一，而是按任务类型分流

我的判断是：一个组织里永远应该同时存在认领和指派，关键是明确哪些任务走哪条路。适合认领的任务具备三个特征：可独立、可判定、可看见。剩下的任务，尤其是强合规、强依赖特定人、外部节点硬约束的任务，直接指派更高效。

强行让所有任务走认领，只会制造长期积压；强行让所有任务走指派，则会让项目负责人被调度工作淹没。分流才是答案。

2. 效率 vs 公平：认领分布离散度要控到什么程度

认领分布越集中，短期效率越高，能者多劳，交付快。但长期看，集中的分布会导致骨干倦怠和新人停滞。我用基尼系数来衡量这个分布，0 表示完全平均，1 表示完全集中。

我对中大型组织的建议是：把基尼系数控制在 0.25 到 0.35 之间。低于 0.25 说明任务被平均分配，可能压制了高效率成员的产出；高于 0.35 说明任务过度集中，需要检查是否有新人不敢认领、或者是否有任务难度分布不合理。

3. 透明 vs 隐私：认领数据公开到什么层级

认领数据越透明，规则越可信；但完全透明会带来压力，尤其是“谁还没认领”“谁认领得最慢”这类信息。我的做法是分层：个人认领明细只对本人和直属负责人可见；团队层面的覆盖率、响应时长、离散度对全员可见；个人排名不公开。

这个分层的逻辑是：让规则可信，但不让人被公开比较。一旦出现公开排名，认领行为就会迅速策略化，前面提到的所有坑都会提前出现。

4. 自由度 vs 可预测性：认领窗口设多长

认领窗口越短，任务流转越快，但成员的选择空间越小；窗口越长，选择空间越大，但交付确定性下降。我在 100 到 500 人组织里的经验值是 24 到 48 小时。

如果组织的交付节点刚性很强，建议压到 24 小时，甚至对 P0 任务设置 4 小时窗口。如果团队处于能力建设期，希望给大家更多尝试空间，可以放宽到 72 小时，但一定要配 WIP 上限，否则窗口的宽容会变成池子的积压。

5. 自建规则 vs 工具内置能力：不要重复造轮子

我见过一些团队用表格加脚本自建认领系统，短期能用，长期维护成本极高：字段校验、权限控制、自动化规则、数据看板都要自己写。一旦人员变动，系统就没人维护。

我的建议是：把规则设计留在组织内部，把规则执行交给工具。认领窗口、WIP 上限、必填字段校验、超时自动指派、指标计算，这些都应该由平台承担。团队要花精力做的是判断规则本身是否合理，而不是维护一套脚本。这也是我在中大型组织里优先推荐具备自动化规则和字段校验能力平台的原因。

八、总结与下一步

回到开头老周那个问题：认领制是不是不适合他们？我的答案到现在还没有变，不是认领制不适合，是他们把认领制当成了“取消分派”。在那家公司后来的调整里，我们做的第一件事不是加规则，而是把 47 个滞留任务逐个过一遍，发现有 26 个任务缺少验收标准或颗粒度过大。改完卡片之后，池子在两周内消化掉了大半。

这篇文章我想留下的最核心的三个独特判断是：第一，认领失败的主因是任务定义质量，不是团队态度；第二，纯认领在中大型组织里几乎跑不通，混合模式才是稳定解；第三，认领数据的正确用途是诊断规则，不是评价个人。这三条如果只能记住一条，我希望是第一条，因为它决定了你第一步应该改什么。

如果你准备在自己的组织里推进认领制，我建议的下一步动作非常具体，按顺序做四件事就够了。

1. 先做一次任务池体检。抽 3 个迭代的滞留任务，按“验收标准不清晰、颗粒度过大、缺权限环境、依赖未就绪、技能不匹配”五类归因，算出各占多少。如果前两类超过 40%，先改任务卡模板，不要先上认领。
2. 选 1 到 2 个平台型小组做两周试点。颗粒度上限 5 人日，WIP 上限 3，认领窗口 48 小时，超时由组长指派。试点期间只观察两个指标：认领覆盖率和认领响应中位时长。
3. 把兜底规则写在明面上并公开。让所有人知道超时会发生什么，这一步做完，试点期的焦虑会下降非常明显。
4. 第一个迭代结束就复盘，只谈规则不谈人。把复盘产出固化成配置项，写进工具里，而不是写在会议纪要里。

最后提醒一句：认领制的维护成本是长期的。我见过太多组织在前三个月做得很好，之后因为缺少持续复盘，规则一点点失效，半年后又退回人工指派。如果你的组织没有能力在每个迭代拿出 30 分钟看健康度指标，那就先不要引入认领制，把任务池公开这一步做好，收益已经足够。