任务分派派发教程：管理层数据分析，避坑指南

我做过一次挺尴尬的复盘：某业务线 180 人的研发组织，管理层每周看到的"任务完成率"是 87%，但真正按期上线的需求只有 61%。差了 26 个百分点，不是有人造假，而是任务分派环节从一开始就没有留下可被管理层追问的数据，派给谁、什么时候派、依据什么派、派了多少、对方承不承接得住，这些字段要么不存在，要么散落在聊天记录里。这篇教程不讲"如何把任务派下去"这种动作层面的事，而是讲管理层在任务分派派发这件事上，应该看什么数据、怎么验证这些数据、以及 90% 的团队会在哪里翻车。

我按自己带过 30 人到 400 人组织的三段经历来写，中间会给出可直接抄用的指标口径、校验 SQL 和一个真实的中大型组织迁移案例。

一、先给结论：任务分派的成败，取决于"派完之后管理层能读到什么"

大多数团队把任务分派当成一个动作，派完就结束了。但站在管理层视角，分派是一个数据链路的起点：它决定了后面所有的产能分析、交付预测、人力规划有没有可信的输入。如果起点字段是脏的，后面所有看板都是精致的错误。

1. 三条我坚持了六年的结论

第一条：任务分派的可分析性，优先于任务分派的效率。派得快但字段缺失，等于每个月多花 20 小时手工补数据；派得慢 30 秒但字段完整，六个月后你能省下一个专职数据分析岗。

第二条：管理层要看的不是"派了多少任务"，而是"派发结构与实际承接结构之间的偏差"。同样的 800 个任务，均匀分给 20 个人和集中在 6 个人身上，产出差异可以到 2 倍以上，但任务总数这个指标完全看不出来。

第三条：任何没有"未派发池"数据的派发体系，其完成率都不可信。你把难做的任务留在池子里不派，完成率当然好看，但这是在用数据掩盖问题。我见过一个团队，未派发池里积压了 300 多条任务，平均滞留 47 天，而管理层看到的完成率是 91%。

2. 为什么多数团队的派发数据经不起追问

我做过一个小样本统计：在 11 个我接触过的研发团队里，能同时回答"上周派出的任务里有多少条超过 5 人天"和"有多少条被承接人主动退回或改期"的，只有 2 个。这两个团队恰好都在用有完整任务生命周期字段的项目管理平台。

剩下的 9 个团队，问题不在于没有数据，而在于数据不闭环。任务在表格里被派发，在另一个系统里被跟踪，在群里被催办，在周报里被总结。四次转手之后，没有人能说清"最初派发时的预估"和"最终交付时的实际"之间的差值是多少。

3. 一条可执行的判断标准

我常用的自检标准是：随机抽取上周派出的 20 条任务，看能否在 5 分钟内回答这五个问题，派发人是谁、承接人是谁、派发时的预估工时、派发时的承诺截止日、当前状态变更时间线。

五个问题里答不上两个以上，说明你的派发体系还不具备管理层分析的基础。这时候上 BI 报表、做数据大屏都是徒劳，因为源头没有结构化的派发事件，下游只能靠拼凑。

二、背景与真实场景：我在三个阶段踩过的坑

任务分派的管理复杂度不是线性增长的，它在 30 人、120 人、400 人这三个节点上各有一次质变。我把三段经历摊开讲，因为每一段的坑都不一样，用后一阶段的方案去套前一阶段，同样会翻车。

1. 30 人阶段：口头派活加表格统计，够用但埋雷

2017 年我带一个 28 人的研发团队，派活方式是早会口头分配，然后由一个助理维护一张 Excel 排期表。这个阶段其实是"够用"的：团队小、信息传递快、任何人对任何任务的状态都心里有数。

但雷埋在人员流动上。那年团队走了 5 个人，其中一个人手上的 14 条任务交接时没有任何上下文，为什么派给他、做到哪一步、和谁有依赖，全靠回忆。我们花了整整三天做交接对齐，其中 3 条任务最后被判定为"重复建设"直接关闭。

