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

# 執行試行方案
<a name="pilot"></a>

完成小型業務領域的端對端遷移專案可快速部署，而不會造成大規模業務中斷的風險。此經驗可以為相對較小的開支建立對價值主張 (能力、營運和成本) 的信心，並可用於為全面專案提供更大的資金和資源合理性。

試行方案會根據最終使用者對新平台的反應，收集全面部署的經驗教訓。其會使用實際資料協助利益相關者回答重要問題，如下所示：
+ 我們提供的培訓是否合適且足夠？
+ 當最終使用者接聽真實電話時，新流程是否正常工作？
+ 使用者是否會被其裝置上的其他應用程式分散注意力？
+ 架構或模式是否在現場環境中按預期工作？

## 最佳實務
<a name="pilot-best-practices"></a>
+ 理想情況下，試行方案應在早期衝刺中成為最初最小可愛產品 (MLP) 交付的一部分。
+ 試行方案的參與者應包括技術使用者、企業使用者和最終使用者。
+ 採訪利益相關者，以獲得有關他們如何使用系統的軼事反饋，並獲取平均處理時間、放棄率等資料，以便將新系統與以前的平台進行比較。 
+ 確保在試行過程中確定的調整和修正被跟蹤到完成為止。 
+ 在試行方案開始之前，定義成功標準和後續步驟。成功標準應該由資料驅動，使決定性評分能做出成功/失敗決策。如果利益相關者簽署試行方案和交付計畫進行任何修訂，則會啟動預先定義的下一個步驟 (例如，啟動全面部署)。
+ 當試行方案發現必須變更甚至重新設計的區域時，請保持積極態度。這是試行方案的寶貴成果，並為成功的上線部署奠定了基礎。不要以零建議的試行方案為目標，這樣的結果會引起對試行方案有效性的擔憂。

## 選擇試行方案小組
<a name="select-pilot-group"></a>

您選擇試驗解決方案的業務領域理想情況下會展示最小可愛產品 (MLP) 範圍內的所有功能，以滿足業務成果。MLP 的成功交付成為構建複雜性和增加服務能力的起點。MLP 試行方案小組應該：
+ 代表非關鍵業務領域 (例如，內部服務台或狀況變更通知)。
+ 處理少量呼叫，因此使用者有時間學習新平台並記錄他們的反饋和觀察。
+ 受到專案團隊和利益相關者的信任，以確保意見回饋公平、準確且客觀。這有助於灌輸對試驗結果的信心，並有助於建立協同合作的開發環境。
+ 執行大多數範圍內的平台功能。在試行方案中，只使用全面部署範圍內百分之十的功能，沒有任何價值或相關性。
+ 執行可能因為技術限制 (例如遠端工作) 或授權而被排除在舊平台之外或未完全整合至舊平台的功能。從舊系統中沒有報告或記錄的群組開始，可以避免建置舊版整合或遷移舊式資料。不過，應該確保試行方案會繼續代表全面部署。

實際上，根據組織中團隊參與試行方案的能力和意願，您可能必須在其中一些因素上妥協。