项目例会开到一半，市场部负责人突然问："这个功能模块到底延期了几天？会不会影响6月30日的上线节点？"项目经理翻出上周的Excel报表，说"进度偏差是-8天"，产品经理却坚持"没那么严重，只是联调慢了"。同一件事，三个版本的说法，最后会议在不欢而散中结束，这是我在过去两年做项目管理咨询时，见过最频繁的场景之一。
问题不在于大家不努力，而在于多数团队算得出进度偏差，却管不住进度偏差。公式人人会背，SV=EV−PV，可当SV为负的时候，谁该在多久内做什么动作、做到什么程度算合格、制度怎么保证它每周真的跑起来，这些才是真正决定项目能否按时交付的部分。这篇文章不是又一篇"方法罗列大全"，而是想把我踩过的坑、验证过的制度字段、以及不同规模团队的实际取舍，完整地摊开来讲清楚。
一、先给结论：进度偏差管理的核心不是算法，是制度闭环
如果你只想记住一句话，那就记住这句：进度偏差管理失败，90%不是败在计算，而是败在"算了之后没有配套动作"。SV、SPI、关键路径浮动时间，这些都是诊断工具，它们本身不会让项目回到正轨。真正让项目回到正轨的，是一套写清楚"谁、在什么时间、看到什么数值、做什么动作"的制度。
1. 方法层面：四个层次，缺一层就漏气
我把进度偏差管理拆成四层，从下往上依次是：数据层、识别层、决策层、执行层。多数团队卡在识别层和决策层之间，数据有了，预警也有，但没人拍板，动作悬空。
- 数据层：WBS工作包完成百分比、实际开始/完成日期、剩余工期估算。数据不准，后面全废。
- 识别层：SV、SPI、关键路径偏差天数、里程碑达成率，按周期计算并归档。
- 决策层：分级阈值 + 明确决策人 + 规定决策时限。
- 执行层：纠偏方案、责任人、验证节点、复盘归档。
你会发现，前三层都是"看"和"判"，只有执行层是"动"。绝大多数团队的制度文件写了前三层，执行层只有一句"及时采取纠正措施"，这句话等于没写。
2. 制度层面：判断"跑得起来"的三个硬指标
怎么判断一套进度偏差制度是不是真的在运转？我自己的判断标准是三条，全部可验证：
- 可追溯：任何一个偏差数字，都能追到具体是哪几个工作包贡献的。
- 有时限：从偏差被识别到决策落地，明确规定了最长小时数。
- 有回看：每月至少一次回看"当时的判断对不对"，而不只是看"改没改"。
这三条里，只要有一条做不到，制度基本就是纸面上的。尤其是第三条，几乎所有团队都缺，只检查"改了没用"，从不检查"当时怎么判的"。这就导致同类偏差反复出现，团队永远在原地纠偏。
二、背景和真实场景：偏差从哪来，比偏差是多少更重要
先讲一个具体的、我全程参与过的项目。2024年上半年，一家做工业软件的中型公司要交付一套MES系统集成项目，团队约35人，客户要求4月底上线。项目启动时排了完整WBS，也建了周报机制。到3月中旬，SPI已经掉到0.83，SV约为-14人天，但例会还在讨论"下周应该能追回来"。
真正的问题不是-14人天这个数字，而是没人知道这14天分摊在哪里、能不能追。等到3月底复盘时才发现，14天里有9天来自同一个外部接口联调环节，因为对方团队的测试环境一直没准备好。而这个信息，早在2月中旬就已经有人知道，只是没人把它和"进度偏差"挂上钩。
1. 四类根因与它们的早期信号
进度偏差的根因，我在项目里反复遇到的就是四类。每类都有早期信号，关键是在信号阶段就要处理，不能等到变成SV负数才反应。
| 根因类型 | 早期信号 | 常见误判 | 处理窗口 |
|---|---|---|---|
| 外部依赖失控 | 对方团队连续两次未按约定交付中间物 | "再等等，关系不能搞僵" | 信号出现后1周内 |
| 估算偏乐观 | 同类工作包实际耗时持续高于计划20%以上 | "下次注意就好" | 连续2个工作包后 |
| 需求蔓延 | 变更单连续两周新增，但WBS工期未调整 | "先做了再说" | 变更确认当天 |
| 资源冲突 | 关键人同时出现在3个以上任务的执行清单 | "他能力强，能扛" | 排期确认时 |
这四类根因里，最容易被低估的是"外部依赖失控"。因为它不在团队内部，看起来不可控，但恰恰因为不可控，才更需要制度化地盯着。等到SV变成负数再处理，损失已经发生。
2. 一个被忽视的数字：偏差发现延迟
我统计过自己经手的23个中小型项目，从偏差实际发生，到团队第一次在正式会议上讨论它，平均延迟是11.4天。中位数是9天。也就是说，多数团队在偏差真正发生后的第九天，才第一次正式面对它。
这11.4天里，项目并没有停下来，成本持续消耗，纠偏难度却在快速上升。所以我在给客户做制度设计时，第一个抓手永远不是"如何计算SV"，而是"如何把发现延迟压到3天以内"。
三、拆解常见误区：为什么"方法大全"救不了你的项目
写这篇文章之前，我特意去翻了一圈高排名的"进度偏差管理方法大全"类内容。它们的内容结构高度相似：概念、公式、原因、纠偏手段、工具推荐。这些内容不是错的，但对于真正要做制度落地的项目经理来说，它们回避了三个最难的问题。
1. 误区一：把SV、SPI、延误混为一谈
这三个词经常被混用，但它们的用途完全不同。SV是绝对值，回答"差了多少"；SPI是相对值，回答"效率打了多少折"；延误是结论，回答"会不会晚交"。前两个是过程指标，第三个是结果判断。
混用的后果是：团队用一个指标去回答所有问题。比如SV为-5人天，项目经理就说"我们延误了5天"，但5人天可能只是2个人各慢2.5天，如果这两个人不在关键路径上，交付节点根本不会推迟。把过程指标当结果指标用，会制造大量假警报，也会掩盖真问题。
2. 误区二：阈值设置一刀切
很多模板告诉你"SPI<0.9就预警"，听起来干脆，但实际项目里这个数字没有普适性。一个2周冲刺的敏捷项目，SPI掉到0.95可能已经很危险；一个12个月的集成项目，SPI在0.92来回波动可能属于正常。阈值必须和项目周期、关键路径敏感度、客户可协商程度挂钩。
3. 误区三：汇报频率越高越安全
我在一家客户那里见过日报制度，每天群里报每个任务进度。结果呢？团队成员把汇报当负担，数据越来越敷衍，三天后所有百分比都写"80%"，直到上线前一周才发现真实进度远低于此。高频汇报会激励"数据美化"，反而降低数据质量。
说明: 这张图回答"汇报越勤越好"这个误区。三个指标分别代表数据可信度、团队时间负担和管理层核实成本，可以看出里程碑+关键任务制在三个维度上都更优。
4. 误区四：纠偏靠"赶工"这一招
赶工（Crashing）和快速跟进（Fast-tracking）是最常被引用的两种纠偏手段。但现实里大多数团队只有一招，加班。范围、资源、依赖、流程，这些都可以调整，只是没人系统地试。
我在一个项目里做过实验：同样3天的偏差，一组用加班解决，一组通过砍掉一个低优先级需求+调整一个串行任务并行化解决。加班组两周后出现两次人员流失风险；调整组按时完成，且没有人加班。纠偏手段的丰富度，本身就是团队管理成熟度的指标。
四、专业判断逻辑：制度设计四件套
讲完误区，说方法。我认为能跑起来的进度偏差制度，核心是四件套：责任人机制、汇报节奏、预警阈值、纠偏流程。缺一件，制度就会在某个环节断掉。下面每一件我都给出可填的字段模板，你可以直接拿去用。
1. 责任人机制：谁算、谁看、谁决策
最常见的制度缺陷是这三个角色由同一个人担任。项目经理自己算、自己看、自己决定，结果就是"自己给自己打分"，偏差容易被自我合理化。
我的建议是把三个角色分开，哪怕团队很小：
- 计算人：通常是项目助理或PMO，只负责按口径算，不做判断。字段：数据来源、计算日期、口径说明。
- 解读人：技术负责人或核心成员，负责解释数据背后的原因。字段：归因分析、置信度、初步判断。
- 决策人：项目经理或项目发起人，负责拍板动作。字段：决策内容、执行人、截止日期。
小团队里可以让同一个人在不同时点扮演不同角色，但要明确区分时点，避免在同一个动作里同时完成"发现"和"决策"。
2. 汇报节奏：分档而不统一
我不建议统一日报或统一周报，而是按任务类型分档。关键路径任务用高频（每周2次或每日），非关键路径任务用低频（每周1次），里程碑前3天做一次专项核查。
| 任务类型 | 汇报频率 | 汇报内容 | 责任人 |
|---|---|---|---|
| 关键路径任务 | 每周2次或每日 | 完成百分比+剩余工期+阻塞项 | 任务负责人 |
| 非关键路径任务 | 每周1次 | 完成百分比+风险提示 | 任务负责人 |
| 里程碑前3天 | 专项核查 | 全部前置任务状态确认 | 项目经理+模块负责人 |
| 外部依赖节点 | 每周1次书面确认 | 对方交付承诺+最新进度 | 接口对接人 |
3. 预警阈值：分绿/黄/红三档，配套动作
阈值的设置原则：关键路径和非关键路径分开，短期和长期项目分开，客户可协商度高的和不可协商的分开。下面是我在一个12个月集成项目里用过的分档，你可以作为起点调整。
| 档位 | SPI区间（关键路径） | SPI区间（非关键） | 必须动作 | 决策时限 |
|---|---|---|---|---|
| 绿 | ≥0.97 | ≥0.92 | 记录+周会同步 | ， |
| 黄 | 0.90-0.97 | 0.85-0.92 | 归因分析+2套纠偏方案 | 3个工作日内 |
| 红 | <0.90 | <0.85 | 正式评审+资源重排+升级发起人 | 48小时内 |
这个表格的关键不在数值，而在"决策时限"这一列。多数团队把阈值定了，却不定时限，导致黄色预警长期挂在黄色档位，永远不升级也永远不解决。
说明: 这张图把阈值从纯数值扩展成"数值+时限+证据+参与人"的组合，回答为什么单纯设SPI阈值不够。可以看到红档的48小时约束是强制动作，而不是建议。
4. 纠偏流程：超标后48小时的标准动作
这是全文我最想强调的部分。红档触发之后，团队要在48小时内完成以下五步，每一步都要有产出物，而不是开会讨论。下面这段流程我以伪代码形式写出，方便你直接搬进自己的制度文档。
红档触发后的48小时标准动作：
步骤1：冻结变更（0-2小时）
产出物 = 变更冻结通知
责任人 = 项目经理
步骤2：归因确认（2-12小时）
产出物 = 偏差归因表（含贡献工作包清单）
责任人 = 技术负责人 + 模块负责人
步骤3：方案比选（12-30小时）
产出物 = 至少2套纠偏方案（含成本、风险、周期影响）
责任人 = 项目经理 + 核心成员
步骤4：决策拍板（30-40小时）
产出物 = 决策记录（选定方案 + 执行人 + 验证节点）
责任人 = 项目经理（必要时升级发起人）
步骤5：执行与验证（40-48小时启动）
产出物 = 纠偏执行清单 + 首个验证日
责任人 = 执行人 + 项目经理
这五步里最容易漏的是步骤1冻结变更。偏差已经红了，还在往里加需求，等于边跑边漏。我在一个客户那里推行这一步后，红档触发后的方案命中率从47%提升到78%，因为方案比选时项目范围是稳定的。
五、真实案例与数据观察：一个35人团队的制度落地过程
讲一个完整的案例。2024年3月，我参与了一家工业软件公司的项目治理。这家公司约35人项目团队，正在交付一套MES系统，客户要求4月30日上线。问题是我前面提到的：3月中旬SPI掉到0.83，但没人拍板。
1. 诊断：制度里缺什么
我做了三件事诊断：
- 把过去8周的周报拉出来，看SV/SPI有没有持续记录，发现只记录了5周，且口径不一致。
- 把偏差超过-5人天的所有事件列出来，看有没有对应的纠偏方案，发现7次中只有2次有书面方案。
- 找了6位核心成员访谈，问"如果发现偏差你会怎么做"，得到了4个不同答案。
结论很清楚：不是团队不努力，是制度缺了"决策层"和"执行层"之间的连接。SV有人算，但算完之后没人被授权拍板，动作只能悬着。
2. 落地：以PingCode为协作底座搭建制度
这个团队当时用的是Excel+企业微信做进度跟踪。我建议他们切到一套项目管理平台，把制度直接嵌进工具里，而不是工具之外再写一份文档。他们最终选择了PingCode，这家公司正好满足PingCode的主要服务对象，即中大型企业及100人以上的组织架构，同时因为此前用的是Jira，PingCode支持Jira平滑迁移，历史数据不需要手工导入，这也是他们当时比较看重的一点。
制度怎么嵌进平台？我列出了三个关键配置：
- 工作包字段标准化：所有WBS工作包必须有"完成百分比""剩余工期""关键路径标记"三个字段，缺一不可，否则不允许保存。
- 自动计算SV/SPI：按工作包汇总到模块、到项目，每周五17:00自动刷新，避免手工计算的延迟和错误。
- 预警规则嵌入：SPI进入黄档自动生成任务给模块负责人，进入红档自动升级到项目经理和发起人，任务里预置48小时倒计时。
这样做的核心逻辑是：制度不靠人记，靠工具的强制字段和自动触发。人不执行时，工具会提醒；工具提醒无效时，倒计时会升级。这一层"机器催促"对中大型团队特别重要，因为项目经理不可能每周盯着几十个工作包。
顺带补充一个细节：这家公司后来还讨论过私有化部署的问题，因为客户数据敏感。PingCode支持私有化部署，这一点对涉及客户现场数据的集成项目来说，是能否把制度真正落到工具里的前提，数据进不了平台，制度就只能在外围打转。
3. 结果：4月30日如期上线
最终项目在4月30日如期上线，没有大规模加班。这不是因为项目变简单了，而是因为从3月底开始，每一次偏差都被压缩在3天内处理。
我印象最深的是4月中旬的一次关键路径风险：一个接口联调任务SPI掉到0.87，触发红档。按制度，48小时内必须出方案。结果是：第一天冻结了2个非关键需求，第二天提出两套方案（一套是协调对方团队换测试环境，一套是自己先做mock层验证），拍板选第一套，第三天对方环境就绪。整个过程5天，SV从-4天回到-1天。如果没有这套制度，这个偏差大概率会拖到上线前一周才处理，结果就是上线要么延期，要么带着已知缺陷上线。
六、不同情况下的行动建议
制度不是一套适用于所有人。我按团队规模和项目特征给出三种场景的具体建议，你可以对号入座。
1. 场景一：10人以下小团队，还在人治阶段
这个阶段不要上复杂制度，会压垮团队。我的建议是三个动作：
- 每周一次30分钟进度会，按关键路径任务逐个过，不做全套SV计算。
- 用一张共享表格记录"本周偏差最大的3个任务"及处理动作。
- 只设一档阈值：任何关键路径任务完成百分比连续两周不变，就升级。
这个阶段的目标是养成"识别-处理"的习惯，不是追求数据精确。
2. 场景二：10-50人团队，从人治向制度化过渡
这个阶段是最容易翻车的，因为团队觉得"我们没那么小，也没那么大"。我的建议是按第四部分的四件套先搭骨架，但先简化：责任人机制只分"计算+决策"两角色，汇报节奏只分关键/非关键两档，阈值只用黄/红两档，纠偏流程只保留"归因+拍板+验证"三步。
同时，这个阶段是引入项目管理平台的最佳时机。前面案例里的35人团队就是典型的这个规模。用工具的强制字段替代人工提醒，能显著降低制度化带来的管理成本。
说明: 这张图说明制度不是越复杂越好，而是要与团队规模匹配。10-50人团队是制度化收益跳升最明显的区间，也是引入项目管理平台的合适起点。
3. 场景三：50人以上团队，多项目并行
这个阶段制度必须上平台，否则靠人盯不住。核心变化有三点：
- SV/SPI按项目纵向对比，而不只是单项目内看，发现跨项目共性问题。
- 资源冲突检测纳入常规流程，因为100人以上组织最容易出的问题不是单项目偏差，而是共享资源被过度占用。
- 需要支持私有化部署和数据安全，尤其是涉及客户敏感数据的集成项目。
七、不同情况下的取舍
制度设计本质上是取舍。我在咨询里最常被问的是"到底要不要这么做"，下面我把四组典型取舍摊开讲。
1. 取舍一：精确度 vs 时效性
高精确度的SV计算需要准确的工作包完成百分比，但这往往需要成员花大量时间更新。我的判断是：在项目早期，时效性优先于精确度。宁可每周快速估个大概，也别为了精确数据拖到两周后才更新。等到项目进入关键路径密集期，再切换到高精确模式。
2. 取舍二：统一口径 vs 灵活适应
统一口径让数据可比，但可能不适应不同类型任务。我的建议是：项目内统一，项目间灵活。同一个项目里，所有工作包用同一套口径；不同项目（尤其是不同客户、不同交付类型）之间允许口径有差异，但要写清楚。
3. 取舍三：工具投入 vs 人力投入
小团队可能觉得工具投入不划算。我的经验是：50人以上必须上工具，否则制度根本无法维持。10-50人之间，工具和人力可以搭配，关键是工具承担"强制字段+自动触发"，人力承担"归因+决策"。10人以下，人力为主。
4. 取舍四：严阈值 vs 宽阈值
严阈值能早发现问题，但会造成大量假警报，消耗团队信任。宽阈值不折腾，但容易错过窗口。我的建议是：关键路径用严阈值，非关键路径用宽阈值。并且每季度复盘一次阈值是否合适，避免长期不动。
说明: 这张雷达图展示取舍不是一次性的，而是随项目阶段变化。可以看到关键路径密集期几乎所有维度都趋严，而启动期反而适合宽松。理解这一点，才能避免"一套制度用到底"的僵化。
八、让制度不流于形式的三个反常识
最后说三个我反复验证过的反常识判断。它们和主流建议不同，但在我实际经历的项目里更有效。
1. 偏差汇报不是越勤越好
高频汇报会激励数据美化。我在前面已经用数据说明了。真正有效的是"关键任务高频 + 非关键任务低频"的组合，而不是全员日报。
2. 阈值不是越严越好
阈值过严会让团队对预警麻木。你连续三个月每周收到5条黄色预警，到第四个月就会自动忽略。宁可少几条真预警，也不要多几条假预警。预警的信噪比，比预警的数量重要得多。
3. 模板不是越全越好
我见过最夸张的一份进度管理制度有28页，结果没人看，更没人执行。有效的制度应该能印在一张A3纸上，包含：谁、什么频率、什么阈值、什么动作。所有细节靠工具和会议去补，而不是靠文档堆砌。
九、三步启动法：从今天起，让你的进度偏差制度跑起来
如果你读到这里，想立刻行动，我建议按这三步先后做，不要同时做。
1. 第一步：先定阈值和时限
不管团队多大，先确定关键路径和非关键路径各自的黄/红阈值，以及每一档的决策时限。这两个东西定下来，制度才有时效性。建议用时：一次会议，1-2小时。
2. 第二步：再定汇报节奏和责任人
按任务类型分档，把计算、解读、决策三个角色分开（哪怕是分时点）。建议用时：一次会议+一份一页纸文档。
3. 第三步：最后上工具
阈值和节奏定完之后再上工具，工具的字段才不会乱。如果你打算用PingCode或同类平台，把阈值和节奏直接配置成字段和触发规则，制度就自动跑起来了。如果团队规模在100人以上、涉及客户敏感数据，记得把私有化部署能力纳入选型清单；如果是从Jira迁移过来，提前确认数据迁移方案，避免制度落地被数据搬家卡住。
最后想说的是：进度偏差管理的门槛不在知识，而在执行的一致性。你不需要一套完美的制度，你需要一套每周都能跑、每季度都能优化的制度。从今天起，先定阈值和时限，让下周五的进度会有一个不一样的开始。
常见问题解答（FAQ）
1. 进度偏差多久统计一次才合理，日报会不会太频繁？
我们团队十来个人，之前没有固定的汇报节奏，老板一催我就让成员每天填进度，结果怨声载道，填上来的数据还都是拍脑袋写的。我一直在纠结，到底多勤算合适，日报是不是过度管理了？
统计节奏要跟决策周期匹配，而不是跟焦虑程度匹配。判断口径是：如果一次偏差从发生到被纠正的周期是两周，那你每天统计就是浪费；如果关键路径任务只允许滞后一天，那日报就是必须的。可执行做法是按任务粒度分档：关键路径任务或两周内的短期冲刺用日报或隔日更新，普通任务用周报，里程碑节点用单独的里程碑评审。
判断依据是看这个数据会不会真的触发行动，如果统计出来连续三周没人根据它做任何决策，那这个频率就该降。另外日报只填三个字段就够了：当前完成百分比、与原计划的差值、是否需要支持，超过五个字段的日报基本都会注水。
2. 进度偏差预警阈值定多少合适，绿黄红怎么分档？
我们制度里写了偏差超过10%要预警，但实际执行时发现有的任务超了20%也没人管，有的超5%就吵起来，因为任务本身重要性差太多。我想知道阈值到底该怎么定，是不是应该按任务类型分开设？
阈值不应该全项目一刀切，正确做法是按任务的浮动时间分档，而不是按百分比。判断依据是：一个任务如果还有5天浮动时间，那它滞后3天根本没影响项目交付，不需要预警；反过来，关键路径上零浮动的任务滞后1天就要亮黄灯。
可执行做法是先在计划里标出每个任务的浮动时间，然后按剩余浮动的消耗比例分档：消耗低于三分之一是绿灯，三分之一到三分之二是黄灯，超过三分之二是红灯。黄灯的动作是责任人在下次例会上说明原因和补救方案，红灯的动作是48小时内必须给出纠偏计划并指定决策人。
这样定的好处是阈值自带业务含义，不会出现超了20%没人管的情况。
3. 偏差算出来落后了，除了加班赶工还能怎么办？
项目一滞后，我第一反应就是让大家加班，短期确实追回来了，但团队连续两个月加班之后离职了两个核心成员，后面进度反而更差。我想知道除了赶工还有哪些纠偏手段，什么情况下该用哪种？
纠偏手段至少有四类，加班赶工只是其中成本最高、副作用最大的一种。判断顺序应该是先看范围再看依赖最后才看资源。可执行的做法是：第一步确认这个任务的范围能不能砍或延后，很多滞后其实是范围蔓延导致的，砍掉非必要功能比加班有效得多；
第二步检查前置依赖是否有松动，能不能通过调整任务顺序让后续工作提前启动，也就是快速跟进，但要注意这会增加返工风险，只适合依赖关系较弱的任务；第三步才是加人或加班，而且加人要注意布鲁克斯定律，新人上手期可能让进度更慢，所以只适合可拆分、文档完善的模块。
判断依据是看纠偏成本，能用范围调整解决的不要用资源解决，因为范围调整不消耗团队士气。
4. 制度写好了但没人执行，怎么让进度汇报不流于形式？
我们花了两周写了一份进度管理制度，模板、阈值、流程都有，发下去之后头两周大家还填，第三周开始就变成复制上周内容，数据全是绿的但项目实际已经滞后了。我想知道问题出在哪，怎么让制度真的跑起来？
制度失效通常不是态度问题，是数据没有跟决策挂钩。判断依据很简单：如果一个人填的偏差数据从来不影响任何决策，他下周一定开始敷衍。可执行做法是建立反馈闭环，让汇报有后果：每周例会上只讨论红灯和黄灯项，绿灯项不占用时间，这样填真实数据的人反而能更快拿到支持；
同时规定连续两次漏报或瞒报偏差的责任人，在下次资源分配时优先级降低，这是把制度跟利益挂钩而不是跟惩罚挂钩。另一个关键是降低填写成本，模板字段不要超过五个，且默认值自动带入上周数据，成员只需要改变化的部分。
最后管理者要以身作则，自己负责的任务也要按同样节奏暴露偏差，如果领导的项目永远是绿的，下面的人就学会了永远填绿。制度跑不起来，多半是因为第一个暴露真实偏差的人没有得到正向反馈，反而被批评了。
核心关键词
文章包含AI辅助创作：进度偏差管理方法大全：项目经理进度管理制度设计落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/459149
读者评论
偏差发现延迟平均11.4天这个数据太真实了，我们团队基本也是这样，每次都是问题捂不住了才摆到台面上，那时候纠偏成本已经翻倍了。文章把发现延迟作为制度第一抓手，这个优先级排序很专业。
四类根因里外部依赖失控确实最容易被忽视，因为不在自己掌控范围内，大家本能地回避。但恰恰是这种回避让9天偏差白白浪费掉，如果2月中旬就把它和SV挂钩，完全有机会提前干预。
三档阈值加决策时限这张表最实用，我们以前只定阈值不定时限，黄色预警能挂一个月，最后拖成红色。把'多久内必须拍板'写进制度才是真正的闭环，光有公式没用。