这个阶段的教训不是"要上系统"，而是：即使是 30 人，派发动作也必须留下最少三个字段，派发人、承接人、预期产出。工具可以是表格，但字段不能省。

2. 120 人阶段：表单化派活，看板很漂亮但数据不可用

2019 年组织扩张到 120 人，分成 9 个小组。我们做了一件当时觉得挺聪明的事：设计了一套结构化派发表单，包含任务类型、优先级、预估工时、期望完成日等 12 个字段。

三个月后我打开数据，发现预估工时的标准差大到没有意义。同一个"接口联调"任务，有人填 2 小时，有人填 3 人天，差了 12 倍。原因不是有人瞎填，而是团队之间对"人天"的定义不一致：A 组按纯编码时间算，B 组按含测试和联调的全周期算。

那三个月教给我一件事：口径不统一的字段，比没有字段更危险。没有字段的时候你知道自己不知道；有字段但口径混乱的时候，你会拿着一张看起来专业的图表做出错误决策。我们当时就据此调整了排期，结果两个季度的人力预测偏差超过 40%。

3. 400 人以上阶段：数据化派活，反而开始"少派多看"

2022 年我参与一个 400 多人研发组织的流程改造。这时候所有任务都在项目管理平台里流转，字段完整、时间线可查、跨项目依赖可视。技术条件是最好的，但管理层反而更焦虑，因为数据一多，噪音也多。

我们最后做的事情是把管理层看的指标从 23 个砍到 6 个，并且规定每个指标必须能回答一个具体的决策问题。比如"人均在办任务数"用来决定要不要招人，"派发超载率"用来决定要不要重新分配，"未派发池滞留时长"用来决定优先级排序是否需要推翻。

这个阶段最大的反常识发现是：数据越全，越要克制派发动作。当你能清楚看到每个人手上还有 7 个在办任务时，你自然不会再多派第 8 个。数据化派发的价值，一半在派，一半在不派。

三、管理层数据分析到底要看什么：四层指标模型

我把任务分派派发相关的管理指标分成四层：派发层、承接层、交付层、成本与健康度层。这四层是递进关系，前一层的数据质量决定后一层能不能算。很多团队直接跳到交付层看完成率，结果发现完成率波动大却找不到原因，就是因为派发层和承接层是空的。

1. 派发层：回答"我们派出了什么结构"

派发层的核心不是数量，是结构。我建议至少记录四个维度：任务类型分布、预估工时分布、优先级分布、跨组派发占比。

其中跨组派发占比这个指标被严重低估。当一个组织的跨组派发占比超过 35% 时，任务的平均流转时长通常会出现非线性上升，因为跨组任务涉及接口对齐、环境协调、验收标准协商，这些时间在单个任务上看不出来，但在聚合数据上会显现。

我在一个 260 人的组织里验证过：跨组派发占比 22% 时，任务平均流转时长 4.3 天；占比升到 41% 时，平均流转时长 9.1 天。翻了一倍多，但没有任何一个团队觉得自己变慢了。

2. 承接层：回答"派下去的东西有没有被真正接住"

承接层是我认为最容易被跳过、但价值最高的一层。它至少要包含三个数据点：承接确认率（派发后承接人明确接受的比例）、改期率（承接人主动申请变更承诺日的比例）、退回率（承接人判定不属于自己职责或信息不足而退回的比例）。

退回率是个特别好的管理信号。正常团队退回率在 3% 到 8% 之间，低于 3% 通常意味着承接人不敢退回（文化问题），高于 15% 通常意味着派发人对业务上下文理解不足（流程问题）。

改期率则反映承诺的严肃性。我见过一个团队改期率长期在 30% 以上，管理层却只看最终完成率，结果每次版本都要延期，因为承诺日从一开始就没有约束力。

3. 交付层：回答"结果如何"，但要带分布

交付层最常见的错误是只看均值不看分布。平均交付周期 6 天听起来不错，但如果分布是双峰的，一半任务 2 天完成、另一半 14 天完成，那这个均值掩盖了两个完全不同的流程问题。

