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

# 任務：定義專案管理程序和工具
<a name="task-project-management"></a>

任何大型遷移專案都需要成熟的管理程序和工具。透過大型遷移，您可以分享資訊、追蹤效能指標、識別正確的會議參與者，以及將任務指派給擁有者。在此任務中，您會記錄金鑰遷移任務和擁有者、判斷遷移的關鍵效能指標 (KPIs)，並決定如何測量、追蹤預算，以及開發工具來管理風險和追蹤決策。

除非另有說明，否則此任務中的許多步驟會同時執行。一般而言，您會在啟動會議之前或之後完成這些步驟。

在此任務中，您會執行下列動作：
+ [步驟 1：選取專案管理工具](#step-pm-tool)
+ [步驟 2：驗證所有遷移活動的角色和責任](#step-validate-roles)
+ [步驟 3：建立利益追蹤辦公室](#step-benefit-tracking-office)
+ [步驟 4：建立專案摘要儀表板](#step-dashboard)
+ [步驟 5：建立財務報告程序](#step-financial-reporting)
+ [步驟 6：決定如何管理和擴展資源](#step-resource-plan)
+ [步驟 7：建立決策日誌](#step-decision-log)
+ [步驟 8：建立 RAID 日誌](#step-raid-log)

## 步驟 1：選取專案管理工具
<a name="step-pm-tool"></a>

在此步驟中，您會建立要用於追蹤進度的工具。您可以選擇使用 Jira 或 Confluence 等軟體解決方案、在 Microsoft Excel 中建置您自己的儀表板，或使用這些工具的組合。選取或建置專案管理工具時，請考慮下列最佳實務：
+ 對於追蹤任務和追蹤進度，我們建議使用視覺化管理工具，例如 Kanban 電路板或 Gantt 圖表，這些工具通常在專案管理應用程式中提供。視覺化管理工具在每日站立會議上特別有效，用於檢閱目前的任務和波動進度。
+ 如果您要選取專案管理應用程式，請考慮是否要在專案管理工具中輸入計劃和程序 （例如呈報計劃、決策日誌或 RAID 日誌），並確認它具有您想要的功能。
+ 請務必讓專案發起人、執行主管、專案經理和外部利益相關者 （如果有的話） 與所選工具保持一致。

如需如何使用這些工具的詳細資訊，請參閱 [建立敏捷的方法](managing-large-migration.md#establish-agile-approach)。

## 步驟 2：驗證所有遷移活動的角色和責任
<a name="step-validate-roles"></a>

在適用於[AWS 大型遷移的 Foundation 手冊](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/)中，您為大型遷移專案中的每個遷移策略和高階任務建立了詳細的 RACI 矩陣。RACI 矩陣是責任指派工具，名稱衍生自矩陣中定義的四種責任類型：負責人 (R)、責任 (A)、諮詢 (C) 和知情 (I)。建議您使用此矩陣格式，以在所有遷移活動中調整角色和責任。此矩陣可以將現場團隊與遠端團隊或外部合作夥伴保持一致。在此步驟中，您會驗證矩陣是否正確，並與專案團隊一起檢閱。

為了為您的組織量身打造 RACI 任務，建議您考慮下列事項：
+ 了解變更管理程序、這些程序所需的前置時間，以及核准變更所涉及的角色。如需詳細資訊，請參閱[步驟 6：了解變更管理程序](task-communication-plan.md#step-change-management)。
+ 在開始遷移之前，請確定您已審核備份和災難復原策略，並與遷移團隊共用此策略。如果您發現策略中的差距，我們建議您使用整合式雲端服務，例如 AWS Backup 或 CloudEndure 災難復原。

請執行下列操作：

1. 如果您尚未這麼做，請根據 [Foundation 手冊中適用於 AWS 大型遷移](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/)的說明，為每個高階任務建立 RACI 矩陣。

1. 與每個矩陣中的個別團隊一起檢閱矩陣。確認已代表所有詳細任務，且團隊熟悉其責任。

1. 當您識別新的遷移策略或支援任務時，請在整個遷移過程中更新和建立新的矩陣。

## 步驟 3：建立利益追蹤辦公室
<a name="step-benefit-tracking-office"></a>

此團隊是一小組個人，負責根據關鍵績效指標 (KPIs評估遷移。此團隊會根據排程評估遷移是否正在進行，並且可以處理任何延遲或阻礙進度的問題。此團隊會在每週或每兩週專案狀態會議之外開會。

在每次會議中，此團隊通常會檢閱並回答下列問題：
+ 遷移的目前狀態為何？
+ 我們是否如期實現目標成果？
+ 我們是否準確測量效能？
+ 我們是否需要進行任何調整，以加速遷移？ 

如果利益追蹤辦公室判斷遷移未達到所需的速度，則此團隊應建議調整程序、資源或通訊計畫。

執行下列動作，為您的大型遷移建立利益追蹤辦公室：

1. 識別適當的參與者。此團隊的典型成員包括專案發起人、專案經理、遷移主管，以及具有範圍內工作負載的每個業務單位的授權代表。

1. 為利益追蹤辦公室建立定期會議節奏。我們建議此團隊每兩週開會一次。

1. 與專案發起人定義大型遷移的定性和量化 KPIs，並收集執行領導層的意見。利益追蹤辦公室會根據您的 KPIs評估遷移進度。KPIs的範例包括：
   + （量化） 相較於計劃遷移的實際伺服器數量
   + （量化） 相較於計劃已解除委任的伺服器數量
   + （定性） 檢閱問卷意見回饋和行動計劃 
   + （定性） 為回應問卷意見回饋而採取的修正步驟

## 步驟 4：建立專案摘要儀表板
<a name="step-dashboard"></a>

專案團隊必須共同與關鍵專案利益相關者合作，以開發可清楚傳達遷移進度的儀表板。您的專案摘要儀表板應該在單一頁面上執行下列動作：
+ 量化整個專案的整體已完成和剩餘工作負載
+ 反映最近完成波的效能 （計劃和實際）
+ 顯示近期波動的預期工作負載 （計劃） 

我們建議從*專案摘要儀表板範本* (Microsoft PowerPoint 格式） 開始，可在[專案控管手冊範本](samples/project-governance-playbook-templates.zip)中找到。請執行下列操作：

1. 視需要為您的專案修改範本。我們建議代表將伺服器配置到每個遷移策略。提供的範本包含重新託管和轉換遷移策略。

1. 與專案利益相關者一起檢閱您的專案摘要儀表板，包括執行領導，並確保所有利益相關者都保持一致，並了解如何使用和存取儀表板。

1. 將儀表板儲存在共用儲存庫中。所有利益相關者都應能夠視需要自行存取此資訊。

## 步驟 5：建立財務報告程序
<a name="step-financial-reporting"></a>

一般而言，您會與專案狀態報告分開追蹤財務報告，因為您想要將其提供給更有限的對象。財務報告應包含*實際成本*，即截至目前為止產生的成本，以及*預測成本*，即專案剩餘部分的預期成本。您可以分別追蹤內部和外部資源成本。若要評估實際和預測的內部資源成本，您可以使用內部時間報告和資源計劃。對於外部資源，您應該要求合作夥伴或顧問提供實際和預測成本。

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

1. 確定應該接收此財務報告的利益相關者。

1. 決定此財務報告是否會在會議或透過電子郵件共用。

1. 視需要為您的專案修改範本。

1. 與執行領導團隊或專案發起人檢閱您的財務報告，以確認格式和內容的一致性。

1. 與利益相關者一起判斷此報告更新和檢閱的頻率。

1. 決定您將儲存此財務報告的位置。由於其中包含敏感的財務資訊，我們不建議將此範本與其餘專案文件一起儲存在共用儲存庫中。

## 步驟 6：決定如何管理和擴展資源
<a name="step-resource-plan"></a>

當專案進行時，有效管理資源對於大型遷移工作至關重要。當專案從初始化階段移至實作階段時，遷移團隊必須向上擴展，以支援遷移波紋。同時，視剩餘的探索活動而定，探索團隊可能可以開始縮減規模。在此步驟中，您會映射資源管理和擴展計畫，以提高效率。此步驟通常由專案經理和工作流程主管執行。定義計畫後，您會在整個專案中持續稽核，以判斷是否需要計畫中的所有資源。例如，建置遷移管道或larger-than-anticipated波浪的延遲可能會影響資源計劃。

每個大型遷移的資源計劃都不同，通常由專案獨有的因素決定。常見因素包括專案預算、專案團隊的組織方式、探索活動完成的速度、產品組合分配給每個遷移策略的方式 （例如重構、重新託管或轉換），以及組織中變更管理程序所需的時間。

規劃資源時，請考慮您產品組合的遷移策略，以及這些策略如何影響您的遷移和產品組合團隊。例如，重新託管是大型遷移的常見策略，因為它的複雜性很低。幾乎每個大型遷移專案都有至少 4-5 個個人的主機遷移 Pod。如果您計劃包含高複雜度遷移策略，例如轉換或重構，您應該為這些策略建立遷移團隊 Pod，並在資源計劃中包含額外的遷移和產品組合團隊資源。如需工作流、團隊結構以及每個 Pod 需要多少人的詳細資訊，請參閱 Foundation 手冊中的[團隊組織和組成](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html)以進行大型遷移。 * AWS *

此外，SAP 等特殊工作負載的存在也需要由具有這些工作負載經驗的個人組成的獨立專業團隊。如需特殊化工作負載的詳細資訊，請參閱 [AWS Migration Acceleration Program](https://aws.amazon.com/migration-acceleration-program/) 中的 *MAP 特殊化工作負載*。

請執行下列操作：

1. 定義支援專案控管所需的資源。典型的資源包括用於交付管理和監督的計劃管理員、專案經理和支援專案經理。

1. 定義支援遷移工具所需的資源。典型的資源包括雲端架構師或外部顧問。

1. 如果您的專案包含遷移特殊工作負載，例如 ERP 系統，請定義支援該工作負載所需的資源。特殊工作負載的一般資源包括：
   + 專案經理
   + 架構主管
   + 架構工程師
   + DevOps 工程師
   + 包含下列項目的專用遷移 Pod：
     + 功能主題專家 (SME)
     + 測試專家 

1. 定義您需要支援每個遷移策略的資源，例如 Rehost。典型的資源包括：
   + 專案負責人
   + 運算、儲存和聯網的架構師和工程師
   + 測試專家 

1. 在專案的各個階段配置支援這些團隊所需的資源數量，包括探索、初始化和實作。當您精簡程序時，請考慮遷移的加速，並考慮如何在階段或專案結束時縮減資源。

## 步驟 7：建立決策日誌
<a name="step-decision-log"></a>

在整個大型遷移過程中， 領導 會做出決策，以解決出現的任何問題。由於大型遷移專案的大小和範圍，每次決策時，專案管理員都無法存在。工作流主管負責記錄影響其工作流的決策。專案經理負責審核決策，並在專案狀態審核會議上呈現最近的決策。

此步驟通常由專案經理執行。在此步驟中，您會在共用儲存庫中建立決策日誌，並確認工作流程主管了解他們記錄決策的責任。如有必要，請使用呈報計畫來協助及時做出決策。如需詳細資訊，請參閱[步驟 2：建立呈報計畫](task-communication-plan.md#step-escalation-plan)。確認所有團隊成員都了解可在每個層級做出的決策類型。

請執行下列操作：

1. 建立決策日誌。您可以為此使用專用專案管理工具，例如 Jira 或 Confluence，也可以在 Microsoft Excel 中建立清單。我們建議您記錄：
   + 決策的簡短描述
   + 狀態
   + 決策如何影響專案
   + 考慮的替代選項
   + 誰做出決策
   + 做出決策的日期 

1. 與工作流主管進行會議，以檢閱決策日誌並訓練他們如何使用它。請務必建立記錄決策的文化。

1. 將決策日誌儲存在共用儲存庫中，並確保所有工作流程主管都可以存取它。

1. 在每次專案狀態審查會議之前，請檢閱日誌中自上次會議以來所做的任何決策，並將這些決策納入您的*專案狀態報告簡報*中。這可確保在專案過程中做出的所有決策的專案層級透明度。

## 步驟 8：建立 RAID 日誌
<a name="step-raid-log"></a>

與決策日誌類似，您應該在稱為風險*、動作、問題和相依性 (RAID) 日誌的專案管理工具中追蹤風險和問題*。無論您規劃大型遷移的徹底程度為何，都會發生問題，而且您會識別專案的一些風險。透過識別和記錄風險和問題，您可以為專案提供透明度，並建立控制和監控潛在問題的程序，將對專案的影響降至最低。

請執行下列操作：

1. 建立 RAID 日誌。您可以為此使用專用專案管理工具，例如 Jira 或 Confluence，也可以在 Microsoft Excel 中建立清單。我們建議您記錄：
   + 類型 （風險、動作、問題或相依性） 
   + 項目的簡短描述 
   + 開啟日期 
   + Probability (可能性) 
   + 影響 
   + 嚴重性分數，計算方式為將機率和影響相乘 
   + Owner 

1. 與工作流主管進行會議，以檢閱 RAID 日誌並訓練他們如何使用它。請務必建立記錄風險和問題的文化。

1. 將 RAID 日誌儲存在共用儲存庫中，並確認所有工作流主管都可以存取它。

1. 在每次專案狀態審查會議之前，請檢閱日誌中自上次會議以來發現的任何風險和問題，並將這些風險和問題納入您的*專案狀態報告簡報*中。這可確保所有風險和問題的專案層級透明度。

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

當您完成下列動作時，此任務即完成：
+ 您已在 Microsoft Excel 中選取一或多個專案管理工具，例如 Jira、Confluence 或儀表板和清單。
+ 您已為每個遷移策略 （例如重新託管） 和大型遷移專案中的每個高階任務建立並驗證詳細的 RACI 矩陣。
+ 您已建立利益追蹤辦公室，為他們的會議建立定期節奏，並為會議建立所有權和報告範本。
+ 內部利益相關者符合財務報告的處理方式。您已建立正式節奏來檢閱財務報告、識別收件人，以及決定誰應該存取財務報告。
+ 您已為專案建立資源計劃。
+ 您已在共用儲存庫中建立決策日誌，而且所有團隊負責人都有權進行更新。
+ 您已定義 RAID 日誌的位置和範本。您已建立維護日誌和排定問題的優先順序的程序。RAID 日誌中的Week-to-week變更摘要於狀態報告中。
+ 所有專案利益相關者都與您如何在專案摘要儀表板中傳達高階專案狀態保持一致。