INFO5990-Week5-Tutorial-Summary
INFO5990 Week 5 Tutorial Answer Sheet Summary
Overview
Week 5 的 tutorial 聚焦于 communication（沟通）、teamwork（团队合作）和 stakeholder management（利益相关者管理） 这三个 IT 项目管理的核心软技能。与 Week 4 侧重于方法论和技术生命周期不同，Week 5 转向了"人"的维度——IT 项目的成败往往不取决于技术方案本身，而取决于团队能否有效沟通、协同工作，以及能否正确管理各方利益相关者的期望。
Tutorial 通过三个递进的部分构建完整的实践框架：Part A 通过 7Cs of Communication 练习，培养结构化沟通的能力——将模糊的、非专业的信息重写为清晰、完整、专业的沟通；Part B 通过 Stakeholder Mapping 练习，运用 Power–Interest Matrix 对大学在线学习平台项目的利益相关者进行识别和分类；Part C 通过医疗 IT 项目案例，将沟通、团队合作和利益相关者管理三个维度综合应用到一个存在多重问题的真实场景中。
这三个部分的逻辑是：Part A 提供沟通工具（如何说），Part B 提供分析工具（对谁说），Part C 综合应用（在复杂场景中如何结合三者解决问题）。这种从工具→分析→综合应用的结构，模拟了 IT 专业人士在项目中处理人际和组织挑战的思维过程。
Learning Outcomes
完成本次 tutorial 后，学生应能够： - LO3 — 分析 IT 专业实践中的更广泛问题，了解 IT 行业人力资源管理的当前趋势。本周通过讨论 IT 项目中的沟通失效模式、团队冲突根源以及利益相关者管理策略来培养这一能力。理解"软技能"在 IT 项目中的重要性并非口号——它直接影响项目的进度、质量和客户满意度。 - LO5 — 展示构建有效书面和口头沟通的能力，涵盖冲突解决、合同谈判、团队组建、领导力和团队动态。本周通过 7Cs of Communication 实践练习，培养将模糊信息转化为结构化专业沟通的能力；通过案例分析，理解不同利益相关者需要不同的沟通策略和频率。 - LO6 — 应用研究方法、模型和工具分析 IT 专业实践。本周运用 Power–Interest Matrix 这一经典分析工具来系统性地识别和分类利益相关者，理解如何基于利益相关者的权力和利益水平制定差异化的参与策略。
Part A — 7Cs of Communication（沟通的 7C 原则）
原句分析
原句："Hey, project's late, not sure when it'll be done. Will let you know."
深入分析： 这句话看似传达了信息，但从专业沟通的角度来看，它几乎违反了 7Cs 的每一条原则。让我们逐一对照分析这句话的问题：
违反 Clear（清晰）： "project's late" 没有指明是哪个项目的哪个部分延迟了。在一个 IT 团队中，同时可能有多个项目或多个模块在并行开发，这种模糊的表述会让接收者不知道该关注什么。是整个项目延迟还是某个特定功能模块？延迟的程度是多大？这些关键信息完全缺失。
违反 Concise（简洁）： 虽然这句话很短，但"简洁"不等于"简短"。简洁的意思是"用最少的词传达最多的必要信息"。这句话虽然短，但有效信息量几乎为零——去掉这句话和读了这句话，接收者的信息状态几乎没有变化。
违反 Concrete（具体）： "not sure when it'll be done" 是一个完全无法行动的信息。接收者无法基于此做任何决策——无法调整资源、无法通知客户、无法更新计划。具体的信息应该包含：延迟的原因是什么，预计还需要多长时间，目前进展到哪一步。
违反 Correct（准确）： 用语过于随意（"Hey"），在专业环境中可能传递不够重视的信号。此外，没有提供任何可验证的事实信息。
违反 Coherent（连贯）： 信息之间没有逻辑连接——为什么项目延迟？延迟导致了什么影响？将采取什么措施？这些逻辑链完全缺失。
违反 Complete（完整）： 缺少关键要素：延迟原因、影响范围、补救措施、下次更新时间、是否需要对方协助。接收者读完这条消息后，除了知道"项目延迟了"以外，完全不知道该怎么做。
违反 Courteous（礼貌/专业）： "Hey" 的开头和整体语气过于随意，在向管理层或客户汇报时不够专业。礼貌不仅是语气，也包括对接收者时间的尊重——给出足够的信息让对方不需要反复追问。
改写版本
改写后： "Hi Alex, the login module is delayed due to integration issues with the API. We need two more days to resolve and test. I'll provide an update by Thursday 5 PM and escalate to the security team if needed."
改写逐条对照分析
Clear（清晰）： 明确指出了延迟的具体模块——"login module"，而不是含糊地说"project"。接收者立刻知道问题在哪里，可以评估对整体项目的影响程度。在 IT 项目中，一个登录模块的延迟和整个后端服务的延迟，对项目的影响完全不同。
Concise（简洁）： 三句话涵盖了问题、原因、影响、时间线和升级计划。没有多余的词，每个句子都承载了必要信息。这就是"简洁"的正确含义——不是少说话，而是每句话都有价值。
Concrete（具体）： "integration issues with the API" 给出了延迟的具体技术原因；"two more days" 给出了具体的时间估算；"Thursday 5 PM" 给出了具体的更新时间。这些具体信息让接收者能够基于事实做出决策。
Correct（准确）： 使用了准确的技术术语（API integration），时间表述明确，升级路径清晰。信息的准确性建立了发送者的专业信誉。
Coherent（连贯）： 逻辑流畅——问题是什么→原因是什么→需要多久→下一步是什么→如果情况恶化怎么办。每个信息点自然地引出下一个，读者无需猜测逻辑。
Complete（完整）： 包含了接收者做出决策所需的所有信息——受影响的范围、根本原因、时间估算、下次沟通时间、升级预案。接收者读完后知道：目前无需干预，等 Thursday 5 PM 的更新即可，除非情况升级。
Courteous（礼貌/专业）： "Hi Alex" 的称呼既专业又不冷漠，整体语气体现了对接收者时间的尊重和对问题的负责态度。
7Cs 在 IT 项目中的实际应用场景
深入理解： 7Cs of Communication 不仅仅是一个写作技巧框架——它是 IT 专业人士日常工作中的核心沟通方法论。在 IT 项目中，沟通失效是项目失败的首要原因之一（PMI 研究指出约 56% 的项目风险与沟通不善直接相关）。
7Cs 特别适用于以下 IT 沟通场景： - 状态报告（Status Reports）： 向管理层汇报项目进展时，需要清晰、具体、完整地传达进度、风险和行动项 - Bug 报告（Bug Reports）： 向开发团队报告缺陷时，需要具体描述复现步骤、预期行为和实际行为 - 变更请求（Change Requests）： 向利益相关者说明变更的原因、影响和成本时，需要准确和连贯 - 事件通报（Incident Reports）： 在生产事件发生时，需要快速、清晰地沟通影响范围和恢复计划 - 跨文化沟通： 在全球化 IT 团队中，Clear 和 Concrete 尤为重要——避免依赖文化背景知识的隐含信息
值得特别注意的是 SBAR 框架（Situation-Background-Assessment-Recommendation），这是医疗行业广泛使用的结构化沟通工具，也越来越多地被 IT 行业采用。SBAR 可以视为 7Cs 的一个实践模板：Situation（当前状况——对应 Clear/Concrete），Background（背景信息——对应 Coherent），Assessment（评估分析——对应 Correct），Recommendation（建议行动——对应 Complete）。
Part B — Stakeholder Mapping（利益相关者映射）
案例场景
一所大学正在启动一个新的在线学习平台（online learning platform）项目。
Power–Interest Matrix 框架
深入理解： Power–Interest Matrix（权力-利益矩阵）是由 Aubrey Mendelow 于 1991 年提出的经典利益相关者分析工具。它将利益相关者按照两个维度进行分类：Power（权力/影响力）——该利益相关者对项目决策的影响程度；Interest（利益/关注度）——该利益相关者对项目结果的关心程度。
这两个维度组合形成四个象限，每个象限对应不同的管理策略。理解这个矩阵的关键在于：它不是一个静态的分类工具，而是一个动态的管理指南——利益相关者的位置可能随项目进展而变化（例如，一个最初不关注项目的高管在项目出问题时可能突然变成 High Power, High Interest），因此需要定期重新评估。
利益相关者识别与分类
High Power, High Interest — Manage Closely（密切管理）
大学管理层（University Administrators）
大学管理层包括校长办公室、教务处副校长（Provost）和学院院长。他们拥有最高的决策权力——批准项目预算、确定战略方向、决定平台的功能范围和上线时间表。同时，他们对项目结果有极高的利益关注——在线学习平台直接关系到大学的招生竞争力、教学质量评估和品牌形象。
管理策略：需要最高频率和最高质量的沟通。定期的 steering committee 会议、结构化的进度报告（使用 7Cs 原则）、关键决策的及时上报。需要用业务语言（而非技术语言）与他们沟通——他们关心的是"平台如何支持大学的战略目标"，而不是"使用了什么技术架构"。
政府监管机构（Government Regulators）
在高等教育领域，政府监管机构（如教育部、TEQSA 等）对在线学习有严格的合规要求——包括学术标准、学生数据隐私（可能涉及 Privacy Act）、无障碍访问（Accessibility Standards）等。他们虽然不直接参与项目日常工作，但有权力通过合规审查来决定平台能否上线使用。
管理策略：需要在项目早期就识别所有合规要求，并在开发过程中持续确保合规性。建议指定专人负责与监管机构的联络，定期提交合规报告。不合规可能导致整个项目被叫停，因此这是一个高优先级的利益相关者。
High Power, Low Interest — Keep Satisfied（保持满意）
IT 部门领导（IT Directors）
大学的 IT 部门领导负责整体 IT 基础设施和安全策略。在线学习平台需要集成到现有的 IT 生态系统中（如 SSO 单点登录、校园网络、数据备份体系）。IT 部门领导有权力决定技术标准、安全要求和基础设施资源分配，但他们可能同时管理多个 IT 项目，对这个特定项目的日常进展不一定高度关注。
管理策略：确保技术方案符合 IT 部门的标准和策略，在关键技术决策点邀请他们参与评审。不需要频繁的日常更新，但在涉及基础设施、安全或集成的重大决策时必须获得他们的认可。如果忽视这个群体，可能在项目后期遇到技术合规性问题。
资金提供方（Funding Bodies）
如果项目使用了外部拨款或政府资助，资金提供方拥有审计和资金使用审批的权力。他们关心的是资金是否按计划使用、项目是否按时完成，但不关心具体的技术实现细节。
管理策略：按照合同要求定期提交财务报告和里程碑报告，确保资金使用透明且合规。不需要事无巨细地汇报，但必须确保不出现资金使用的合规问题。
Low Power, High Interest — Keep Informed（保持知情）
学生（Students）
学生是在线学习平台的最终用户和直接受益者。他们对平台的功能、体验和可靠性有极高的关注度——平台的质量直接影响他们的学习效果和体验。然而，学生在项目决策中的正式权力较低——他们通常不参与预算审批或技术选型。
管理策略：虽然学生的正式权力低，但忽视他们是一个常见且致命的错误。应该通过用户调研（surveys）、焦点小组（focus groups）和 beta 测试来收集学生的需求和反馈。学生的"非正式权力"不可低估——如果平台上线后学生大量投诉，可能引发媒体关注和管理层介入，反向推动项目变更。
深入理解： 学生群体的一个特殊之处在于他们的多样性——不同专业、不同年级、不同技术水平、不同设备偏好（有些依赖手机，有些使用笔记本电脑）。平台设计需要考虑这种多样性，而不是假设所有学生都有相同的使用场景。
讲师/教师（Lecturers）
讲师是平台的另一类核心用户——他们使用平台发布课程内容、管理作业、与学生互动。讲师对平台的"教学功能"有高度关注——功能是否支持他们的教学方式，操作是否简单高效，是否能减轻而非增加他们的工作负担。
管理策略：讲师的参与对项目成功至关重要——如果讲师觉得平台难用或不符合教学需求，他们可能拒绝使用或消极使用，导致平台名存实亡。应该在需求收集阶段就积极邀请不同学科的讲师代表参与，理解不同教学场景的需求差异。
Low Power, Low Interest — Monitor（监控）
未直接参与项目的技术支持人员（Technical Support Staff）
大学 IT 部门中不直接参与本项目的技术支持人员。他们的日常工作可能不受在线学习平台项目的直接影响，但平台上线后，他们可能需要提供技术支持和故障排除服务。
管理策略：当前阶段只需保持基本的信息共享（如项目通讯邮件）。但需要注意——随着项目接近上线，这部分人员的 Interest 可能会上升（因为他们需要准备支持流程），到时可能需要重新分类到 "Keep Informed" 象限。
Power–Interest Matrix 的动态性
深入理解： Power–Interest Matrix 不是一次性的分析——它应该在项目的关键阶段被重新评估。例如： - 项目启动阶段： 管理层和资金方是焦点，因为需要获得批准和预算 - 需求收集阶段： 学生和讲师成为焦点，因为需要理解他们的实际需求 - 开发阶段： IT 部门和技术供应商成为焦点，因为需要确保技术可行性 - 上线前： 监管机构和合规审查成为焦点，因为需要获得上线许可 - 上线后： 技术支持团队的 Interest 上升，因为他们需要处理用户问题
这种动态视角是 Week 4 提到的持续 IT 生命周期思维在利益相关者管理领域的体现——管理不是一次性的活动，而是持续迭代的过程。
Part C — Case Study Discussion（案例分析）
案例背景
一个 IT 团队正在为一家 healthcare provider（医疗服务提供商） 开发一款 mobile app。当前项目面临三个严重问题：开发人员（Developers）和测试人员（Testers）之间频繁发生冲突；医生（Doctors）抱怨他们在开发过程中没有被咨询；管理层（Management）觉得项目更新不够清晰。
深入理解： 这个案例表面上看是三个独立的问题，但实际上它们是同一个系统性失败的不同症状——项目缺乏有效的沟通机制、团队协作框架和利益相关者管理策略。这三个问题相互加强：开发和测试的冲突导致进度延迟→管理层因为缺乏清晰信息而焦虑→焦虑的管理层给团队施加更大压力→压力导致开发和测试的冲突加剧→医生因为持续被忽视而越来越不满→不满可能导致最终产品不符合临床需求→产品失败反过来验证了管理层的焦虑。这种恶性循环如果不从根本上打破，项目最终必然失败。
问题 1：沟通是在哪里出问题的？（Where is communication breaking down?）
沟通的崩溃发生在多个层面和多个方向：
1. 向上沟通失效（Upward Communication Breakdown）
管理层收到的项目更新"不够清晰"——这不是简单的"信息不足"，而是沟通的结构和内容出了问题。可能的表现包括：状态报告只列出"已完成任务"而不提及风险和阻碍；使用技术术语而非管理层能理解的业务语言；报告频率不规律，管理层不知道什么时候能收到更新；报告中没有清晰的"下一步行动"和"需要管理层决策的事项"。
运用 Part A 学习的 7Cs 来分析：这种向上沟通缺乏 Clear（不清楚当前状态是好是坏）、Complete（缺少风险信息和决策请求）和 Coherent（缺乏逻辑——为什么延迟？延迟导致什么后果？需要什么支持？）。
2. 横向沟通失效（Lateral Communication Breakdown）
开发人员和测试人员之间的冲突通常源于沟通不畅：开发人员可能觉得测试人员"吹毛求疵"，不理解在时间压力下某些 bug 可以暂时搁置；测试人员可能觉得开发人员"不重视质量"，在代码没有充分自测的情况下就提交。这种冲突的根源往往是双方对"完成"（Definition of Done）的理解不一致——开发认为"功能实现了"就算完成，测试认为"通过所有测试用例"才算完成。
此外，在医疗软件的语境中，代码质量和测试覆盖率不仅是内部工作标准，还涉及患者安全和法规合规——这使得开发和测试之间的分歧不仅是工作方式差异，还涉及专业伦理和法律责任。
3. 外向沟通缺失（Outward Communication Absence）
医生抱怨"没有被咨询"——这是最严重的沟通失败，因为它不是沟通质量差，而是完全没有沟通渠道。医生作为医疗应用的领域专家和最终用户，他们的临床知识对于确保应用的功能设计符合医疗工作流至关重要。没有医生的参与，开发团队可能基于自己的假设来设计功能——而 IT 人员对临床流程的理解往往是不完整甚至错误的。
深入分析： 这种外向沟通缺失在 IT 项目中极为常见，尤其是在 IT 团队与领域专家之间。原因通常有几个：IT 团队觉得"我们知道怎么做软件"，低估了领域知识的重要性；医生的日程紧张，IT 团队觉得"不好意思打扰他们"；缺乏有效的参与机制——没有人负责协调医生与 IT 团队的交互。
问题 2：可以看到哪些团队合作挑战？（What teamwork challenges can you spot?）
1. 开发和测试团队的角色冲突（Role Conflict）
开发人员和测试人员的冲突是 IT 项目中的经典团队问题。从 Tuckman's Team Development Model 的角度来看，这个团队显然还停留在 Storming（风暴期） 阶段——成员之间在工作方式、优先级和责任划分上存在分歧，还没有找到有效的协作模式。
深入分析： Tuckman 模型将团队发展分为五个阶段：Forming（组建期）→ Storming（风暴期）→ Norming（规范期）→ Performing（高效期）→ Adjourning（解散期）。案例中的团队卡在 Storming 阶段，需要通过明确的规范（如 Definition of Done、代码评审流程、bug 优先级标准）来过渡到 Norming 阶段。
在 Belbin Team Roles 框架中，这种冲突可能反映了角色重叠或角色缺失——例如，团队中可能缺少一个 Coordinator（协调者）角色来调和开发和测试之间的分歧，或者缺少一个 Team Worker（团队合作者）角色来润滑人际关系。如果团队中都是 Shaper（塑造者）类型的人，冲突就更容易发生，因为每个人都想推动自己的方向。
2. 跨职能协作不足（Cross-functional Collaboration Deficit）
医生没有被纳入开发过程，说明团队的组织方式是职能型孤岛而非跨职能团队。在传统的 Waterfall 模式中，这种做法很常见——业务需求在前期由分析师收集，然后交给开发团队，最终用户在 UAT 阶段才参与。但在 Agile 和以用户为中心的现代开发实践中，领域专家应该是团队的一部分或至少是定期参与者。
深入分析： 在医疗 IT 领域，跨职能协作不足的后果特别严重。开发团队可能开发了一个"技术上完美"但"临床上无用"的功能——例如，一个需要医生在手术中操作触摸屏的功能（忽略了医生在手术时戴着手套的事实），或者一个需要输入大量详细信息的表单（忽略了急诊科医生每个患者只有 5 分钟的现实）。
3. 信息透明度不足（Lack of Transparency）
管理层不清楚项目状态，说明团队内部可能也存在信息不对称。团队成员之间是否清楚彼此的工作进展？是否有共享的任务看板（如 Kanban 或 Scrum Board）来可视化工作状态？是否有定期的同步机制（如 Daily Standup）来确保信息流动？
4. 缺乏共同目标和价值观（Absence of Shared Goals）
开发人员可能优先考虑"按时交付功能"，测试人员优先考虑"确保质量无缺陷"，医生关心"支持临床工作流"，管理层关心"控制成本和进度"。这些目标本身都合理，但如果没有一个统一的项目愿景将它们对齐，各方就会各自为战。团队需要一个所有人都认同的北极星目标——在这个案例中，可能是"为医疗从业者提供安全、高效、易用的移动工具，改善患者护理质量"。
问题 3：你会如何管理利益相关者？（How would you manage stakeholders here?）
运用 Part B 学习的 Power–Interest Matrix，对案例中的利益相关者进行系统性分析和策略制定：
Executives / 高管（项目赞助者）
分类：High Power, High Interest → Manage Closely
高管是项目的赞助者（Sponsors），控制预算和战略方向。在当前混乱的状况下，他们的焦虑可能正在升级——项目更新不清晰让他们无法向自己的上级交代，也无法做出及时的决策。
管理策略： - 建立固定频率的结构化汇报机制——例如每两周一次的 steering committee 会议，使用 SBAR 格式的进度报告 - 汇报内容使用业务语言而非技术语言——不说"API 集成有 bug"，说"用户无法登录，影响 30% 的测试场景，预计 3 天内修复" - 主动汇报风险和障碍，不要只报好消息——管理层更害怕"意外"，提前告知风险可以让他们有时间准备 - 需要管理层做决策时，提供明确的选项和建议，而不是开放式问题——"我们有 A 和 B 两个方案，A 更快但成本高 20%，B 更稳但需多 2 周，建议选 B 因为医疗合规风险更低" - 当管理层对发布速度提出压力时，需要清晰地解释合规性和安全性的 trade-off——在医疗软件领域，加速发布可能带来患者安全风险和法规合规风险
Doctors / 医生（终端用户）
分类：High Interest, Medium Power → Keep Informed and Engaged
医生是应用的核心用户，他们的临床知识是确保产品可用性的关键。当前他们感到被忽视，这是一个需要紧急修复的关系。
管理策略： - 立即建立正式的参与渠道——邀请 2-3 名医生代表加入 Product Advisory Group，定期参与需求评审和 usability 测试 - 采用适合医生日程的参与方式——医生很忙，不能期望他们参加每周的 Sprint Review。可以使用异步方式（如录屏演示 + 反馈表单）或安排在他们方便的时段进行短时间的 focused session - 在需求收集阶段进行临床工作流观察（Clinical Workflow Observation）——实地观察医生的工作环境和习惯，理解他们的真实需求而非假设需求 - 提供清晰的反馈闭环——医生提出的建议被采纳了要告知，没有被采纳也要解释原因。没有反馈闭环的咨询机制会让参与者觉得"说了也白说"，最终失去参与意愿
Compliance Officers / 合规官（监管角色）
分类：High Power, High Interest → Manage Closely
在医疗软件开发中，合规官的角色至关重要——他们确保软件符合 HIPAA（美国）、Privacy Act（澳大利亚）等法规要求，以及医疗数据安全标准。
管理策略： - 在项目早期阶段就让合规官参与，识别所有合规要求——等到开发完成再做合规审查是最昂贵的策略 - 将合规检查嵌入到开发流程中——而不是作为独立的最终审查。例如，每个 Sprint 的 Definition of Done 中包含"通过合规检查" - 定期提供合规文档更新——审计追踪（audit trail）、数据处理协议、安全测试报告 - 邀请合规官参与测试阶段的早期评审，避免在上线前出现阻断性的合规问题
Testers & Developers / 测试人员与开发人员（内部团队）
分类：Medium Power, High Interest → Empower Through Teamwork
作为项目的执行者，开发和测试团队的协作效率直接决定项目的成败。当前他们之间的冲突是项目最紧迫的问题之一。
管理策略： - 通过Agile 仪式建立结构化协作——Daily Standup 确保每日信息同步，Sprint Retrospective 提供反思和改进的安全空间，Sprint Planning 确保对目标和优先级的共识 - 建立共享文档和工具——统一的 bug tracking 系统（如 Jira）、共享的测试用例仓库、一致的 Definition of Done 标准 - 引入 pair programming 或 code review 实践——让开发和测试在代码层面建立共同理解，减少"扔过墙"式的工作模式 - 如果冲突已经影响到人际关系，可能需要一次facilitated team session（由中立的 Scrum Master 或外部教练引导），让双方表达关切并共同制定协作规范
问题 4：Communication、Teamwork 和 Stakeholder Management 如何结合解决问题？
核心观点： 这三个维度不是独立的工具——它们是一个相互增强的系统。单独改善任何一个维度都不够，因为它们之间存在深层的依赖关系。
Communication 提供 Clarity（沟通提供清晰度）
运用 7Cs 和 SBAR 等结构化沟通工具，团队可以在多个层面改善信息传递：向管理层提供清晰、完整、有逻辑的项目更新，消除信息不确定性带来的焦虑；在开发和测试之间建立明确的沟通协议（如 bug 报告模板、代码评审流程），减少因为沟通模糊导致的冲突；为医生提供正式的反馈渠道，确保他们的临床洞察被系统性地纳入开发过程。
关键洞察： 有效沟通不仅传递信息，还建立信任。当管理层持续收到高质量的状态更新时，他们对团队的信任增加，微观管理减少，团队的自主性提高。当医生看到自己的反馈被认真对待并反映到产品中时，他们从"被忽视的抱怨者"转变为"积极的产品共建者"。
Teamwork 提供 Collaboration（团队合作提供协同力）
通过 Agile 仪式（Daily Standup、Sprint Retrospective）和共享工具，开发和测试团队可以从 Tuckman 模型的 Storming 阶段过渡到 Norming 和 Performing 阶段。具体来说：明确的角色定义和 Definition of Done 消除了责任边界模糊导致的冲突；定期的 retrospective 提供了安全的空间来讨论和解决团队问题；共享的目标（"为患者提供更好的护理工具"）将个人对立转化为团队合作。
关键洞察： Teamwork 不是让冲突消失——适度的、建设性的冲突（如对代码质量标准的辩论）实际上有助于团队提升。关键是将个人冲突转化为议题讨论——不是"你写的代码有问题"，而是"我们如何建立更好的测试覆盖率标准"。
Stakeholder Management 提供 Direction（利益相关者管理提供方向）
通过 Power–Interest Matrix 系统性地识别和分类利益相关者，团队可以将有限的沟通和协作资源分配到最关键的地方：高管（Manage Closely）需要最频繁和最结构化的参与；合规官（Manage Closely）需要在关键决策点的早期介入；医生（Keep Informed and Engaged）需要建立有效但不过度负担的参与机制；内部团队（Empower）需要自主性和协作工具的支持。
关键洞察： Stakeholder Management 的核心不是"让所有人都满意"——而是基于利益相关者的权力和利益水平，做出合理的优先级排序。在资源有限的情况下，试图让所有人都得到同等关注是不现实的，也是低效的。矩阵帮助团队做出这种优先级判断。
三者的协同效应
当 Communication、Teamwork 和 Stakeholder Management 三者同时改善时，会产生正向循环：
- 结构化的沟通 → 管理层获得清晰信息 → 管理层信任增加 → 团队获得更多自主权 → 团队有更多时间和空间进行有效协作
- 有效的团队协作 → 开发和测试冲突减少 → 交付速度和质量提升 → 管理层更满意 → 沟通中有更多好消息可报
- 系统的利益相关者管理 → 医生被纳入开发流程 → 产品更符合临床需求 → 医生满意度提升 → 医生成为项目的支持者而非反对者 → 管理层看到终端用户的正面反馈 → 项目获得更多支持和资源
这种正向循环与 Part A 中的原始消息（"Hey, project's late"）所代表的负向循环形成鲜明对比。专业沟通是启动正向循环的第一步——这就是为什么 7Cs of Communication 被放在本周 tutorial 的第一部分。
关键概念总结
本周核心框架关系
Week 5 的三个核心概念形成了一个三角形的支撑结构：Communication 是基础——没有有效沟通，teamwork 和 stakeholder management 都无从谈起；Teamwork 是引擎——没有团队协作，沟通策略和利益相关者管理计划都无法执行；Stakeholder Management 是方向盘——没有对利益相关者的系统分析，沟通和协作的努力可能投向错误的方向。
与前几周的知识连接
Week 5 的内容与前几周紧密相连： - Week 2 的 Professionalism — 7Cs of Communication 是 IT 专业人士的专业素养的具体体现。专业的沟通能力是将 Knowledge 转化为 Expertise 的关键技能之一 - Week 3 的组织结构 — 不同组织结构对沟通路径和利益相关者关系有直接影响。在 Matrix 组织中，stakeholder management 更加复杂，因为团队成员可能同时向多个管理者汇报 - Week 4 的方法论 — Agile 方法论内置了很多沟通和协作机制（Sprint Review、Daily Standup、Retrospective），DevOps 文化强调打破 IT 和运维之间的沟通壁垒。方法论的选择直接影响团队的沟通模式和利益相关者参与方式
对 IT 专业人士的启示
在 IT 行业中，技术能力是入门门槛，而沟通、协作和利益相关者管理能力决定了一个专业人士能走多远。很多技术优秀的 IT 人才在职业发展中遇到瓶颈，往往不是因为技术不够好，而是因为无法有效地与非技术利益相关者沟通、无法在多元化团队中发挥领导力、无法系统性地管理项目各方的期望。Week 5 的知识框架——7Cs + Power–Interest Matrix + 三者协同——为 IT 专业人士提供了系统性提升这些"软技能"的工具和方法论。
关键术语表
| 术语 | 英文 | 含义 |
|---|---|---|
| 沟通 7C 原则 | 7Cs of Communication | 有效沟通的七个标准：Clear, Concise, Concrete, Correct, Coherent, Complete, Courteous |
| 权力-利益矩阵 | Power–Interest Matrix | 根据权力和利益两个维度对利益相关者进行分类的工具 |
| SBAR 框架 | Situation-Background-Assessment-Recommendation | 源于医疗行业的结构化沟通工具 |
| 利益相关者映射 | Stakeholder Mapping | 系统性识别和分析项目利益相关者的过程 |
| 团队发展模型 | Tuckman's Team Development Model | 团队发展的五个阶段：Forming → Storming → Norming → Performing → Adjourning |
| 贝尔宾团队角色 | Belbin Team Roles | 九种团队角色模型，描述团队中不同行为和贡献类型 |
| 完成的定义 | Definition of Done (DoD) | 团队对"工作完成"的共识标准 |
| 跨职能团队 | Cross-functional Team | 包含不同专业角色的团队，能独立完成交付 |
| 反馈闭环 | Feedback Loop | 信息从接收到回应的完整循环，确保反馈被跟踪和处理 |
| 筒仓效应 | Silo Effect | 组织中团队或部门之间缺乏沟通和协作的现象 |
| 风暴期 | Storming | Tuckman 模型的第二阶段，团队成员产生冲突和分歧 |
| 密切管理 | Manage Closely | Power–Interest Matrix 中高权力高利益象限的管理策略 |
参考
- INFO5990 Week 5 Tutorial Sheet & Answer Sheet
- INFO5990 Week 5 Lecture: Professional Communication, Collaboration, and Stakeholder Management
- Mendelow, A. (1991). Stakeholder Mapping — Power–Interest Matrix
- Tuckman, B. (1965). Developmental Sequence in Small Groups
- Belbin, M. (2010). Team Roles at Work
- PMI PMBOK Guide — Communications Management Knowledge Area