我建议交付层至少看四个指标：按期交付率、交付周期 P50 与 P90 的差值、返工率（交付后被判定需要重做的比例）、以及任务关闭时的实际工时与派发时预估工时的比值。

最后这个比值我管它叫预估偏差系数，健康区间是 0.9 到 1.3。低于 0.9 说明预估过于保守，可能有人在"囤工期"；高于 1.3 说明预估系统性乐观，排期一定会失控。

4. 成本与健康度层：回答"这套派发方式本身贵不贵"

这一层最容易被忽略。派发体系本身是有成本的：填写字段的时间、协调会议的时间、数据清洗的时间、以及过度派发带来的上下文切换成本。

上下文切换成本尤其值得量化。根据我自己的抽样观察，一个研发人员同时手上在办任务数从 3 个增加到 7 个时，单任务的平均净编码时长会上升约 40%，因为每次切换需要重新加载上下文。这部分损耗不会体现在任何任务工时里，但会体现在整体交付周期上。

四、常见误区拆解：八个我在真实复盘里反复遇到的坑

这八个误区按出现频率排序，前三个几乎每个团队都中过。我把每个坑的表现、根因和代价分开说，方便你对照自查。

1. 坑一：把"任务数量"当产能指标

表现是周报里写"本周完成任务 156 个，环比增长 12%"。根因是任务颗粒度不统一，一个"修复文案错别字"和一个"重构支付模块"被算成同一个单位。

代价很直接：团队会主动把任务拆细来刷数量。我见过一个团队把一个需求的 8 个子任务拆成 34 个，完成数好看了，但交付周期一天没缩短。正确的替代指标是"完成任务的总预估工时"加上"预估偏差系数"，数量只作为辅助。

2. 坑二：用"完成率"考核派发的执行方

一旦完成率被用来考核派发人，派发人就会本能地把难任务留给别人派或者干脆不派。这是激励机制直接污染数据的经典案例，而且非常隐蔽，因为没有任何一条数据是假的，只是难任务消失了。

判断方法很简单：看未派发池的任务难度分布和已派发任务的难度分布是否一致。如果不一致，一定有筛选行为。我建议派发人只考核"派发信息完整率"和"退回率"，完成率考核承接方。

3. 坑三：跨项目派活没有统一的人天口径

这是 120 人阶段那个坑的通用版本。A 项目的人天含测试，B 项目不含；C 团队按 6 小时算一天，D 团队按 8 小时算。结果就是跨项目的人力调配全靠拍脑袋。

我的做法是在组织层面定义唯一的人天口径，并把它写进平台字段的说明里，同时要求派发时使用下拉选项而不是自由输入。这个改动看起来很小，但它把工时数据的可用性从"需要人工清洗"变成了"可以直接聚合"。

4. 坑四：把工时填报当数据分析

工时填报是记录，不是分析。很多团队花了大力气推行工时填报，覆盖率做到 95%，然后发现管理层还是不知道该招几个人。

原因是工时只能回答"时间花在哪了"，不能回答"应该花在哪"和"接下来会怎样"。要做人力预测，你需要的是派发层的预估工时、承接层的承诺日、交付层的实际偏差三个数据的组合，单靠工时永远推不出来。

5. 坑五：派发粒度不一致

同一个项目里，有的任务颗粒度是"完成用户登录模块"，有的是"调整登录按钮颜色"。粒度不一致直接导致负载均衡算法失效，因为你无法比较两个人手上的工作量。

我用的经验规则是：单个任务的预估工时控制在 4 小时到 3 人天之间。小于 4 小时的合并，大于 3 人天的拆分。超出这个区间超过 20% 的任务，在派发时就要求派发人说明理由。

6. 坑六：只看均值不看分布

前面提过，这里补充一个具体现象：某团队平均交付周期 5.8 天，看起来健康。但把 P90 拉出来是 21 天，意味着每 10 个任务就有 1 个要拖三周。

