INFO6007 Week 02 Tutorial 解析：三重约束权衡挑战

课程：INFO6007 — Project Management in IT，Semester 2 2026 来源：Tutorial Sheet - INFO6007 Week 02.pdf + Tutorial Answers - Week 2.pdf

这是本课程的第一次 tutorial（Week 1 没有 tutorial）。 它练的是 Week 01 讲义的三重约束 —— 答案文档开头原文写着： "Drawing from Week 1 lecture, students will reinforce their understanding of triple constraints scope, time, and quality by applying it to a given scenario."

这句话顺带证实了课程的固定节奏

Tutorial	实际练的内容
Week 2（本文）	Week 1（三重约束）
Week 3	Week 2（方法论、干系人分析）
Week 4	Week 3（范围蔓延、WBS、关键路径）
Week 5	Week 4（EVM 计算）

tutorial 恒比 lecture 慢一周 —— 从第一次 tutorial 就是如此，并由课程文档本身写明。 复习策略：想练某周 lecture 的内容，去看下一周的 tutorial。

---

一、Tutorial 目标与结构

目标：让大家互相认识，并通过基于场景的实践学习来应用三重约束。依托 Week 1 讲义，学生将通过把 scope、time、quality 应用到给定场景来巩固理解。

部分	内容	性质
A	欢迎与自我介绍	破冰
B	三重约束权衡挑战	核心活动
C	小组项目	事务

学习成果：LO1 理解各项目管理知识领域；LO4 初步掌握项目管理工具与实践。

💡 注意目标里写的是 "scope, time, and quality" 而不是 "scope, time, and cost"。 讲义 p34 的三重约束是「范围 / 时间 / 成本」，但这份 tutorial 刻意把 quality 拉了进来 —— 这个措辞上的差异正是整个活动想让你体会的：质量是那个被挤压时最先让步的东西。

---

二、Part A：欢迎与自我介绍

tutor 会引导大家互相介绍，可以聊：

• 姓名与专业背景
• 你能为项目团队贡献的一项技能或经验
• 你希望在 INFO6007 中培养的一项技能
• 一个非学术兴趣

💡 中间两项其实是在为后面的组队做铺垫 —— 记下谁擅长什么，Week 3–4 组队时用得上。

---

三、Part B：三重约束权衡挑战

以 3–4 人小组进行（⚠️ 不一定是你的项目组）。

场景基线

大学正在开发 UniConnect —— 一款面向学生的手机应用，项目外包给本地软件公司。

约束	基线
Scope（范围）	四项功能：个人课表、作业提醒、校园地图、紧急通知
Time（时间）	12 周，须在下学期开始前就绪
Cost（成本）	最高预算 $180,000
Quality（质量期望）	应用必须是安全的、无障碍的、可靠的（secure, accessible, reliable）

注意「外包给本地软件公司」这个设定 —— 它让后面的分析多了一层：约束变化不只是内部调整，还涉及与供应商重新谈判。

五个要回答的问题

1. 识别哪个约束发生了变化
2. 解释对另外两个约束的可能影响
3. 建议项目应如何应对
4. 指出一个对质量或项目风险的可能影响
5. 准备一个 60 秒的汇报（可用文档、在线协作文档或 PPT）

---

四、Change A：范围增加

场景：发起人要求增加「实时聊天」和「教室预订」功能。截止日期和预算保持不变。

① 变化的约束

范围增加 —— 新增 live chat 和 room booking 两项功能。

② 对时间和成本的影响

额外功能需要更多的分析、设计、开发、集成和测试。

如果完整接受新范围，项目通常需要更多时间、更多预算，或两者都要。

⚠️答案原文的关键句： 「保持 12 周期限和 $180,000 预算不变，会造成删减其他工作或仓促交付的压力。」

注意这句话在说什么：当三条边有两条被锁死、第三条却在增长时，压力必然要找出口 —— 要么砍掉别的工作（隐性缩范围），要么赶工（牺牲质量）。

③ 建议应对

把原有四项功能保留在 12 周的版本内，把 live chat 和 room booking 移到后续版本。

