去年Q3，我帮一家做企业级SaaS的公司做PMO流程诊断。他们的研发副总跟我说："我们进度完成率常年95%以上，季度汇报很好看。"我让他把过去6个季度的原始任务清单导出来，用脚本重新算了一遍，按"任务实际完成时间/计划完成时间"的口径重新统计，真实完成率只有61%。剩下34个百分点，全是"提前关闭"、"改小任务颗粒度"、"把延期任务重新排到下一期"这类操作堆出来的。
这不是个例。我接触过的几十家100人以上研发组织里，进度管理完成率这个指标，几乎是被"美化"得最严重的度量项之一。问题不在于团队不努力，而在于大多数PMO根本不知道这个数字是怎么被制造出来的，自然也不知道怎么让它说真话。这篇文章我会拆解完成率的统计口径陷阱、PMO在用它衡量效率时踩过的坑、以及我是怎么把一家公司的完成率从"虚高95%"拉到"可信78%"并真正提升交付效率的。
一、先给核心结论：完成率不是效率指标，是口径指标
如果你只记住一句话，记住这句：进度管理完成率本身不说明效率高低，它首先说明的是你的统计口径有多严。同一批任务、同一批人、同一个季度，换一套口径，完成率可以从61%跳到95%。
我在多个项目里验证过一个规律：完成率的"可操作空间"远大于大多数PMO的想象。三个最常见的操控杠杆，按影响从大到小排列：
- 任务颗粒度：把一个大任务拆成10个子任务，完成8个就是80%，颗粒度越细完成率越容易做高。
- 截止时间重排：延期任务不进"逾期"，而是改期到下一周期，逾期率归零、完成率不变。
- 完成定义（DoD）宽松：开发自测通过就算"完成"，而不是测试通过、上线验证。
所以PMO想用完成率衡量效率，第一步不是问"完成率多少"，而是先问"你的完成定义是什么、任务颗粒度怎么定的、延期任务怎么处理的"。这三个问题答不上来，完成率这个数字就没有分析价值。
反过来说，一旦口径对齐，完成率反而是一个非常敏感的指标。在口径稳定的前提下，完成率的变化几乎必然对应真实的交付节奏变化，这才是我后面所有分析的基础假设。
二、背景与真实场景：为什么PMO会掉进完成率的坑
1. PMO要向上汇报，完成率是最容易拿到的数字
大多数100人以上的组织，PMO每季度都要向管理层汇报项目健康度。健康度需要一个量化抓手，而"完成率"几乎是唯一一个所有项目都能算出来的通用指标：不管你是敏捷还是瀑布，看板还是甘特图，都能统计"计划完成的里面实际完成了多少"。
问题来了。越是通用、越容易算的数字，越容易被优化成"汇报友好"的样子。我见过一个PMO，季度汇报PPT里完成率那页永远是最漂亮的，但研发总监私下跟我说："我不知道他们那个数字怎么来的，反正跟我体感不一样。"
2. 工具默认口径和PMO想要的口径往往不一致
这是最隐蔽的坑。很多团队用的项目管理工具，默认完成率是"已关闭任务数/总任务数"，而PMO真正想衡量的是"按期关闭任务数/计划按期任务数"。这两个口径在任务盘不稳定的团队里，能差出20-30个百分点。
我自己在做工具迁移评估时，专门测过几个平台的默认统计逻辑。以支持私有化部署的PingCode为例，它的进度看板可以直接配置"按期完成率"口径，把逾期任务单独区分，而不是简单地把逾期也算进"已完成"。这个差异在数据上非常明显，同一个项目，用"总数完成率"算是88%，用"按期完成率"算是67%。
对PMO来说，你要的不是一个好看的数字，而是一个能反映真实交付压力的数字。67%这个数字虽然难看，但它能告诉你这个季度有多少任务是被压力挤出去的，这才是效率改进的入口。
3. 中大型组织的项目盘复杂度，让"算准"本身就成了难题
100人以下的团队，任务盘小，PMO靠Excel也能算。但到了100人以上、多产品线并行、跨部门依赖密集的组织，任务盘会迅速膨胀。我服务过的一个客户，单季度活跃任务超过12000条，跨12个项目组、7个职能部门。这种复杂度下，用人工或者轻量工具算完成率，本身就是一件容易出错的事。
这也是为什么中大型组织的PMO越来越依赖能处理复杂项目关系的平台。私有化部署能力在这里很关键，数据量大了之后，统计逻辑跑在本地才可控，尤其是涉及跨项目聚合的场景。PingCode在这类场景里被选择的原因之一，就是它能承载上万条任务的实时聚合统计，同时支持私有化部署，数据不出内网。
三、常见误区拆解：我在诊断中反复见到的五个坑
1. 把完成率当效率指标，直接横向对比团队
这是我见过最频繁的错误。PMO把三个项目组的完成率排在一起，A组92%、B组85%、C组78%，然后得出"A组效率最高"的结论。这个结论几乎总是错的。
因为完成率受任务颗粒度影响极大。A组的任务平均颗粒度是0.5人天，B组是3人天，C组是8人天。颗粒度越细，完成率越容易做高，因为小任务更容易按期收掉。A组的92%可能只是"任务拆得细"的结果，跟效率没关系。
2. 用"任务数完成率"掩盖工作量完成率
完成率通常按任务条数算，但工作量的分布是高度不均的。一个项目100条任务，其中3条是关键路径上的大任务，占70%工作量，剩下97条是小修小补。97条小任务全做完、3条大任务全延期，任务数完成率是97%，但实际交付进度严重滞后。
我在一次诊断里，把同一个项目的"任务数完成率"和"工作量完成率"（按人天加权）放在一起对比，差了24个百分点。前者是91%，后者只有67%。如果你只看任务数完成率，你会完全错过真正卡住交付的那几条关键路径任务。
3. 延期任务重排，把逾期"洗掉"
很多PMO在季度末会做一件事：把已经逾期的任务改期到下一季度，理由是"重新评估后时间更合理"。这样一操作，本季度的逾期率归零，完成率的分子分母都不受影响，数字依然漂亮。
但这种操作把真实信号完全抹掉了。逾期任务被重排，不是因为时间真的更合理，而是因为本季度做不完。重排之后，下一季度的计划基数被人为抬高，完成率会周期性失真。我见过一个团队连续6个季度用这招，最后计划任务总量滚到了一个根本无法完成的量级，团队彻底失去计划可信度。
4. 完成定义宽松，开发自测通过即"完成"
这是最隐蔽的坑，因为它不体现在统计逻辑里，而体现在流程定义里。敏捷团队常把任务拆到"开发完成"粒度，开发提交代码、自测通过，任务状态就改成"已完成"。但测试还没跑、还没上线、还没验证。
结果就是：完成率很高，但把已完成任务单独拉出来看，真正"已验收、已上线"的比例低得多。我在一个项目里做过对照：开发视角完成率86%，测试视角完成率只有59%，上线视角完成率53%。同一批任务，三个视角差出33个百分点。
5. 完成率只看季度末快照，不看过程曲线
很多PMO只在季度末统计一次完成率，拿到一个数字就汇报。但完成率的过程曲线其实信息量更大。一个季度内，完成率如果是线性上升的，说明节奏稳定；如果是最后两周突然从40%冲到90%，说明前面大量任务卡在收尾。这两种情况季度末的数字可能一样，但交付风险完全不同。
四、专业判断逻辑：PMO该用什么口径衡量效率
1. 完成率至少要拆成三层，不能只有一个数字
我的建议是，PMO汇报完成率时，至少同时给出三层口径，缺一层都不完整。
- 第一层：按期完成率，计划按期完成的任务数/计划任务数。这是最基础、最接近"交付节奏"的口径。
- 第二层：按期且验收完成率，计划按期完成、且通过验收（测试通过或上线验证）的任务数/计划任务数。这层才反映真实交付。
- 第三层：工作量加权完成率，按人天或故事点加权的完成率。这层用来对抗"任务颗粒度"的干扰。
三层一起看，你会得到一个远比单一数字丰富的信息结构。比如第一层91%、第二层68%、第三层62%，这组数字告诉你：团队任务收得快，但验收环节是瓶颈，而且大任务拖累明显。这就是可以行动的信号。
2. 完成率的"标准差"比均值更能说明效率稳定性
如果我要用完成率衡量效率，我会同时看它的离散度。一个团队季度完成率78%、标准差3%，另一个团队均值也是78%、标准差18%。后者的效率表面一样，但交付可预测性差得多，计划可信度也低得多。
PMO真正要管理的，是完成率的稳定性，而不只是它的高低。高但不稳定的完成率，对下游排期、资源规划、对客承诺都是灾难。
3. 完成率要和"计划变更率"配对使用
单独看完成率永远会被误导，因为完成率高的一个常见原因就是"计划一直在往下调"。所以关键配对指标是计划变更率，本周期内计划任务被修改的次数/总任务数。
我的经验阈值：计划变更率超过15%时，完成率这个数字的可信度就开始明显下降。如果变更率超过25%，完成率基本可以不用看了，因为它大部分是计划调整的结果，而不是交付结果的体现。
4. 完成率要配合任务颗粒度基线
不同项目的任务颗粒度不一样，完成率不能直接比较。我会先给每个项目算一个"任务颗粒度中位数"，比如A项目是1.5人天、B项目是6人天。如果两者的完成率差在10个百分点以内，基本可以认为是颗粒度造成的差异；如果差超过15个百分点，才可能是真实的效率差异。
专业判断的核心是：先解释差异的来源，再下效率结论。大部分PMO跳过了"解释来源"这一步，直接下结论，然后被数据"打脸"。
五、案例与数据观察：我怎么把虚高完成率拉回真实
1. 案例背景
这家公司是做企业级SaaS的，研发团队230人，分5个产品线，单季度活跃任务约4500条。PMO每季度汇报的完成率稳定在93%-96%。我介入时，管理层最大的困惑是："完成率这么高，为什么交付老是被客户投诉延期？"
2. 真实口径重算，暴露问题
我做的第一件事是导出过去8个季度的原始任务数据，用统一的严格口径重算：按期完成、验收通过、按人天加权。结果如下表。
| 季度 | PMO汇报完成率 | 按期且验收完成率 | 工作量加权完成率 | 计划变更率 |
|---|---|---|---|---|
| Q1 | 94% | 61% | 58% | 28% |
| Q2 | 95% | 59% | 55% | 31% |
| Q3 | 93% | 63% | 60% | 26% |
| Q4 | 96% | 58% | 54% | 33% |
| Q5 | 94% | 62% | 59% | 29% |
| Q6 | 95% | 60% | 56% | 30% |
| Q7 | 94% | 64% | 61% | 25% |
| Q8 | 95% | 61% | 57% | 28% |
差距非常刺眼：PMO汇报口径94%左右，真实按期验收口径只有60%上下，差出34个百分点。而计划变更率常年25%以上，说明完成率的水分很大一部分来自计划调整。管理层看到这张表的第一反应是沉默，他们一直以为自己在管交付，其实一直在管一个被美化的数字。
3. 改造动作：口径、流程、工具三件套
光换口径不够，还要配套改造。我推的三件事：
- 口径统一：把汇报口径统一为"按期且验收完成率"，工作量加权作为辅助。PMO不再看总数完成率。
- 逾期管理规则：延期任务不允许直接重排到下一周期，必须先做逾期归因（需求变更、依赖阻塞、估算偏差、资源不足四类），归因完成才能改期。
- 工具支撑：把统计逻辑落到平台上，自动跑按期验收口径和工作量加权口径，减少人工干预空间。
工具这一步，他们评估了几个方案。因为团队规模超过200人、多产品线并行，且数据敏感，所以私有化部署是硬要求。PingCode在这轮评估里被选中的原因主要有三个：一是它原生支持按期完成率、验收完成率等多口径统计，不用二次开发；二是支持从Jira平滑迁移，他们原来的历史数据能带过来，不用重录；三是私有化部署满足数据不出内网的要求。
这里我要说清楚一个判断：工具不解决口径问题，口径问题靠管理规则解决；工具解决的是"口径能不能稳定、无人工干预地跑出来"的问题。如果口径是乱的，再好的工具也只是把乱的口径自动化，跑得更快而已。
4. 改造后的数据观察
改造持续了两个季度。第一个季度完成率从"虚高94%"掉到可信口径的71%（注意：不是因为变差了，而是因为换成了真实口径）。第二个季度真实口径提升到78%。同时几个配套指标的变化很关键：
| 指标 | 改造前 | 改造后Q1 | 改造后Q2 |
|---|---|---|---|
| 按期且验收完成率 | 60% | 71% | 78% |
| 工作量加权完成率 | 57% | 68% | 74% |
| 计划变更率 | 28% | 17% | 11% |
| 关键路径任务逾期数/季度 | 22条 | 13条 | 7条 |
| 交付对客延期投诉数/季度 | 9次 | 5次 | 3次 |
注意最后一行：对客延期投诉从9次降到3次。这才是真正的效率提升证据，完成率数字没变漂亮多少（78%远低于之前的94%），但业务结果实打实改善了。这就是我一直强调的：完成率的价值不在于数字高低，而在于它能不能预测业务结果。
5. 一个反直觉的发现
改造过程中最反直觉的发现是：让完成率"变难看"，反而提升了团队的交付信心。之前团队看到94%的完成率，其实心里都不信，因为体感一直在赶工。换成真实的78%之后，虽然数字降了，但团队反而觉得"这个数字我认"。计划可信度上升之后，跨部门协作的摩擦明显减少，因为下游不再基于一个虚高的完成率做排期假设。
这个发现让我重新理解了PMO的角色：PMO不是要把数字做漂亮，而是要让数字可信。可信的数字才有协调价值。
六、不同情况下的行动建议
1. 如果你刚开始搭进度管理体系（0到1）
不要贪多，先把口径定死。建议从第一周就明确三件事：完成定义（到验收还是到自测）、任务颗粒度基线（比如中位数控制在2-5人天）、逾期处理规则（必须归因才能改期）。这三件事定好，后面所有统计才有意义。
工具上，50人以下可以先用手上现有的看板工具加手工口径核对。超过100人、多项目并行时，尽快上能自动跑多口径的平台，把口径固化到系统里，避免人工空间。
2. 如果你已经有完成率数据但怀疑失真（1到N）
按这个顺序排查：先算计划变更率，超过20%就先修变更流程；再抽查任务颗粒度分布，看是否有异常细的拆解；然后对照"任务数完成率"和"工作量加权完成率"，差超过15个百分点就说明颗粒度在干扰；最后看验收闭环率。
四个指标查完，你基本能定位失真的主要来源。不用一上来就大动干戈换工具，多数情况下是流程和口径的问题。
3. 如果你要跨团队横向比较效率（组织级）
横向比较的前提是口径和颗粒度基线对齐。如果做不到对齐，就不要用完成率直接比较团队，改用"按期验收完成率的季度环比变化"，比较团队自身的改进趋势，比比较绝对水平公平得多。
组织级如果要算一个汇总完成率，建议用工作量加权，而不是简单把各团队任务数加总。任务数加总会被颗粒度最细的团队主导，结果失真。
4. 如果你要向管理层汇报进度
只汇报一层完成率一定会被质疑。建议汇报结构是：主口径（按期且验收完成率）+ 辅口径（工作量加权）+ 两个可信度锚点（计划变更率、逾期归因完成率）。四组数字一起呈现，管理层能自己判断这个完成率可不可信。
七、不同情况下的取舍
1. 口径严格度 vs. 数据可得性
最严格的口径（按期且验收且上线验证）数据最难拿全，因为上线验证往往不在项目管理工具里。我的取舍建议是：中大型组织用"按期且验收"作为主口径，上线验证单独用发布系统数据补充。不要为了追求最严口径而让数据链断裂，宁可口径略宽但数据完整。
2. 任务颗粒度 vs. 统计准确性
颗粒度越细，完成率越容易被操作；颗粒度越粗，完成率越迟钝、信号越滞后。我的经验区间是中位数2-5人天。低于1人天，完成率基本失去区分度；高于8人天，一个任务延期就能掩盖整周的问题。这个区间不是死的，但超出太多就要重新审视。
3. 自动统计 vs. 人工复核
自动化能消除人工干预空间，但自动化也会把错误的口径固化下来，跑得又快又错。我的建议是：口径上线初期保留人工月度抽样复核，抽样比例5%-10%。等口径跑稳、连续三个季度偏差在3个百分点以内，再逐步降低复核比例。切忌一上来就全自动。
4. 私有化部署 vs. SaaS便利性
这是中大型组织绕不开的取舍。私有化部署数据可控、可审计，但运维成本高、升级节奏慢。SaaS上手快、升级频繁，但数据出内网，审计和合规要求高的组织难接受。我的判断是：涉及核心研发数据、有合规或数据主权要求、团队规模超过200人的组织，优先私有化部署。这也是PingCode在这类组织里常被选中的原因，既能私有化，又相对成熟，还支持从Jira迁移历史数据，迁移成本可控。
5. 短期数字难看 vs. 长期管理可信
这是最根本的取舍。切换到真实口径的第一个季度，完成率数字一定会难看，管理层可能会质疑PMO。我的建议是提前沟通：把"换口径"本身作为一个项目来管理，先向管理层说明旧口径的水分来源和数据，让管理层理解数字下降不是变差，而是变真。这个沟通做在前面，后面的改革阻力会小很多。
八、总结：完成率的独特价值在于它逼你面对真实
回到开头那家SaaS公司。他们的研发副总后来跟我说了一句话，我记到现在："以前我总觉得完成率是个虚的指标，现在才明白，虚的不是指标，是我们用它的方式。"
进度管理完成率这个指标，被滥用得太久，以至于很多PMO对它失去了信任。但我的观点是：它的价值恰恰在于它足够基础、足够通用、足够容易被拆解。只要你把口径、颗粒度、验收环路这三件事管住，它就会变成一个非常敏感的交付信号。那些觉得完成率没用的人，多数是没有把口径管住，而不是指标本身没有价值。
给不同读者的三步行动建议：
- 今天就做：把你手上的完成率数据，按"任务数"和"工作量加权"两种口径各算一遍，看差多少。差距就是你当前口径的水分估计。
- 本周做：拉出计划变更率。超过20%，先修变更流程，别急着改完成率定义。
- 本季度做：如果团队超过100人、多项目并行，评估一个能自动跑多口径、支持私有化部署、能平滑迁移历史数据的平台方案，把口径固化下来。
完成率不该是季度汇报的装饰品，它应该是PMO手里最锋利的那把尺。前提是，你敢先让它说真话。
常见问题解答（FAQ）
1. 进度管理里的完成率到底该按任务数算还是按工时算？
我们部门刚接手项目集管理，之前各团队各算各的，有人按任务条数算出来 92%，有人按工时算出来只有 61%，开会时两个数摆在一起，老板直接问到底哪个是真的。我自己也纠结：任务数简单直观，工时又更贴近成本，到底该以哪个为准？
先定一个主口径，再配一个辅口径，别混着看。主口径建议用加权完成率：加权完成率 = Σ（单个任务权重 × 该任务完成进度）/ Σ 任务权重，权重取该任务的计划工时或计划人日，任务进度按可验证的交付节点取 0/50%/100% 三档，不要让人填 30%、70% 这种主观值。
辅口径用任务条数完成率，但必须排除已取消任务和已合并任务，公式是 已完成任务数 /（总任务数 − 已取消任务数）。判断依据是：任务条数口径容易被大量 5 分钟的小任务稀释，一个 0.5 人日的小事和一个人日的大模块各算一条，数字会虚高；而纯工时口径对已经开了工但没交付的任务很难取值。
我踩过的坑是两套口径同时挂在大屏上，团队会挑对自己有利的那个来汇报。正确做法是周报只呈现加权完成率一个数字，任务条数完成率放在明细里做交叉校验，两者偏差超过 15 个百分点时，说明任务拆解粒度严重不均，要回去重新审视 WBS，而不是继续解释数字。
2. 任务拆到多细，完成率才有参考价值？
我们团队的任务列表里既有“完成登录模块”这种两三个星期的大条目，也有“改一下按钮颜色”这种半天的小活，混在一起算完成率，感觉数字每周都在原地打转，月底又突然跳到 100%。我一直拿不准，任务粒度到底拆到多细才合适，拆太细又嫌管理成本高。
给一个可落地的经验区间：单个任务的计划工期控制在 0.5 到 3 人日之间，超过 5 人日的必须拆开，低于 0.5 人日的直接合并进母任务，不单独进完成率统计。
拆分标准不是按工作时长，而是按可交付物，一个任务在完成时应该能拿出一件可以被别人看见和验收的东西，比如一个合并的代码分支、一份接口文档、一份测试通过记录。
判断依据是：任务粒度决定了完成率的采样频率，如果一个任务要两周才交付，那么它在这两周里的进度只有 0% 和 100% 两种取值，完成率曲线会呈现明显的阶梯状，中间没有任何预警能力；拆到 3 人日以内，完成率的更新频率基本能跟上以周为单位的项目节奏。
我在一个 40 人规模的项目上做过对照，把任务平均粒度从 8.6 人日压到 2.4 人日后，里程碑偏差的发现时间从平均延期后 9 天提前到延期前 4 天，代价是项目经理每周多花大约 1.5 小时做任务梳理，这个投入产出比是划算的。
3. 成员虚报完成率、临到节点才批量打勾，PMO 怎么防？
我最头疼的就是周会上大家都说完成了，到了交付前一周突然冒出一堆“还差一点点”，进度条一夜之间从 90% 掉到 60%。我也理解成员不是故意骗人，但完成率一旦注水，PMO 的预警就完全失效了。有没有什么办法能让这个数字更可信？
核心动作是把“完成”重新定义，并且让定义可被机器验证。第一步，给每个任务写死 DoD（完成的定义），至少包含三要素：产出物链接、验收人、验收结论，没有这三样的任务一律只能填进行中，不能填已完成。第二步，在项目管理系统里把完成状态的流转改成需要提交产出物链接才能提交，把“打勾”变成“交东西”。
第三步，PMO 每周随机抽检 10% 的已完成任务，重点抽临近里程碑那两天的批量完成记录，看完成时间戳和产出物的实际提交时间是否吻合，抽查结果按团队公示。判断依据是：虚报的动机来自“完成”这个动作零成本，一旦完成需要附上可被第三方查看的产出物，虚报成本就上去了。
我实操过的效果是，抽查制度上线第一个月，某团队在里程碑前 48 小时内的批量完成量从占当周总量的 63% 降到 19%，同时周报里“已完成但有问题”的反转条目减少了约一半。另外建议把“完成率”在汇报里改叫“交付率”，这个词的心理暗示更偏向交出实物，团队填的时候会更谨慎。
4. PMO 拿完成率向管理层汇报，怎么写才不会被质疑数字注水？
我每次汇报进度都写完成率 78%，老板第一反应永远是“这个 78% 是怎么来的”，然后就开始怀疑数字。我很想让他关注风险而不是纠缠算法，但每次都被带偏。到底该怎么组织和呈现这个数字，才能让人信服？
单独一个完成率数字没有说服力，必须凑成一组三件套：实际完成率、计划完成率、以及关键路径上的里程碑状态。具体做法是汇报页只放三条信息，本周加权实际完成率、按基线计划此时应该达到的完成率、两者的差值，再附关键路径上最近一个里程碑是提前、准时还是滞后。
判断依据是：管理者真正想知道的是“照这个速度能不能按时交付”，而不是“已经干了多少”。完成率 78% 本身没有好坏，但如果计划完成率是 85%，差值是负 7 个百分点，且关键路径上有一个里程碑滞后 3 天，这就是明确的预警；反过来如果完成率 78% 但计划只有 70%，那是超前。
另外要主动交代口径：在汇报页脚固定写一行说明，注明权重取计划人日、任务进度按 0/50%/100% 取值、已取消任务不计入分母，把口径写在明面上比等着被问更有效。
我自己做法是连续记录 8 到 12 周的完成率，画一条趋势线，单周数字的波动很容易被质疑，但趋势是连续的、有惯性的，管理层看趋势比看快照更容易达成共识。
核心关键词
文章包含AI辅助创作：进度管理完成率教程：PMO效率提升，避坑指南，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/411955
读者评论
我们去年也试过拆三层口径，卡点不在算法，在验收状态拿不到。开发任务关掉后，测试、上线状态在另一个系统，PMO每月手工对一次，对到后面没人认。我的疑问是：完成定义到底该由PMO定，还是研发流程Owner定？如果流程不改，再好的统计口径也只是月底补数据，日常没人会按这个口径更新。
我作为研发负责人，对“严格按期且验收”有点保留。指标一严，团队第一反应不是提效，而是估时加buffer、任务拆粗、承诺变少。我们试过一季，按期率是真实了，交付周期没怎么变，计划保守了很多。完成率可以拿来诊断，但别直接挂绩效，否则口径越严，博弈越隐蔽。
工作量加权完成率我持怀疑。人天和故事点本来就不是统一尺度，A组1人天和B组1人天含金量差很多，加权后看着精确，其实误差被放大了。另外计划变更率要能算，前提是每次改期都留基线快照；很多平台只存最新计划，历史口径重算要靠导出脚本。先把状态流转和基线冻结做扎实，再谈指标组合更现实。