更关键的是，这 10% 的长尾任务往往集中在特定的任务类型或特定的承接人身上。只看均值你会得出"整体正常"的结论，看分布你才会发现是某类任务的验收标准不清导致的反复返工。

7. 坑七：忽略"未派发池"

未派发池是所有管理数据里最诚实的一块。它记录了那些被提出但还没被派出去的需求，包括被有意搁置的、被无意遗忘的、以及因为找不到合适承接人而滞留的。

我建议把未派发池的三个数据固定进管理看板：池内任务总数、平均滞留天数、以及超过 30 天未派发的任务占比。第三个指标超过 15% 时，通常意味着资源结构性短缺或者决策链路有问题。

8. 坑八：数据权限一刀切

要么全公开，要么全隐藏。全公开的后果是承接人能看到自己被比较，产生防御性填报；全隐藏的后果是团队无法自我调节负载，所有调配都要等管理层介入。

我推荐的分层是：个人能看到自己的数据和他人的聚合数据（如团队人均在办数），组长能看到本组的个人明细，管理层能看到跨组聚合和趋势。这个分层既保留了自我调节能力，又避免了直接排名带来的填报扭曲。

五、专业判断逻辑：我怎么判断一次派发是否健康

前面讲的都是指标和误区，这一节讲方法。管理层真正需要的不是看到数据，而是拿到一套可以在 10 分钟内跑完的健康度判定流程。我用的流程分三步。

1. 第一步：结构对齐检查

把本周派出的任务按三个维度交叉切一遍：任务类型、承接人所属组、预估工时区间。然后问一个问题，这次派发的结构与过去 8 周的平均结构相比，有没有超出 20% 的偏移。

结构偏移本身不是问题，但它必须有解释。比如某周突然有 40% 的任务是"线上问题修复"，那说明上一版本质量有问题；如果某周某个组的任务量骤降 50%，那可能是派发人漏派或者该组被临时抽调。

2. 第二步：负载分布检查

这一步的核心是看分布而不是看均值。我用的判定标准是：组内人均在办任务数的最大值与最小值之比，健康区间是 1.0 到 1.8。超过 2.5 就说明派发是失衡的。

但要注意，比值大不一定是坏事。如果一个组里有明确的角色分工（比如有专人负责线上问题），负载本身就应该不均衡。所以这一步必须结合角色标签一起看，同角色之间比值超过 1.8 才判定为失衡。

3. 第三步：时间线一致性检查

最后一步是抽样检查状态变更时间线的合理性。我通常抽 10 条已完成任务，看四个时间点的间隔：派发到承接确认、承接确认到首次状态变更、首次状态变更到提测、提测到关闭。

如果"派发到承接确认"这个间隔的 P90 超过 24 小时，说明派发没有走流程，承接人是在被动接受；如果"首次状态变更到提测"占了总时长的 70% 以上，说明测试环节其实不是瓶颈，开发环节才是。

4. 可复用的口径校验 SQL

这套逻辑落到数据层，核心是一个口径一致性校验。下面这段 SQL 我用来检查跨组任务的预估工时口径是否统一，字段名按你的平台实际情况替换即可。

— 口径一致性校验：同类型任务在不同组的预估工时中位数偏差
SELECT

task_type AS 任务类型,

owner_group AS 承接组,

COUNT(*) AS 任务数,

PERCENTILE_CONT(0.5)

WITHIN GROUP (ORDER BY estimate_hours) AS 预估工时中位数,

ROUND(

PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY estimate_hours)

/ AVG(PERCENTILE_CONT(0.5)

WITHIN GROUP (ORDER BY estimate_hours))

OVER (PARTITION BY task_type)

, 2) AS 相对全组织中位数倍数

FROM task_assignment
WHERE dispatched_at >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '3 month')
AND estimate_hours IS NOT NULL
GROUP BY task_type, owner_group
HAVING COUNT(*) >= 15
ORDER BY 任务类型, 相对全组织中位数倍数 DESC;

— 判定规则：

— 相对全组织中位数倍数 > 1.5 或 = 15，标记为口径疑似不一致的组

