INFO6007 Week 03 Tutorial 解析：方法论选型与干系人分析
INFO6007 Week 03 Tutorial 解析：方法论选型与干系人分析
课程：INFO6007 — Project Management in IT，Semester 2 2026 来源：
Tutorial sheet Week 03 INFO6007.pdf+Week 3 Tutorial Sheet Answers.pdf⚠️⚠️ 老规矩：tutorial 内容比 lecture 慢一周。 Week 3 的 lecture 讲范围管理与进度管理（见 Week 03 讲课总结）， 而这份 tutorial 做的是 Week 2 的内容 —— 方法论选型、需求收集与干系人分析。
课程明写的错位规律
| Tutorial | 实际考的内容 | 对应笔记 |
|---|---|---|
| Week 2 | Week 1（三重约束） | 课程文档原文写明 |
| Week 3 | Week 2（方法论、干系人） | 本文 |
| Week 4 | Week 3（范围蔓延、WBS、关键路径） | Week 04 Tutorial |
| Week 5 | Week 4（EVM 计算） | Week 05 Tutorial |
从第一次 tutorial 起就是慢一周 —— Week 2 的答案文档开头原文写着 "Drawing from Week 1 lecture"，这是课程自己明说的，不是推断。
复习时按这个规律找练习题即可 —— 想练某周 lecture 的内容，去看下一周的 tutorial。
一、Tutorial 目标与结构
目标：让学生掌握在 IT 项目情境中识别、分析和沟通干系人以及有效收集项目需求的实践技能。学生将学会认识干系人影响力与利益的重要性、应用干系人分析工具、并把干系人需求与项目交付物关联起来。同时探讨需求收集策略（访谈、研讨会、观察等）与干系人分析策略（含 Power–Interest 网格），确保能针对不同项目场景选择并应用最合适的技术。
| 部分 | 内容 | 性质 |
|---|---|---|
| A | 项目方法论 | 对比分析 + 论证 |
| B | 需求收集与干系人分析 | 角色扮演 |
| C | 讲义回顾 | 汇总 |
| D | 小组组建 | 事务 |
学习成果：LO1 理解各项目管理知识领域；LO4 初步掌握项目管理工具与实践。
二、Part A：项目方法论
场景
你的组织受托为一家医疗服务提供商开发新的移动应用。项目涉及多方干系人（医生、患者、监管机构），且必须符合严格的法律与安全标准。
注意这个场景的设计：它刻意把两种相互拉扯的力量放在一起 —— 医疗需求在演进（偏向敏捷） vs 监管合规要求文档与可追溯性（偏向瀑布）。 所以答案必然是混合方案，题目本身就是这么设计的。
① Agile vs Waterfall 六维对比（标准答案）
| 维度 | Agile | Waterfall |
|---|---|---|
| 方式 | 迭代增量式；在短 sprint 中交付可运行软件 | 顺序线性；所有需求前期一次性收集 |
| 灵活性 | 高度灵活，项目进行中可纳入变更 | 灵活性低，设计阶段后的变更代价高昂 |
| 干系人参与 | 持续反馈与协作 | 主要在开头（需求）和结尾（交付）参与 |
| 文档 | 轻量自适应，文档随项目演进 | 进入下一阶段前需大量前期文档 |
| 风险管理 | 每个 sprint 中迭代式识别和缓解风险 | 早期识别风险，但项目中途出现的风险可能被忽略 |
| 合规与质量 | 可以把合规评审集成进每个 sprint | 合规主要在最终测试/验证阶段检查 |
② 推荐方案：Water-scrum-fall 混合
标准答案推荐 Hybrid Agile-Waterfall（也叫 "Water-scrum-fall"）。
理由：
| 取自 | 得到什么 |
|---|---|
| Agile | 增量交付、用户反馈、对变化中的医疗需求的适应性 |
| Waterfall | 结构化的合规、文档和可追溯性 —— 这对医疗法规（HIPAA、GDPR）至关重要 |
实施方式：
- 用 Waterfall 做：初始需求收集、合规设计、监管签字
- 切换到 Agile 做：迭代开发与用户反馈循环
这个分工的逻辑很清楚： 合规要求「一次定好、白纸黑字、可追溯」——这是瀑布的强项； 功能实现要求「快速试错、持续调整」——这是敏捷的强项。 把不该变的固定住，把该变的放开 —— 这就是混合方法的本质。
③ 三个风险与缓解策略（标准答案）
| 风险 | 影响 | 缓解策略 |
|---|---|---|
| 监管不合规 | 法律处罚、项目延期 | 从第一天就让合规官参与，每个 sprint 结束时做合规评审 |
| 敏捷中的干系人疲劳 | 参与度下降、需求不清 | 轮换评审会议、优先安排高影响力干系人、保持 sprint review 简短 |
| 敏捷迭代与瀑布文档之间的集成难题 | 技术交付物与合规交付物错位 | 设立专职的集成经理，让敏捷产出与合规文档对齐 |
第三个风险是混合方法特有的，也是最容易被忽略的： 敏捷两周一个迭代在快速变化，而合规文档是静态的。 如果没人负责同步，做出来的东西和签过字的文档会慢慢分叉 —— 到审计时才发现就晚了。
第二个风险也很现实：医生和患者都很忙，「持续反馈」听起来美好，但让医生每两周开一次评审会是不现实的 —— 所以答案给的是「轮换 + 优先高影响力 + 保持简短」。
三、Part B：需求收集与干系人分析
场景
你在一家公司工作，正在为某大学开发在线选课系统（Online Course Registration System）。
任务：① 列出至少 6 位干系人；② 放进 Power/Interest 矩阵；③ 角色扮演——一人当 PM 向其他干系人收集需求，干系人提供需求、约束和期望，PM 最后汇总 Top 5 功能性与非功能性需求。
① 六位干系人（标准答案）
| 干系人 | 角色 |
|---|---|
| Registrar（教务主任） | 监督选课流程、确保符合学术政策 |
| Students（学生） | 终端用户，进行选课/退课 |
| Lecturers（讲师） | 需要更新的班级名单、课表和选课数据 |
| IT Manager（IT 经理） | 负责技术基础设施、集成与安全 |
| Finance Officer（财务） | 处理与选课挂钩的学费 |
| University Administration（校方管理层） | 批准项目方向与资金的行政机构 |
② Power/Interest 矩阵（标准答案）
| High Power | Low Power | |
|---|---|---|
| High Interest | Registrar — Closely
Manage（重点管理） IT Manager — Closely Manage |
Students — Keep
Informed（随时告知） Lecturers — Keep Informed |
| Low Interest | University Administration — Keep Satisfied（令其满意） | Finance Officer — Monitor（监督） |
四象限策略速记
这个矩阵最反直觉的地方是「学生」的位置： 学生是终端用户、利益极高，但个体权力低 ⇒ 落在 Keep Informed，而不是 Closely Manage。 这不是说学生不重要，而是说管理策略不同 —— 对学生要做的是充分沟通和信息透明，而不是把他们拉进每次决策会议。
反过来，校方管理层权力大但日常利益低 ⇒ Keep Satisfied：定期给高层简报，别让他们不满意，但不必事无巨细汇报。
💡 这道题的教学意图：权力和利益是两个独立维度，不能混为一谈。 很多人会本能地把「最重要的用户」放进 Closely Manage，那就答错了。
③ 各干系人的需求、约束与期望（标准答案）
| 干系人 | 需求（Needs） | 约束（Constraints） | 期望（Expectations） |
|---|---|---|---|
| Registrar | 能批准课程开设、强制执行先修要求 | 必须符合大学规章 | 系统准确、减少人工处理 |
| Students | 在线搜索、选课、退课 | 仅在开放选课期间可访问 | 快速、移动端友好、无差错 |
| Lecturers | 查看班级名单、发送通知 | 编辑权限受限，避免课表冲突 | 与学习管理系统（LMS）集成 |
| IT Manager | 安全、可扩展的托管；与现有数据库顺畅集成 | 必须使用大学批准的技术栈 | 高可用、易维护 |
| Finance Officer | 与选课联动的自动学费计算 | 符合财务法规 | 实时财务报表 |
| University Administration | 选课趋势的报表仪表盘 | 预算与项目截止期 | 可证明的 ROI、学生满意度提升 |
注意「需求 / 约束 / 期望」这个三分法本身就是考点： - Needs（需求）= 系统必须能做什么 —— 转化为功能性需求 - Constraints（约束）= 不可谈判的边界 —— 常来自法规、技术栈、时间窗口 - Expectations（期望）= 质量层面的期待 —— 转化为非功能性需求
约束最容易被漏掉，但它往往是项目失败的源头 —— 比如「必须使用大学批准的技术栈」这一条，可能直接排除掉你原本打算用的框架。
④ Top 5 功能性与非功能性需求
💡 答案文档把这一步留给了课堂讨论。以下是基于上表干系人输入的合理推导。
功能性需求（系统做什么）
| # | 需求 | 来源干系人 |
|---|---|---|
| 1 | 学生可搜索、选择和退选课程 | Students |
| 2 | 系统自动校验先修课程与选课资格 | Registrar |
| 3 | 讲师可查看班级名单并向选课学生发送通知 | Lecturers |
| 4 | 选课确认后自动计算并推送学费到财务系统 | Finance Officer |
| 5 | 管理层可查看选课趋势报表仪表盘 | University Administration |
非功能性需求（系统做得怎么样）
| # | 需求 | 来源期望 |
|---|---|---|
| 1 | 性能：高峰期支持并发选课，响应时间 < 2 秒 | Students「快速」 |
| 2 | 可用性：移动端友好的响应式界面 | Students「移动端友好」 |
| 3 | 安全性：学生数据加密，基于角色的访问控制 | IT Manager「安全」 |
| 4 | 可靠性：选课期间高可用（如 99.9% uptime） | IT Manager「高可用」 |
| 5 | 兼容性：与现有 LMS 和财务系统集成 | Lecturers、Finance Officer |
划分功能性 vs 非功能性的判据： 功能性回答「系统能做什么」，非功能性回答「系统做得多好」。 诀窍：期望（Expectations）栏里的形容词——「快速」「安全」「易维护」——几乎都会变成非功能性需求。
💡 一个有意思的呼应：非功能性需求 1（并发性能）正是 Week 05 讲义那道选课系统讨论题里被漏掉的东西 —— 那个系统「通过了所有测试」却在真实并发下崩溃。同一个案例，Week 3 教你怎么收集这条需求，Week 5 教你漏掉它的后果。
四、Part C：讲义回顾
需求收集策略（来自 Week 3 讲义）
| 技术 | 描述 | 适用场景 |
|---|---|---|
| Interviews（访谈） | 一对一对话挖掘需求 | 深挖关键干系人的细节需求 |
| Workshops（研讨会） | 互动式会议建立共识 | 需要多方达成一致、化解冲突需求时 |
| Surveys / Questionnaires（问卷） | 高效触达大规模群体 | 干系人数量大（如全体学生） |
| Prototyping（原型） | 用早期版本细化需求 | 用户「说不清要什么，但见了就知道」时 |
| Observation（观察） | 研究用户实际操作 | 用户的实际做法与他们描述的做法不一致时 |
选型的关键在于「干系人规模」和「需求清晰度」两个维度： - 人少、需求深 → 访谈 - 人多、需求浅 → 问卷 - 需求有冲突 → 研讨会 - 需求说不清 → 原型 / 观察
💡 NSW 数字驾照的实际做法可以直接借鉴：试点反馈 + 可用性测试（驾照持有人）、数据与接口研讨会（TfNSW）、实操试验 + 观察（警察）、场所试点 + 反馈（查验人员）—— 不同干系人用不同技术。
干系人分析策略
| 策略 | 说明 |
|---|---|
| Power/Interest Grid（权力–利益网格） | 本 tutorial 的核心工具，按权力和利益两个维度分四象限，对应四种管理策略 |
| Stakeholder Register（干系人登记册） | 记录每位干系人的身份、角色、联系方式、需求与影响力 |
| Salience Model（显著性模型） | 按权力、合法性、紧迫性三个维度分类 |
| Stakeholder Engagement Matrix | 评估当前参与度 vs 期望参与度，识别需要提升参与的对象 |
| RTM（需求追溯矩阵） | 把干系人需求一路追踪到交付物、测试和验收 |
Power/Interest 网格是本课重点，其余几种了解即可。RTM 在 Week 3 讲义的「收集需求」过程中被列为正式输出，值得记住。
五、Part D：小组组建
- 组建 4–5 人小组
- 写下每位成员的 student ID、unikey 和姓名，交给 tutor
- 本周没定下来也没关系，Week 4 会继续处理
💡 对照后续：Week 4 tutorial 要求正式敲定分组；Week 5 起改用课程统一创建的 GitHub 仓库和看板（见 Week 05 Tutorial第五节）。
六、考点重点
- Agile vs Waterfall 六维对比要能默写：方式、灵活性、干系人参与、文档、风险管理、合规与质量。
- 强合规场景（医疗、金融、政府）的标准答案是混合方法：Waterfall 做需求/合规/签字，Agile 做迭代开发。
- 混合方法特有的风险：敏捷迭代与瀑布文档错位 —— 对策是设专职集成经理。
- Power/Interest 四象限及其策略：
- 高权力 + 高利益 → Closely Manage
- 低权力 + 高利益 → Keep Informed
- 高权力 + 低利益 → Keep Satisfied
- 低权力 + 低利益 → Monitor
- 权力与利益是两个独立维度 —— 终端用户（学生）利益高但权力低，属 Keep Informed，不是 Closely Manage。
- 需求 / 约束 / 期望三分法：Needs → 功能性需求；Expectations → 非功能性需求；Constraints 是不可谈判的边界。
- 五种需求收集技术及其适用场景；选型看干系人规模与需求清晰度。
- 功能性 vs 非功能性：「能做什么」vs「做得多好」。
七、与讲义的关系
| Week 3 Lecture | Week 3 Tutorial | |
|---|---|---|
| 主题 | 范围管理 + 进度管理（WBS、CPM、进度压缩） | 方法论选型、需求收集、干系人分析 （出自 Week 02 讲义） |
| 实际对应周次 | Week 3 | Week 2（PM 方法论） |
不过两者有两条真实的连接： 1. Part B 的需求收集技术就是 Week 3 讲义「过程 2：收集需求」列出的五种 —— tutorial 是在实操讲义里的表格 2. Part B 收集到的需求最终要通过 RTM 追溯到 WBS 的交付物 —— 干系人需求是范围定义的输入
相关笔记： - Week 03 范围管理与进度管理讲课总结 —— WBS 六条规则、四类依赖、CPM 完整解答 - Week 04 Tutorial 解析 —— 本讲 lecture 内容的练习题在这里 - Week 05 Quality Management 讲课总结 —— 那道选课系统崩溃的讨论题，正是本 tutorial 漏掉并发需求的后果