INFO5990-Week4-Lecture-Summary
一、本周整体框架
Week 4 Lecture 分成三大部分：
- Professional Communication（专业沟通）
- Teamwork（团队协作）
- Stakeholder Management（利益相关者管理）
老师的核心结论非常清晰：
- Communication 是胶水（glue）：保证信息清晰、对齐预期
- Teamwork 是引擎（engine）：推动协作、创新和交付
- Stakeholder Management 是方向盘（direction）：确保团队做的是对的事，而不是只是在"很努力地做错事"
三者缺一不可，互相依赖。
二、Professional Communication（专业沟通）
2.1 为什么沟通在 IT 项目里特别重要？
Lecture 开篇强调：Communication is the backbone of IT projects.
IT 项目天然就是多角色协作：developers、testers、project managers、clients、end users、external stakeholders。如果沟通出问题，常见结果就是延期（delays）、成本超支（cost overruns）、甚至项目失败（project failure）。
核心公式：
Success = Technology + Communication
沟通的四大作用： - Requirement Gathering：收集需求——确保做出来的东西是客户想要的 - Team Coordination：团队协同——确保各角色知道谁在做什么 - Stakeholder Engagement：与干系人互动——保持期望对齐 - Reporting Progress：汇报进展——让管理层和客户了解状态
2.2 沟通的四种类型
（1）Written Communication（书面沟通）
分为正式（emails、reports、contracts、documentation）和非正式（Slack chats、shared notes）两种。
Best practices： - 清晰简洁（clear and concise） - 避免行话（avoid jargon）——除非对方也是技术人员 - 校对（proofread）——拼写和语法错误会影响专业形象
（2）Verbal Communication（口头沟通）
包括面对面会议、视频会议、电话、日常 stand-up 等。
优势是可以快速澄清问题、建立信任。关键技能包括： - 主动倾听（active listening） - 清晰表达（speaking with clarity） - 管理语调和节奏（managing tone and pace）
常见陷阱：少数人主导发言（dominance of few voices）、缺少会后跟进（missed follow-ups）。
（3）Presentation / Visual Communication（演示/视觉沟通）
用于项目提案、利益相关者更新、产品演示等场景。
关键要素： - 讲故事结构：Problem → Solution → Impact - 视觉辅助：图表、流程图、原型 - 了解受众：面对技术团队和面对高管的表达方式完全不同 - 练习和把控时间 = 建立可信度
（4）Non-verbal Communication（非言语沟通）
包括肢体语言、面部表情、眼神接触等。在远程沟通场景（如视频会议）中同样重要，例如摄像头开关、背景环境等都会传递信息。
2.3 沟通的 7Cs 框架
这是一个经典的沟通质量检查清单：
| 原则 | 含义 |
|---|---|
| Clear | 信息明确，不模糊 |
| Concise | 简洁，不啰嗦 |
| Concrete | 有具体细节和数据支撑 |
| Correct | 信息准确无误 |
| Coherent | 逻辑连贯 |
| Complete | 信息完整，不遗漏关键点 |
| Courteous | 礼貌尊重 |
2.4 SBAR 框架
SBAR 是一个结构化沟通工具，特别适合汇报问题或做决策建议：
- S — Situation：发生了什么？（当前状况）
- B — Background：背景是什么？（相关上下文）
- A — Assessment：你的评估是什么？（分析和判断）
- R — Recommendation：你建议怎么做？（行动方案）
实际案例：手机 App 支付功能在更新后崩溃 - S：支付功能在最新版本更新后无法使用 - B：更新涉及后端 API 变更，之前的测试覆盖了主要路径但遗漏了边缘场景 - A：问题根源在 authentication API 的返回格式变化，影响约 15% 的用户 - R：建议立即回滚到上一版本，同时修复 API 兼容性问题，预计 2 天内完成
2.5 沟通障碍（Barriers to Communication）
- 技术行话和缩写：不是每个人都懂 API、CI/CD、Sprint
- 文化和语言差异：全球化团队尤其明显
- 远程协作挑战：时区差异、缺乏面对面互动
- 假设和缺乏主动倾听：以为对方理解了，其实没有
- 文档不足：导致知识断层（knowledge gaps）
2.6 沟通工具
Lecture 提到常用工具：Slack、Microsoft Teams、Discord（即时沟通）；Jira、Trello、Asana（项目管理和任务追踪）。
关键原则： - 根据目的选择合适的工具（right tool for right purpose） - 重要决策要留下记录 - 定期 check-in
2.7 差沟通 vs 好沟通的对比
Lecture 给出了一个开发者向 PM 更新延期任务的例子：
差的版本：模糊、没有时间线、没有责任归属 > "Hey, the task is taking longer than expected. Not sure when it'll be done."
好的版本：具体说明问题、时间线、更新计划、升级方案 > "The authentication API integration is causing errors in edge cases. I need about 2 more days. I'll provide an update by Thursday 5pm. If not resolved, I'll escalate to the security team."
深入理解
这个对比非常重要。在工作中，很多人以为"说了"就等于"沟通了"，但沟通的质量差异巨大。好的沟通包含：问题是什么（specific issue）、影响范围（impact）、预计时间（timeline）、下一步（next action）、升级计划（escalation）。SBAR 框架在这里可以直接套用。这不是"过度沟通"，而是专业的体现。
三、Teamwork（团队协作）
3.1 为什么 IT 项目需要团队协作？
IT 项目本质上是协作性的（collaborative），需要结合多种专业角色：developers、testers、designers、managers、business analysts 等。
团队协作的好处： - 更快地解决问题（faster problem-solving） - 更高的创造力和创新（higher creativity & innovation） - 共享责任和问责（shared responsibility & accountability） - 更强的项目交付成果（stronger project outcomes）
3.2 关于团队协作的常见误解
| 误解 | 现实 |
|---|---|
| "所有人必须达成一致" | 健康的分歧（healthy disagreements）反而能推动更好的结果 |
| "团队协作会拖慢进度" | 好的协作减少返工和错误，实际上更快 |
| "好的团队没有冲突" | 冲突是正常的，关键在于如何解决 |
| "每个人的贡献必须相等" | 不同角色的贡献方式不同，不能用同一标准衡量 |
3.3 高效 IT 团队的特征
- 明确的角色和责任（clear roles & responsibilities）
- 信任和心理安全（trust & psychological safety）
- 开放和尊重的沟通（open and respectful communication）
- 共享的目标和问责（shared goals and accountability）
- 适应变化的能力（ability to adapt to change）
- 技术能力和软技能的平衡（balance of technical and soft skills）
3.4 团队与多样性（Diversity）
多样性的类型： - 文化/语言多样性 - 教育/技术背景多样性 - 性别/年龄/经验多样性
好处： - 更全面的问题解决（better problem-solving） - 更以用户为中心的产品（user-centered products）
挑战： - 沟通障碍 - 无意识偏见（unconscious bias）
3.5 团队动态的挑战
- 参与不均（unequal participation）
- 主导型人格 vs 安静的贡献者（dominant personalities vs quiet contributors）
- 目标不一致（misaligned goals）
- 跨文化误解
- 远程/虚拟团队的挑战
3.6 Tuckman 的团队发展阶段模型
这是团队发展的经典五阶段模型：
| 阶段 | 特征 |
|---|---|
| Forming（组建期） | 团队成员初次见面，礼貌但不确定，了解任务和角色 |
| Storming（风暴期） | 出现分歧和冲突，成员争夺角色和影响力，这是最关键的阶段 |
| Norming（规范期） | 团队开始建立共识和工作规范，信任逐渐建立 |
| Performing（执行期） | 团队高效运作，协作流畅，专注于交付 |
| Adjourning（解散期） | 项目结束，团队解散，进行总结和反思 |
深入理解
Storming 阶段是很多团队失败的地方。很多人以为冲突 = 团队有问题，实际上 Storming 是健康团队发展的必经之路。关键在于团队能否在 Storming 阶段有效处理冲突，建立起共识和规范（transition to Norming）。如果 Storming 被压制或回避，表面上和谐，但团队永远无法进入 Performing 状态。
3.7 Belbin 的团队角色理论
Belbin 把团队角色分为三大类、九种角色：
Social / People-oriented Roles（社交型角色）： - Resource Investigator：外向、善于探索外部资源和建立联系 - Teamworker：合作性强、善于调和关系、促进团队和谐 - Coordinator：善于协调、明确目标、擅长委派任务
Thinking Roles（思考型角色）： - Plant：创意型人才、善于提出非常规的解决方案 - Monitor Evaluator：分析型、冷静客观、善于评估方案优劣 - Specialist：深度专家、在特定领域提供专业知识
Action / Task-oriented Roles（行动型角色）： - Shaper：推动者、有紧迫感、不怕挑战 - Implementer：执行者、善于把计划变成实际行动 - Completer Finisher：完美主义者、注重细节、确保质量
每种角色都有对应的优势和允许的弱点（allowable weaknesses）。一个好的团队应该有角色的多样性和互补性。
深入理解
Belbin 的意义在于：它告诉我们不是每个人都适合同一种工作方式。有人擅长创意（Plant），有人擅长执行（Implementer），有人擅长收尾（Completer Finisher）。如果一个团队全是 Plant，创意很多但没人落地；如果全是 Implementer，执行力强但缺乏创新。理解自己和队友的角色，能大幅减少摩擦、提升效率。在小组作业中，这个理论非常实用——先了解每个人的强项，再分配任务。
3.8 心理安全与 Google 的 Project Aristotle
Google 对 180+ 个团队的研究发现：心理安全（Psychological Safety）是团队成功的第一要素，比专业能力和组织结构更重要。
心理安全的含义：团队成员可以放心地提出想法、承认错误、提出质疑，而不会被嘲笑或惩罚。
如何创建心理安全的环境： - 鼓励好奇心（encourage curiosity） - 正常化错误（normalize mistakes）——把错误当作学习机会 - 积极倾听（active listening） - 包容的环境（inclusive environment） - 明确的期望（clear expectations）
深入理解
这个研究的核心发现让很多人意外：团队成功的关键不是"找到最聪明的人"，而是"创建一个让每个人都敢说话的环境"。在技术团队中，如果 junior 开发者不敢说出自己发现的 bug，或者不敢质疑 senior 的设计决策，那团队的实际能力就打了折扣。心理安全不是"做老好人"，而是建立一种"可以安全地提出异议"的文化。
3.9 敏捷（Agile）团队实践
Lecture 介绍了四种关键的敏捷实践：
- Daily Standup（每日站会）：≤15 分钟，每人回答三个问题：昨天做了什么、今天要做什么、有什么障碍
- Sprint Planning（冲刺计划）：团队一起决定这个 Sprint 要做哪些任务
- Sprint Review（冲刺回顾）：向利益相关者展示完成的工作，获取反馈
- Sprint Retrospective（冲刺反思）：团队内部反思什么做得好、什么需要改进
四、冲突管理（Conflict Management）
4.1 冲突的来源
- 优先级竞争（competing priorities）
- 沟通不畅（miscommunication）
- 性格冲突（personality clashes）
- 责任不清（ambiguous responsibilities）
- 资源约束（resource constraints）
如果不管理冲突，后果包括：生产力下降、士气低落、利益相关者不满。
4.2 Thomas-Kilmann 冲突风格模型（TKI）
TKI 模型基于两个维度——果断性（assertiveness） × 合作性（cooperativeness）——划分出五种冲突处理风格：
| 风格 | 果断性 | 合作性 | 适用场景 |
|---|---|---|---|
| Competing（竞争） | 高 | 低 | 紧急情况、需要快速决策 |
| Collaborating（协作） | 高 | 高 | 重要问题、需要双方都满意的方案 |
| Compromising（妥协） | 中 | 中 | 双方都有合理诉求、需要快速达成折中 |
| Avoiding（回避） | 低 | 低 | 问题不重要或时机不对 |
| Accommodating（迁就） | 低 | 高 | 问题对你不重要但对对方很重要 |
深入理解
没有"最好的"冲突处理风格——关键是根据情境选择。但很多人习惯性地使用同一种风格（比如总是 Avoiding 或总是 Competing），这就会出问题。在 IT 团队中，Collaborating 通常是最理想的，但也是最耗时的。Sprint 中时间紧迫时可能需要 Compromising；安全漏洞等紧急情况下可能需要 Competing。理解每种风格的优缺点和适用场景，是成熟的专业人士的标志。
4.3 任务冲突 vs 关系冲突
| 类型 | 焦点 | 性质 |
|---|---|---|
| Task Conflict（认知冲突） | 围绕工作内容的分歧（用什么技术、怎么设计） | 可以是建设性的，推动更好的决策 |
| Relationship Conflict（情感冲突） | 围绕人际关系的矛盾（性格不合、互相不喜欢） | 通常是破坏性的，应尽早化解 |
五、Stakeholder Management（利益相关者管理）
5.1 谁是利益相关者？
利益相关者是受项目影响或对项目有利益/关注的个人、群体或组织。
常见类型：clients（客户）、end users（终端用户）、sponsors（赞助者）、vendors（供应商）、developers（开发者）、testers（测试人员）、regulators（监管者）、executives（高管）。
5.2 为什么利益相关者管理重要？
- 对齐期望与交付物（aligns expectations with deliverables）
- 最小化冲突和范围蔓延（minimizes conflict and scope creep）
- 建立信任和可信度（builds trust and credibility）
5.3 利益相关者分析和映射
分析步骤： 1. Identify（识别）：找出内部和外部所有利益相关者 2. Assess（评估）：了解每个利益相关者的利益、期望和影响力 3. Prioritize（排序）：根据重要性排序 4. Develop（制定策略）：为不同利益相关者制定针对性的互动策略
5.4 Power-Interest Matrix（权力-利益矩阵）
这是最常用的利益相关者分类工具，将利益相关者按权力（Power） 和利益/关注度（Interest） 两个维度分为四个象限：
| 象限 | 策略 | 举例 |
|---|---|---|
| High Power / High Interest | Manage Closely（密切管理）——最优先 | CEO、项目赞助者 |
| High Power / Low Interest | Keep Satisfied（保持满意） | 高管、董事会 |
| Low Power / High Interest | Keep Informed（保持知情） | 终端用户、技术社区 |
| Low Power / Low Interest | Monitor（监控） | 一般公众 |
5.5 Salience Model（显著性模型）
Salience Model 比 Power-Interest Matrix 更精细，基于三个属性：
- Power（权力）：影响项目决策的能力
- Legitimacy（合法性）：与项目关系的正当性
- Urgency（紧迫性）：诉求的时间敏感度
三个属性的组合产生七种利益相关者类型：
| 类型 | 属性组合 | 优先级 |
|---|---|---|
| Definitive（确定型） | Power + Legitimacy + Urgency | 最高优先级 |
| Dominant（主导型） | Power + Legitimacy | 高 |
| Dependent（依赖型） | Legitimacy + Urgency | 中高 |
| Dangerous（危险型） | Power + Urgency | 中高（需警惕） |
| Dormant（休眠型） | Power only | 中 |
| Discretionary（自由裁量型） | Legitimacy only | 中低 |
| Demanding（要求型） | Urgency only | 低 |
深入理解
Power-Interest Matrix 简单直观，适合快速分类；Salience Model 更细致，能识别 Power-Interest Matrix 无法区分的情况。例如，一个只有 Power 和 Urgency 但缺乏 Legitimacy 的利益相关者被归类为 "Dangerous"——他们可能会用非正当手段影响项目。在考试或作业中，如果题目要求"比较两个模型"，关键点在于：Power-Interest Matrix 用两个维度做四象限分类，简单实用；Salience Model 用三个维度做七类分类，更精细但更复杂。
5.6 利益相关者参与策略
五个参与层级（从低到高）：
- Inform（告知）：单向传递信息
- Consult（咨询）：征求意见但最终决策权不在对方
- Involve（参与）：邀请参与过程
- Collaborate（协作）：共同决策
- Empower（授权）：将决策权交给利益相关者
使用多种渠道：报告、演示、Town Hall 会议、仪表盘等。
5.7 利益相关者管理的挑战
- 项目生命周期中需求不断变化（changing requirements）
- 利益相关者群体之间的利益冲突（conflicting interests）
- 文化/语言障碍（全球 IT 团队尤其明显）
- 利益相关者有不切实际的期望（unrealistic expectations）
- 隐藏的利益相关者未被及早识别（hidden stakeholders）
- 对某些群体过度或不足沟通（over- or under-communicating）
5.8 最佳实践
- 尽早开始利益相关者分析并定期更新
- 使用清晰的沟通框架（7Cs、SBAR）
- 管理期望——under-promise, over-deliver（承诺少一点，交付多一点）
- 培养信任和透明（foster trust and transparency）
- 记录决策和协议
- 平衡在不同利益相关者群体上花费的时间（不要忽视"低权力、高利益"的用户）
- 定期互动——评审、反馈循环、演示
六、三者的内在联系
6.1 Communication、Teamwork 和 Stakeholder Management 的关系
这三者是 IT 项目成功的铁三角，不能孤立运作：
- 沟通不好 → 团队协作受损 → 利益相关者失去信任
- 团队协作不好 → 沟通崩溃 → 交付延期
- 利益相关者管理不好 → 即使团队很强、沟通很好，做出来的东西也可能被拒绝（因为不符合利益相关者的真正需求）
6.2 Hospital EMR System Rollout 案例
Lecture 用一个医院电子病历（EMR）系统上线的例子来说明三者如何协同工作：
Step 1: Communication - IT 团队从医生、护士和行政人员那里收集需求 - 使用清晰的书面文档、每日 stand-up 和演示，确保所有人了解进展和挑战
Step 2: Teamwork - 开发者、测试人员和 UX 设计师在 Agile Sprint 中协作 - 依靠有效的团队实践和冲突解决策略
Step 3: Stakeholder Management - 团队使用 Power-Interest Matrix 规划沟通频率 - 定期演示让高权力利益相关者保持参与 - 培训课程帮助终端用户做好采用准备
Result： - 系统按时交付 - 医生和护士顺利采用（因为他们的反馈被听取——好的沟通 + 团队协作） - 管理层满意（因为期望得到了管理——利益相关者管理） - 监管者被纳入合规文档流程
"An IT project succeeds when communication ensures clarity, teamwork drives collaboration, and stakeholder management aligns delivery with expectations."
七、Case Study：移动银行应用程序
7.1 背景
一家软件公司正在为一家大型银行开发移动银行应用程序（mobile banking app）。
利益相关者： - 银行高管（sponsors） - 合规官员（regulators） - 客户支持团队 - IT 开发者 - 终端用户（银行客户）
7.2 问题
开发过程中出现多重冲突： - 外部冲突：高管希望快速发布（faster release），而合规官员要求更多安全检查（more security checks），两者需求矛盾 - 内部冲突：测试人员抱怨开发者不提供足够的文档，而开发者认为截止日期太紧 - 客户沟通不畅：客户抱怨更新不清晰，说"不确定项目到底在发生什么"
7.3 分析问题
End of Lecture Questions（与 Case Study 结合）：
- 识别至少两个沟通失败：客户收到不清晰的更新；开发者和测试人员之间文档不足
- 这个团队处于 Tuckman 模型的哪个阶段？ → Storming 阶段——角色冲突、目标分歧、内部矛盾
- 对开发者和测试人员之间的冲突应用什么策略？ → Collaborating（协作）——双方坐下来讨论，找到既能保证文档质量又不过度增加开发负担的方案
- 将利益相关者放入 Power-Interest Matrix：
- Executives → High Power / High Interest → Manage Closely
- Compliance Officers → High Power / High Interest → Manage Closely
- End Users → Low Power / High Interest → Keep Informed
- 三者如何协同防止延期？ → 用清晰的沟通（SBAR）向客户汇报；用团队协作（Agile retrospective）解决内部冲突；用利益相关者管理（Power-Interest Matrix）优先处理高管和合规的矛盾
八、End of Lecture Questions 梳理
7Cs of Communication 是什么？为什么在 IT 项目中重要？ → Clear、Concise、Concrete、Correct、Coherent、Complete、Courteous。确保信息质量，减少误解和返工。
Tuckman 模型中 Storming 阶段通常发生什么？ → 团队成员出现分歧和冲突，争夺角色和影响力，可能出现不满和紧张。这是正常的，关键在于如何处理。
冲突解决策略有哪些？何时使用？ → TKI 的五种：Competing（紧急时）、Collaborating（重要问题）、Compromising（双方都有道理）、Avoiding（不重要或时机不对）、Accommodating（你不太在意但对方很在意）。
利益相关者管理的两个常见挑战及应对方法？ → ①不切实际的期望 → under-promise, over-deliver ②隐藏的利益相关者 → 尽早做全面的利益相关者识别
比较 Power-Interest Matrix 和 Salience Model → Power-Interest Matrix 用两个维度（Power × Interest）分四象限，简单直观；Salience Model 用三个维度（Power × Legitimacy × Urgency）分七类，更精细。
三者如何协同确保项目成功？ → Communication 保证信息清晰、Teamwork 驱动协作执行、Stakeholder Management 确保做对的事。三者互相依赖、缺一不可。