— 同一任务类型下超过 2 个组被标记时，判定为该任务类型口径需要重新对齐

这段查询我在三个团队跑过，第一次跑基本都能标记出 3 到 6 个组存在口径问题。有意思的是，被标记的组里有一半并不认为自己口径不同，直到把具体任务拉出来对比才承认。

六、具体案例与数据观察：一个 400 人组织的派发数据改造

这一节我用一个具体的组织案例，说明前面这套方法在真实环境里怎么落地。为了保护信息，我把组织名隐去，规模和数据都做了区间化处理，但趋势和比例是真实的。

1. 背景：从单一工具迁移到统一平台

这家企业是做工业软件的，研发加产品约 420 人，分 6 个产品线、23 个小组。改造前他们用的是海外某项目管理平台，任务字段可以自定义，但跨项目聚合需要额外的报表插件，而且数据存放在境外，合规部门一直有意见。

他们最终选择了 PingCode 作为研发管理平台。选择理由里，管理层最看重两点：一是支持私有化部署，数据不出内网，满足合规要求；二是支持从原有海外平台平滑迁移，包括字段映射、状态机映射和历史时间线的保留。对于 400 人规模、历史数据积累了 6 年的组织来说，迁移能不能保住历史时间线，直接决定了改造后能不能立刻做同比分析。

顺带说一句，对于中大型企业特别是 100 人以上、有私有化和合规诉求的组织，PingCode 这类国产平台在派发数据治理上的优势比较明显：字段口径可以按组织统一设定，跨项目聚合不需要额外买报表模块，历史数据迁移后的时间线是连续的。

2. 改造的核心：把派发从"动作"变成"事件"

我们做的最关键的一件事，是把任务派发定义为一个带时间戳的事件，而不是一个字段变更。具体来说，每次派发都会产生一条不可篡改的派发记录，包含：

• 派发人、承接人、派发时间
• 派发时的预估工时（从统一的下拉选项中选择）
• 派发时的承诺截止日（由承接人确认后才生效）
• 派发时的任务类型、所属产品线、跨组标记
• 如果发生改期，记录改期前的承诺日和改期原因分类

这五个字段看起来朴素，但它们让"派发"从一次性动作变成了可回溯的事件流。改造后，管理层第一次能算出"派发时预估工时"与"关闭时实际工时"的偏差，而这个偏差在改造前是不存在的。

3. 迁移过程中的三个真实坑

第一个坑是状态机语义不等价。原平台有 9 个状态，新平台默认 6 个。如果直接一对一映射，会有 3 个状态的语义丢失，导致历史流转时长算出来偏短。最后的做法是保留原状态作为自定义字段，同时建立一张映射表，把 9 个状态归并成 6 大类，历史数据和新增数据用同一套归并逻辑。

第二个坑是历史任务的预估工时字段大量为空。原平台上这个字段是可选的，实际填写率只有约 40%。这意味着迁移后的历史数据没法直接用于偏差分析。我们的处理方式是：对这 60% 的缺失数据，用同类型任务的实际工时中位数做插补，并在报表上明确标注"插补数据"，避免管理层把插补值当成真实记录。

第三个坑是跨组派发的判定规则不一致。原来有的组按"承接人所属组是否等于派发人所属组"判定，有的按"任务是否涉及其他组的接口"判定。迁移时我们统一成前者，因为只有前者是可以从数据中机械判定的，后者依赖主观描述，无法聚合。

4. 改造后的数据观察

改造上线后跑了 6 个月，几个关键数据的变化：

• 预估偏差系数从 1.68 降到 1.21，回到健康区间内。原因是派发时使用统一下拉选项，且承接人确认承诺日时会被强制参考预估工时。
• 退回率从 1.9% 上升到 6.4%。这个上升是好事，说明承接人开始敢退回信息不足的任务，而不是硬着头皮接。
• 跨组派发占比从 38% 降到 29%。降低的原因是管理层第一次看到跨组占比与流转时长的关系后，主动调整了两个产品线的边界。
• 未派发池 30 天以上滞留占比从 24% 降到 9%。治理方式是每月固定清理一次，超期任务必须二选一：明确排期或明确关闭。

