INFO6007 Week 03 范围管理与进度管理讲课总结
INFO6007 Week 03 讲课总结：范围管理与进度管理
课程：INFO6007 — Project Management in IT，Semester 2 2026 讲义：
Lecture - INFO6007 Week 03 - Time Management.pdf（72 页） 参考：Schwalbe, K. (2018). IT Project Management, pp. 241–284；Roseke, B. (2016). Schedule Planning.本讲一次讲了两个知识领域：Project Scope Management（6 个过程） 和 Project Schedule Management（6 个过程）。 终点落在 关键路径法（CPM） —— 这是本周计算题的核心。
一、开场：Week 2 Muddy Card 答疑
Agile vs Scrum（很多人混淆）
| 是什么 | |
|---|---|
| Agile | 一种广义的方法论，适用于需求可能变化、工作可以逐步交付的项目 |
| Scrum | 一个具体的框架，通过短的、时间盒定的 sprint 来实践敏捷 |
一句话区分：Agile 是整体心态（mindset），Scrum 提供把它落地的结构化方式。
讲义的大学 App 例子：团队用 Agile（而非瀑布）逐步发布功能并根据学生反馈调整；用 Scrum 则是从 backlog 选功能、在两周 sprint 内开发测试、然后评审结果。
Alpha 与 Beta 测试
| 定义 | |
|---|---|
| Alpha 测试 | 在开发者的受控环境中测试，通常由开发团队之外的人执行 |
| Beta 测试 | 由选定的外部用户在真实环境中测试，在更大范围发布之前 |
三种交付模式下的应用：
| 模式 | 做法 |
|---|---|
| Waterfall | 接近尾声时的一个正式周期：System Testing → Alpha → Beta → Release |
| Agile | 对每个可发布增量重复；反馈进入 backlog 供后续 sprint 处理。团队可能改称 UAT、试点测试、用户测试或早期访问 |
| DevOps | 集成进发布流水线；CI/CD、功能开关、监控与回滚。流水线本身没有「Alpha/Beta」阶段，常用术语是 staging、内部预览、金丝雀发布、功能开关灰度、受限生产发布 |
关键理解：Alpha/Beta 的目的不变，变的是时机、频率和反馈速度。
📢 课堂公告
- 本周和 Week 4 组建小组：4–5 人，在自己的 tutorial 时段内组
- Suggested weekly progress 已上传（例：Week 4–6 完成 Project Charter、Stakeholder Management Plan）
- EFT Quiz 于 Week 4 初发布：Week 4 周日（8 月 30 日）截止；30 分钟 / 10 道选择题 / 开卷 / 3 次机会；有练习版可做
第一部分：Project Scope Management
二、范围管理计划
Scope Management Plan 定义项目范围将如何被定义、验证和控制。 它确保「所有该做的工作、且仅有这些工作」被纳入并成功完成。
八个关键组成部分
| 组成 | 描述 |
|---|---|
| Scope Statement | 项目将交付什么（以及不交付什么）的高层叙述 |
| Scope Management Approach | 定义和管理范围的方法论（敏捷、瀑布） |
| Requirement Collection | 如何收集和记录干系人需求 |
| Work Breakdown Structure | 项目交付物的层级分解 |
| Scope Validation Process | 交付物如何被干系人评审和批准 |
| Scope Control Process | 范围变更如何被识别、评估和管理 |
| Roles and Responsibilities | 谁负责定义、验证和控制范围 |
| Assumptions and Constraints | 定义范围时考虑的条件或限制 |
注意 Scope Statement 那句「以及不交付什么」 —— 明确写出 exclusions 是防范围蔓延最有效的一招，后面的 Week 4 tutorial 会再次强调。
三、范围管理六大过程
| # | 过程 | 核心目标 | 主要输出 |
|---|---|---|---|
| 1 | Plan Scope Management | 制定范围管理计划 | 范围管理计划 |
| 2 | Collect Requirements | 确定、记录和管理干系人需求 | 需求文档 + 需求追溯矩阵（RTM） |
| 3 | Define Scope | 制定详细的项目范围说明书 | 项目范围说明书 |
| 4 | Create WBS | 把范围和交付物分解成更小的可管理组件 | WBS + WBS 字典 |
| 5 | Validate Scope | 获得客户/发起人对已完成交付物的正式验收 | 已验收交付物、变更请求 |
| 6 | Control Scope | 监控范围状态并管理对范围基线的变更 | 变更请求、更新的文档 |
1. 规划范围管理
输入：项目章程、项目管理计划、事业环境因素、组织过程资产。
为什么重要：它为所有后续范围决策奠定基础。没有它，范围工作会变得混乱且不一致。
2. 收集需求
| 技术 | 描述 |
|---|---|
| Interviews（访谈） | 一对一对话挖掘需求 |
| Workshops（研讨会） | 互动式会议建立共识 |
| Surveys/Questionnaires（问卷） | 高效触达大规模干系人群体 |
| Prototyping（原型） | 用早期版本细化需求 |
| Observation（观察） | 研究用户的实际操作 |
输出：需求文档 + Requirement Traceability Matrix（需求追溯矩阵，RTM）。
RTM 的价值：把每条需求一路追踪到设计、开发、测试和验收。这是后面「控制范围」时判断「这个功能到底是不是原来答应的」的依据。
3. 定义范围
输出：项目范围说明书，包含 产品范围描述、交付物、exclusions（排除项）、成功标准。
「这份文档成为关于「什么包含、什么不包含」的正式协议，从而减少歧义。」
NSW 数字驾照的范围说明书示例：
| IN SCOPE | OUT OF SCOPE |
|---|---|
| Service NSW App 中的可选数字驾照 | 实体卡：不替代、不淘汰 |
| 账号与 TfNSW 驾照数据的集成 | 政策：不重新设计发牌规则或资格 |
| 让警察和查验人员能确认驾照状态 | 其他证件：不在本项目基线内 |
| 试点、测试并准备全州发布 | — |
看这个 OUT OF SCOPE 列写得多具体 —— 这就是范围说明书该有的样子。
4. 创建 WBS
WBS 是项目中所涉工作的面向交付物（deliverable-oriented）的分组，定义了项目的总范围。 创建 WBS 用的技术叫「分解（decomposition）」 —— 把高层交付物拆成子交付物，再拆成工作包（work packages）。
WBS 是项目规划的骨干：澄清交付物、辅助资源规划、为成本与进度跟踪打基础。
五种开发 WBS 的方法
| 方法 | 做法 |
|---|---|
| Using guidelines（用指南） | 有些组织（如美国国防部 DOD）提供 WBS 编制指南 |
| Analogy（类比） | 参考类似项目的 WBS 并针对本项目裁剪 |
| Top-Down（自上而下） | 从项目最大的条目开始往下拆 |
| Bottom-Up（自下而上） | 从具体任务开始往上汇总 |
| Mind-mapping（思维导图） | 从核心想法向外辐射分支来组织思路 |
两种 WBS 表现形式
- WBS Tree Diagram（树形图）
- WBS Dictionary（WBS 字典） —— 每个 WBS 条目的详细说明文档
创建 WBS 的六条规则（考点密集）
| # | 规则 |
|---|---|
| 1 | 一个工作单元只能出现在 WBS 的一个位置 |
| 2 | 一个 WBS 条目的工作内容 = 其下所有子条目之和（100% 法则） |
| 3 | 一个 WBS 条目只由一个人负责，即使有很多人参与其中的工作 |
| 4 | WBS 必须与工作实际执行的方式一致 |
| 5 | 项目团队成员应参与 WBS 的制定，以确保一致性和认同感（buy-in） |
| 6 | 每个 WBS 条目都必须记录在 WBS 字典中 |
NSW 数字驾照的「工作包测试标准」很值得记： 「每个最底层条目都有一个负责人、一个估算、一个可测试的产出，以及验收证据。」 能通过这四条，才算拆到位了。
另外注意讲义那句：WBS 按「交付物」组织，而不是按「参与的机构」组织。
5. 验证范围
目标：获得客户或发起人对已完成交付物的正式验收。
主要活动：呈交交付物供干系人检查 → 获取批准 → 管理反馈并记录验收。
为什么重要：没有正式验证，后期会产生纠纷。这也是能在范围蔓延升级之前抓住它的环节。
输出：已验收交付物、变更请求（若交付物未被接受）、工作绩效信息。
6. 控制范围
目标：监控项目与产品范围的状态，管理对范围基线的变更。
三种主要技术：偏差分析（实际 vs 计划范围）、绩效评审、整合变更控制流程。
💡 NSW 的实际变更例子很有代表性： 请求：在全州推广前纳入「学习准驾证（learner permits）」。 2018 年的范围明确排除了 learner permits ⇒ 必须评估法律、数据、UX、测试和进度影响后，才能批准、推迟或拒绝。 「每一项获批变更都仍然与需求、测试和正式验收保持关联。」
四、范围管理的四类问题与对策
| 问题 | 描述 | 影响 |
|---|---|---|
| Scope Creep（范围蔓延） | 不受控的变更或范围持续增长，却不调整时间、成本和资源 | 延期、预算超支、团队倦怠 |
| Lack of Stakeholder Engagement | 干系人未被恰当地纳入范围定义或验证 | 期望落空、不满意、后期范围变更 |
| Miscommunication | 团队、客户或管理层对「什么在范围内」理解不一致 | 混乱、冲突、交付物不一致 |
| Overambitious Scope | 想在一个项目周期内做太多 | 增加复杂度、风险和失败概率 |
五条缓解措施
- 清晰的范围说明书，含包含项、排除项、假设
- 用 RTM 把需求与交付物关联起来
- 在范围定义和变更的每个阶段获得干系人签字
- 实施正式变更控制流程
- 定期开展范围评审
这五条和 Week 4 Tutorial Part A 要求的「两条防控策略」完全一致 —— 变更控制（事后闸门）+ 范围说明书（事前围栏）。
第二部分：Project Schedule Management
五、进度管理计划
Project Schedule Management 是规划、制定、管理、执行和控制项目进度，使其在约定时间内完成的过程。
通俗说：决定要做什么、按什么顺序做、要花多长时间，并确保它一直在正轨上，直到项目完成。
六个关键组成部分
| 组成 | 内容 |
|---|---|
| Schedule Development Approach | 方法论（CPM、敏捷、滚动式规划）；工具（MS Project、Primavera、Jira） |
| Activity Definition and Sequencing | 如何识别活动（WBS、交付物分解）；定义依赖与约束的规则 |
| Estimating Durations | 技术（Analogous、Parametric、Three-point/PERT）；估算假设与准确度范围 |
| Schedule Baseline | 基线如何以及何时设定；基线审批流程 |
| Schedule Control and Monitoring | 绩效指标（SPI、SV、里程碑跟踪）；更新频率；触发纠正措施的偏差阈值 |
| Reporting Format | 呈现方式（甘特图、里程碑图、仪表盘）；干系人更新频率 |
注意 SPI 和 SV 在这里就出现了 —— 它们是 Week 4 EVM 的内容，进度管理和成本管理共用同一套 EVM 指标。
六、进度管理六大过程
| # | 过程 | 核心 |
|---|---|---|
| 1 | Planning Schedule Management | 定义进度将如何被制定、监控和控制 |
| 2 | Defining Activities | 把 WBS 的工作包拆解成具体的可管理任务 |
| 3 | Sequencing Activities | 确定任务的逻辑顺序并定义依赖关系 |
| 4 | Estimating Activity Durations | 预测每个活动要花多久，考虑资源可用性 |
| 5 | Developing Schedule | 应用 CPM；分配资源解决冲突；设定进度基线 |
| 6 | Controlling Schedule | 监控进展、识别偏差、采取纠正措施 |
过程 2 是 WBS 与进度的接合点：WBS 拆到工作包，活动定义再把工作包拆成带动词的具体任务。
NSW 的「活动清单测试标准」：每个活动都有一个动作动词、一个负责人、一个前置活动和明确的完成标准。
七、四类依赖关系（考点）
| 类型 | 定义 | 别名 |
|---|---|---|
| Mandatory（强制性） | 工作本身固有、无法改变的依赖 | hard logic（硬逻辑） |
| Discretionary（选择性） | 基于最佳实践、偏好或便利性设定的依赖 | soft logic（软逻辑） |
| External（外部） | 依赖项目团队控制范围之外的活动 | — |
| Internal（内部） | 项目团队可控范围内活动之间的依赖 | — |
两组对照要分清： - Mandatory vs Discretionary 问的是「能不能改」—— 硬逻辑改不了（必须先编码才能测试），软逻辑可以改（先做前端还是先做后端是团队偏好） - External vs Internal 问的是「谁能控制」—— 外部依赖（等供应商开权限）是常见的进度风险源
NSW 的例子：强制性 —— 先构建才能集成、先集成才能端到端测试；外部 —— 警察和查验人员就绪后才能做实地试点。
八、三种网络图
| 图 | 全称 | 特征 |
|---|---|---|
| AON | Activity on Node | 活动 = 节点（方框），箭头 = 依赖关系。当今最广泛使用，易懂易画，主流 PM 软件都支持 |
| AOA | Activity on Arrow | 活动 = 箭头，节点 = 事件/里程碑。因项目复杂度上升现已较少使用。唯一通常需要「虚活动」（dummy activity，0 工期的箭头）来正确表达依赖的图 |
| PDM | Precedence Diagramming Method | AON 的一种，显式定义四种依赖类型，允许 lead 和 lag |
PDM 的四种依赖类型
| 类型 | 含义 |
|---|---|
| Finish to Start (FS) | A 完成后 B 才开始 —— 最常见 |
| Start to Start (SS) | A 开始时 B 开始 |
| Finish to Finish (FF) | A 完成时 B 完成 |
| Start to Finish (SF) | A 开始时 B 完成 —— 罕见 |
Lead 与 Lag
| 定义 | 目的 | 效果 | |
|---|---|---|---|
| Lead Time（提前量） | 后续活动可以在前置活动完成之前提前开始的时间量 | 加速进度 | 加快进度 |
| Lag Time（滞后量） | 前置活动完成后，必须等待多久后续活动才能开始 | 考虑延迟或等待期 | 拖慢进度 |
记忆法：Lead = 抢跑（提前开始），Lag = 等待（强制延后）。 典型 lag 例子：混凝土浇筑后必须养护 7 天；软件里则是数据迁移后必须等 24 小时的批处理完成。
九、讲义两道网络图例题（讲义未给答案）
⚠️ 讲义 p44 和 p46 只给了活动表，没有给出关键路径的答案。以下是我用前推/后推法算出并验证的完整解答。
例题一：AON（讲义 p44）
| 活动 | 工期 | 前置 |
|---|---|---|
| A | 5 | — |
| B | 4 | A |
| C | 5 | B |
| D | 6 | B |
| E | 7 | D |
| F | 3 | C, D |
| G | 6 | D |
| H | 7 | F, G |
| I | 8 | E, G |
| J | 3 | H, I |
前推 / 后推结果
| 活动 | 工期 | ES | EF | LS | LF | 浮动 | 关键 |
|---|---|---|---|---|---|---|---|
| A | 5 | 0 | 5 | 0 | 5 | 0 | ✓ |
| B | 4 | 5 | 9 | 5 | 9 | 0 | ✓ |
| C | 5 | 9 | 14 | 15 | 20 | 6 | |
| D | 6 | 9 | 15 | 9 | 15 | 0 | ✓ |
| E | 7 | 15 | 22 | 15 | 22 | 0 | ✓ |
| F | 3 | 15 | 18 | 20 | 23 | 5 | |
| G | 6 | 15 | 21 | 16 | 22 | 1 | |
| H | 7 | 21 | 28 | 23 | 30 | 2 | |
| I | 8 | 22 | 30 | 22 | 30 | 0 | ✓ |
| J | 3 | 30 | 33 | 30 | 33 | 0 | ✓ |
所有路径
| 路径 | 时长 |
|---|---|
| A–B–D–E–I–J | 33 |
| A–B–D–G–I–J | 32 |
| A–B–D–G–H–J | 31 |
| A–B–D–F–H–J | 28 |
| A–B–C–F–H–J | 27 |
关键路径 = A–B–D–E–I–J，总工期 = 33。
值得注意的地方：次关键路径 A–B–D–G–I–J = 32，只差 1 天（这也正是 G 的浮动时间 = 1）。 这意味着如果 G 延误超过 1 天，关键路径就会转移 —— 这正是「浮动时间小的活动也要盯紧」的原因。
例题二：AOA（讲义 p46）
| 活动 | 工期 | 前置 |
|---|---|---|
| A | 1 | — |
| B | 2 | — |
| C | 3 | — |
| D | 4 | A |
| E | 5 | B |
| F | 4 | B |
| G | 6 | C |
| H | 6 | D, E |
| I | 2 | G |
| J | 3 | H, I |
前推 / 后推结果
| 活动 | 工期 | ES | EF | LS | LF | 浮动 | 关键 |
|---|---|---|---|---|---|---|---|
| A | 1 | 0 | 1 | 2 | 3 | 2 | |
| B | 2 | 0 | 2 | 0 | 2 | 0 | ✓ |
| C | 3 | 0 | 3 | 2 | 5 | 2 | |
| D | 4 | 1 | 5 | 3 | 7 | 2 | |
| E | 5 | 2 | 7 | 2 | 7 | 0 | ✓ |
| F | 4 | 2 | 6 | 12 | 16 | 10 | |
| G | 6 | 3 | 9 | 5 | 11 | 2 | |
| H | 6 | 7 | 13 | 7 | 13 | 0 | ✓ |
| I | 2 | 9 | 11 | 11 | 13 | 2 | |
| J | 3 | 13 | 16 | 13 | 16 | 0 | ✓ |
所有路径
| 路径 | 时长 |
|---|---|
| B–E–H–J | 16 |
| A–D–H–J | 14 |
| C–G–I–J | 14 |
| B–F | 6 |
关键路径 = B–E–H–J，总工期 = 16。
这题有个容易漏的细节：活动 F 没有任何后继活动 —— 它是一条悬空的分支，做完就结束了。 所以 F 的浮动时间高达 10 天（在 16 天工期内，它只需在第 12 天前开工即可）。 💡 在 AOA 图里，这类结构往往需要一条「虚活动」把 F 的末端连回终点节点 —— 这正是讲义说 AOA 「唯一通常需要 dummy activity」的场景。
前推后推法速记
浮动 = 0 的活动就是关键活动；把它们串起来就是关键路径。
十、估算活动工期
三点估算 / PERT
| 估计 | 含义 |
|---|---|
| Optimistic (O) | 一切顺利时完成任务的最短时间 |
| Most Likely (M) | 正常条件下所需时间的最佳猜测 |
| Pessimistic (P) | 出问题时任务可能花费的最长时间 |
这个公式在 Week 4 成本管理里原样复用，只是把「工期」换成「成本」。必背。
其他两种估算技术
| 技术 | 特点 |
|---|---|
| Analogous（类比） | 自上而下，基于类似项目的历史数据。比详细估算更快更省，但需要专家判断确保可比性；适合项目早期信息有限时；时间和成本都能用 |
| Parametric（参数） | 定量技术，用变量之间可测量的关系计算。历史数据 + 数学模型；确定单位费率 × 所需单位数；在变量关系稳定且可扩展时效果最好 |
💡 NSW 项目按活动特性选估算方法的例子很有参考价值：
活动 方法 工期范围 依据 App 与 API 构建 Bottom-up 10–14 周 工作包估算 集成与安全测试 Three-point 6–10 周 接口 + 缺陷不确定性 Dubbo 试点 Analogous + 专家 4 周 可比的推广工作 扩大试验与发布准备 Rolling-wave 8–12 周 用试点经验细化 要点：不确定性越高的活动，越要用三点估算或滚动式规划。
十一、制定进度：甘特图与关键路径法
甘特图
条形图，把项目活动对着时间轴展示，每个任务用一条水平条表示，长度代表工期。
用途：可视化时间线、对照基线跟踪进展、识别重叠 / lead / lag、向干系人清晰沟通进度。
关键路径法（CPM）
CPM 用于识别项目中最长的一串相互依赖的活动 —— 这条路径决定了项目可能的最短工期。
关键路径上的任何延误都会延误整个项目。
三大优点： - 帮助确定任务优先级 - 识别哪里存在灵活性（即浮动时间） - 对进度压缩（Fast Tracking、Crashing）很有用
注意「最长路径 = 最短工期」这个看似矛盾的表述： 因为所有路径必须都走完项目才结束，所以最长的那条决定了下限 —— 你不可能比最长的那条更快。
十二、控制进度与两种压缩技术
关键活动：比较实际 vs 计划绩效；使用 EVM 指标 SPI 和 SV；必要时应用进度压缩技术。
两种进度压缩技术（高频考点）
| 技术 | 做法 | 代价 |
|---|---|---|
| Fast Tracking（快速跟进） | 把原本串行的活动改为并行执行 | 增加风险，但缩短进度 |
| Crashing（赶工） | 向关键路径上的活动增加资源以更快完成 | 增加成本，也可能增加风险 |
必须能秒答两者区别： - Fast Tracking = 改顺序（并行化）⇒ 主要代价是风险（返工） - Crashing = 加资源（加人加钱）⇒ 主要代价是成本
两者都只对「关键路径上的活动」有意义 —— 压缩非关键活动不会缩短总工期，只是浪费。
💡 NSW 的进度监控四指标：里程碑（计划 vs 实际）、关键路径的偏差与浮动、预期完成日期的预测、已批准的基线变更。
十三、课堂讨论题：选课系统替换
场景：某大学必须在 14 周内、选课开放前替换在线选课系统。项目涉及配置新系统、迁移学生记录、与支付系统集成、测试、培训员工。
约束： - 支付系统集成必须等外部供应商在 4 周后提供访问权限 - 现有学生数据的状况不明 - 数据迁移和系统集成需要同两位技术专家 - 上线日期不可推迟
分析框架
| 约束 | 类型 | 应对 |
|---|---|---|
| 供应商 4 周后才给权限 | 外部依赖（External dependency） | 前 4 周安排不依赖它的工作（配置、数据清理、培训材料准备）；与供应商确认承诺日期并设置预警 |
| 数据状况不明 | 不确定性 | 用三点估算给数据迁移一个范围而非单点值；尽早做数据剖析（data profiling）把未知变成已知 |
| 两位专家同时被两项工作需要 | 资源冲突（不是逻辑依赖！） | 资源平衡（resource leveling）；⚠️ 这会把原本可并行的活动强制串行化，可能延长关键路径 |
| 上线日不可推迟 | 硬约束 | 时间固定 ⇒ 只能调范围或资源：分阶段上线（先上核心选课，支付集成后补）；或加资源（crashing） |
这道题最容易被忽略的一点是第三条： 「两位专家同时被需要」是资源约束，不是活动之间的逻辑依赖。 在网络图上它们本可以并行，但资源不够会迫使它们串行 —— 这就是为什么「制定进度」这个过程要求「分配资源并解决冲突」，而不只是画网络图。 纯 CPM 算出来的工期是「资源无限」下的理想值。
十四、课后案例：HR 管理系统
场景：管理一个 12 个月的项目开发 HR 管理系统。范围含需求收集、设计、开发、测试、培训、部署。 客户坚持部署必须在 12 月完成以配合新财年。
关键约束： - 同时只有两名高级开发可用 - 设计团队还在做另一个项目，4 周后才有空 - 支付软件集成的供应商审批最多需要 3 周
五道题的分析要点
① 三个可能的范围风险与应对
| 风险 | 应对 |
|---|---|
| 范围蔓延 —— HR 系统模块多，客户容易追加需求 | 正式变更控制流程 + 范围说明书明确写出 exclusions |
| 需求不完整 —— 干系人参与不足导致后期返工 | 用 RTM 追溯每条需求；分阶段获得签字 |
| 范围过于雄心勃勃 —— 12 个月做完六个阶段且资源受限 | 按优先级分阶段交付；用 MoSCoW 区分必须与可选 |
② WBS 如何帮助控制范围蔓延
- WBS 定义了项目的「总范围」 —— 任何不在 WBS 上的工作，按定义就在范围之外，这给了 PM 拒绝的依据
- 100% 法则（条目 = 其下子条目之和）让新增工作无处隐藏，必须显式加进 WBS 并触发变更评估
- 每个工作包只有一个负责人 ⇒ 新需求出现时责任归属清晰
- WBS 是成本和进度估算的基础 ⇒ 加工作包就必须重新估算，代价立刻可见
③ 如何在每个阶段确保范围验证
在每个阶段末设置正式的验收关口（对照 NSW 的做法）：
| 阶段 | 验收物 |
|---|---|
| 需求 | 需求文档 + RTM 签字 |
| 设计 | 设计评审通过 |
| 开发 | 增量演示 |
| 测试 | 测试结果 + 缺陷清单 |
| 培训/部署 | UAT 通过 + 正式验收记录 |
每次验收产生三种结果之一：接受 / 拒绝并提变更请求 / 记录缺陷。
④ 哪些是强制性依赖、哪些是外部依赖
| 依赖 | 类型 |
|---|---|
| 需求 → 设计 → 开发 → 测试 → 部署 | 强制性（hard logic） —— 工作本身固有 |
| 必须先开发完才能测试 | 强制性 |
| 等设计团队 4 周后才有空 | ⚠️ 严格说是资源约束，但因为团队不在本项目控制下，实践中当作外部依赖处理 |
| 等供应商审批（3 周） | 外部依赖 —— 典型例子 |
| 只有两名高级开发 | 资源约束（不是依赖） |
⑤ 若供应商审批变成 5 周而非 3 周，对关键路径的影响
分三种情况讨论，这才是完整答案：
| 情况 | 影响 |
|---|---|
| 若供应商审批已在关键路径上 | 多出的 2 周直接 1:1 传导，项目延期 2 周 |
| 若它不在关键路径上，且浮动时间 ≥ 2 周 | 总工期不变，只是把该活动的浮动吃掉 2 周 |
| 若它不在关键路径上，但浮动时间 < 2 周 | 关键路径会转移到这条路径上，项目延期 =（2 周 − 原浮动时间） |
好答案必须先问「它在不在关键路径上」，而不是直接说延期 2 周。 💡 应对手段：Fast tracking（把集成测试的准备工作与等待审批并行）；提前启动供应商审批流程（把它变成非关键路径）；在计划中就为外部依赖预留 lag 缓冲。
十五、考点重点
- Agile 是心态，Scrum 是把它落地的框架；Alpha（开发者环境）vs Beta（用户真实环境）。
- 范围管理六大过程：规划 → 收集需求 → 定义范围 → 创建 WBS → 验证范围 → 控制范围。
- 收集需求的五种技术；输出含 RTM（需求追溯矩阵）。
- 范围说明书必含 exclusions；创建 WBS 的技术叫「分解」，WBS 是面向交付物的。
- WBS 六条规则，尤其 100% 法则（条目 = 子条目之和）和 一个条目只有一个负责人。
- 五种开发 WBS 的方法：指南、类比、自上而下、自下而上、思维导图。
- 验证范围 = 获得正式验收，是抓住范围蔓延的关键环节。
- 范围管理四类问题，范围蔓延的定义要能默写：不受控增长且不调整时间/成本/资源。
- 进度管理六大过程：规划 → 定义活动 → 排序活动 → 估算工期 → 制定进度 → 控制进度。
- 四类依赖：强制性（hard logic）/ 选择性（soft logic）/ 外部 / 内部；两组对照分别问「能不能改」和「谁能控制」。
- 三种网络图：AON（最常用）/ AOA（唯一需要 dummy activity）/ PDM（显式四种依赖 + lead/lag）。
- PDM 四种依赖：FS（最常见）、SS、FF、SF（罕见）。
- Lead = 提前开始（加速），Lag = 强制等待（减速）。
- 三点估算
—— Week 4 成本管理原样复用。 - 前推后推求关键路径：
；浮动 = 0 即关键活动。 - CPM = 最长路径 = 最短可能工期；关键路径上任何延误都延误整个项目。
- Fast Tracking（改并行，增加风险）vs Crashing（加资源，增加成本）；两者只对关键路径活动有意义。
- 纯 CPM 假设资源无限 —— 资源冲突会把并行活动强制串行，可能延长实际工期。
十六、本讲与前后的衔接
| Week | 内容 | 关键词 |
|---|---|---|
| 2 | PM 方法论 | 瀑布 vs 敏捷、Scrum、Kanban |
| 3 | 范围管理 + 进度管理 | WBS、依赖、CPM、进度压缩 |
| 4 | 成本管理 | EVM、成本基线、储备 |
| 5 | 质量管理 | QA/QC、CoQ |
本讲是后面两周的地基： 1. WBS → 成本估算：Week 4 的「自下而上估算」要求在工作包层级分配成本，而工作包正是本讲 WBS 的产物 2. 三点估算公式在 Week 4 原样复用，只是把工期换成成本 3. SPI 和 SV 在本讲的「进度控制」中已经出现，Week 4 才给出完整的 EVM 体系 4. 范围蔓延的五条缓解措施在 Week 4 Tutorial Part A 被再次考到
⚠️⚠️ 关于 tutorial 的错位（三周已确认的固定规律）：
Tutorial 实际做的内容 Week 3 tutorial Week 2 内容（方法论、干系人分析）—— 见 Week 03 Tutorial 解析 Week 4 tutorial Week 3 内容（范围蔓延、WBS、关键路径） Week 5 tutorial Week 4 内容（EVM 计算） 所以本讲（范围 + 进度）的练习题在 Week 4 Tutorial 里。