任務：定義專案管理程序和工具 - AWS 方案指引
步驟 1：選取專案管理工具步驟 2：驗證角色和責任步驟 3：建立利益追蹤辦公室步驟 4：建立專案摘要儀表板步驟 5：建立財務報告程序步驟 6：建立資源計劃步驟 7：建立決策日誌步驟 8：建立 RAID 日誌任務結束條件

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

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

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

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

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

步驟 1：選取專案管理工具

在此步驟中，您會建立要用於追蹤進度的工具。您可以選擇使用 Jira 或 Confluence 等軟體解決方案、在 Microsoft Excel 中建置您自己的儀表板，或使用這些工具的組合。選取或建置專案管理工具時，請考慮下列最佳實務：

  • 為了追蹤任務和追蹤進度，我們建議使用視覺化管理工具，例如 Kanban 電路板或 Gantt 圖表，這些工具通常在專案管理應用程式中提供。視覺化管理工具在每日站立會議上特別有效，用於審核目前的任務和波浪進度。

  • 如果您選取專案管理應用程式，請考慮是否要在專案管理工具中輸入計劃和程序 （例如升級計劃、決策日誌或 RAID 日誌），並確認它具有所需的功能。

  • 專案發起人、執行主管、專案經理和外部利益相關者 （如果有的話） 務必與所選工具保持一致。

如需如何使用這些工具的詳細資訊，請參閱 建立敏捷的方法。

步驟 2：驗證所有遷移活動的角色和責任

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

為了為您的組織量身打造 RACI 任務，我們建議您考慮下列事項：

  • 了解變更管理程序、這些程序所需的前置時間，以及核准變更所涉及的角色。如需詳細資訊，請參閱步驟 6：了解變更管理程序。

  • 在開始遷移之前，請確定您已審核備份和災難復原策略，並與遷移團隊共用此策略。如果您發現策略中的差距，我們建議您使用整合雲端服務，例如 AWS Backup 或 CloudEndure 災難復原。

請執行下列操作：

  1. 如果您尚未這麼做，請根據適用於AWS 大型遷移的基礎手冊中的指示，為每個高階任務建立 RACI 矩陣。

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

  3. 當您識別新的遷移策略或支援任務時，請更新和建立新的矩陣。

步驟 3：建立利益追蹤辦公室

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

在每次會議中，此團隊通常會檢閱並回答下列問題：

  • 遷移的目前狀態為何？

  • 我們是否正朝著實現目標成果的方向邁進？

  • 我們是否準確測量效能？

  • 我們是否需要進行任何調整，以加速遷移？

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

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

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

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

  3. 與專案發起人定義大型遷移的定性和定量 KPIs，並收集執行領導層的意見。利益追蹤辦公室會根據您的 KPIs評估遷移進度。KPIs的範例包括：

    • （量化） 相較於計劃遷移的實際伺服器數量

    • （量化） 相較於計劃已解除委任的伺服器數量

    • （定性） 檢閱問卷意見回饋和行動計劃

    • （定性） 為回應問卷意見回饋而採取的修正步驟

步驟 4：建立專案摘要儀表板

專案團隊必須與關鍵專案利益相關者共同合作，以開發儀表板，清楚傳達遷移的進度。您的專案摘要儀表板應該在單一頁面上執行下列動作：

  • 量化整個專案的整體已完成和剩餘工作負載

  • 反映最近完成波的效能 （計劃和實際）

  • 顯示即將來臨的浪潮中預期的工作負載 （計劃）

