步驟 1：定義通訊閘道步驟 2：建立 T-minus 排程範本步驟 3：為每個閘道建立標準電子郵件範本任務結束條件

任務：定義通訊閘道和排程

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

在此任務中，您會執行下列動作：

步驟 1：定義通訊閘道
步驟 2：建立 T-minus 排程範本
步驟 3：為每個閘道建立標準電子郵件範本

步驟 1：定義通訊閘道

在遷移期間，您會重複每個波或一組波的通訊閘道，直到您遷移所有工作負載且專案完成為止。我們建議至少使用以下通訊閘道。您可以決定為您的專案新增更多適合的閘道。

閘道	大約時間軸	用途	Gate 擁有者	目標對象
閘道 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 小時	確認遷移切換準備	專案經理或通訊團隊	雲端營運團隊、應用程式擁有者、基礎設施團隊
第 7 階段：T-0 切換會議	切換日期	切換並測試應用程式	專案經理和遷移主管	雲端營運團隊
階段 8：Hypercare 期間開始	切換後 1 個工作天	切換已完成且 Hypercare 期間已開始的通知	專案經理或通訊團隊	應用程式擁有者
第 9 階段：Hypercare 期間結束	切換後 4 個工作天	Hypercare 期間已完成的通知	專案經理、通訊團隊或雲端營運團隊	波浪中的應用程式擁有者、通訊主管、雲端營運團隊

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

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

判斷您的專案是否需要額外的通訊閘道。例如，如果您的專案沒有負責與應用程式擁有者促進遷移準備的單執行緒領導者，您可能想要包含額外的通訊閘道，以提醒應用程式擁有者即將進行的活動和到期日。
在共用儲存庫或專案追蹤應用程式中，例如 Jira 或 Confluence，記錄大型遷移專案的通訊閘道。請務必為每個閘道記錄下列屬性（例如，請參閱通訊閘道表)：
- 閘道號碼和名稱
- 閘道發生與工作流程里程碑或切換相關的大約時間軸
- 閘道的目的
- 負責閘道的個人或團隊，稱為閘道擁有者
- 接收通訊或參加大門會議的個人或團隊，稱為受眾
- （選用）閘道擁有者應使用的通訊範本或簡報範本

步驟 2：建立 T-minus 排程範本

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

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

我們建議您從專案控管手冊範本中提供的 T-minus 排程範本 (Microsoft PowerPoint 格式）開始。請執行下列操作：

開啟 T-minus 排程範本。此範本包含重新託管遷移策略的預設 T-minus 排程。
根據您的使用案例修改預設重新託管遷移活動。如需每個遷移策略的活動清單，請參閱您在 Foundation 手冊中針對 AWS 大型遷移建立的負責、負責、諮詢、知情 (RACI) 矩陣。
根據您在中所做的決策修改預設通訊閘道步驟 1：定義通訊閘道。
使用重新託管 T-minus 排程作為起點，為每個遷移策略建立 T-minus 排程，例如 replatform 或 refactor。
與通訊團隊、遷移團隊和雲端營運團隊共用 T-minus 排程。確保所有團隊都保持一致，而且不需要調整。
將完成的 T-minus 排程範本新增至您的啟動簡報和您的波浪研討會簡報。

步驟 3：為每個閘道建立標準電子郵件範本

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

我們建議您從下列範本開始，這些範本包含在專案控管手冊範本中：

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 格式）

任務結束條件

當您完成下列操作時，此任務即完成：

您已定義大型遷移專案的通訊閘道。
您已建立 T-minus 排程範本。
您已與專案利益相關者共用 T-minus 排程範本。
您已將 T-minus 排程範本整合到您的啟動簡報和波浪研討會簡報中。
您已建立閘道電子郵件通訊的標準範本。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

任務：建立通訊計劃

任務：定義專案管理程序和工具