本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 任務：建立通訊計劃
控管模型的關鍵元素是識別誰負責與應用程式擁有者進行通訊，以及如何在應用程式擁有者未回應時向上呈報。在此任務中，您會定義負責通訊的人員、判斷一般通訊和會議的內容、建立標準通訊範本，以及判斷需要呈報問題時會發生的情況。
在此任務中，您會執行下列動作：
+ [步驟 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_tw/prescriptive-guidance/latest/large-migration-governance-playbook/task-communication-plan.html)
## 步驟 3：定義會議及其節奏
在此步驟中，您會識別遷移專案的定期、週期性會議，並建立會議頻率或*節奏*。記錄會議及其節奏可提高專案透明度。當問題發生時，團隊成員可以快速識別適當的會議來解決問題。您應該識別會議的名稱、頻率、核心目標，以及擁有者和參與者。隨著遷移的進行，您可能需要更新此文件，並識別新的會議參與者。
下列定期會議在大型遷移專案中很常見：
1. **指導委員會會議** – 這些會議通常每月舉行兩次，目標是分享專案狀態並解決需要執行領導層參與的任何問題。此會議的參與者通常包括專案發起人、執行領導和專案管理辦公室的代表。
1. **專案狀態審查會議** – 這些會議通常每週舉行一次。目標是在工作流程層級檢閱專案狀態，並評估資源或主題專家的需求。此會議的參與者包括專案經理、專案利益相關者、工作流擁有者和遷移主管。
1. **每日站立** – 這些是每天舉行一次非常簡短的會議。它稱為站立式，因為會議應該夠短，參與者不需要椅子。目的是檢閱計劃和最近完成的任務，並找出任何問題。在日常站立中，您通常會使用視覺化任務管理工具，例如您在 中決定的 Kanban 電路板或 Gantt 圖表[步驟 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)中：
+ *狀態報告範本 (Microsoft PowerPoint 格式）*
+ *指導委員會會議範本* (Microsoft PowerPoint 格式）
+ *Wave 研討會範本* (Microsoft PowerPoint 格式）
+ *切換準備度評估範本 *(Microsoft Excel 格式）
請執行下列操作：
1. 為您的專案自訂*指導委員會會議範本*。
1. 自訂專案*的狀態報告範本*。此簡報用於專案狀態審查會議，通常每週舉行一次。此範本是您在上一個步驟中建立的執行層級摘要更強大的版本。
1. 為您的專案自訂 *Wave 研討會範本*。此簡報用於 T-28 和 T-14 遞交會議。在 T-28 遞交會議中，應用程式擁有者會遞交到波動，而在 T-14 遞交會議中，他們會重新遞交到切換日期。
1. 為您的專案自訂*切換整備評估範本*。此簡報用於基礎設施和操作檢查點會議，以檢閱遷移活動的目前進度。簡報的目的是協助團隊確認已符合進度閘道，且應用程式已準備好進行切換。
1. 將這些簡報範本存放在共用儲存庫中，讓會議擁有者可以存取這些範本。
1. 對於每種類型的會議，定義共用儲存庫，讓會議擁有者可以儲存其簡報。每次會議之後，會議擁有者應該在此儲存庫中儲存其簡報和任何其他會議成品的版本，以便會議出席者和專案團隊可以參考此資訊。例如，專案狀態審查會議的儲存庫將包含每次會議呈現的狀態報告副本。
## 步驟 5：排程階段 1 的定期會議
如果您已完成調動階段，您可能已在此步驟中建立一些會議。針對您尚未排程的任何會議，完成此步驟。根據您在 中制定的會議計畫[步驟 3：定義會議及其節奏](#step-define-meetings)，會議擁有者應排定下列週期性會議：
+ 每個工作流的每日站立
+ 財務報告會議
+ 指導委員會會議
+ 專案狀態檢閱
+ 基礎設施和操作檢查點會議
這些會議會持續進行，直到遷移完成為止。
## 步驟 6：了解變更管理程序
了解組織的變更管理程序對於大型遷移專案的成功至關重要。變更管理程序會影響遷移中的排程和截止日期。您必須了解每個工作負載所需的資訊和核准。請確定您了解：
+ 在波動計畫中提交應用程式和伺服器的截止日期
+ 在計劃日期取得移動工作負載的核准所需的條件和資訊
+ 必須完成的任何正式程序文件
+ 提交防火牆或網域變更的程序
所有遷移潛在客戶都應在探索活動之前了解變更管理程序。有些遷移相關任務需要核准，團隊成員需要了解他們在變更管理程序中的責任。如需訓練的詳細資訊，請參閱 Foundation 手冊中[大型遷移所需的訓練和技能](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/training-skills.html)。 * AWS *
## 任務結束條件
當您完成下列動作時，此任務即完成：
+ 您已建立通訊團隊。
+ 您已定義所有會議的參與者。
+ 您已建立並核准呈報計畫。
+ 您已排定從階段 1 開始的定期會議，如您的會議計畫所定義。
+ 您已定義每個會議應使用的標準簡報。
+ 您為每個會議定義了一個共用儲存庫，用於擷取所有簡報、活動和成品。
+ 了解並記錄所有變更管理程序。