进行试点

完成小型企业领域的 end-to-end迁移项目可以实现快速部署，而不会出现大规模业务中断的风险。这种经验可以建立人们对以相对较小的支出实现价值主张（能力、运营和成本）的信心，并且可以用来证明应为全面项目腾出更多的资金和资源。

试点人员根据最终用户对新平台的反应收集全面部署的经验教训。这有助于利益相关者使用现实生活中的数据回答例如以下的重要问题：

• 我们提供的培训是否合适、充分？

• 当最终用户真正接听电话时，新流程能否正常运行？

• 用户是否会被设备上的其他应用程序分散注意力？

• 在实际环境中，架构或模式能否按预期工作？

最佳实践

• 理想情况下，试点人员应在早期冲刺中作为初期最小喜爱产品（MLP）交付的一部分。

• 试点的参与者应包括技术用户、业务用户和最终用户。

• 采访利益相关者，获取有关他们如何使用系统的经验反馈，并捕获平均处理时间、放弃率等数据，据此将新系统与以前的平台进行比较。 

• 确保对试点期间确定的调整和修改进行跟踪直至完成。 

• 在试点开始之前，定义您的成功标准和后续步骤。成功标准应以数据为导向，以便对成功/失败决策做出决定性评分。如果利益相关者签署了有关任何修改的试点计划和交付计划，则会启动预定义的后续步骤（例如，开始全面部署）。

• 当您的试点人员发现需要更改甚至需要重新设计的区域时，请保持乐观积极的态度。这是试点的宝贵成果，为成功的发布部署奠定了基础。不要以试点零建议为目标，这种结果会引起人们对试点有效性的担忧。

选择试点小组

理想情况下，您选择试点该解决方案的业务领域将展示最小喜爱产品（MLP）范围内的所有能力，以实现业务成果。成功交付 MLP 是构建复杂性和增加服务能力的起点。MLP 试点小组应：

• 代表非关键业务领域（例如，内部帮助中心或情况变更通知）。

• 处理少量呼叫，这样用户就有时间学习新平台并记录他们的反馈和观察。

• 受到项目团队和利益相关者的信任，确保反馈是公平、准确和客观的。这有助于树立人们对试点结果的信心，并有助于创建协作开发环境。

• 执行大多数范围内的平台功能。如果试点仅使用全面部署范围内的功能的百分之十，则该试点几乎没有价值或相关性。

• 执行可能由于技术限制（例如远程办公）或许可而被排除在旧平台之外或未完全集成到旧平台中的功能。从一个在原有的系统中没有报告或记录的群组入手，您便可能能够避免构建旧版集成或迁移旧版数据。但是，您应确保试点仍然可以代表全面部署的效果。

实际上，您可能需要对其中一些因素做出妥协，具体取决于组织中团队参与试点的能力和意愿。