企业管理的108个问题 · 第88问

上一问我们聊了从0到1和从1到100的管理差异（第87问），核心结论：两种阶段需要完全不同的管理方式——从0到1靠”能打的通才和快速试错”，从1到100靠”系统和纪律”。

但不管你在哪个阶段——有一个”千古难题”永远不会缺席：

项目延期。

做软件的，延期。做工程的，延期。做营销活动的，延期。写报告的，也延期。

如果有一件事，是全行业通用的”默认规则”——那就是：项目一定会延期。

不是夸张——根据项目管理协会（PMI）的报告：超过60%的项目无法按时交付。

今天我们不讲那些”宏大但没用”的理论——就来掰扯一下：项目到底为什么总是延期？以及——到底怎么治？

一、项目延期的五大”元凶”

用”一句话”来概括每一个元凶——你大概率亲身经历过。

元凶一：计划本身就是”错的”——“乐观估计偏差”

经典场景：

“这个功能要多久？”

“嗯……3周吧。”

——实际上做了8周。

为什么？

因为做计划的人——不管是项目经理还是执行者——都会”无意识地乐观”。

乐观估计偏差具体表现为：

• 只算了”正常工作所需的时间”——没算”被打断的时间”
• 只算了”coding”的时间——没算”debug、测试、改bug”的时间
• 只算了”自己做”的时间——没算”等别人回复”的时间
• 只算了”最顺利的情况”——没算”任何意外”

这不是”人不行”——这是”计划的方法有问题”。

标准操作： 大多数人做计划的时候，大脑默认选择了”曲线中的最优点”——而不是”正常点”。

元凶二：需求变化——“改一下，就一下”

经典场景：

项目做到一半——“老板，市场部说想加一个功能””客户说原来的界面不好看，能不能换个方案？”

项目经理：…………

需求变更，是项目延期的第一号”杀手”。

一项研究发现： 在一个典型的软件开发项目中——需求变更导致的时间增加，占到总开发时间的30-50%。

但问题是——需求变化本身不是错——市场确实在变、客户确实在想——问题在于”管理变化”的方式错了。

元凶三：资源冲突——“A项目/B项目”夹击

经典场景：

团队A的成员——同时被”拉去帮”团队B——因为”B项目比较急”。

然后——A延期了——B也没如期完成——两头不讨好。

“资源被冲撞”是组织规模变大后最普遍的延期原因。

一个团队同时”背着”2-3个项目——每个项目经理都认为”我的项目是最优先的”——但谁都没有”真正的优先级”——结果：所有项目都延期。

元凶四：隐性工作量——“除了做项目，还有一堆事”

经典场景：

你以为团队每天8小时都在做项目——但实际上：

• 2小时：各种会议（晨会、周会、跨部门对齐会、评审会）
• 1小时：回复邮件、消息、审批
• 1.5小时：处理线上问题、临时需求、内部沟通
• 1小时：学习和培训

“实际做项目”的时间——只有2.5小时。

这是最被低估的延期原因。 项目经理在做计划的时候——假设的是”100%的人效”——但实际人效，通常在50-60%。

元凶五：反馈延迟——“卡在等别人回复”

经典场景：

• 开发做完了——等设计师签字——等了3天
• 设计方案出来了——等老板确认——等了1周
• 测试报了一个bug——等开发修复——等了半天——但开发被其他事拖住了——又等了2天

项目里最”隐形”的时间黑洞——就是”等待”。

项目管理协会的数据：在一个典型项目中，30-40%的时间花在”等待”上——而不是”工作”上。

二、找出”元凶”之后：五招”治延”策略

策略一：用”保守算法”做计划——而不是”理想算法”

操作方法：

做任何时间预估的时候——不要只用”一个数字”——用”三个数字”：

实操公式：

计划工期 = (正常时间 × 1.5) + (乐观时间 - 正常时间) × 0.5

这是一个”保守但不夸张”的估算——如果你觉得”计划这么保守，老板会骂我”——那你就把”最坏情况”写在备注里。

更好的方法是： 把”缓冲时间”明着写入计划——“预留20%的缓冲时间——用于应对需求变化和意外情况”。

策略二：建立”需求变更防火墙”——别让”小改”变成”大拖”

需求变更不是不能改——是不能”随随便便改”。

建立”变更管理流程”：

第一步：分类——“这个变更大不大？”

第二步：记录——所有变更，必须有书面记录

不要”口头改”——“你说改就改”——改完了没人记得——以后再改回来——浪费时间。

第三步：评估——“这个变更带来的价值，值不值我们延期的代价？”

不是”不能改”——是”改之前先算清楚账”。

策略三：明确优先级——“只能做一件事”

如果资源是冲突的——项目经理需要一个”明确的优先级排序”。

