第四章 进度失控：估时不准、依赖阻塞、进度不可见
进度失控，说白了就是项目一拖再拖。我见过太多项目，一开始信心满满，最后却陷入无休止的延期循环。为什么会这样？三个核心原因：估时不准、依赖阻塞、进度不可见。咱们一个一个拆解。
4.1 估时不准：为什么程序员总是低估工期？
我个人习惯，每次估时都会先问自己一个问题：「这个任务我做过类似的吗？」如果答案是「没有」，那估时基本就是猜的。猜的结果，十有八九是低估。
举个例子，一个看似简单的「用户登录功能」，新手可能估2天，老手可能估5天。为什么差这么多？因为老手知道，登录不只是「输入账号密码」——还有密码加密、生成、Session管理、异常处理、日志记录……这些细节，新手根本想不到。
4.1.1 估时陷阱清单
| 陷阱类型 | 典型表现 | 后果 |
|---|---|---|
| 乐观偏差 | 「这个很简单，两天搞定」 | 实际耗时5天 |
| 忽略非编码工作 | 只算写代码的时间 | 测试、文档、沟通被遗忘 |
| 忽略干扰 | 假设全天无中断 | 实际效率只有60% |
| 忽略学习成本 | 「这个框架我熟」 | 新版本API变了，得重新学 |
我在项目中遇到过最典型的案例：一个同事估时「3天」的模块，最后做了2周。为什么？因为他没算上「跟第三方API对接」的沟通成本。你想想看，光是等对方回复邮件，就耗了3天。
4.1.2 靠谱的估时方法
我建议用「三点估算法」：
- 乐观时间（O）： 一切顺利，无任何干扰
- 悲观时间（P）： 所有能出问题的地方都出问题
- 最可能时间（M）： 正常情况下的耗时
最终估时 = (O + 4M + P) / 6
举个例子：一个功能，乐观估2天，悲观估8天，最可能估4天。那最终估时 = (2 + 4×4 + 8) / 6 = 4.33天。嗯，这个数字比单纯的「4天」靠谱多了。
4.2 依赖阻塞：卡在别人手里怎么办？
依赖阻塞，说白了就是「等」。等接口、等审批、等测试环境、等另一个团队发版……我见过最夸张的项目，80%的时间都在等。
为什么会这样？因为很多团队把「依赖」当成了「理所当然」。你想想看，你依赖另一个团队提供API，但你有没有想过：他们也有自己的排期，你的需求在他们那可能只是「低优先级」。
4.2.1 依赖管理的三个层次
我曾经在一个项目中，前端团队等后端API等了整整两周。后来我们改了策略：先定义接口文档，前端用Mock数据开发。等后端真正上线时，前端已经跑通了所有流程。说白了，依赖阻塞的解法就是「别傻等」。
4.2.2 依赖阻塞的避坑指南
- 提前暴露依赖： 项目启动时就把所有依赖列成表格，标注「风险等级」
- 设置依赖负责人： 每个依赖指定一个人去跟踪，不要「大家一起等」
- 准备Plan B： 如果依赖方无法按时交付，有没有替代方案？
- 定期同步： 每周至少一次依赖方同步会，5分钟就行
4.3 进度不可见：黑盒开发的噩梦
进度不可见，是项目失控的加速器。你想想看，如果项目经理问「进度怎么样了」，你回答「快了快了」——这跟没说有什么区别？
我见过最糟糕的情况：一个团队闷头开发了两个月，到演示那天才发现方向完全错了。为什么？因为中间没有任何进度反馈。
4.3.1 让进度「可视化」的三个方法
我个人习惯用「看板墙+燃尽图」的组合。看板墙让每个人知道「今天该做什么」，燃尽图让管理者知道「整体进度是否健康」。嗯，这两个工具配合使用，效果翻倍。
4.3.2 进度汇报的「三句话」原则
我要求团队每次进度汇报只说三句话：
- 我完成了什么？（具体成果，不是「在做了」）
- 我接下来要做什么？（未来1-2天的计划）
- 有什么阻碍？（需要谁帮忙解决）
你想想看，如果每个人都能说清楚这三件事，项目进度还会不可见吗？
4.4 实战：进度失控的急救方案
如果你的项目已经失控了，怎么办？别慌，我有一套「急救三步法」：
4.4.1 第一步：冻结需求
进度失控时，最忌讳的就是「边做边加需求」。我见过一个项目，原计划3个月，结果中途加了5次需求，最后做了8个月。说白了，需求每加一次，进度就崩一次。
怎么做？ 立刻冻结所有新需求，只做「必须做」的功能。其他需求排到下一期。
4.4.2 第二步：重新估时
用前面说的「三点估算法」，把剩余任务重新估一遍。注意：这次要加上「缓冲时间」。我建议在总估时上再加20%的缓冲。
// 示例：剩余任务重新估时
任务A：O=2天, M=3天, P=5天 → 估时=(2+4*3+5)/6=3.17天
任务B：O=1天, M=2天, P=4天 → 估时=(1+4*2+4)/6=2.17天
任务C：O=3天, M=5天, P=8天 → 估时=(3+4*5+8)/6=5.17天
总估时 = 3.17 + 2.17 + 5.17 = 10.51天
加上20%缓冲 = 10.51 * 1.2 = 12.61天
4.4.3 第三步：每日同步
进度失控后，周会已经不够了。我建议改成每日同步，每次15分钟，只回答三个问题：
- 昨天完成了什么？
- 今天计划做什么？
- 有什么阻碍？
我曾经用这个方法救过一个延期2个月的项目。每天同步，每天调整，最后只延期了1周就交付了。你想想看，如果放任不管，可能延期更久。
4.5 总结：进度可控的三个关键
| 关键点 | 核心动作 | 常见误区 |
|---|---|---|
| 估时准 | 三点估算法 + 任务拆分 | 只估编码时间，忽略其他 |
| 依赖清 | 提前识别 + Mock并行 + 缓冲 | 等别人交付，不主动跟进 |
| 进度明 | 看板墙 + 燃尽图 + 三句话汇报 | 「快了快了」式模糊反馈 |
说白了，进度失控不是技术问题，是管理问题。估时不准就学方法，依赖阻塞就主动破，进度不可见就建工具。这三件事做好了，项目延期至少减少一半。
嗯，这一章就到这里。下一章咱们聊聊「需求蔓延」——那个让所有项目经理头疼的问题。