INFO6007 Week 06 Resource Management 讲课总结

Posted on In , Word count in article: 6.7k Reading time ≈ 24 mins.
INFO6007 Week 06 讲课总结，整理项目资源管理的六个过程（规划、估算、获取、建设团队、管理团队、控制资源）， 领导风格、内在/外在激励、Maslow 需求层次与 Herzberg 双因素理论，RACI、RBS、资源直方图、资源负荷与资源平衡， Tuckman 团队发展五阶段、五种冲突处理模式、团队失能五因素，生产率/可用性/成本的分派算例，敏捷资源管理， 以及本周 tutorial 的质量工具与质量成本练习。

INFO6007 Week 06 讲课总结：Resource Management

课程：INFO6007 — Project Management in IT，Semester 2 2026 来源：讲义 PDF + tutorial（无转录稿） - Lecture - INFO6007 Week 06 - Resource Management Plan.pdf（77 页） - Guest Lecture - HJ (HEO).pdf（客座讲座，10 页） - Reading 1 - Maslow's Hierarchy of Needs.pdf（Simply Psychology） - Tutorial sheet INFO6007 Week 06 + Tutorial answers Week 06

参考：Schwalbe, K. (2018). Information Technology Project Management, pp. 373–424。

本讲主线是 PMBOK 的 资源管理六个过程，贯穿全课的 NSW 数字驾照（Digital Driver Licence）案例 在每个过程后各给一页示例。中间穿插了「人」的部分：领导风格、激励理论（Maslow / Herzberg）、Covey 七个习惯、Tuckman 团队发展、冲突处理模式。

⚠️ 注意：本周 tutorial 做的是 Week 5 质量管理 的练习（tutorial 内容一直滞后一周），放在第十章。

一、什么是项目资源管理

Project Resource Management 是识别、获取和管理项目成功交付所需资源（人力和实物）的过程。

IT 项目中要管两类资源：

类型 例子
Human resources（人力） 开发、测试、分析师、PM、DevOps、数据工程师
Physical / technical resources（实物/技术） 服务器、云基础设施、软件许可证、硬件、工具

为什么 IT 项目尤其需要资源管理

  • IT 项目需要专门角色（云工程师、数据科学家、网络安全专家），稀缺且难替代
  • 很多资源被多个项目共享（共享专家、共享测试环境）
  • 许可证、云额度、硬件必须提前规划（有采购周期）
  • 规划不善 → 资源冲突、延期、成本上升

六个过程（PMBOK 第 6 版 Figure 9-1）

# 过程 主要输出
1 Plan Resource Management（规划资源管理） 资源管理计划、团队章程（team charter）
2 Estimate Activity Resources（估算活动资源） 资源需求、估算依据、RBS
3 Acquire Resources（获取资源） 实物资源分配、项目团队分派、资源日历
4 Develop Team（建设团队） 团队绩效评估
5 Manage Team（管理团队） 变更请求、计划更新
6 Control Resources（控制资源） 工作绩效信息、变更请求

记忆线索：前三个是「把资源弄到手」（计划 → 算多少 → 拿到），后三个是「把资源用好」（培养人 → 管人 → 管物）。 第 6 步 Control Resources 主要针对实物/技术资源；人的问题在第 5 步 Manage Team 里处理。

二、规划资源管理与「管人」

Planning Resource Management：定义如何估算、获取、管理和使用资源（人力、实物、材料）的过程（Roseke, 2018）。

人力资源是最关键的资产

  • 项目中的 HRM：组织、管理和领导项目团队的过程
  • 目标：合适的人 + 合适的技能，并在整个生命周期内被激励、被管理、被留住
  • 与机器和预算不同，人的绩效是可变的——受技能、动机、沟通和文化影响

管理人的五个关键方面：领导与激励、沟通、冲突解决、绩效管理、团队建设。

领导 vs 管理

Leadership（领导） Management（管理）
本质 激励、鼓舞、促成协作 计划、组织、控制资源

IT 项目里领导力特别关键，因为：团队通常是跨职能的；技术变化快；全球/分布式团队需要协调。好的领导者会根据项目环境、团队成熟度、组织文化调整风格。

三种领导风格（讲义版）

风格 做法 优点 缺点
Autocratic（独裁/指令式） 领导单方面决策 决策快，适合危机（如系统宕机） 士气低、扼杀创造力
Democratic（民主/参与式） 让团队参与决策 鼓励创新、提升投入 决策慢、可能引发冲突
Laissez-faire（放任式） 极少指导，给予自主 适合高技能、自驱的团队 可能造成混乱、缺乏协调