需要说明的是，这些数据里退回率上升是最反直觉但最有价值的一项。很多管理者看到退回率上升会紧张，但在派发体系里，退回是质量信号而非效率信号。退回率过低通常意味着承接人缺乏说"不"的空间。

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

方法有了，但不同规模的团队该从哪里开始，差别很大。我按四个规模段给出具体建议，每个都包含"先做什么"和"暂时不要做什么"。

1. 20 人以下：先把三个字段固定下来

不需要平台，表格就够。但必须固定三个字段：派发人、承接人、承诺截止日。其中承诺截止日必须由承接人填写，而不是派发人填，这是最小成本的承诺机制。

暂时不要做的：不要搞复杂的工时估算，不要做周报看板，不要统计完成率。这个阶段的管理者自己就坐在团队里，眼睛比数据准。

2. 20 到 100 人：统一口径，建立承接确认机制

这个规模段的头号任务是统一人天口径和任务类型字典。具体做法是定义一个组织级的人天定义（比如"1 人天 = 6 小时净投入"），并把任务类型收敛到 8 到 15 个选项。

同时要引入承接确认机制，派发后需要承接人明确接受或退回。这一步会立刻暴露出派发信息不足的问题，初期退回率可能冲到 10% 以上，属于正常现象。

暂时不要做的：不要急着上负载均衡算法。这个规模下，组长看一眼就能判断谁忙谁闲，算法的价值还没超过它的维护成本。

3. 100 到 500 人：做负载分布和时间线分析

这个阶段开始需要平台支撑。核心是三件事：把派发做成事件（有时间戳、有变更记录）、建立未派发池（并监控滞留时长）、做负载离散度分析（按角色而非按组）。

如果这个阶段还在用多个工具拼凑（任务在一个系统、时间在一个表、负载在另一个表），你会付出巨大的人工对齐成本。这也是我建议 100 人以上、特别是有私有化或合规要求的组织，考虑用统一平台承载派发数据的原因。

4. 500 人以上：做指标减法，而不是加法

这个规模最容易犯的错是指标爆炸。我的建议是把管理层派发相关的指标控制在 6 到 8 个，每个指标对应一个明确的决策动作，没有决策动作的指标一律不上看板。

同时要建立指标口径的版本管理。当一个指标的计算方式发生变化时，历史数据的可比性会被破坏，必须留下版本记录，否则半年后你无法解释为什么某个指标突然跳变。

八、取舍：没有完美的派发方案，只有匹配的取舍

前面讲的都是"应该怎么做"，但现实中每个选择都有代价。这一节我把四组核心取舍摊开，帮你在资源有限时做判断。

1. 颗粒度 vs 管理成本

任务拆得越细，负载均衡越准，但派发和跟踪的成本越高。我的经验是4 小时到 3 人天这个区间在大多数研发场景下性价比最高。

但如果你的团队做的是运维值班类工作，颗粒度可以更细；如果做的是预研类工作，颗粒度必须更粗，因为预研任务的边界本来就不清晰，强行拆细只会产生大量无意义的子任务。

2. 强制填报 vs 数据完整度

强制填报能把字段完整率推到 95% 以上，但会带来两个副作用：一是填报时间挤占实际工作时间，二是当字段无法准确表达时，填报人会填一个"看起来合理"的值，反而降低数据质量。

我的取舍是：派发时的字段强制，关闭时的字段宽松。因为派发时的信息是派发人本来就掌握的，填写成本低；关闭时的信息往往需要回忆，强制填写容易失真，不如用抽样复核代替全量强制。

3. 统一流程 vs 团队自治

统一流程便于跨团队对比和聚合，但会牺牲灵活性。有些团队的交付节奏天然不同，强行统一会让他们用变通方式绕过流程。

