本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 任務：定義通訊閘道和排程
<a name="task-create-communication-gates"></a>

在大型遷移專案的第 2 階段中，產品組合工作流程正在積極規劃波浪，而遷移工作流程正在遷移這些波浪。專案控管工作流程會監督這些活動，並協助引導波浪通過通訊閘道。當您正式向利益相關者傳達持續的波動活動和狀態時，*通訊閘道*是一個接觸點。在每個閘道上，指定的閘道擁有者會通知指定的對象有關波動狀態，並提醒應用程式擁有者即將進行的活動或會議。Gates 通常對應於遷移里程碑，而定義通訊閘道可最大限度地提高所有專案利益相關者的透明度。您可以個別移動波浪通過閘道，也可以將波浪分組在一起。

在此任務中，您會執行下列動作：
+ [步驟 1：定義通訊閘道](#step-communication-gates)
+ [步驟 2：建立 T-minus 排程範本](#step-create-tminus-schedule)
+ [步驟 3：為每個閘道建立標準電子郵件範本](#step-email-templates)

## 步驟 1：定義通訊閘道
<a name="step-communication-gates"></a>

在遷移期間，您會針對每一波或一組波重複通訊閘道，直到您遷移所有工作負載且專案完成為止。我們建議至少使用下列通訊閘道。您可以決定為您的專案新增更多適合您專案的閘道。<a name="communication-gate-table"></a>


****  

| 閘道 | 大約時間軸 | 用途 | 閘道擁有者 | 目標對象 | 
| --- | --- | --- | --- | --- | 
| 閘道 1：建立 T-minus 排程 | 波動計畫完成之前 | 每個閘道的排程日期 | 專案經理或通訊團隊 | 應用程式擁有者、通訊主管、遷移主管 | 
| 第 2 階段：T-28 遞交會議 | 切換前 4 週 | 與應用程式擁有者開始波動  | 專案經理或通訊團隊 | 應用程式擁有者、通訊主管、遷移主管 | 
| 閘道 3：T-21 通訊 | 切換前 3 週 | 提醒切換排程在 21 天內發生 | 專案經理或通訊團隊 | 應用程式擁有者、通訊主管 | 
| 第 4 階段：T-14 檢查點會議 | 切換前 2 週 | 檢閱排程並評估整備任務的進度  | 專案經理和遷移主管 | 應用程式擁有者、通訊主管、遷移主管 | 
| 閘道 5：T-7 通訊 | 切換前 1 週 | 提醒切換排程在 7 天內發生 | 通訊團隊 | 應用程式擁有者、營運團隊 | 
| 第 6 階段：T-1 go 或 no-go 會議 | 切換前 24-48 小時 | 確認遷移切換準備 | 專案經理或通訊團隊 | 雲端營運團隊、應用程式擁有者、基礎設施團隊  | 
| Gate 7：T-0 切換會議 | 切換日期 | 切換並測試應用程式 | 專案經理和遷移主管 | 雲端營運團隊 | 
| 階段 8：Hypercare 期間開始 | 切換後 1 個工作日 | 切換已完成且 Hypercare 期間已開始的通知 | 專案經理或通訊團隊 | 應用程式擁有者 | 
| 階段 9：Hypercare 期間結束 | 切換後 4 個工作天 | Hypercare 期間已完成的通知 | 專案經理、通訊團隊或雲端營運團隊 | 波浪中的應用程式擁有者、通訊主管、雲端營運團隊 | 

下圖顯示產品組合和遷移工作流程中這些通訊閘道的序列。閘道 1 發生在波動規劃期間，閘道 2–6 發生在遷移期間，閘道 7 是切換會議，而閘道 8–9 發生在超級護理期間。閘道 2–6 的命名格式為 `T-#`。`T` 是指剩餘的時間，而 `#`是排程切換日期之前剩餘的天數。

![\[遷移和產品組合工作流程中的通訊閘道順序\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-governance-playbook/images/gates.png)


定義大型遷移專案的通訊閘道，如下所示：

1. 判斷您的專案是否需要額外的通訊閘道。例如，如果您的專案沒有負責促進應用程式擁有者遷移準備的單一執行緒領導者，您可能想要包含額外的通訊閘道，以提醒應用程式擁有者即將進行的活動和到期日。

1. 在共用儲存庫或專案追蹤應用程式中，例如 Jira 或 Confluence，記錄大型遷移專案的通訊閘道。請務必為每個閘道記錄下列屬性 （例如，請參閱[通訊閘道資料表](#communication-gate-table))：
   + 閘道號碼和名稱
   + 閘道發生與工作流程里程碑或切換相關的大約時間軸
   + 閘道的用途
   + 負責閘道的個人或團隊，稱為*閘道擁有者*
   + 收到通訊或參加大門會議的個人或團隊，稱為*受眾*
   + （選用） 閘道擁有者應使用的通訊範本或簡報範本

## 步驟 2：建立 T-minus 排程範本
<a name="step-create-tminus-schedule"></a>

*T-minus 排程*是一種視覺化方式，可代表每個波動需要完成的所有高階遷移活動。它涵蓋從波浪規劃結束到 Hypercare 期間結束之間的期間。由於高階遷移活動會根據遷移策略而有所不同，因此您需要每個遷移策略的 T-minus 排程範本。您在啟動會議和 T-28 和 T-14 遞交會議分享 T-minus 排程。

一般而言，您可以透過從切換日期返回來建立 T-minus 排程。您可以將活動組織成遷移里程碑，並在專案管理工具中單獨追蹤詳細任務。T-minus 排程也會反白顯示您在 中定義的通訊閘道[步驟 1：定義通訊閘道](#step-communication-gates)。

我們建議您從[專案控管手冊](samples/project-governance-playbook-templates.zip)*範本中提供的 T-minus 排程*範本 (Microsoft PowerPoint 格式） 開始。請執行下列操作：

1. 開啟 *T-minus 排程範本*。此範本包含主機遷移策略的預設 T-minus 排程。

1. 根據您的使用案例修改預設重新託管遷移活動。如需每個遷移策略的活動清單，請參閱您在 [Foundation 手冊中為 AWS 大型遷移](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/)建立的負責、負責、諮詢、明智 (RACI) 矩陣。

1. 根據您在 中所做的決策修改預設通訊閘道[步驟 1：定義通訊閘道](#step-communication-gates)。

1. 使用重新託管 T-minus 排程做為起點，為每個遷移策略建立 T-minus 排程，例如轉換或重構。

1. 與通訊團隊、遷移團隊和雲端營運團隊共用 T-minus 排程。確保所有團隊都保持一致，而且不需要調整。

1. 將完成的 T-minus 排程範本新增至您的啟動簡報和波動研討會簡報。

## 步驟 3：為每個閘道建立標準電子郵件範本
<a name="step-email-templates"></a>

為每個您將在每個通訊閘道傳送給應用程式擁有者的電子郵件通訊建立範本。這些電子郵件應包含有關波動中應用程式的基本資訊、通知應用程式擁有者波動狀態，以及提醒利益相關者任何即將到來的到期日和會議。

我們建議您從以下範本開始，這些範本包含在[專案控管手冊範本](samples/project-governance-playbook-templates.zip)中：
+ *T-28 的通訊範本* (Microsoft Word 格式）
+ *T-21 的通訊範本* (Microsoft Word 格式）
+ *T-14 的通訊範本* (Microsoft Word 格式）
+ *T-7 的通訊範本* (Microsoft Word 格式）
+ *T-1 的通訊範本* (Microsoft Word 格式）
+ *T-0 的通訊範本* (Microsoft Word 格式）
+ *切換完成的通訊範本* (Microsoft Word 格式）
+ *Hypercare 的通訊範本完成* (Microsoft Word 格式） 

## 任務結束條件
<a name="task-create-gates-exit-criteria"></a>

當您完成下列動作時，此任務即完成：
+ 您已定義大型遷移專案的通訊閘道。
+ 您已建立 T-minus 排程範本。
+ 您已與專案利益相關者共用 T-minus 排程範本。
+ 您已將 T-minus 排程範本整合到您的啟動簡報和波動研討會簡報中。
+ 您已為閘道電子郵件通訊建立標準範本。