NSW 案例的「自适应领导」写法很值得背：事故中用指令式；设计讨论用参与式；对可信赖的专家用放任式。 Week 9 会再补充 transformational、transactional、adaptive/agile 等风格。

📝 Practice Exam Q2(b) 正是这一点：资深开发者想要自主、新调来的员工需要明确指导，PM 却对所有人都用指令式——答案方向是按团队成熟度区分风格（对资深者放任/参与式，对新人指令式 + 辅导），一刀切的风格会压制资深者、同时可能也没给新人足够支持。

内在激励 vs 外在激励

方面 Intrinsic（内在） Extrinsic（外在）
定义 源自个人内部：满足感、好奇心、热情 源自外部：奖励、认可、避免惩罚
特征 享受工作本身、想掌握技能、成就感 由有形或社会性激励驱动，绩效与外部奖励挂钩
驱动来源 自我驱动 奖励/惩罚
关注点 乐趣、精通、好奇 金钱、认可、晋升

Maslow 需求层次

需求按层级排列，低层需求得到满足后，高层需求才成为行为的驱动力。

层级（自下而上） 内容 IT 项目中的对应
1. Physiological（生理） 食物、水、睡眠、住所 合理工时、不长期通宵赶工
2. Safety（安全） 工作保障、健康、财务安全、可预测性 合同/岗位稳定、薪资按时发放
3. Love & Belonging（归属） 友谊、信任、被接纳 团队融入、远程成员的归属感
4. Esteem（尊重） 自尊（成就、精通、独立）+ 他人尊重（地位、认可） 公开表扬、署名、授予责任
5. Self-actualization（自我实现） 发挥潜能、个人成长 挑战性任务、新技术学习机会

（Reading 1 的 Maslow 补充点不在 2026 S2 期末范围，已删除，依据 Ed #88、#99：阅读材料不直接考。）

Herzberg 双因素理论（Motivation–Hygiene）

基于职场满意度研究：满意和不满意由两组不同的因素决定。

Motivators（激励因素） Hygiene Factors（保健因素）
性质 内在，关乎工作内容 外在，关乎工作环境
存在时 提高满意度和动机 不会提升动机，只是防止不满
缺失时 不一定导致不满，但缺乏动机 导致不满
例子 成就、认可、责任、晋升、个人成长、有意义/有挑战的工作 薪资福利、公司政策、工作保障、工作条件、监督质量、同事关系

最容易考的反直觉点：薪资是保健因素，不是激励因素。 加薪可以消除不满，但不会让人长期更有干劲；真正的激励来自成就、认可、责任和成长。

Maslow vs Herzberg：Maslow 是层级/顺序模型（先满足下层）；Herzberg 是二维模型（「不满意」的反面是「没有不满意」，「满意」的反面是「没有满意」）。Herzberg 的保健因素大致对应 Maslow 的低层，激励因素对应高层。

Covey 的七个习惯（提升团队人力资源效能）

# 习惯 在项目中的含义
1 Be Proactive 主动预判问题而非被动救火
2 Begin with the end in mind 从目标/交付物倒推
3 Put first things first 按优先级处理（重要而非紧急）
4 Think win-win 谈判和冲突中追求双赢
5 Seek first to understand, then to be understood 先倾听（empathic listening），再表达
6 Synergize 让团队整体大于个人之和
7 Sharpen the saw 持续学习与自我更新

Schwalbe 教材特别强调第 5 条——移情倾听是 PM 处理干系人和团队问题的关键技能。

三、分派工作的三件工具：RACI、RBS、资源直方图

RACI 矩阵

责任分配工具，在多干系人的复杂 IT 项目中防止混乱、重叠和问责空白。

字母 角色 含义 沟通方向
R Responsible 实际干活的人（可以多人） —
A Accountable 最终负责、批准工作的人 —
C Consulted 事前征求意见的人 双向
I Informed 需要被告知进展或决定的人 单向

铁律：每项任务恰好一个 A（多个 A = 没人负责；没有 A = 问责空白）。R 可以多个。

📝 Question Bank Q21 要求为「批准设计变更」写一个 RACI 示例。参考：

活动 PM 首席架构师 两位资深工程师 远程承包商 产品负责人
批准设计变更 I A C R（提交变更说明） C

关键是明确唯一的批准人，消除「谁批设计变更」的争议。