如果发起人坚持两项功能都要在首发时上线，则必须在承诺变更之前修订已批准的进度或预算。

④ 质量影响与风险

仓促测试可能引入安全、隐私、无障碍、集成或可靠性问题。

这对 live chat 尤其重要，因为它可能处理个人信息。

这个细节值得学：答案没有泛泛地说「质量会下降」，而是指出了具体哪个功能带来哪类风险 —— 实时聊天 → 处理个人信息 → 隐私与安全风险。答题时具体化永远比笼统更有说服力。

⑤ 为什么这个应对是恰当的

答案原文：「它让权衡变得可见（makes the trade-off visible），保护了既有的期限和预算，并防止质量成为吸收这次变更的隐藏约束。」

"prevents quality from becoming the hidden constraint that absorbs the change" —— 这是整个 tutorial 最重要的一句话。 三重约束里没有质量，所以当三条边都不让步时，质量就成了那个默默买单的人。

---

五、Change B：时间缩短

场景：应用必须在 8 周而非 12 周内交付。预算保持不变。

① 变化的约束

时间从 12 周减少到 8 周 —— 减少 4 周，约为三分之一。

② 对范围和成本的影响

• 若要维持完整范围，项目可能需要额外的人手或资源，这会增加成本
• 但因为预算是固定的，更现实的应对是减少或推迟部分范围
• ⚠️ 试图在 8 周内同时维持完整范围和预算，会造成巨大的交付压力

这段推理的逻辑链值得完整记住： 时间↓ → 想保范围就得加资源 → 但预算锁死不能加资源 → 所以只能砍范围。 这就是三重约束的实际用法：不是三个独立的量，而是「锁死两个，第三个就被决定了」。

③ 建议应对

与发起人商定一个更小的首发版本。

答案给的具体例子：

版本	功能
8 周首发	个人课表 + 紧急通知
后续版本	作业提醒 + 校园地图

最终的功能优先级应与用户和发起人共同确认。

💡 为什么答案挑了「课表 + 紧急通知」： 课表是这个 App 存在的理由（核心价值），紧急通知关乎安全（不可延后） —— 而作业提醒和校园地图都是「有更好，没有也能过」的增强功能。 这就是按业务价值排优先级的思路，不是随便砍两个。

④ 质量影响与风险

压缩的进度可能减少用于安全、无障碍、集成和可靠性测试的时间，增加缺陷或发布失败的可能性。

⑤ 为什么这个应对是恰当的

答案原文：「它在满足更早期限和固定预算的同时保护了必要的质量工作。它还向干系人提供了一个可用的首发版本，而不是一个包含全部功能但不可靠的版本。」

最后半句是关键：「可用的少数功能」优于「不可靠的全部功能」。 💡 这正好呼应 Week 01那条误解：「按时按预算完成 = 成功」是错的 —— 如果产品不可用，就不是成功。

---

六、Change C：成本削减

场景：预算削减 25%，从 135,000。截止日期保持不变。

① 变化的约束

成本减少 180,000 降到 $135,000，降幅 25%。

② 对范围和时间的影响

• 项目能资助的员工工时、专业服务或其他资源变少
• 维持完整范围通常需要更多时间
• 但因为 12 周期限固定不变，项目很可能需要减少或推迟部分范围

和 Change B 完全对称的推理：成本↓ → 想保范围就得延长工期 → 但工期锁死 → 所以只能砍范围。

③ 建议应对

请发起人和用户对原有功能排定优先级。

答案给的例子：

决定	功能
保留首发	个人课表 + 紧急通知
推迟	校园地图 + 作业提醒

必要的安全、无障碍和测试工作应在削减后的预算内予以保留。

最后这句是本题的答题要害：预算被砍时，第一反应不该是砍测试。 答案明确要求「保住必要的质量工作」 —— 这再次呼应了「质量不能成为隐藏泄压口」。

④ 质量影响与风险

给外包团队的资源不足可能导致仓促工作、技术债、缺陷，或就「供应商在降价后能交付什么」产生分歧。

