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

# 團隊組織和組成
<a name="team-org"></a>

**Topics**
+ [團隊組織和合成的最佳實務](#bp-team-org)
+ [建立 RACI 矩陣](#raci)
+ [雲端啟用引擎 (CEE)](#cee)

## 團隊組織和合成的最佳實務
<a name="bp-team-org"></a>

大型遷移中的團隊組成會因組織和專案過程中的變更而有所不同。以下是所有大型遷移專案常見的最佳實務：
+ **識別專案層級的單一執行緒技術領導者並避免孤立 – **大型遷移專案通常有多個工作流程和團隊，每個團隊都有不同的任務和預期成果。專案層級的單一執行緒領導者很重要，因為此領導者可確保所有工作流程一起運作並保持連線。這有助於防止孤立和界限。例如，產品組合工作流需要持續將遷移中繼資料傳送至遷移工作流，以支援遷移活動。如果不完全了解所需的遷移中繼資料，產品組合工作流程的輸出可能無法做為遷移工作流程的輸入。單執行緒領導者有助於協調每個工作流的輸入和輸出，以協助遷移有效率地執行。
+ **將所有工作流層級成果與專案層級業務成果保持一致** – 專案層級業務成果應在遷移開始之前傳達給所有工作流領導者。每個工作流程領導者都必須了解其工作流程的角色，並設計其程序以支援專案層級的業務成果。例如，如果專案層級的業務成果在未來 12 個月內結束資料中心，而速度是最重要的因素，則工作流程領導者應執行下列動作：
  + 所有工作流程都應排定重新託管遷移的優先順序、減少手動任務的數量，以及新增自動化以改善速度。
  + 產品組合工作流程應定義標準化模式並限制可自訂模式，以減少設計目標環境所需的時間。
+ **根據專案範圍和階段設計工作流程** – 每個遷移專案都不同，且一個大小並不符合所有項目。我們建議為所有大型遷移專案擁有四個核心工作流：遷移工作流、產品組合工作流、專案控管工作流和基礎工作流。視您的使用案例而定，您可能會決定建立其他支援的工作流。如需工作串流的詳細資訊，請參閱[大型遷移中的工作串流](workstreams.md)。例如，如果您尚未在調動階段設計安全護欄，您需要建立安全與合規工作流，以便在開始遷移之前定義安全與合規要求。如需有關在調動階段中建置安全護欄的詳細資訊，請參閱*在調動您的組織以加速大規模遷移*中[的安全性、風險和合規性](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/security-risk-and-compliance.html)。
+ **在遷移之前讓應用程式團隊參與** – 大型遷移不只是 IT 基礎設施專案，它會改變您企業的操作模式。儘早讓應用程式團隊參與，並將應用程式擁有者嵌入大型遷移工作流程，對於大型遷移專案的成功至關重要。例如，在產品組合評估期間，提早安排與應用程式擁有者的會議，讓他們可以參與深入探索，並協助設計其應用程式的目標狀態 AWS。
+ **根據工作流和業務成果來決定團隊大小** – 您的預期業務成果和遷移策略可推動每個團隊的大小，該團隊由稱為 Pod 的較小單位組成。在每個工作流中，您會為每個遷移策略定義團隊，然後將這些團隊分成 Pod。例如，如果重新託管是您的主要遷移策略，則您應該有一個重新託管遷移團隊，該團隊由包含 3-5 個人的 Pod 組成。以尖峰速度操作時，遷移團隊中 4-5 人的 Pod 通常每週可以重新託管最多 50 個伺服器。這大約是每月 200 個 伺服器或每年 2，500 個 伺服器。如果您的目標是每週重新託管 100 個 伺服器，您應該在重新託管遷移團隊中建立兩個 4-5 人的 Pod。如果您目標是 每週少於 50 個，您可以將遷移 Pod 的大小縮減為 3 個人。平台遷移的成本通常高於重新託管，相同大小的 Pod 每週最多可以遷移 20 個 伺服器。產品組合工作流通常為遷移工作流大小的一半。您可以在每個工作流程中建立其他團隊和 Pod，以支援每個遷移策略。這些建議假設您的遷移資源熟練，不需要進行重大訓練。下表範例說明如何將遷移和產品組合工作流分割為團隊和 Pod，以用於重新託管和轉換遷移策略。下列範例假設您需要每週遷移 120 個 伺服器 (100 個 主機 \+ 20 個平台） 或每年 6，000 個 伺服器。此範例是最大速度。建議您規劃其他資源，以協助防止延遲。    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html)
+ **在早期階段建置控管模型** – 大型遷移通常涉及許多人員，包括來自您公司、第三方軟體供應商、系統整合商或外部顧問的人員。您的專案可能包含來自 的代表 AWS，例如您的客戶團隊、支援工程師或 AWS Professional Services 的專家。您的交付模型取決於您的專案範圍，以及您與誰合作交付專案。例如，您的專案可能包含 AWS 或 系統整合商，或者您可以同時包含兩者。請務必儘早建置控管模型，並建立可清楚定義角色和責任的 RACI 矩陣。作為建議，我們也建議您在組織中建立 Cloud Enablement Engine (CEE)，也稱為 *Cloud Center of Excellence*，包括來自各方的表示。CEE 的主要目的是將組織從內部部署操作模型轉換為雲端操作模型。這個集中式團隊對於大型遷移的成功至關重要，因為它可以管理關係、做出關鍵決策，以及在整個專案中處理呈報。本指南稍後會更詳細地討論 CEE。

## 建立 RACI 矩陣
<a name="raci"></a>

大型遷移專案通常涉及許多人員，因此建置控管模型對於管理專案至關重要。控管模型的其中一個關鍵元件是 *RACI 矩陣*，用於定義涉及大型遷移的所有各方的角色和責任。名稱 RACI 矩陣衍生自矩陣中定義的四種責任類型：
+ **負責 (R)** – 此角色負責執行工作以完成任務。
+ **負責任 (A)** – 此角色負責確保任務已完成。此角色也負責確保符合先決條件，並將任務委派給負責的人員。
+ 已**諮詢 (C)** – 應諮詢此角色以取得有關任務的意見或專業知識。視任務而定，可能不需要此責任類型。
+ **通知 (I)** – 此角色應保持在任務進度的最新狀態，並在任務完成時收到通知。

由於大型遷移的複雜性，我們不建議使用單一 RACI 矩陣來記錄大型遷移中的每個任務。多層 RACI 矩陣是一種更易於存取的方法。首先建立高階 RACI 矩陣，然後在每個區段中新增更多詳細資訊，以建置詳細的矩陣。建置詳細的 RACI 矩陣不是一次性的方法。隨著產品組合的進展，您需要建立新的矩陣或將更多詳細資訊新增至現有矩陣，並探索更多遷移策略和模式。

在[基礎手冊範本](samples/foundation-playbook-templates.zip)中，您可以使用 RACI 範本 (Microsoft Excel 格式） 做為建置自己高階且詳細 RACI 矩陣的起點。此範本包含兩個詳細 RACI 矩陣的範例，一個用於重新託管遷移，另一個用於轉換遷移。這些範例中的任務僅用於範例用途，您應該根據您的使用案例自訂這些範例。

### 建置高階 RACI 矩陣
<a name="raci-matrix"></a>

開始建置高階 RACI 矩陣之前，您需要備妥下列資訊：
+ **誰是涉及此遷移的高階各方？**識別將涉及此專案的任何合作夥伴或顧問，例如 AWS Professional 服務或系統整合商。考慮目前 IT 基礎設施的任何部分是否由外部合作夥伴管理。以下是高階各方的範例：
  + 您的組織
  + AWS 專業服務
  + 系統整合商
+ **遷移中的工作流有哪些？** 如需詳細資訊，請參閱[大型遷移中的 Workstreams](workstreams.md)。您至少應該有四個核心工作流，而且您可以視需要為專案新增支援工作流。
+ **遷移中的高階任務有哪些？** 建立遷移中高階任務的清單。以下是高階任務的範例：
  + 建置 AWS 登陸區域
  + 執行產品組合評估並收集遷移中繼資料
  + 執行重新託管、轉換或重新放置遷移
  + 執行應用程式測試和切換
  + 執行專案管理和管理任務

執行下列動作來建置您的高階 RACI 矩陣：

1. 在[基礎手冊範本](samples/foundation-playbook-templates.zip)中，開啟 *RACI 範本* (Microsoft Excel 格式）。

1. 在**高階 RACI** 索引標籤的第一列中，輸入您的組織名稱和您識別的任何合作夥伴。

1. 在第一欄中，輸入您識別的高階任務和工作流程。

1. 在矩陣中，判斷哪些各方負責每個任務，如下所示：
   + 如果一方**負責**完成任務，請輸入 **R**。
   + 如果一方**負責**任務，請輸入 **A**。
   + 如果應該**向一方諮詢**任務，請輸入 **C**。
   + 如果應**通知**一方有關任務的資訊，請輸入 **I**。

下表是高階 RACI 矩陣的範例。


| 任務 | 您的組織 | 合作夥伴 A | 合作夥伴 B | 合作夥伴 C | 
| --- | --- | --- | --- | --- | 
| 建置 AWS 登陸區域 | R/C | A | I | I | 
| 執行產品組合評估和波動規劃 | R/C | A | I | I | 
| 執行主機遷移活動 | C | C | R/A | I | 
| 執行轉換遷移活動 | C | C | I | R/A | 
| 專案管理和管理 | R/C | A | I | I | 
| 應用程式變更和測試 | C | R/A | C | C | 
| 雲端操作 | I | C | R/A | I | 

### 建置詳細的 RACI 矩陣
<a name="raci-details"></a>

 建立高階 RACI 矩陣後，下一步是為每個高階任務建立詳細的 RACI，並進一步精簡任務、各方和擁有權。開始建置詳細矩陣之前，您需要備妥下列資訊：
+ **遷移中的詳細任務有哪些？** 準備好大型遷移專案的 Runbook 和任務清單後，這些 Runbook 中的程序和詳細資訊會形成 RACI 矩陣的詳細圖層。例如，對於重新託管遷移，詳細任務可能包括安裝複寫代理程式、驗證複寫，以及啟動測試執行個體以進行開機測試。如果您尚未這麼做，請依照下列手冊中的指示建立這些文件：
  + [適用於 AWS 大型遷移的產品組合手冊](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-portfolio-playbook/)
  + [AWS 大型遷移的遷移手冊](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/)
+ **每個工作流和每個高層派對組成哪些較小的團隊？** 例如，組織中的團隊可能包括應用程式團隊、基礎設施團隊、營運團隊、聯網團隊或專案管理辦公室。

執行下列動作來建置詳細的 RACI 矩陣：

1. 開啟您的高階 RACI 矩陣。

1. 建立**詳細 RACI （範本）** 試算表的副本。

1. 為您在 中識別的高階任務命名複製的試算表[建置高階 RACI 矩陣](#raci-matrix)。

1. 在第一列中，輸入涉及此高階任務的團隊名稱。

1. 在第一欄中，輸入您為此高階任務識別的詳細任務。您可以將詳細任務分組為邏輯序列群組，這有助於讀者導覽矩陣。

1. 在矩陣中，判斷哪些團隊負責每個任務，如下所示：
   + 如果團隊**負責**完成任務，請輸入 *R*。
   + 如果團隊**負責**完成任務，請輸入 *A*。
   + 如果應該**向團隊諮詢**任務，請輸入 *C*。
   + 如果團隊應收到任務的相關**通知**，請輸入 *I*。

1. 對於每個詳細任務，請確認只有一個團隊負責，而只有一個團隊負責。如果多個團隊負責或負責，這可能表示任務未明確定義或沒有明確的擁有權。

1. 與已識別的團隊共用詳細的 RACI 矩陣，並確認所有團隊都熟悉其角色和責任。

1. 針對您在 中識別的每個高階任務重複此程序[建置高階 RACI 矩陣](#raci-matrix)。

如需詳細 RACI 矩陣的範例，請參閱 RACI 範本中的 **Rehost RACI** and **Replatform** RACI 試算表，可在[基礎手冊附件](samples/foundation-playbook-templates.zip)中找到。 **

## 雲端啟用引擎 (CEE)
<a name="cee"></a>

### 使用 CEE 的最佳實務
<a name="best-practices-cee"></a>

CEE 的目的是將 IT 組織從內部部署操作模型轉換為雲端操作模型，並負責引導組織完成組織和文化變革。根據最佳實務，建議您為大型遷移建立 CEE。CEE 的明確定義基礎程序和護欄可協助您達到大型遷移所需的規模和速度。如需設定 CEE 的資訊，請參閱[雲端啟用引擎：實務指南](https://d1.awsstatic.com/whitepapers/cloud-enablement-engine-practical-guide.pdf)。以下是為大型遷移專案建立 CEE 的其他建議和最佳實務：
+ CEE 團隊應由具有下列品質的跨職能領導者組成：
  + 擁有深入的機構知識
  + 擁有強大、長期的內部關係
  + 對大型遷移的進度和成功充滿興趣
  + 好奇且想要學習
  + 主要或僅專注於遷移
+ CEE 團隊應該是先前合作過的人，以及可提供新洞見的新進人員的混合。
+ CEE 團隊應該對遷移目標擁有強大的執行支援和一致性。
+ 確定 CEE 團隊的目標專屬於大型遷移。
+ 定期舉行公開會議，提供問答的機會、示範雲端服務和架構，並分享成功遷移和其他成功的更新。
+ CEE 團隊應有權對大型遷移專案做出關鍵決策。

### 大型遷移的一般 CEE 角色和責任
<a name="cee-roles"></a>

下表提供大型遷移 CEE 團隊中的角色，並說明每個角色的一般任務和責任。您團隊的實際組成及其責任可能會因您的使用案例、範圍和業務目標而有所不同。


| 角色 | 任務和責任 | 
| --- | --- | 
| 執行發起人 |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html)  | 
| 企業架構師或專案層級技術主管 |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html)  | 
| 專案管理辦公室主管 |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html)  | 
| 遷移潛在客戶 |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html)  | 
| 產品組合主管 |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html)  | 
| 雲端操作主管 |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html)  | 
| 應用程式團隊領導者 |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html)  | 
| 網路和基礎設施主管 |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html)  | 
| 授權主管 |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html)  | 
| 安全與合規主管 |  [See the AWS documentation website for more details](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html)  |