Resource Breakdown Structure（RBS，资源分解结构）

  • 按类别和类型对项目资源进行层级分解
  • 与 WBS 互补：WBS 分解的是工作，RBS 分解的是资源
  • 理想情况下三层：
层级 内容 例子
Level 1 资源大类 Human / Equipment / Software / Materials
Level 2 子类（人→角色；软件→工具/平台） 后端开发、QA；IDE、测试工具
Level 3 具体资源 具体人名、工具版本、服务器、许可证

Resource Histogram（资源直方图）

  • 条形图，显示每种资源在各时间段内被分配的时间量
  • 用来可视化资源使用、工作量分布和过度分配
  • 结构：X 轴 = 时间段（天/周/月/sprint）；Y 轴 = 资源使用量（小时、FTE、人数）；柱 = 该时段该资源被分配的量
  • 不仅用于人，也可以表示设备、软件许可证或预算使用

💡 直方图上超过可用量那条线的部分就是过度分配，这正是下面「资源平衡」要解决的问题。

四、估算活动资源

Estimating activity resources：确定完成项目活动所需资源（人、设备、材料、软件）的类型和数量。资源估算直接影响成本、进度和风险管理。

目的：每个活动需要多少资源；准确规划预算和进度；尽早识别资源约束或缺口；支持工作量分配和资源平衡。

四种估算技术

技术 做法 特点
Expert judgement 借助团队成员或 SME 的经验 有类似项目经验时有用
Analogous estimating（类比） 基于类似项目的历史数据 快但粗
Bottom-up estimating（自下而上） 逐个活动估算再汇总 最准确但最耗时
Three-point (PERT) 乐观 O、最可能 M、悲观 P 处理不确定性

PERT 公式（Week 3 已学）：

📝 Practice Exam Q1(c)： → 天。局限： 远大于 （右偏），说明有较大延期风险；用 8 天承诺交付日期只有约 50% 把握，应加缓冲。

估算时要问的问题

  • 具体活动的难度如何？范围里有没有特殊之处会影响资源？
  • 资源是全职还是兼职？一个人能否同时承担多个任务？
  • 和其他项目有没有潜在冲突？
  • 需要哪些硬件、软件、工具？需要许可证或订阅吗？
  • 可用性或容量有什么限制？

NSW 案例：估算

资源领域 方法 主要资源 主要不确定性
App 开发 Bottom-up 移动开发 + UX + 测试设备 功能复杂度
系统集成 Expert judgement API 工程师 + 安全测试环境 遗留接口
安全与隐私保证 Expert judgement 安全/隐私人员 + 保证工具 审查发现
试点与上线准备 Analogous + parametric 服务团队 + 云容量 用户需求量

五、获取资源：资源负荷与资源平衡

Resource acquisition：获得完成项目活动所需的人力、实物和材料资源，确保合适的资源在合适的时间到位。

四种获取方式

方式 说明 优势
Internal 使用现有员工或内部资源 熟悉公司文化、入职快
External 招聘新员工、承包商或顾问 带来特定技能或额外产能
Procurement 通过供应商获取设备、软件或服务 （Week 8 详讲）
Multi-source 内部 + 承包商 + 供应商组合 灵活

NSW 案例的获取四步：确认需求 → 预分派（pre-assign）→ 谈判（共享专家、供应商）→ 开通（访问权限、云、许可证、设备、入职）；产出是实物资源分配、团队分派、资源日历。

Resource Loading（资源负荷）

把具体资源按时间分派给活动并衡量其工作量，用来发现过度分配或利用不足。单位：小时、天或 FTE。

  • Load → 过度分配（over-allocated）
  • Load → 利用不足（under-utilised）

Resource Leveling（资源平衡）

通过调整进度或重新分配资源来解决过度分配；目标是没有人超负荷，同时尽量保持工期。

目的：防止倦怠；避免资源短缺引起的冲突和延期；优化利用率；保证进度现实可行。

四种技术：Delay tasks（推迟，优先推迟有浮动时间的任务）、Split tasks（拆分）、Reassign tasks（转给别人）、Adjust work hours（调整工时）。

⚠️ 资源平衡可能延长项目工期：如果被推迟的任务在关键路径上（或推迟量超过其总浮动时间），完工日期就会后移。

补充（教材概念，讲义未单列，但 Question Bank Q20 考到）：

Resource Leveling Resource Smoothing
约束 资源上限是硬约束 完工日期是硬约束
能否改关键路径/工期 可以，工期可能变长 不可以，只在浮动时间内调整
适用 资源确实不够用 只想削峰填谷

