三年前我接手一个 260 人研发组织的 PMO 时，最先被追问的问题不是"项目延期了多少天"，而是"为什么有人手上同时压着 7 条在办任务，有人却在排期队列里空转两天"。当时我们的分派看板只统计了两件事：本周派了多少条任务、平均派单用了多少分钟。数据每周都在涨，士气每周都在掉。真正让我改掉整套指标的，是一次复盘：我们抽查了 480 条已经关闭的任务，发现有 137 条在流转过程中被转派过至少一次，其中 62 条转派原因是"技能不匹配"，还有 29 条是"原执行人已经满负荷但系统没提示"。
这 137 条任务的平均交付周期，比一次性派对的 343 条任务长了 41%。从那天起我认定一件事：PMO 任务分派的数据分析，核心不是算清楚"派了多少"，而是把"派得对不对"变成可采集、可归因、可干预的指标。
一、核心结论：分派指标要度量"决策质量"，而不是"动作数量"
我后来把任务分派的数据指标分成两层。第一层是动作计数，比如分派总量、平均派单耗时、单人在办任务数。第二层是决策质量，比如一次派对率、被动转派率、分派后返工率、负荷基尼系数。绝大多数 PMO 的看板只覆盖第一层，所以永远解释不了"人明明都很忙，项目为什么还是慢"。
这个判断不是我拍脑袋得出的。动作计数类指标的共同特点是：只要派单动作发生，指标就变好；但它和管理结果之间没有必然因果。一个下午派 200 条任务，分派总量很漂亮，可如果其中 60 条后来被转派，这 200 条里真正产生价值的只有 140 条，剩下 60 条的沟通、上下文交接、重新理解成本全部沉没。
1. 三层指标的分工不能混
我在落地时把分派指标拆成三层：输入层看需求成熟度，过程层看匹配与流转，结果层看返工与一次通过。三层的采集口径、责任人和干预手段完全不同，混在一张表里就会变成"人人都看，没人负责"。
| 指标层 | 代表指标 | 数据来源 | 主要责任角色 | 典型干预手段 |
|---|---|---|---|---|
| 输入层 | 需求可执行率、验收标准完整率、估算偏差率 | 需求单字段、评审记录 | 需求方 + 产品负责人 | 准入检查清单、拒绝不成熟需求 |
| 过程层 | 一次派对率、被动转派率、分派响应时长 | 任务流转日志、转派原因字段 | PMO / 项目经理 | 技能标签、负荷阈值、自动推荐 |
| 结果层 | 返工率、一次通过率、交付周期偏差 | 测试记录、验收记录、关闭时间 | 交付负责人 | 复盘机制、分派人画像修正 |
2. 一个反常识的起点：先测"被动转派率"
如果你只能上一个新指标，我建议先上被动转派率。它的定义很朴素：任务分派出去之后，由执行人主动发起、且原因归属为"人岗不匹配"或"负荷超限"的转派次数，除以总分派次数。
我坚持先上这个指标，是因为它天然是"负面指标"，不容易被粉饰。分派总量可以靠批量操作做上来，平均派单耗时可以靠敷衍式点选压下去，但被动转派必须由另一个人主动发起，而且系统里会留下发起人、时间戳和原因。它把"分派决策错了"从一种主观抱怨，变成一条带责任链的客观记录。
二、背景与真实场景：我经历过的三次分派失效
分派问题之所以长期被低估，是因为它在项目健康度报表里几乎不留痕。项目延期了，报表上写的是"需求变更""技术难度""资源不足"，很少有人写"派错人了"。我经历过三次典型的失效，每次的根因都不一样。
1. 场景一：200 人组织的"人肉派单"与隐性排队
那家组织的派单方式是：项目经理在周会上凭印象把任务分给某个人，会后在工具里建单。问题是，周会一周一次，而需求是一周七天在产生的。周一派出去的任务，周三来的紧急需求就得等到下周一。
我统计过那段时期的"分派等待时长"：从需求进入待分派队列，到任务被真正指派到人，中位数是 2.3 天，P90 是 6.1 天。也就是说，有 10% 的需求在派出去之前就卡了将近一周。而项目周期报表里，这段时间被记成了"计划缓冲"，没人把它算作浪费。
2. 场景二：跨部门协作中的"接单率幻觉"
第二次失效更隐蔽。我们上线了"抢单池"，鼓励执行人主动接任务。上线第一个月，接单率达到 94%，看板上非常好看。但两个月后我们发现，某些高价值但费力的任务长期无人接，最后只能由项目经理硬指派。
我把接单池的任务按"预估工时"分桶后发现：预估 1 人天以内的任务接单率 97%，预估 3 人天以上的任务接单率只有 48%。接单率这个指标本身没有错，错的是它被当成一个单一的、不分层的指标来汇报。一旦分层，它立刻暴露出选择偏差。
3. 场景三：私有化环境下的数据断层
第三次失效发生在做国产化替代的时候。组织要求所有研发数据不出内网，工具必须私有化部署。迁移完成后，我们才发现分派相关的字段只带过来了一半，任务标题、指派人、状态都在，但"转派原因""技能标签""负荷快照"这些自定义字段全丢了。
没有负荷快照，就回不出"分派那一刻这个人还背着多少任务"；没有转派原因，被动转派率就只剩一个分母。这件事让我形成了一个固执的做法：任何关于分派的数据模型，必须先确认字段在目标环境里能不能完整落地，再谈指标怎么设计。
三、拆解常见误区：为什么你现在的分派看板会骗你
我复盘过十几个 PMO 的分派报表，问题高度集中在四类误区上。它们的共同点是：指标本身算得没错，但被赋予了错误的解释权。
1. 误区一：把分派数量当作产能
"本月分派任务 2800 条，环比增长 15%"，这句话在管理会上经常被当作效率提升的证据。但分派数量本质上是一个输入量，它和产出之间隔着一个"完成"和一个"验收"。
我在一个组织里做过对照：分派量增长 15% 的那个季度，任务关闭量只增长 3%，而在办任务存量增长 22%。分派量增长快于关闭量增长，通常意味着分派变成了"清空待分派队列"的动作，而不是"配置产能"的动作。
2. 误区二：用平均派单时长掩盖长尾
平均派单时长从 6 小时降到 2 小时，看起来是巨大进步。但如果 P90 从 30 小时涨到 48 小时，这个"进步"其实是把资源集中到了容易派的任务上，难派的任务被进一步延后。
我的做法是：分派时效类指标一律用中位数 + P90 双报告，禁用单一平均值。中位数反映常态体验，P90 反映最差体验，而最差体验通常决定了关键路径上项目的延期风险。
3. 误区三：只看接单，不看返工
任务被接走不等于被解决。我在第二个场景里追踪过一条链路：任务从分派到关闭用了 9 天，看起来正常；但拆开看，前 6 天是等待，交付后 3 天被打回重做。如果报表只记录"关闭用时 9 天"，这条链路的真实问题，分派延迟 6 天，就完全被掩盖了。
所以我要求分派报表必须把"等待时长"和"执行时长"分开记录，并且单独统计"分派后 72 小时内被返工"的任务占比。这个指标比返工率更敏感，因为它专门捕捉"派错了"而不是"做错了"。
4. 误区四：技能匹配靠标签感觉，不靠数据回填
大部分组织的技能标签是自评填写的，填完就没人维护。结果是标签和实际交付能力脱节，分派时的"技能匹配"只是心理安慰。
我的替代做法是：用历史数据反向生成技能画像，而不是用手填标签驱动分派。具体来说，统计每个人在过去 6 个月内承接某类任务的数量、一次通过率、平均实际工时与预估工时之比，用这三个数生成一个"实际胜任度"，再和自评标签做对比。凡是自评"精通"但实际一次通过率低于均值的领域，一律降级为"需协助"。
四、专业判断逻辑：分派指标的五个层次
指标不是越多越好。我在多个组织落地后收敛出一套五层结构，每层解决一个特定问题，层与层之间有因果顺序，不能跳级。
1. 输入层：需求成熟度决定分派上限
如果需求本身没有验收标准、没有明确边界，派给谁都做不好。所以我要求所有进入分派队列的需求必须通过三项准入检查：验收标准是否可验证、依赖是否已识别、工作量是否给出区间估算。
这三项检查的通过率，我称为"需求可执行率"。在一个 180 人的组织里，我们上线准入检查前，可执行率是 54%；上线六个月后提升到 83%。可执行率每提升 10 个百分点，被动转派率大约下降 4 到 6 个百分点，这个弹性系数在我经历的两个组织里都比较稳定。
2. 匹配层：人岗匹配度是可以算出来的
匹配层我只看三个数：技能胜任度（历史同类任务一次通过率）、当前负荷率（在办任务的估算工时之和除以可用工时）、近期切换成本（过去 5 个工作日承接的不同任务类型数）。
（1）技能胜任度
用历史数据算，不用自评。低于该类任务组织均值的，视为不胜任；高于均值 20% 以上的，视为优选。
（2）当前负荷率
超过 100% 的人不进入推荐池，无论技能多匹配。这一条在很多组织里最难推，因为"能者多劳"是默认文化，但数据显示超负荷承接的任务返工率显著更高。
（3）近期切换成本
一个人五天里做了七种不同类型的任务，上下文切换成本会显著抬高。我把它作为推荐排序的扣分项，而不是硬性禁止项。
3. 过程层：流转时效要分段，不要合并
我把分派全链路切成四段：待分派等待时长、分派响应时长（从被指派到被接受或拒绝）、执行时长、验收时长。四段分开统计，谁慢一目了然。
合并统计会导致一个典型后果：执行快但分派慢的团队，和分派快但执行慢的团队，在报表上看起来一样。而这两种情况的干预手段完全不同，前者要改分派机制，后者要改产能配置。
4. 结果层：一次通过率是分派质量的最终裁判
一次通过率的定义是：任务从被指派到第一次验收通过，中途没有发生转派、没有发生返工。这个指标最苛刻，也最诚实。
我在一个组织里跑过对照：一次通过率高的执行人，其承接任务的平均交付周期比一次通过率低的人短 34%。原因不复杂，少一次返工就少一轮沟通、少一轮等待、少一次上下文重建。
5. 健康层：负荷均衡是长期产能的保险
我用负荷基尼系数衡量团队内部的负荷分配均衡度。0 表示完全平均，1 表示全部压在一个人身上。实践中，长期高于 0.35 的团队，离职意向调查中的"工作量"选项得分会明显恶化。
这个指标的价值不在于短期产出，而在于它是唯一能提前六个月预警"关键人流失"的分派类指标。
五、具体案例与数据观察：中大型组织如何把分派数据跑起来
下面这个案例来自我参与过的一次分派体系重建，组织规模 320 人，研发占比约 65%，属于典型的中大型企业。他们当时最大的约束是：数据不能出内网，同时历史数据沉淀在旧工具里，需要完整迁移。
1. 为什么先解决数据落地，再谈指标设计
我们做的第一件事不是设计看板，而是确定字段能不能落地。分派类指标依赖的字段有几个很特殊：转派原因、分派时刻的负荷快照、技能标签版本、指派方式（自动推荐 / 人工指派 / 主动接单）。
其中"分派时刻的负荷快照"最容易丢。它不是一个人工字段，而是需要在分派动作发生的瞬间自动记录当时该执行人的在办任务估算工时之和。如果工具不支持在流转动作上挂自动化逻辑，这个字段就只能靠事后推算，而事后推算出来的负荷值是不准的，因为后续任务已经改变了当时的负荷状态。
这也是我在做工具选型时最看重的一点：能不能在分派动作上挂自动化规则，能不能把自定义字段带进流转日志，能不能在私有化环境里完整跑这套逻辑。放弃私有化部署去换功能便利，在数据不出内网的行业里是不可接受的交换。
2. PingCode 在这个场景里的实际落点
这个组织最终选择了 PingCode。PingCode 主要服务中大型企业及 100 人以上组织，这个定位和他们的规模是匹配的：320 人、跨三个业务线、有独立的 PMO 和测试团队。
选择它的直接原因是三点。第一，支持私有化部署，所有分派流转数据、负荷快照、技能标签都留在内网，满足数据不出内网的合规要求。第二，支持从 Jira 平滑迁移，他们过去八年的历史任务、转派记录、自定义字段需要完整搬过来，迁移后我们才能用历史数据回填技能画像。第三，作为国产替代方案，它在字段自定义和流转自动化上的开放度足够支撑我们自定义的分派规则。
我要说清楚的是，工具本身不解决分派问题。它解决的是"数据能不能被采到、能不能被带过来、能不能被规则触发"这三个前置问题。指标设计和分派规则的合理性，仍然是 PMO 自己的活。
3. 三个月的指标变化记录
下面是这个组织上线分派规范后 12 周的观测数据。需要说明的是，这是单组织的样本观察，不是行业统计，读者应把它当作参考基准而非通用结论。
| 指标 | 第 0 周（基线） | 第 4 周 | 第 8 周 | 第 12 周 | 观测口径 |
|---|---|---|---|---|---|
| 被动转派率 | 27.4% | 21.6% | 15.2% | 12.1% | 转派原因归属人岗不匹配或负荷超限 / 总分派数 |
| 分派等待时长中位数 | 2.1 天 | 1.4 天 | 0.7 天 | 0.5 天 | 需求进入待分派队列至被指派 |
| 分派等待时长 P90 | 6.4 天 | 5.2 天 | 3.1 天 | 2.2 天 | 同上，取 90 分位 |
| 分派后 72 小时返工率 | 14.8% | 12.9% | 9.4% | 7.6% | 指派后 72 小时内被打回重做的任务占比 |
| 一次通过率 | 61.3% | 65.8% | 71.2% | 74.5% | 无转派无返工直接验收通过的任务占比 |
| 负荷基尼系数 | 0.41 | 0.38 | 0.31 | 0.27 | 团队内在办估算工时的分布均衡度 |
第 4 周的变化主要来自"分派动作可追溯"这件事本身。当转派必须填写原因、且原因会进入执行人画像时，分派人在派单前的谨慎程度会明显上升。这是典型的观察者效应，但它是真实的效率提升来源。
第 8 周的变化来自负荷阈值上线。我们把负荷率超过 100% 的人从推荐池里剔除，分派等待时长短期内有小幅反弹（因为可选人变少了），但 72 小时返工率下降幅度最大。这是一个必须承受的短期代价。
4. 一个必须说清楚的代价
第 8 周之后，我收到了两类反馈。第一类是项目经理抱怨"可选人变少了，紧急任务派不出去"。第二类是高技能执行人抱怨"我的任务变少了，是不是被边缘化了"。
这两类反馈都是负荷阈值带来的真实副作用。我的处理方式是把负荷阈值从硬性规则改成软性提示：超过 100% 仍然可以派，但必须由项目经理填写"为什么必须派给他"，并记录到系统里。这条记录后来成了复盘会的重要素材，统计显示，这类"例外分派"的返工率是常规分派的 2.3 倍，用数据让例外自动收敛。
六、不同情况下的行动建议
分派体系没有通用模板，落地顺序取决于组织当前的成熟度和约束条件。我按四种典型情况给出建议。
1. 情况一：完全没有分派数据，只有任务列表
第一步不是上指标，是把四个字段补上：转派原因（枚举值）、分派方式（自动推荐 / 人工指派 / 主动接单）、分派时刻的负荷值、指派到接受的响应时间。
这四个字段补齐后，被动转派率、分派响应时长、分配方式效果对比三个指标立刻可用。其余指标都可以等。
2. 情况二：有数据，但只在单项目内可见
这种情况的瓶颈是跨项目视角缺失。一个人同时参与三个项目时，每个项目经理看到的他都"负荷不满"，全局看却已经超载。建议优先建立跨项目的统一负荷视图，再谈分派优化。
3. 情况三：有数据、有视图，但转派率长期不降
这时候要检查的不是分派规则，而是技能画像。我在两个组织里都遇到过同样的问题：分派规则已经很精细，但技能标签是两年前填的，早就和实际能力脱节。解决办法是用历史一次通过率反向重算画像，并把自评标签降级为参考项。
4. 情况四：受合规约束，数据不能出内网
这类组织必须优先确认工具在私有化环境下的字段完整性和自动化能力。特别是分派时刻的负荷快照这类需要流转触发才能采集的字段，一旦环境不支持，指标就无法回算。
对 100 人以上、有独立 PMO 的中大型组织来说，PingCode 是这类场景里我实际用过、能支撑完整分派数据链路的方案之一；它的私有化部署能力保证数据不出内网，从 Jira 平滑迁移的能力保证历史转派记录不丢，这两点直接决定技能画像能不能用历史数据回填。
七、不同情况下的取舍：哪些指标现在做，哪些必须往后放
分派指标体系最容易失控的地方，是想一次把所有指标都上齐。我在 320 人那个项目里的做法是：先上三个，跑稳一个季度再加两个。下面是我总结的取舍逻辑。
1. 短期优先级：可归因 > 可比较 > 可预测
优先上"能归因到具体动作"的指标。被动转派率可以归因到某条分派记录，分派等待时长可以归因到某个时间段，这类指标上完之后立刻能改行为。
"可比较"类指标比如跨团队分派效率排名，价值在于横向对标，但容易引发博弈，建议第二个季度再上。"可预测"类指标比如基于历史数据预测分派成功率，需要至少 6 个月稳定数据，急不来。
2. 精度与成本的取舍
负荷快照用"实时精确值"还是"每日快照近似值"，成本差很多。实时精确值需要流转自动化支持，投入大但准；每日快照实现简单，但一天内的多次分派会共用同一个负荷值。
我的判断标准是：如果团队内单人日均分派超过 3 次，就必须用实时精确值；低于 1 次，每日快照足够。这条线是在两个组织里对着数据试出来的。
3. 强制与引导的取舍
负荷阈值、技能门槛这类规则，做成硬性阻断会让分派失去灵活性，做成纯提示又会被忽略。我倾向的做法是"软阻断 + 强制留痕"：允许例外，但例外必须写理由，并且例外本身进入统计。
这个设计的好处是：规则不阻断业务，但例外会自己暴露。当例外分派占比超过 15% 时，说明阈值设错了；低于 5% 时，说明阈值太松。
4. 指标公开范围的取舍
被动转派率这类指标，公开到团队层级即可，不要公开到个人排名。一旦个人排名公开，转派会从工具里转到线下，数据反而失真。个人层面的数据只用于画像修正和一对一沟通，不作为考核依据。
八、落地路线图：12 周把分派数据跑起来
我把前面所有内容压缩成一个可以照着执行的 12 周路线图。它不是理论推演，是我在 320 人组织实际跑过的节奏，略有压缩。
1. 第 1-2 周：口径与字段
- 定义被动转派率、分派等待时长、分派后 72 小时返工率三个指标的计算口径，写成文档。
- 补齐四个必填字段：转派原因、分派方式、分派时刻负荷值、指派到接受响应时间。
- 确认字段在私有化环境下的可落地性，尤其是负荷快照是否能由流转动作自动触发。
2. 第 3-6 周：基线采集与首次复盘
- 不做任何干预，纯采集四周数据，建立基线。
- 按业务线、任务类型、预估工时分桶，找出转派率最高的分桶。
- 开第一次复盘会，只讨论"为什么这个分桶转派率是均值的两倍"，不讨论个人。
3. 第 7-9 周：规则上线
- 上线负荷阈值软提示，允许例外但强制留痕。
- 需求准入检查清单上线，未通过检查的需求不进入分派队列。
- 用历史一次通过率反向重算技能画像，替换自评标签。
4. 第 10-12 周：效果验证与调整
- 对比基线与当前数据，重点看例外分派占比是否落在 5%-15% 区间。
- 检查分派等待时长 P90 是否随中位数一起下降，避免长尾恶化。
- 固定三项指标进入月度 PMO 报表，其余指标转入季度复盘。
这个节奏里最容易出问题的是第 7-9 周。规则一上线，各种"这次是特例"的请求会集中爆发。我的经验是提前准备好例外分派的统计数据模板，用三周后的真实数据说话，比在会议上争论谁的活更紧急有效得多。
九、总结：分派数据的终点是让"派错"这件事无法隐藏
我做了这么多年 PMO，最深的体会是：任务分派之所以长期是管理盲区，不是因为它不重要，而是因为它太容易被解释。任务延期可以归因于技术难度、需求变更、资源不足，这些理由都成立，也都无法证伪。
分派数据的作用，是把其中一个模糊的理由变得精确：不是"资源不足"，是"这 62 条任务被派给了技能不匹配的人"；不是"需求变更频繁"，是"这 29 条任务在派出去的时候执行人已经超载"。当理由变精确，干预才有落点。
我的独特判断有两条，和主流做法不太一样。第一条：不要先建分派效率排行榜，先建被动转派率的归因闭环，前者制造博弈，后者产生改进。第二条：技能画像必须用历史一次通过率反向生成，自评标签只能当参考，否则再精细的分派算法都建在流沙上。
如果你的组织正准备开始，我建议下一步只做三件事：先确认工具能不能在私有化环境里记录分派时刻的负荷快照；再花两周纯采集数据建立基线，不做任何干预；然后开一次只讨论分桶、不讨论个人的复盘会。分派指标的价值不在报表好不好看，而在它让"派错了"这件事第一次无处可藏。
常见问题解答（FAQ）
1. PMO做任务分派数据分析，最先该盯哪几个指标？
我年初接手PMO的数据复盘，从平台里一口气导了三十多个字段，结果每次汇报都变成念报表。领导问一句分派到底有没有问题，我竟然答不上来。后来才发现，指标不是越多越好，先分层才有结论。
建议分三层盯，不要混在一起看。第一层是流程健康度：分派及时率（任务创建到指派人字段被写入，≤4小时算及时，按团队SLA可调）和改派率（首次指派人发生变更的任务数÷总任务数，健康线在10%以内）。
第二层是负载层：人均在办任务数WIP（用近4周滚动平均，不要用当天快照）和饱和度（在办任务预估工时÷可用工时，可用工时按6小时/天折算，已扣会议和休假）。第三层才是交付层：按期完成率、平均流转时长。
判断顺序不能反，因为前两层是PMO当天就能干预的，交付类指标受需求变更和外部依赖影响大，直接归因到分派环节会误伤。另外两个口径细节：时效类指标看中位数不看均值，均值会被几条跨月的老任务拉爆；样本小于30条的团队不做排名，只做趋势。
2. 任务分派的数据该从平台日志取，还是用手工台账？
我们团队用Excel台账管分派管了两年，后来一次跨部门对账，发现台账里写的分派时间和平台里的操作时间差了整整一天。当时我第一反应是平台有bug，查了半天才明白，是台账在事后补录。
优先用平台的操作日志，而不是台账里那种计划分派时间字段。具体取四类字段：任务ID、创建时间、指派人变更记录（要含旧值和新值）、状态流转时间。手工台账只保留平台里没有的维度，比如业务负责人、需求来源、客户归属，用来做关联分析，不要用它承载时效数据。
原因很直接：台账是事后补录，一旦进入追责氛围，人会本能地把时间往对自己有利的方向挪，这个偏差不是靠要求认真填表能解决的。做一次对账就能验证：随机抽20条任务，人工回溯群聊和邮件记录，如果台账与日志的时间差超过8小时的比例高于15%，这份台账就不能用于任何时效类指标。
如果平台日志本身不全，退一步可以用创建时间到首次有人认领作为近似口径，但必须在报表上标注口径差异，跨团队对比时不能和标准口径混用。
3. 怎么判断任务分派是不是不均衡，有没有可量化的阈值？
每次迭代评审都有人说自己活多得快炸了，也有人抱怨自己被晾着没事干，吵到最后还是凭谁的嗓门大。我试过按任务件数统计，结果发现一个人接了10个小需求就被判成过载，反而更没说服力。
用WIP离散度加饱和度分档两个指标组合判断。第一步，按人统计近4周滚动WIP，算变异系数CV等于标准差除以均值：CV低于0.25算均衡，0.25到0.4之间要看具体原因，高于0.4基本可以判定分派机制出了问题。
第二步，算饱和度，即个人在办任务的预估工时除以可用工时，分三档：低于70%偏闲，70%到90%合理，高于110%过载。关键提醒是不要只看件数，任务颗粒度差异大的团队必须按预估工时或故事点加权，否则小需求密集的岗位会被系统性误判。
判断依据可以这样用：CV偏高但所有人饱和度都正常，通常是任务颗粒度设计的问题，不是分派问题；CV和饱和度双高，才是真的分派不均，这时候要回头查分派人是不是习惯把活压给几个顺手的人。这套口径我们用在月度分派复盘上，比开会吵架有效得多。
4. 分派规范写进制度了，怎么用数据证明它真的被执行了？
规范发出去三个月，群里半夜派活的情况照样有，有人被指派了三天都不点确认。我想推一把，又怕拿不出证据变成拍脑袋管理。后来我把制度里的每条要求翻译成平台日志能捕捉的动作，才有底气。
把规范拆成四个可被日志捕捉的动作，每个配一个指标。一是有指派人才开工，无指派直接进入处理中状态的任务占比应低于5%。二是24小时内确认受理，受理率等于有人工确认动作的任务数除以已分派任务数，目标95%以上，这里的口径要特别注意，系统自动确认不算人工确认，必须剔除。
三是改派走审批，未经审批的改派次数目标为零，改派记录要能从日志里还原出旧值和新值。四是超载保护，饱和度超过110%的人当月仍被分派新任务的比例应低于10%。执行方式是每月从平台日志跑一次，按团队出这四个数字，只公布数据不点名，连续两个月不达标的团队才进管理例会讨论。
还有一个经验：不要一上来就把个人分派数据挂绩效，我们发现那样做会促使大家靠拖延改派时间来刷指标，反而把数据做脏了。建议先观测三个月不考核，等基线稳定、大家认可口径之后再逐步收敛阈值。
核心关键词
文章包含AI辅助创作：委派流程与规范：PMO任务分派数据分析关键指标，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/364749
读者评论
被动转派率这个切入点我认同，但落地时最大的坑是转派原因字段的质量。执行人为了省事常选“其他”或随手勾一个，最后分母有了、归因没了。我们后来把原因收敛成四个可验证选项，并要求转派时自动带出负荷快照，否则不允许提交，数据才勉强可用。另外，小团队历史数据少，技能胜任度很难算，建议先做负荷率和需求可执行率，别一上来就上五层模型。
从执行人角度看，被动转派率一旦被考核，很容易变成“不敢转派”。明明人岗不匹配，也先拖着做，指标好看了，交付周期反而更长。所以它必须和分派后72小时返工率、等待时长一起看。我们团队试过只盯转派率，结果有人把任务拆碎硬扛，上下文切换成本比转派还高。指标要防的是分派决策，不是防执行人转派。
文章提到私有化迁移丢字段，我深有同感。但更想问：如果现有某项目管理平台的历史流转日志不完整，没有负荷快照和转派原因，数据回填根本做不了。这种情况下硬推指标只会得到假数据。我们的做法是先只强制采集三个字段：分派时间戳、转派原因、当时在办任务数，跑满一个季度再谈分析。另外，用历史数据反向生成技能画像也有风险：一个人如果长期只被派某类任务，画像会自我强化，可能漏掉他其实能胜任的其他工作。