本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 任务：制定沟通计划
治理模型的一个关键要素是确定谁负责与应用程序所有者沟通，以及如果应用程序所有者不响应，如何上报。在此任务中，您将定义谁负责沟通，确定定期沟通和会议，创建标准沟通模板，并确定在需要上报问题时会发生什么。
在此任务中，您将执行以下操作：
+ [第 1 步：创建沟通小组](#step-communications-team)
+ [第 2 步：制定升级计划](#step-escalation-plan)
+ [第 3 步：定义会议及其节奏](#step-define-meetings)
+ [第 4 步：准备会议演示文稿](#step-prepare-presentations)
+ [第 5 步：为第 1 阶段安排定期会议](#step-schedule-meetings-stage1)
+ [第 6 步：了解变更管理流程](#step-change-management)
## 第 1 步：创建沟通小组
沟通团队是项目治理工作流程的一部分。该团队负责在关键迁移里程碑上与项目利益相关者沟通、安排会议、协调反馈以及确认所需会议参与者的出席情况。沟通团队的活动通常由沟通门控制，你可以在中定义沟通门[任务：定义通信门和日程安排](task-create-communication-gates.md)。
执行以下操作：
1. 确定该团队的适当成员。
1. 指定一名*沟通负责*人。在整个迁移过程中，此人充当单一联系人，负责安排门口会议、协调来自其他工作流程的问题和反馈，以及与所需的参与者确认会议出席情况。
## 第 2 步：制定升级计划
当迁移过程中出现问题时，您必须能够快速解决问题。通过在迁移开始之前定义升级计划，您可以提前向团队提供明确的行动计划，这有助于防止延迟、沮丧或意外。我们建议为每个业务部门指定一个单线程主管。如果应用程序所有者没有参与或回应，则可以上报给该人。
此步骤通常由项目经理和项目发起人完成。在制定上报计划时，您需要定义问题的类型、应将问题上报的情况（称为*触发因素*），并定义升级等级。我们建议不要超过三个等级。对于每个等级，您都应确定*受众*或*回复所有者*，以及受众必须回复的时间。例如，如果第一个上报受众未能在 24 小时内解决问题，则将问题上报给第二级受众，即不同的受众。每次升级时，都会对之前任何等级的受众进行CC。
执行以下操作：
1. 制定升级计划。你可以为此使用专用的项目管理工具，例如 Jira 或 Confluence，也可以在 Microsoft Excel 中创建列表。我们建议记录下来：
+ 对预期或遇到问题的简短描述
+ 触发器
+ 升级和受众等级
+ 每个等级必须对问题做出回应的时间
1. 与工作流负责人和项目发起人举行会议，以审查升级计划。
1. 与整个项目团队共享上报计划，确保所有成员都熟悉上报流程。
1. 将升级计划保存在共享存储库中，并确保所有项目团队成员都可以访问该计划。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/large-migration-governance-playbook/task-communication-plan.html)
## 第 3 步：定义会议及其节奏
在此步骤中，您将确定迁移项目的定期会议，并确定会议频率或*节奏*。记录会议及其节奏可以提高项目的透明度。出现问题时，团队成员可以快速确定合适的会议来解决问题。您应该确定会议名称、频率、核心目标以及所有者和参与者。随着迁移的进行并确定新的会议参与者，您可能需要更新此文档。
在大型迁移项目中，以下定期会议很常见：
1. **指导委员会会议** — 这些会议通常每月举行两次，目的是分享项目状态并解决任何需要执行领导层参与的问题。此次会议的参与者通常包括项目发起人、执行领导层和项目管理办公室的代表。
1. **项目状态审查会议** — 这些会议通常每周举行一次。目的是审查工作流程层面的项目状况，并评估对资源或主题专家的需求。本次会议的参与者包括项目经理、项目利益相关者、工作流所有者和迁移主管。
1. **每日脱口秀** — 这些会议非常简短，每天举行一次。之所以称之为脱口秀，是因为会议时间应足够短，以至于参与者不需要椅子。目的是审查计划中和最近完成的任务，并发现任何问题。在日常短片中，您通常使用可视化任务管理工具，例如看板或甘特图，由您自己决定。[第 1 步：选择项目管理工具](task-project-management.md#step-pm-tool)
1. **基础设施和运营检查点会议** — 这些会议通常每周举行两次。目标是审查迁移进度，审查活跃的问题并决定是否需要上报，跨工作流进行协作，并为下一个冲刺规划资源。本次会议的参与者包括拥有 RACI 定义的迁移活动的技术团队成员。
1. **迁移工作时间** — 此时间保留为公开会议，供应用程序所有者寻求支持或指导。我们建议您每周保持三次工作时间。
我们建议从[项目治理手册](samples/project-governance-playbook-templates.zip)模板中提供的*会议计划模板*（Microsoft Excel 格式）开始。此模板包含一个默认示例，您可以根据自己的项目对其进行自定义。
## 第 4 步：准备会议演示文稿
如中所定义[第 3 步：定义会议及其节奏](#step-define-meetings)，大型迁移需要频繁开会，以协调工作流程、解决问题并确认迁移是否按计划进行。为这些会议定义标准格式和演示文稿有助于与会者建立对会议的一致期望。它还有助于减少每次会议的准备时间。在此步骤中，您将为定期安排的会议创建演示文稿模板。
我们建议从以下模板开始，这些模板包含在[项目治理手册模板](samples/project-governance-playbook-templates.zip)中：
+ *状态报告模板（微软 PowerPoint 格式）*
+ *指导委员会会议模板*（微软 PowerPoint格式）
+ *Wave 研讨会模板*（微软 PowerPoint 格式）
+ *切换准备情况评估模板*（微软 Excel 格式）
执行以下操作：
1. 为您的项目自定义*指导委员会会议模板*。
1. 为您的项目自定义*状态报告模板*。此演示文稿用于项目状态审查会议，这些会议通常每周举行一次。此模板是您在上一步中创建的高管级摘要的更强大版本。
1. 为您的项目自定义 *Wave 研讨会模板*。此演示文稿用于 T-28 和 T-14 提交会议。在 T-28 提交会议中，应用程序所有者承诺顺应潮流，在 T-14 提交会议中，他们重新承诺切换日期。
1. 为您的项目自定义 “*直接转换准备情况” 评估模板*。此演示文稿用于基础架构和操作检查点会议，以审查迁移活动的当前进展。本演示文稿的目的是帮助团队确认进度门已达到，并且应用程序已准备好进行切换。
1. 将这些演示模板存储在共享存储库中，会议所有者可以在其中访问它们。
1. 对于每种类型的会议，定义一个共享存储库，会议所有者可以在其中保存其演示文稿。每次会议结束后，会议所有者应在此存储库中保存其演示文稿和任何其他会议构件的版本，以便会议参与者和项目团队可以参考此信息。例如，项目状态审查会议的存储库将包含在每次会议上提交的状态报告的副本。
## 第 5 步：为第 1 阶段安排定期会议
如果您完成了动员阶段，则此步骤中可能已经安排了一些会议。对于尚未安排的任何会议，请完成此步骤。根据您制定的会议计划[第 3 步：定义会议及其节奏](#step-define-meetings)，会议所有者应安排以下定期会议：
+ 每个工作流的每日脱口秀
+ 财务报告会议
+ 指导委员会会议
+ 项目状态审查
+ 基础设施和运营检查点会议
这些会议一直持续到迁移完成。
## 第 6 步：了解变更管理流程
了解贵组织的变更管理流程对于大型迁移项目的成功至关重要。变更管理流程会影响迁移的时间表和截止日期。您必须了解每项工作负载所需的信息和批准。确保你明白：
+ 提交波浪计划中应用程序和服务器列表的截止日期
+ 获得批准在计划日期移动工作负载所需的标准和信息
+ 任何必须填写的正式流程文件
+ 提交防火墙或域名变更的流程
在发现活动之前，所有迁移负责人都应了解变更管理流程。一些与迁移相关的任务需要批准，团队成员需要了解他们在变更管理流程中的责任。有关培训的更多信息，请参阅《大型迁移*基础手册》*中的[大型迁移所需的培训和技能](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/training-skills.html)。 AWS
## 任务退出标准
完成以下操作后，此任务即告完成：
+ 您已经创建了一个沟通小组。
+ 您已经为所有会议定义了参与者。
+ 您已经制定并批准了升级计划。
+ 根据会议计划中的定义，您已经安排了从第 1 阶段开始的定期会议。
+ 您已经定义了应在每次会议中使用的标准演示文稿。
+ 对于每个会议，您都定义了一个共享存储库，用于捕获所有演示文稿、活动和项目。
+ 所有变更管理流程都被理解并记录在案。