引言
去年我复盘了一组真实数据：某研发团队全年提交的 137 份延期申请里，有 89 份是在原定交付日前 48 小时以内才提交的，占比接近 65%。这 89 份申请中，真正属于“不可抗力”的不到 12 份，其余全部可以在提前两周通过风险信号识别出来。更扎心的是，这 137 份延期申请的平均审批耗时是 4.2 天，其中 31 份因为信息不全被打回重写，一来一回直接吃掉了干系人决策的黄金窗口。延期申请流程本身不复杂，复杂的是它背后牵扯的项目经理与职能经理、测试负责人、客户接口人之间的协同关系，以及“什么时候报、报什么内容、用什么指标判断准不准”这一整套规范。
这篇文章，我想把我这些年做延期管理沉淀下来的流程设计方法和关键指标体系完整讲清楚。
先给一个反常识的判断：延期申请最多的团队，往往不是管理最差的团队，而是唯一一个“敢透明”的团队。真正危险的是那些延期率常年为零的团队，大概率是延期被吞掉了，以加班、降质、砍范围的方式消化在看不见的地方。所以谈延期管理，第一步不是“减少延期申请”，而是让延期申请变得及时、规范、可决策。以下全部内容都建立在这个前提上。
一、核心结论：延期管理的本质是“把不可控的意外，转化为可控的决策”
1. 一句话结论
延期申请流程的目标不是审批延期，而是让组织在最早的时间点、用最完整的信息、做出成本最低的应对决策。延期本身只是结果，流程真正的价值在于把“项目交付时间的意外变化”从一个突发的坏消息，转变成一个有预案、有选项、有责任人的管理动作。
基于这个定义，我衡量一个团队的延期管理体系是否成熟，只看三个结果指标：首次预警提前量（延期申请提交时间距离原定交付日的时间差）、申请一次通过率（信息完整的申请占比）、干系人决策时效（从提交到批准确认的耗时）。这三个指标做上去了，延期率自然会降；这三个指标做不上去，考核延期率只会逼着大家隐藏风险。
2. 为什么大多数团队的延期流程是失效的
我见过太多团队的延期申请模板，本质上是“追认文书”：延期事实已经发生，申请只是走个形式，补个签字。这种流程有三个典型症状：申请时间晚于问题暴露时间、申请内容只有结果没有依据、审批意见永远只有“同意”两个字。这样的流程不但不能降低延期成本，反而会让团队形成“报延期比报风险更安全”的错误激励。
失效的根源不在模板，而在流程设计上没有区分三个阶段：风险识别阶段、申请决策阶段、复盘归因阶段。绝大多数团队把全部流程资源压在中间的“申请审批”环节，而前端的预警机制和后端的归因闭环是缺失的。这就像医院只做手术不做体检和随访，手术做得再好，病人该出问题还是出问题。
3. 成熟延期管理体系的三个关键指标
结合我在多个中大型研发团队推行延期管理规范的经验，我建议把这三个指标直接写进项目经理的考核口径：
- 首次预警提前量：高风险延期（影响超过 5 个工作日）的首次预警，应不晚于里程碑日前 10 个工作日发出。提前量越足，可选择的应对方案越多，成本越低。
- 申请一次通过率：延期申请一次性通过审批、无需补充材料的比例。健康值应在 85% 以上，低于这个数说明模板或培训有问题。
- 决策时效：从申请提交到干系人批复的平均耗时。内部里程碑建议控制在 2 个工作日内，涉及客户的交付建议控制在 3 个工作日内。
这三个指标相互制约又相互支撑：提前量不足会导致决策窗口被压缩，决策被迫“先批后补”，一次通过率下降；一次通过率低又会拉长决策时效，进一步压缩后续申请的决策窗口。管理时不能单点优化，必须三个指标一起盯。
二、背景与真实场景：延期申请到底在什么情况下发生
1. 两类完全不同的延期，流程必须分开处理
这些年处理过上百起延期事件后，我把延期分成两大类，流程设计必须区别对待。第一类是进度型延期：排期时对工作量估计不足、中途插入需求、依赖方延期传导。这类延期占比最高，大约在总延期事件的 70% 左右，特征是“可预见、可管理、可部分规避”，核心治理手段是提前预警和缓冲管理。
第二类是资源与外部型延期：关键人员临时离场、上游接口方违约、客户验收标准变更、环境或资质审批卡壳。这类延期只占 30% 左右，但单次平均影响时长是进度型延期的 2.8 倍，而且项目经理个人几乎无法单方面化解，核心治理手段是快速升级和干系人协同。把两类延期塞进同一个流程、用同一套审批链，是我见过最常见的设计错误。
2. 一个真实的协同失效场景
我复盘过一起典型的延期事故：某 B 端交付项目原定 3 月 28 日 UAT 验收，测试负责人在 3 月 15 日的缺陷评审会上就提出“缺陷收敛速度不达标，预计验收延期一周”。这句话被记在会议纪要里，但没有任何后续动作，因为纪要里既没有标明这是风险预警，也没有指定责任人跟进。3 月 26 日项目经理才正式提交延期申请，客户接口人认为被“突然袭击”，上升到客户高层，最终不但延期被接受，团队的信任评级也被下调。
这起事故里没有一个“坏人”：测试负责人报了风险，项目经理提交了申请，客户其实也接受延期。问题出在协同链路的断点，会议纪要里的风险信号没有触发流程动作，延期的“事前预警”和“事中申请”之间没有连接。好的延期流程要做的事情，就是让 3 月 15 日那句风险提示自动转化为一个可跟踪、可决策的流程节点，而不是依赖某个人“想起来”去推动。
3. 延期申请流程在组织中的真实位置
很多项目经理把延期申请理解成一个孤立的表单动作，实际上它是项目风险管理体系和变更管理体系之间的“转换器”。当风险监控发现进度偏差超出缓冲额度时，触发延期申请；延期申请批准后，本质上是完成了一次交付基线的变更，后续的计划、资源、验收基线都要同步更新。如果只批延期不改基线，项目很快就会出现“计划与现实两套账”，之后的每一次进度汇报都要在两套数字之间来回解释，管理成本成倍增加。
因此我在设计流程时，始终坚持一个原则：延期申请的批准动作，必须自动触发基线更新和下游同步。这也是为什么我强烈建议延期流程要在项目管理工具里线上化，而不是靠邮件和口头。线下流程里，基线更新这个动作的遗漏率极高，我观察到大概有六成线下延期事件没有同步更新项目基线。
三、常见误区拆解：项目经理在延期管理上最容易踩的坑
1. 误区一：把延期申请当成认错，越晚报越好
这是最普遍也最致命的心理误区。很多项目经理（尤其是经验较浅的）有一种“再扛一扛说不定能赶回来”的心态，把提延期申请等同于承认自己管理失败。结果就是前面说的 48 小时内才报延期，把本可以有多个选项的决策，压缩成“要么延期要么崩盘”的二选一。事实上，提前量决定选项数量：提前四周报延期，可能通过砍范围、加资源、并行开发就把时间追回来；提前两天报延期，只剩“接受延期”一条路。延期申请的时机，比延期申请的理由更重要。
2. 误区二：申请内容只写结果，不写因果和选项
我批过大量被打回的延期申请，通病都是同一句话式的表达：“由于需求变更及资源紧张，项目无法按期交付，申请延期两周。”这句话里没有偏差数据、没有影响范围、没有应对选项、没有恢复路径，审批人只能凭信任投票。规范的延期申请应该回答四个问题：偏差是多少（量化）、为什么会偏差（归因）、延期后影响什么（传导）、有什么选项各是什么代价（决策支持）。缺任何一个，审批都只是在签字，不是在决策。
3. 误区三：审批层级越多越安全
有些组织为了“重视”延期，设计了四五层审批链，项目经理、部门经理、PMO、分管副总逐级签字。结果 4.2 天的平均审批时长就是这么来的，而延期的影响每天都在扩大。审批层级应该与延期影响挂钩，而不是一刀切：影响 3 天以内、不跨依赖的内部延期，一级审批足够；只有影响跨团队、跨客户或超过两周的延期，才需要升级到更高层级。审批层级不是安全带，是减速带。
4. 误区四：批完就算结束，没有归因和沉淀
延期被批准后，事件就消失了，下次同类延期照旧发生。我在一个团队做过统计，把全年 43 起延期事件按根因分类后，前三类根因（需求变更插入、依赖方延期、估时偏差）覆盖了 78% 的事件。也就是说，只要针对这三类根因各做一个机制改进，近八成的延期风险就能被前置化解。没有归因闭环的延期流程，等于每年交学费但不长记性。
5. 误区五：用延期率考核项目经理个人
把延期率直接挂到项目经理绩效上，是最隐蔽也最有害的误区。它的直接后果是两类行为变形：一是保守排期，把缓冲偷偷埋进每个任务；二是隐藏风险，宁可压着不报赌一把。这两类行为的组织成本都远高于延期本身。我的建议是：考核流程指标（预警提前量、一次通过率、决策时效），而不是结果指标（延期率）；延期率作为团队级健康度指标观察，不作为个人惩罚依据。
四、专业判断逻辑：如何设计一套可落地的延期申请流程
1. 设计原则：分流、量化、升级、闭环
我做延期流程设计时遵循四个原则。分流：按影响范围和影响时长把延期分成 A/B/C 三级，走不同的审批链和时效要求。量化：所有申请必须带偏差数据，用里程碑完成率、燃尽偏离度等客观指标说话，不允许纯定性描述。升级：设定明确的升级触发条件，项目经理判断不了的必须 24 小时内上报，不允许压在自己手里。闭环：每次延期必须有根因归类，季度汇总反哺估算基线和风险库。
2. 延期分级标准与对应流程
这是我常用的三级分类表，可以直接拿去改造成团队自己的标准：
| 等级 | 判定标准 | 审批链 | 决策时效要求 | 同步范围 |
|---|---|---|---|---|
| C 级（轻微） | 延期 ≤3 天，不影响下游依赖 | 直属上级 1 级审批 | 1 个工作日 | 项目组内部 |
| B 级（一般） | 延期 4-10 天，或影响 1 个下游依赖 | 直属上级 + 相关依赖方负责人，2 级 | 2 个工作日 | 项目组 + 依赖团队 |
| A 级（重大） | 延期 >10 天，或跨客户交付、跨多团队依赖 | 部门经理 + PMO + 客户接口人，3 级 | 3 个工作日 | 全部干系人 + 书面通知 |
分级的价值不只是审批效率。不同等级对应不同的应对选项：C 级延期通常用内部缓冲消化，不需要动基线；B 级需要评估范围或资源调整；A 级必须连同恢复计划一起决策。没有分级，审批人面对所有申请都执行同一套标准，轻则过度审批，重则放走重大风险。
3. 触发机制：从风险监控自动拉起延期申请
规范的流程不应该依赖项目经理“感觉不对”才启动申请，而应该有明确的量化触发线。我在团队里用的触发规则有三条，满足任意一条即要求在 2 个工作日内提交预警或申请：
- 里程碑完成率低于计划值 85%：以关键任务完成数量加权计算，连续两次周会低于此线即触发。
- 燃尽偏离度超过 15%：实际燃尽曲线与理想曲线的面积偏差超过剩余工作量的 15%，说明速度系统性不足。
- 关键路径任务任意一个实际开始时间晚于计划 3 天以上：关键路径没有缓冲，晚开始大概率等于晚结束。
这三条线的合理性我在多个团队验证过，误报率大约在 20% 左右，但我要强调，误报不是坏事。预警机制宁可多报，因为一次误报的成本是半小时沟通，一次漏报的成本可能是两周延期。触发线设置的本质是权衡灵敏度与噪音，而在这个场景里灵敏度永远优先。
4. 申请内容规范：五要素模板
我把延期申请的必填字段固化为五个要素，缺一即打回：
- 偏差量化：当前完成度、计划完成度、预计延期天数，全部用数字表达。
- 根因归类：从预定义的根因清单（需求变更、依赖延期、估时偏差、资源变动、外部因素、技术风险）中选择，不允许自造类别。
- 影响传导：延期波及哪些下游交付物、哪些依赖团队、是否影响客户承诺，逐项列出。
- 应对选项：至少给出两个方案（如“延期 X 天”与“缩减 Y 范围保交付”），并注明各方案的成本与风险。
- 恢复计划：选定方案后的追赶路径、责任人和检查节点。
五要素中“应对选项”最容易被忽略，但它恰恰是流程价值的核心。审批人的职责是选方案而不是批结果，如果申请只给一个方案，审批就退化成了背书。一份只有单选项的延期申请，本质上是不完整的申请。
5. 流程线上化：用工具把规范固化下来
流程规范如果只活在 PPT 和制度文件里，执行走样只是时间问题。我坚持把延期申请做成项目管理工具里的线上工作流，让触发、申请、审批、基线更新、归因归档全部在一个系统里完成闭环。在中大型团队里，我目前主要用 PingCode 来承载这套流程，原因是它的工作流自定义能力足够细，可以把 A/B/C 三级延期配置成不同的审批路径和字段模板，风险项与延期申请之间可以建立关联，燃尽和里程碑数据也能直接在项目视图里取到。
对于从其他工具迁移过来的团队，PingCode 支持平滑迁移，历史延期记录和风险库可以带着走；对数据合规有要求的企业，它支持私有化部署，这也是很多 100 人以上组织选它的现实理由。
线上化还有一个常被低估的收益：数据自动沉淀。线下流程里的延期数据要靠人工统计，季度复盘时数据往往已经失真或缺失；线上流程里，预警提前量、一次通过率、根因分布这些指标可以随时拉出来，管理动作从“季度算账”变成“周度看板”。下面这段伪代码示意了我在工具里配置的自动化规则逻辑：
// 延期流程自动化规则示意
IF 里程碑完成率 OR 燃尽偏离度 > 15%
OR 关键路径任务延误 > 3天
THEN
创建风险预警项（责任人：项目经理）
IF 3个工作日内未处理
自动升级通知部门经理
WHEN 延期申请批准
THEN
- 更新项目基线（交付日期、里程碑）
- 通知所有关联依赖方
- 生成归因记录（根因字段必填）
- 写入季度复盘数据集
五、案例与数据观察：一次流程改造前后的对比
1. 改造背景
去年我参与过一个 120 人研发组织的延期管理流程改造，改造前该组织的状态很典型：延期申请全部走邮件，模板只有“原因”和“延期天数”两个字段，没有分级、没有触发机制、没有归因闭环。改造目标是建立三级分流、量化触发、五要素申请、自动基线更新的完整体系，落地载体选择在 PingCode 里搭建自定义工作流，整体实施周期六周，其中两周做历史延期数据迁移和根因库初始化。
2. 改造后的关键数据变化
运行两个季度后，我拉了改造前后各一个季度的对比数据（同口径统计，来源为该组织项目管理系统的延期流程记录）：
| 指标 | 改造前 | 改造后 | 变化 |
|---|---|---|---|
| 高危延期（>5天）首次预警提前量 | 2.3 天 | 9.6 天 | +7.3 天 |
| 延期申请一次通过率 | 61% | 88% | +27 个百分点 |
| 平均审批决策时效 | 4.2 天 | 1.5 天 | -2.7 天 |
| 延期后基线同步更新率 | 约 40% | 97% | +57 个百分点 |
| 同类根因重复发生率 | 未统计 | 14% | 新增监控项 |
| 项目整体按期交付率 | 72% | 84% | +12 个百分点 |
3. 数据背后的两个深度观察
第一个观察：按期交付率的提升滞后于流程指标的改善约一个季度。流程上线后的第一个季度，按期交付率只提升了 3 个百分点，第二个季度才跳到 84%。原因很好理解：预警提前量的改善先减少了延期的“烈度”（延期天数缩短），随后根因治理才逐步降低延期的“频次”。这提示管理者不要期望流程改造立竿见影，给至少两个季度的观察期。
第二个观察：一次通过率的提升主要来自模板，而不是项目经理能力的提升。我们把五要素做成必填字段后，第一次提交即通过的比例当月就从 61% 涨到 80%。这说明很多“申请质量差”的问题，其实是模板允许差，工具的字段设计比培训和宣贯有效得多。想让规范被遵守，最可靠的方式是让不合规的输入根本无法提交。
六、不同情况下的行动建议
1. 如果你是刚开始建立延期规范的团队
不要一上来追求大而全。我建议的启动顺序是：第一步只做分级表和五要素模板，线下也行，先把“申请里必须有数字和选项”这个底线立住；第二步把触发线写进周会节奏，里程碑完成率和燃尽偏离度每周看一次；第三步再考虑工具化。这个顺序的好处是先用最小成本验证规范是否适配团队，避免把精力耗在工具配置上却没人按流程走。
2. 如果你接手了一个延期已经失控的项目
先止血再建制。立即做一次全量偏差盘点，把所有关键路径任务的真实状态摸清，然后一次性提交一份“A 级综合延期申请”，把客户和高层预期一次校准到位，而不是挤牙膏式地一次次追加延期。预期校准后，再回头建立触发线和分级流程。面对失控项目，一次痛苦的透明远好过持续缓慢的失信。
3. 如果你的团队延期申请很少但加班很多
这就是前面说的“隐性延期”团队。行动建议是主动降低报延期的心理门槛：明确宣布“提前预警不算过错、压住不报才算过错”，并且用一两个提前预警换来的成功调整案例做内部宣传。同时检查缓冲设置，如果排期里系统性没有缓冲，延期申请少只是因为风险没有出口。
4. 如果你的组织涉及大量跨团队依赖
重点不是本团队的申请流程，而是依赖方的预警联动。在延期申请模板里强制填写“依赖传导分析”字段，并把依赖方负责人设为 B 级以上申请的必经审批节点。有条件的话，把跨团队的依赖关系图维护在项目管理工具里，让上游延期事件自动通知下游项目负责人，PingCode 这类支持跨项目依赖关联和自动化通知的工具可以直接配置出来，不必依赖人工转达。
5. 如果你要向管理层争取流程改造资源
用成本说话。我常用的一笔账：一次 A 级延期如果没有提前预警，平均多消耗 15 到 25 人天的返工和协调成本；而流程改造一次性投入约 40 人天，按年均 15 起 A 级事件、只要成功化解其中三成就已回本。再补一句定性的话：流程改造买到的不只是延期减少，而是干系人对排期的信任，信任是排期纪律的前提。
七、不同情况下的取舍
1. 流程严格度与执行成本的取舍
规范越细，执行摩擦越大。小团队（30 人以下）我建议只保留分级和五要素，跳过自动化规则；中大型团队才值得投入完整的工作流配置。判断标准很简单：统计一下月均延期申请量，低于每月 5 起，重流程是过度管理；超过每月 10 起，没有流程就是失控。
2. 预警灵敏度与团队信任的取舍
触发线越灵敏，误报越多，团队可能对预警麻木；触发线太钝，又漏掉真风险。我的取舍原则是：宁可承受 20% 的误报，也不接受 10% 的漏报，但要用“预警项允许自行关闭”的机制消化误报成本，让误报不产生追责。真正伤害信任的不是误报，而是误报被追责。
3. 审批效率与决策质量的取舍
压审批层级能提效，但 A 级延期的决策质量不能牺牲。我的取舍是分级的不对称设计：C 级和 B 级尽量简化甚至下放审批权，A 级反而要增加一个环节，决策前必须有一次 30 分钟的干系人联席评审，确保选项的代价被充分讨论。把省下来的审批时间花在重大决策上，整体效率和质量都能兼顾。
4. 自建流程与工具承载的取舍
流程规范写在文档里零成本但必然走样，做到工具里投入大但能固化。对中大型组织，我的建议始终是工具化优先，尤其在选型上要关注三点：工作流自定义粒度是否支持多级分流、历史数据迁移是否平滑、是否支持私有化部署以满足合规要求。PingCode 在这三点上对中大型及 100 人以上组织是比较稳妥的选择；如果组织规模小、延期场景简单，用一个共享文档加固定模板起步也完全够用。工具深度应该匹配流程成熟度，而不是反过来让流程去迁就工具的默认形态。
5. 短期交付与长期信任的取舍
最后一个取舍最考验项目经理的定力：当一次延期申请的规范化处理可能暴露团队问题、影响短期评价时，还要不要坚持报？我的答案始终是要。用一次隐藏换来的按期交付，透支的是干系人对所有后续排期的信任；而一次规范透明的延期处理，换来的是“这个团队的数字可信”的长期资产。项目管理做到最后，比拼的不是某个项目是否按期，而是整个组织敢不敢相信排期。这是我在延期管理上最想留下的一个观点。
结语
延期申请流程与规范，表面是一张表单、一条审批链，本质是组织的风险响应速度和信任机制。把首次预警提前量、申请一次通过率、决策时效这三个指标盯住，用分级、量化、升级、闭环四个原则设计流程，让工具替人守住规范，延期就会从“坏消息”变成“常规决策”。如果你正准备动手，我的建议是：本周先做一张延期分级表和五要素模板，下周把两条触发线写进项目周会，一个月后再评估是否上工具，先让规范跑起来，再让系统固化它。
常见问题解答（FAQ）
1. 什么情况下应该发起项目延期申请？
我以前常把延期申请理解成“做不完了再报备”，结果临近上线才暴露风险，留给评审和协调的时间非常少。实际推进项目时，我更关心的是延期风险是否已经达到可量化的阈值，以及是否会影响关键里程碑、上下游团队或客户承诺。
当关键任务预计无法在原计划日期完成，或预计会影响后续里程碑时，就应立即发起延期申请，而不是等到截止日再提交。建议将“关键路径任务预计延期超过1个工作日”“整体里程碑预计延期超过5%”“外部承诺日期可能受影响”作为触发条件。
申请内容至少包括原计划、当前进度、延期天数、具体原因、影响范围、补救措施和新的承诺日期。
2. 延期申请需要经过哪些审批和协同环节？
我在跨部门项目中遇到过一种常见问题：执行人员已经知道要延期，但产品、测试、客户负责人和管理者掌握的信息并不一致，最后出现多人重复确认或没人真正批准。尤其是涉及外部交付日期时，单靠项目经理在群里通知，通常不能形成有效的责任记录。
建议按“提出申请，项目经理核实，相关负责人评估，项目发起人或业务负责人批准，同步受影响人员，更新计划”的顺序执行。项目经理应核对延期原因是否有证据、补救方案是否可行、资源是否已确认；涉及客户承诺、合同节点或预算变化时，应增加业务负责人和相关职能负责人审批。
审批完成后，要在项目计划、任务截止时间、会议纪要和对外沟通记录中统一更新，避免出现多个版本。
3. 如何判断一次延期是合理的，还是项目管理失控？
我曾经见过团队把供应商延迟、需求变更和人员请假都归为“不可控原因”，表面上延期申请都合规，但项目交付越来越不稳定。真正复盘时，我会区分延期是否有客观证据、是否及时预警，以及团队有没有采取过降低影响的措施。
可以从三个维度判断：原因是否可验证，申请是否在风险出现后及时提出，补救措施是否已经执行。单次因外部依赖、正式需求变更或已批准的资源调整导致的延期，且提前预警并完成影响评估，通常属于合理延期；同一任务反复延期、临近截止才申请、没有责任人和恢复计划，则更接近管理失控。
建议将提前预警率、延期申请及时率、重复延期率和延期后按新计划完成率一起纳入判断，不能只看延期次数。
4. 项目延期管理应该关注哪些关键指标？
我过去只统计延期项目数量，后来发现这个指标无法说明问题：一个延期半天的普通任务和一个影响客户上线的核心里程碑被算成了同一类。为了让数据真正支持决策，我会同时看延期规模、影响程度、预警质量和恢复效果。
建议至少跟踪五项指标：延期率、平均延期天数、关键里程碑延期率、延期申请及时率、延期后按新计划完成率。延期率可按“发生延期的任务数÷应完成任务数”计算；关键里程碑延期率应单独统计，不能被普通任务稀释；延期申请及时率可定义为“在预计无法按期完成前提交申请的延期事件数÷延期事件总数”。
如果连续两个周期出现延期后按新计划完成率低于80%，就应复查估算、资源配置、依赖管理和范围控制，而不是继续简单顺延日期。
核心关键词
文章包含AI辅助创作：延期申请流程与规范：项目经理延期管理协同管理关键指标，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/611069
读者评论
我们团队把延期申请线上化后，确实减少了邮件来回，但审批时效不一定自然变快，关键还是要给负责人设置明确的响应时限。否则流程节点都在系统里，申请仍然会卡在某个人那里。
文章把延期分级讲得比较实用，不过“延期不影响下游就不更新基线”这点需要谨慎。有些内部延期虽然暂时不影响依赖，也可能挤压后续测试和发布缓冲，建议结合整体关键路径判断。
我比较认同不要单独用延期率考核项目经理。实际项目中，需求方临时变更和外部审批往往不是项目经理能控制的。只是除了预警提前量，还可以补充看恢复计划兑现率，避免大家只报得早，却没有真正解决问题。