Q20 的情形（主开发者 160%、有关键路径任务、两名测试员闲置）：只靠 smoothing 解决不了关键路径上的过载；更现实的是先把可转移的工作（如测试脚本、部分开发）交给闲置测试员（reassign），剩下的再做 leveling，并评估对完工日期的影响。

六、建设团队（Develop Team）

提升能力、团队互动和整体团队环境以增强项目绩效；关注技能、动机、协作和信任。

目的：提升技能；促进协作沟通；提升动机与投入；提升绩效与质量；建立信任和积极文化。

关键做法：培训/辅导/工作坊；建立信任与合作的活动；认可成就、提供反馈、让任务匹配兴趣；及时处理人际冲突；确保每个人清楚职责和汇报关系。

Tuckman 团队发展模型（1965，五阶段）

阶段 团队表现 PM 应该做什么
Forming（组建） 互相认识、建立规则；彼此客气、像陌生人 明确目标、角色（RACI）、规则；指令式
Storming（激荡） 开始表达感受，但仍把自己当个人；抵制领导控制、出现敌意 调解冲突、辅导；不要回避
Norming（规范） 产生归属感，接受他人观点就能完成工作 支持、放权
Performing（执行） 开放信任、灵活为主、层级不重要 放任/授权，清障
Adjourning（解散） 评估、交接角色、认可成员贡献 总结经验、表彰

PM 在各阶段的角色是促进者、教练和调解者，监控团队动态、动机和绩效。

📝 Practice Exam Q4(b) 必背：一支已经「Performing」的团队加入两名新开发者后出现分歧、交付变慢，赞助人认为「有经验的团队不需要团队建设支持」。 评析：赞助人的看法不对——Tuckman 模型不是一次性的线性过程，成员变动会让团队退回 Forming/Storming。新成员要重新协商工作方式、建立信任。 干预：组织一次工作方式工作坊/更新团队章程（重新确认规范和 RACI），配合结对（pairing）/导师制让新人融入——帮团队快速回到 Norming。

团队建设的工具

工具 用途
RACI 矩阵 明确角色和职责
资源分配工具 跟踪可用性和工作量
协作工具 改善沟通
绩效跟踪工具 监控和改进绩效
问卷/反馈工具 收集团队意见

奖励与认可体系

目的：激励最佳表现、强化期望的行为和项目价值观、提升投入与满意度、留住人才、降低流失、鼓励持续改进与创新。

类型 说明
Monetary 直接经济激励
Non-monetary 不涉及直接经济补偿的认可（表扬、证书）
Career-based 促进成长和前途（培训、晋升机会）
Team-based 鼓励协作与共同问责

💡 结合 Herzberg：非货币、职业型奖励往往比奖金更能持久激励；而团队型奖励能避免个人奖励引发的内部竞争。

NSW 案例的团队建设五步：明确角色 → 建立安全感与归属感 → 辅导以达到精通 → 促成协作 → 认可成就。

七、管理团队（Manage Team）

跟踪团队绩效、提供反馈、解决问题、协调变更以优化项目成功。

五种冲突处理模式（Thomas–Kilmann）

模式 描述 果断性 合作性 何时使用
Competing（竞争） 牺牲他人坚持己见（赢–输） 高 低 关键问题需快速决策、时间有限
Collaborating（合作） 与各方共同寻找双赢 高 高 复杂问题、需要各方意见
Compromising（妥协） 找中间点（部分双赢） 中 中 时间紧、临时方案
Avoiding（回避） 忽略或推迟冲突 低 低 小问题，或情绪过高时
Accommodating（迁就） 把他人需求放在自己之前 低 高 维护关系，或问题对对方更重要

记忆法：以「果断性 × 合作性」两轴画 2×2 + 中心点：高高 = 合作；高低 = 竞争；低高 = 迁就；低低 = 回避；中中 = 妥协。

📝 Question Bank Q21（两名资深工程师对技术方向冲突）：首选 Collaborating（技术方向是复杂且重要的问题，需要双方知识）；若有截止压力，可限时 Collaborating，失败后由 Accountable 的架构师做 Competing 式裁决；不应 Avoiding——技术方向问题拖下去只会扩大返工。

团队失能的五个原因（Lencioni 金字塔）