我們建議您從專案摘要儀表板範本 (Microsoft PowerPoint 格式） 開始，可在專案管理手冊範本中找到。請執行下列操作：

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

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

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

步驟 5：建立財務報告程序

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

我們建議您從 專案控管手冊範本中提供的 Financial glide 路徑範本 (Microsoft PowerPoint 格式） 開始。請執行下列操作：

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

  2. 決定此財務報告是否會在會議或透過電子郵件分享。

  3. 視需要修改範本以用於您的專案。

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

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

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

步驟 6：判斷如何管理和擴展資源

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

資源計劃會因每次大型遷移而異，通常由專案特有的因素決定。常見的因素包括專案預算、專案團隊的組織方式、探索活動完成的速度、產品組合如何分佈到每個遷移策略 （例如重構、重新託管或轉譯），以及組織中的變更管理程序需要多少時間。

規劃資源時，請考慮您產品組合的遷移策略，以及這些策略如何影響您的遷移和產品組合團隊。例如，重新託管是大型遷移的常見策略，因為它的複雜性較低。幾乎每個大型遷移專案都有至少一個 4-5 個人的重新託管遷移 Pod。如果您計劃包含高複雜度遷移策略，例如 replatform 或 refactor，您應該為這些策略建立遷移團隊 Pod，並在資源計劃中包含額外的遷移和產品組合團隊資源。如需有關工作流、團隊結構和每個 Pod 需要多少人的詳細資訊，請參閱 Foundation 手冊中的團隊組織和組成，了解大型遷移。 AWS

此外，有 SAP 等特殊工作負載，也需要有個別的專業團隊，由具有這些工作負載經驗的人員組成。如需特殊化工作負載的詳細資訊，請參閱AWS 遷移加速計劃的 MAP 特殊化工作負載。

請執行下列操作：

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

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

  3. 如果您的專案包含遷移特殊工作負載，例如 ERP 系統，請定義支援該工作負載所需的資源。特殊工作負載的典型資源包括：

    • 專案經理

    • 架構領導

    • 架構工程師

    • DevOps 工程師

    • 包含下列項目的專用遷移 Pod：

      • 功能主題專家 (SME)

      • 測試專家

  4. 定義支援每個遷移策略所需的資源，例如重新託管。典型的資源包括：

    • 專案領導

    • 運算、儲存和聯網的架構師和工程師

    • 測試專家

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

步驟 7：建立決策日誌

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

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

請執行下列操作：

  1. 建立決策日誌。您可以為此使用專用專案管理工具，例如 Jira 或 Confluence，也可以在 Microsoft Excel 中建立清單。我們建議記錄：

    • 決策的簡短描述

    • Status

    • 決策如何影響專案

    • 考慮的替代選項

    • 誰做決定

    • 做出決策的日期

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

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

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

步驟 8：建立 RAID 日誌

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

請執行下列操作：

  1. 建立 RAID 日誌。您可以為此使用專用專案管理工具，例如 Jira 或 Confluence，也可以在 Microsoft Excel 中建立清單。我們建議記錄：

    • 類型 （風險、動作、問題或相依性）

    • 項目的簡短描述

    • 開啟日期

    • Probability (可能性)

    • 影響

    • 嚴重性分數，其計算方式是將機率和影響相乘

    • Owner

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

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

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

任務結束條件

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

  • 您已在 Microsoft Excel 中選取一或多個專案管理工具，例如 Jira、Confluence 或儀表板和清單。

  • 您已為每個遷移策略 （例如重新託管） 和大型遷移專案中的每個高階任務建立並驗證詳細的 RACI 矩陣。

  • 您已建立利益追蹤辦公室、為其會議建立定期節奏，並為會議建立所有權和報告範本。

  • 內部利益相關者會針對財務報告的處理方式保持一致。您已建立正式節奏來檢閱財務報告、識別收件人，並決定誰應該存取財務報告。

  • 您已為您的專案建立資源計劃。

  • 您已在共用儲存庫中建立決策日誌，且所有團隊領導都有權進行更新。

  • 您已定義 RAID 日誌的位置和範本。您已建立維護日誌和排定問題的優先順序的程序。RAID 日誌中的Week-to-week變更摘要於狀態報告中。

  • 所有專案利益相關者都與您如何在專案摘要儀表板中傳達高階專案狀態保持一致。