进度管理基础：活动定义、依赖与估算

核心概念

进度管理(Schedule Management) 把 WBS 的工作包，翻译成一串有顺序、有工期的活动，再汇成可承诺的进度表。四步：

1. 活动定义(Activity Definition)：把工作包拆成具体活动(「写登录接口」而非「做登录模块」)。产出活动清单。
2. 活动排序(Sequence)：确定依赖关系。四种逻辑依赖：
   • 完成-开始(FS)：A 完成才开始的 B(最常见)。
   • 开始-开始(SS)：A 开始 B 才能开始(并行启动)。
   • 完成-完成(FF)：A 完成 B 才能完成。
   • 开始-完成(SF)：极少用。 依赖分强制(硬)依赖(物理必然，如浇混凝土后才能砌墙)与选择性(软)依赖(约定俗成，可松绑以赶工)。
3. 活动资源估算：每项活动要什么资源(人/机/料)。
4. 活动工期估算(Duration Estimate)：单活动从开始到结束的日历时间。

三种估算技术：

• 类比估算：参考相似历史项目。快、粗，依赖可比性。
• 参数估算：用单位量化(如「每人天 200 行代码 × 规模」)。需可靠参数模型。
• 三点估算(PERT)：给最乐观 O、最可能 M、最悲观 P，期望 TE = (O + 4M + P) / 6。显式处理不确定性。

进度表不是「填日期」，而是对依赖与工期的建模。模型准，承诺才可信；模型漏了关键依赖，承诺就是空中楼阁。

实务直觉

第一原则：依赖决定关键路径，估算决定工期长度——两者都错，进度必崩。 排序漏一条隐藏依赖(「得等安全评审」)，执行时就会卡死。

• 软依赖是赶工的第一突破口。 强制依赖动不了；但「我们先做 A 再 B」常是习惯而非必然。把 SS/FF 软依赖改成并行，能压缩总工期而不加人。
• 工期是日历时间，不是人时。 「这项工作 5 人时」≠「1 天做完」——还要看资源是否全职、能否并行、有无等待。混淆两者是排期乐观的常见来源。
• 三点估算专治过度自信。 只报一个「最可能」值，人会本能取乐观端。用 O/M/P 把悲观情景显性化，总进度才扛得住现实。

跨学科应用

图论：活动网络 = 有向无环图(DAG)

活动是节点(或箭线)，依赖是有向边。进度计算本质是在 DAG 上求最长路径(关键路径，见 0004)。环(A 等 B、B 等 A)意味着死锁，必须消解。

概率：PERT 是 beta 分布近似

三点估算用 (O+4M+P)/6 逼近 beta 分布的均值，方差 (P−O)/6² 衡量不确定性。活动越多，中心极限定理让总工期趋近正态——可算「按时完工概率」。

排队论：资源冲突让估算失真

多人抢同一专家(如唯一架构师)，活动实际等待时间远超「纯工期」。资源约束下的排期(资源平衡)比纯时间排期复杂得多。

行为：规划谬误(Planning Fallacy)

人系统性低估自己任务的耗时( Kahneman)。对策不是「更仔细想」，而是用参考类预测——看同类历史项目的实际耗时，而非凭直觉。这正是类比估算的认知学依据。

练习题

单选题

单选题

判断题

案例题

两个活动 A、B 原定 FS 依赖(A 完 B 始)，各 10 天。你发现 B 其实只需 A 开始就可并行启动(改 SS)，且 B 前 4 天不依赖 A 产出。改动后能省多少天？

参考答案：原总工期 20 天(A 10 + B 10)。改 SS 后 A、B 并行，B 在 A 启动后第 0 天就开始；若 B 完全不依赖 A 产出，则 B 在 A 进行的 10 天内跑完 10 天，总工期压缩到 10 天——省约 10 天。这正是「松绑软依赖改并行」的威力。前提是确认 B 真不依赖 A 的中间产出(强制依赖不能动)。