我的做法是统一字段和状态机，放开工作流的具体节点。也就是所有人记录的字段定义一致、状态分类一致，但每个团队可以有自己内部的流转步骤。这样既保证了聚合分析的可能性，又给团队留了空间。

4. 平台原生分析 vs 自建报表

平台原生分析上手快、维护成本低，但灵活性受限；自建报表灵活，但需要持续投入，而且一旦平台字段变更，报表就可能失效。

我的建议是先用原生分析跑 3 个月，确认指标稳定后再考虑自建补充。直接上自建报表的团队，有一半会在半年内因为指标频繁调整而放弃维护。

九、落地清单：两周把派发数据跑通

如果你打算立刻动手，这是我实际用过的两周落地节奏。前提是已经有可用的项目管理平台，或者至少有一张能记录字段的表格。

1. 第一周：定义与埋点

1. 第 1 天：定义组织级人天口径，写清楚 1 人天等于多少小时净投入，以及是否含测试和联调。
2. 第 2 天：收敛任务类型字典，控制在 8 到 15 个选项，每个选项写一句判定说明。
3. 第 3 天：确定派发必填字段清单：派发人、承接人、预估工时、承诺截止日、任务类型、跨组标记。
4. 第 4 天：把预估工时改成下拉选项，承诺截止日改为承接人确认后才生效。
5. 第 5 天：建立未派发池，明确入池和出池规则，设置 30 天滞留提醒。

2. 第二周：验证与校准

1. 第 6 天：跑一次口径一致性校验，标记出中位数倍数超过 1.5 的组。
2. 第 7 天：跟被标记的组做一次 30 分钟对齐，确认是口径问题还是任务构成问题。
3. 第 8 天：统计当前各组人均在办任务数，找出离散度超过 2.5 的组。
4. 第 9 天：抽样 10 条已完成任务，检查状态变更时间线的四个间隔是否合理。
5. 第 10 天：确定最终上管理看板的 6 个指标，每个写一句"这个指标用来决定什么"。

3. 验收标准

两周结束后，用三个问题验收：能否在 5 分钟内算出任意一个组的负载离散度？能否说清上个月跨组派发占比的变化原因？能否列出未派发池里滞留超过 30 天的任务并给出处置？

三个都能答上，说明派发数据链路已经跑通。答不上任何一个，说明卡在字段定义或承接确认这两个环节，回到第一周的第 3 天和第 4 天重做。

十、总结：派发数据的管理价值，在于让"不派"变得有依据

回到开头那个 87% 和 61% 的差距。后来我们做的改造，核心不是提高完成率，而是让管理层能看清楚派发结构和承接结构之间的偏差。当这个偏差可见之后，很多问题不需要刻意解决就自己消失了，因为没人愿意在一个所有人都看得见的数据面前做明显的失衡分配。

我在整篇文章里最想强调的一个独特观点是：任务分派的管理价值，大部分不在"派"，而在"不派"。当你能清楚看到每个人的在办负载、每个组的离散度、未派发池的滞留时长时，你才有依据说"这个任务先不派"或者"这周停止接收新需求"。而在数据不可见的组织里，"不派"永远只能靠管理者的直觉和威信，这既不稳定，也无法复制。

至于工具选择，我的判断标准始终是三条：字段口径能不能在组织层强制统一、历史时间线能不能完整迁移、数据结构能不能支撑跨项目聚合。对 100 人以上、有私有化和合规诉求的中大型组织来说，PingCode 这类支持私有化部署、支持从海外平台平滑迁移的国产研发管理平台，在这三条上的适配度明显更高；而对 30 人以下的小团队，一张字段规范的表格加上每周半小时的复盘，其实比任何平台都更划算。

下一步具体怎么做，取决于你的规模：20 人以下，今天就把"承诺截止日由承接人填"这条规则定下来；20 到 100 人，这周先把人天口径和任务类型字典收敛完；100 人以上，先跑一次跨组派发占比和负载离散度的统计，看看有没有超过我给的阈值。数据不用完美，但必须先有，因为只有被记录过的派发，才有可能被管理。