# 原因 表现
1 Absence of trust 不敢暴露弱点、不敢求助
2 Fear of conflict 表面和气，回避建设性争论
3 Lack of commitment 没有真正讨论过，所以对决定不买账
4 Avoidance of accountability 不愿指出同事的问题
5 Inattention to results 个人利益/面子优先于团队结果

这五个是自下而上层层导致的：没信任 → 怕冲突 → 不承诺 → 不问责 → 不看结果。IT 项目因技术复杂、工期紧、远程团队、角色不清而尤其常见。

管理团队的策略

  • 用 RACI 明确角色、职责和问责
  • 保持开放、透明、定期的沟通
  • 采用合适的领导风格（transformational、servant、situational）
  • 尽早识别和处理冲突
  • 认可贡献以提振士气

NSW 案例的「团队管理循环」：观察（进度、负荷、行为）→ 领导（按情境和团队成熟度调整风格）→ 激励（精通、意义、认可）→ 解决（冲突、阻碍、角色缺口）。

八、控制资源：生产率、可用性与成本

Controlling resources：监控资源利用、确保高效使用、解决资源冲突、做出调整；保证合适的资源在合适的时间可用，防止过度分配或利用不足。

NSW 案例的五步：收集使用数据 → 与计划对比 → 分析短缺 → 重新分配或替换 → 更新并沟通；控制决策是 keep / reallocate / replace / release；跟踪对象是设备、安全测试环境、云容量、软件许可证、上线设备。

三个概念

概念 含义
Productivity（生产率） 资源多高效地被用来达成目标；高生产率 = 用最少浪费产出最多
Availability（可用性） 资源在需要时可获得、可投入的程度
Cost（成本） 获取、使用和维护资源的支出

算例：Bill / Mary / Minh 谁来做？（重要计算题型）

某任务 SME 估计需 90 effort hours：

成员 生产率 可用性 时薪
Bill 60% 50% $45
Mary 120% 40% $80
Minh 100% 40% $60

公式：

① 以成本为先：

成员 实际工时 成本
Bill h
Mary h
Minh h

→ Minh 最省钱。

② 以进度为先：

成员 实际工时 日历时间
Bill 150 h h
Mary 75 h h
Minh 90 h h

→ Mary 日历时间最短。

易错点： 1. 成本只看实际工时 × 时薪，与可用性无关（可用性只影响要多少日历时间）。 2. 时薪最低的 Bill 反而最贵——生产率低意味着要付更多小时。 3. 时薪最高的 Mary 也不是最贵——生产率高抵消了一部分费率。

九、敏捷环境中的资源管理

  • 不是固定的长期分配，而是让团队产能匹配 sprint 目标
  • 按可用时间、技能和工作量计划，不假设全时可用
  • 团队跨职能、自管理——关注团队整体是否具备交付所需能力
  • 资源管理是持续活动，随优先级和产能变化定期复审

关键步骤：定义范围 → 识别资源 → 估算需求 → 分配和排期 → 监控利用率。

关键活动： - Capacity planning（容量规划）：一个 sprint 实际能完成多少 - Sprint planning：在业务优先级和真实产能之间平衡选择工作 - 监控工作量，避免过度分配、瓶颈、倦怠 - 迭代交付 → 可以频繁重平衡，不必等大的重新计划

最佳实践：清晰沟通与协作、持续监控与重评估、灵活、干系人参与、文档与报告。

敏捷视角的核心：人是最重要的资源；跨职能团队减少交接延迟。

（HEO 客座讲座要点不在 2026 S2 期末范围，已删除，依据 Ed #88、#99：客座讲座不直接考。）

十、Tutorial（Week 6）：质量工具与质量成本

本周 tutorial 是 Week 5 质量管理的应用练习（理论见 Week 05 Quality Management 讲课总结）。另外 Weekly Progress Evaluation 从本周开始（Part D）。

Part A 场景 1：云端 HRM 系统薪资计算频繁出错

① 因果图（鱼骨图）——answer sheet 给出的根因：

类别 可能原因
People 开发者缺乏经验；未接受薪资规则培训
Processes 公式实现错误；代码评审不足
Tools 自动化薪资计算软件有 bug；依赖库过时
Environment 测试数据不一致；与其他模块的集成问题

② 三个预防措施（每条都对应鱼骨的一根骨）： 1. 开发者培训：薪资规则 + 软件最佳实践（→ People） 2. 正式代码评审 + 薪资计算的自动化单元测试（→ Processes） 3. 标准化测试数据，加强与其他 HRM 模块的集成测试（→ Environment）