操作：

1. 每个项目/每个任务，只有一个”最高优先级”

2. 所有项目按”P0/P1/P2”分级：

   • P0（最高级）： 必须按期完成——资源优先保障——其他项目一律让路
   • P1（重要）： 正常推进——如果资源被抢——可以适当延期
   • P2（不紧急）： 按剩余资源做——做不完就做不完——下个周期再做

3. 关键： 一个团队的”P0项目”最多同时只能有1个——超过1个，就没有”优先级”了。

策略四：计算”真实可用时间”——不是8小时，是4-5小时

做项目计划时，不要按”全员每天8小时”算。

实操方法：

第一步：统计”隐性占用”

• 每个人每周花在”会议+沟通+审批+杂事”上的时间是多少？
• 如果一个人说”我大概40%的时间在做杂事”——那他的”真实可用时间”就是每天的4.8小时

第二步：用”真实可用时间”做计划

• 假设团队5个人——每人每天工作8小时——“
• 实际可用：5人 × 4.8小时/天 = 24小时/天（不是40小时/天）

一个经验公式：

计划人天 = 估算工作量（理想人天） / 0.6

——0.6是一个经验系数——表示”60%的有效人效”——如果你的组织”杂事更多”——用0.5（50%）——甚至0.4。

策略五：设置”反馈Deadline”——“不给反馈 = 默认同意”

等待反馈——是项目里最隐形的浪费。怎么治？

设”反馈Deadline”：

具体做法：

• 每次”等着别人给反馈”——都设置一个明确的截止时间
• 例如：周一发出设计稿——给反馈截止到周三下午5点——超时未回复——“默认同意，继续推进”

关键： 这个”默认规则”要提前和所有人”约法三章”——不是”偷袭”——是”明确规则”。

A级反馈（影响项目进度的关键决策）： 24小时内必须回复
B级反馈（常规确认）： 48小时内必须回复
C级反馈（知悉即可）： 一周内——逾期默认

三、三个”治延”的高阶原则

原则一：80%法则——“做80%比做100%好”

很多项目延期——是因为追求”完美”——“这个要调一下”、”那个要再优化一下”。

但”完美的1.0”是不存在的——做得”够了”比做得”完美”重要。

追求”做完80%”的价值：

• 80%的功能已经可以给客户/用户使用了
• 剩下的20%可以在”运行中”迭代优化
• 如果等到100%才上线——市场机会已经错过了

关键操作： 在项目启动时明确——“1.0版本的上线标准是什么？”——定义好”MVP版本”的范围——不追求”完美”——追求”能用”。

原则二：范围换时间——“砍功能”比”延期”好

当项目发现”要延期”了——最差的解决方案是：”大家加个班，把它赶出来。”

更好的选择是： “砍——这次不做什么”。

操作：

当项目进度出现问题——第一个问的应该是：“这次必须做的是什么？可以删掉的是什么？”

把”可做可不做的”功能砍掉——或者推到下个版本——而不是”压缩开发和测试的时间”。

原则三：定期”健康检查”——别等到”来不及了”才发现

做”项目健康检查”——就像人的”体检”——不是”等到疼了再去看”。

检查频率：

• 小项目（1-3个月）：每两周检查一次
• 大项目（3个月以上）：每个月检查一次

检查内容（三问）：

1. 进度偏差： 实际的进度和计划比——现在落后了多少？如果超过10%——警报；超过20%——启动”延期应对预案”
2. 需求变更： 自上次检查以来——有没有新增需求变更？如果变更累计超过20%——需要重新评估整个项目计划
3. 团队状态： 团队的心态、状态如何？如果出现持续加班超过2周——迟早出问题——需要”踩刹车”

四、项目延期的”应对方案选择表”

当项目确定要延期了——你有以下选择。不是”延期就完了”——是”怎么延期”。

五、最后的话

项目延期——不是”不够努力”——是”计划方式出了问题”。

大多数延期，不是因为团队”不够拼”——是因为”一开始就没算对”。

而”没算对”的原因也很简单：“人总是倾向于低估复杂性、高估自己的效率。”

这不是你一个人的问题——这是”人性的问题”。

所以，治延的第一步——不是”更努力”——是”更诚实”。

诚实面对：

• “这个项目到底需要多久”——不是”我希望多久”
• “我的人到底有多少时间在做项目”——不是”他们签的8小时”
• “这个需求变更是真的紧急”——还是”改一下也不算坏事”

项目管理的本质——不是”让项目不延期”——是”让延期的后果，可预期、可管理”。

把”一定会延期”当成一个预设前提——提前留好缓冲、做好预案——才是真正”治延”的心态。🎯

明日预告：第89问 —— 如何建立有效的内部沟通机制，减少信息失真？