注意这条特别提到了「外包」这个设定：降价后与供应商的期望管理本身就是一个风险源 —— 你以为少给钱只是少做功能，供应商可能理解成什么都做但都做得糙。

⑤ 为什么这个应对是恰当的

答案原文：「它直接回应了削减的预算，而没有假装原有的范围、期限和质量可以全部保持不变。」

---

七、三种变更的对照总结（答案原文表格）

变更	产生的压力	应对示例
范围增加	通常需要更多时间和/或成本	分期交付新功能，或修订基线
时间减少	通常需要更多成本和/或更少范围	交付更小的首发版本
成本减少	通常需要更多时间和/或更少范围	排定功能优先级，保住必要的质量工作

三条应对策略的共同结构

把三行放在一起看，会发现它们其实是同一个动作的三种表述：

步骤	内容
1	承认权衡真实存在，不假装三者可以同时不变
2	让权衡显性化（make it visible），摆到发起人面前
3	优先保住核心价值与必要的质量工作
4	把其余部分分期/推迟，或正式修订基线

三份答案的措辞里反复出现同一件事： - Change A："prevents quality from becoming the hidden constraint" - Change B："protecting essential quality work" - Change C："Essential security, accessibility and testing work should be preserved"

这就是这个 tutorial 真正想教的东西：三重约束是三条边，但被牺牲的往往是那个不在图上的第四样东西 —— 质量。

一个重要的评分提示

⚠️ 答案文档开头写着： 「These are worked examples, NOT the only correct answers. Another response may be valid if it clearly explains the trade-off and protects the stated quality expectation.」

所以给分点是两个： ① 清楚地解释权衡；② 保护既定的质量期望。 只要这两点做到了，具体砍哪个功能不是唯一答案。

---

八、Part C：小组项目

思考潜在的队友 —— 下周（Week 3）正式开始组队。

💡 后续时间线： Week 3 tutorial 开始组建 4–5 人小组 → Week 4 tutorial 敲定分组 → Week 5 起改用课程统一创建的 GitHub 仓库与看板（见 Week 05 Tutorial第五节）。

---

九、考点重点

1. 三重约束的三条传导规则（与 Week 01 讲义 p35 完全一致）：
   • 范围↑ ⇒ 时间和/或成本↑
   • 时间↓ ⇒ 成本↑ 和/或 范围↓
   • 成本↓ ⇒ 时间↑ 和/或 范围↓
2. 三重约束的实际用法：锁死其中两个，第三个就被决定了 —— 这是所有权衡推理的核心。
3. 质量是「隐藏的第四个约束」 —— 当三条边都不让步时，质量成为默默买单的那一个。答题时必须显式保护它。
4. 数值要记：12 → 8 周 = 减少 4 周 ≈ 三分之一；135,000 = 减少 $45,000 = 25%。
5. 通用应对模板：承认权衡 → 让它显性化 → 保住核心价值和必要质量 → 其余分期或正式修订基线。
6. 「可用的少数功能」优于「不可靠的全部功能」 —— 呼应 Week 1 的成功观。
7. 答题技巧：具体化风险（如「live chat 处理个人信息 → 隐私风险」）比泛泛地说「质量下降」得分更高。
8. 评分点只有两个：清楚解释权衡 + 保护既定的质量期望。

---

十、与讲义的关系

	Week 2 Lecture	Week 2 Tutorial（本文）
主题	PM 方法论（瀑布 vs 敏捷、Scrum、Kanban）	三重约束权衡
实际对应周次	Week 2	Week 1（导论）

本 tutorial 是 Week 01 讲义第六节「三重约束」的直接实操，把讲义 p34–35 的三条抽象规则放进一个具体场景里跑了一遍。

它还是后面几周的伏笔： - Change A 的「范围增加但期限预算不变」 = Week 3 讲义里 Scope Creep 的标准定义，也是 Week 4 Tutorial Part A 的完整场景 - Change B 的「加人手以保范围」 = Week 3 讲义的 Crashing（赶工），代价是成本 - 三次强调的「保住必要的质量工作」 = Week 5 讲义的 Time vs Quality 权衡，以及 CoNC（不符合成本） 的由来