③ 检查表（checksheet）：answer sheet 只写「参照讲义」。一个可用的示例（自拟）：

缺陷类型 Release 1 Release 2 Release 3 合计
加班费计算错误
税额计算错误
假期/休假扣减错误
与考勤模块数据不同步
舍入/格式错误

检查表的要点：预先定义好类别 + 按时间/版本划记计数，后续可以直接画成 Pareto 图。

Part A 场景 2：报表生成时间歇性崩溃——选两种工具

工具 为什么
Control Chart（控制图） 跟踪崩溃频率和严重度随时间的变化，判断崩溃是随机波动还是有特定模式（超出控制限 = 特殊原因）
Histogram（直方图） 看崩溃事件在不同报表类型或用户负载下的分布，找出最容易崩溃的条件，确定纠正措施的优先级

也可以答 Scatter Diagram（负载/数据量 vs 崩溃次数的相关性）或 Pareto（哪几类报表贡献了 80% 的崩溃）——只要说清「为什么能找出趋势/模式」即可。

Part B：成本分析与权衡

测试中发现缺陷，内部修复花 $8,000；跳过部分预防措施现在能省 $2,000，但上线后可能导致 $20,000 外部失败成本。

① 识别 CoC 与 CoNC：

分类 金额 说明
CoC（符合成本） $2,000 预防措施（培训、测试、代码评审）
CoNC（不符合成本） 内部失败 潜在20,000 外部失败 修复缺陷 + 上线后故障

② 权衡： - 省 的短期节约换来20,000 的长期风险——预防（CoC）比处理上线后缺陷（CoNC）划算 - Time vs Quality：不充分测试就仓促上线会增加 CoNC，损害客户满意度和项目声誉

③ PM 应采取的行动：投资预防措施（额外测试、代码评审），即使短期成本上升，也要最小化总 CoQ、降低外部失败风险。

💡 粗略量化：只要外部失败发生的概率 满足 ，即 ，保留预防措施就是更优的选择。这和 Week 7 的 EMV 思路一致。

十一、本周考点速记 / 易错点

  1. 资源管理六过程：Plan → Estimate → Acquire → Develop Team → Manage Team → Control Resources；Control Resources 主要管实物资源。
  2. 领导 vs 管理：激励协作 vs 计划控制；三种风格（独裁/民主/放任）的适用场景；按团队成熟度调整风格（Practice Exam Q2b）。
  3. Herzberg：薪资是保健因素——缺失导致不满，存在不增加动机；激励因素 = 成就、认可、责任、成长。
  4. Maslow：五层（生理→安全→归属→尊重→自我实现），低层满足后高层才驱动。
  5. RACI：每项任务只有一个 A；C 双向、I 单向。
  6. RBS 分解资源、WBS 分解工作；RBS 三层。
  7. 资源直方图：X 时间、Y 用量；超出可用线 = 过度分配。
  8. Resource Load = Σ分配工时 / 可用工时；Leveling 可能延长工期，Smoothing 不改工期。
  9. 四种估算技术：专家判断、类比、自下而上（最准最慢）、PERT。
  10. Tuckman 五阶段：Forming → Storming → Norming → Performing → Adjourning；成员变动会让团队退回早期阶段（Practice Exam Q4b）。
  11. 五种冲突模式按果断性 × 合作性记；复杂重要问题用 Collaborating。
  12. Lencioni 五种失能：信任缺失 → 惧怕冲突 → 缺乏承诺 → 逃避问责 → 忽视结果。
  13. Bill/Mary/Minh 算例：成本 = 工时/生产率 × 时薪（与可用性无关）；日历时间再除以可用性。
  14. 敏捷资源管理 = 容量规划 + sprint 内平衡 + 频繁重平衡。

十二、本讲与前后的衔接

Week 内容 关键词
4 成本管理 EVM、估算
5 质量管理 QA/QC、CoQ（本周 tutorial）
6 资源管理 RACI、RBS、资源平衡、激励理论、Tuckman
7 风险管理 EMV、风险应对（tutorial 做本周的资源管理）
9 领导力、治理与对齐 补充 transformational / adaptive 领导风格

与其他周的呼应： 1. 估算技术（类比/自下而上/PERT）与 Week 3 时间管理、Week 4 成本管理共用 2. 资源平衡对关键路径的影响连接 Week 3 的 CPM 3. Procurement 作为获取资源的一种方式，在 Week 8 展开 4. 领导风格在 Week 9 扩展为 adaptive/agile 领导