Power BI 实施规划：BI 解决方案规划
注意
本文是 Power BI 实现规划系列文章中的一篇。 本系列着重介绍 Microsoft Fabric 中的 Power BI 体验。 有关该系列的介绍，请参阅 Power BI 实施规划。
本文可帮助规划支持你的商业智能 (BI) 策略的解决方案。 主要面向以下对象：
- BI 和分析主管或经理：负责监督 BI 计划和具有重要战略意义的 BI 解决方案的决策者。
- 卓越中心 (COE)、IT 和 BI 团队：为其组织设计和部署企业 BI 解决方案的团队。
- 主题专家 (SME) 以及内容所有者和创建者：在部门中支持分析以及为自助服务、部门 BI 或团队 BI 使用方案设计和部署解决方案的团队和个人。
BI 战略是指实施、使用和管理数据和分析的计划。 可从 BI 战略规划开始定义 BI 策略。 战略规划可帮助你确定 BI 重点领域和目标。 若要确定实现 BI 目标的路径，请使用战略规划描述特定关键结果。 然后，通过规划和部署 BI 解决方案来实现这些关键结果。
注意
在目标和关键结果 (OKR) 框架中，目标明确、简要地描述了要实现的目标。 相比之下，关键结果是具体的、可实现的结果，用于衡量实现目标的进展情况。
此外，计划或解决方案是用于帮助你实现一个或多个关键结果的流程或工具。 解决方案可解决用户的特定数据需求。 解决方案可以采用多种形式，例如数据管道、数据湖屋、Power BI 语义模型或报表。
有关 OKR 的详细信息，请参阅了解 OKR (Microsoft Viva Goals)。
可通过多种方法规划和实施 BI 解决方案。 本文介绍一种可用于规划和实施支持 BI 策略的 BI 解决方案的方法。
下面的高级关系图描述了如何执行 BI 解决方案规划。
执行以下步骤来执行 BI 解决方案规划。
| 步骤 | 描述 |
|---|---|
| 1 | 组建一个项目团队来收集要求并定义解决方案的设计。 |
| 2 | 通过执行工具和流程的初始设置来规划解决方案部署。 |
| 3 | 执行解决方案概念证明 (POC) 来验证有关设计的假设。 |
| 4 | 使用迭代开发和验证周期创建和验证内容。 |
| 5 | 将解决方案发布到生产环境后，部署、支持和监视解决方案。 |
有关详细信息，请参阅 Power BI 迁移系列。 虽然系列涉及迁移，但关键操作和注意事项与解决方案规划相关。
步骤 1：收集要求
首先收集要求并定义解决方案设计，开始规划解决方案。
注意：战略和战术规划由领导计划的工作团队领导。 相反，解决方案规划由项目团队（由内容所有者和创建者组成）领导。
收集正确的要求对于成功部署和采用解决方案至关重要。 收集要求的一种方法是确定正确的利益干系人并让其参与，协同定义要解决的问题，并使用对问题的共同理解来创建解决方案设计。
下面是使用协作方法收集要求的一些好处。
- 用户输入生成更有用的设计：通过让用户参与重点讨论来收集要求，可以更有效地捕获业务数据需求。 例如，用户可以向内容创建者演示他们如何使用现有解决方案，并提供有关这些解决方案的感知有效性的反馈。
- 避免假设并缓解更改请求：与用户的讨论通常会显示细微差别、异常和隐藏的复杂性。 这些见解降低了后期请求的可能性，而后期请求的处理成本可能很高。
- 加入用户可以提高解决方案采用率：通过让用户参与设计和早期开发，你可以为他们提供影响最终结果的机会。 参与还可以让用户对解决方案有一种知识所有权和责任感。 高度参与的用户更有可能认可该解决方案，并引导其实践社区有效使用该解决方案。
- 设计为利益干系人和业务用户设定了期望：通过生成解决方案设计的模型或插图，可以清楚地向利益干系人展示解决方案将提供的内容。 它还有助于建立对预期项目结果的相互理解。 此过程也称为设计思维，它可以是一种有效的方法来解决和理解复杂的问题。
你可以采用不同的方法来吸引用户并收集要求。 例如，可以使用业务设计和技术设计收集要求（本文后面部分详细介绍）。
业务设计是收集业务要求的一种方法。 它侧重于在业务设计会话中吸引业务用户来协作设计解决方案。 业务设计的输出由解决方案模型和描述性设计文档组成。
技术设计是一种将业务要求转换为技术要求并解决设计假设的方法。 技术设计侧重于验证业务设计和定义要使用的技术方法。 为了验证设计，内容创作者通常会在必要时与技术专家进行集中讨论（称为技术设计会议）。
重要
收集错误的要求是实施失败的常见原因。 通常，团队收集错误的要求是因为，他们接洽了错误的利益干系人（例如为要生成的解决方案提供自上而下请求的决策者）。
通过使用业务设计等协作方法吸引业务用户可帮助你收集更好的要求。 更好的要求通常会带来更高效的开发和更可靠的解决方案。
注意
对于某些团队来说，采用结构化要求收集过程是一个重大变化。 确保管理此更改，并且它不会中断解决方案规划。 我们建议你找到调整这些方法的方式，以适应团队的工作方式。
为解决方案规划做好准备
应首先考虑以下部分中所述的因素，为解决方案规划做好准备。
- 确定谁将执行解决方案规划：作为 BI 战术规划的一部分，工作团队创建了优先的解决方案积压工作。 在解决方案规划中，项目团队负责设计、开发和部署积压工作中的一个或多个解决方案。 对于积压工作中的每个解决方案，应组建一个项目团队来负责解决方案。 除了运行 BI 解决方案规划外，项目团队还应：
- 定义解决方案规划的时间线和里程碑。
- 确定适当的利益干系人并让其参与要求收集。
- 设置一个用于沟通、记录和规划的集中位置。
- 让利益相关者参与收集要求。
- 与利益干系人和业务用户进行沟通和协调。
- 协调业务用户的迭代开发和测试周期。
- 记录解决方案。
- 通过定义和制定培训计划将用户加入解决方案。
- 提供部署后解决方案支持。
- 解决用户在部署后更改或更新解决方案的合理请求。
- 如有必要，请在部署后执行解决方案迁移。
- 集中沟通和记录：项目团队将沟通和记录集中到 BI 解决方案规划中非常重要。 例如，项目团队应集中要求、利益干系人沟通、时间线和可交付结果。 请考虑将所有文档存储在一个集中门户。
- 计划要求收集：项目团队应首先规划业务设计会议来收集业务要求。 这些会议采用交互式会议的形式，它们可以遵循与战略规划研讨会类似的格式。
提示
请考虑在要求收集过程中尽早确定负责解决方案的支持团队并让这些团队参与进来。 为了有效地支持该解决方案，支持团队需要全面了解解决方案、其目的和用户。 当项目团队仅由外部顾问组成时，这一点尤为重要。
收集业务要求
收集正确的业务要求对于设计正确的解决方案至关重要。 为了收集正确的要求并定义有效的解决方案设计，项目团队可以与业务用户一起召开业务设计会议。
业务设计会议的目的是：
- 确认初始解决方案范围。
- 定义并了解解决方案应解决的问题。
- 确定解决方案的正确关键利益干系人。
- 收集正确的业务要求。
- 准备满足业务要求的解决方案设计。
- 准备支持设计文档。
下图描述了如何使用业务设计方法收集业务要求并定义解决方案设计。
该图描述了以下步骤。
| 项目 | 描述 |
|---|---|
 |
项目团队通过确认战略规划中首次记录的解决方案范围来开始业务设计。 它们应阐明解决方案涵盖的业务领域、系统和数据。 |
 |
项目团队确定用户社区中将参与业务设计会议的关键利益干系人。 关键利益干系人是具有足够知识和可信度的用户，可以代表解决方案的主题领域。 |
 |
项目团队规划业务设计会议。 规划涉及通知利益干系人、组织会议、准备可交付结果以及与业务用户互动。 |
 |
项目团队收集并研究业务用户当前用于满足现有业务数据需求的现有解决方案。 为了加快此过程，项目团队可以使用 BI 战略规划中的相关研究，该研究已记录在通信中心中。 |
 |
项目团队与利益相关者进行业务设计会议。 这些会议是小型互动会议，项目团队在其中指导利益相关者了解业务数据需求和要求。 |
 |
项目团队通过向利益干系人和其他用户提供解决方案设计草稿来结束业务设计，以获得反馈和批准。 当利益干系人同意设计将有助于他们实现其业务目标时，业务设计会成功。 |
业务设计以以下可交付结果结尾。
- 草稿解决方案设计：模型、原型或线框图说明了解决方案设计。 这些文档将要求转换为具体的设计蓝图。
- 业务指标列表：解决方案中预期的定量字段，包括业务定义和预期聚合。 如果可能，请按照对用户的重要性对它们进行排名。
- 业务属性列表：解决方案中预期的相关属性和数据结构，包括业务定义和属性名称。 如果可能，请包括层次结构，并按对用户的重要性对属性进行排名。
- 补充文档：关键功能或合规性要求的说明。 本文档应尽可能精确，但应尽可能简洁。
业务设计可交付结果在技术设计中使用并由技术设计进行验证。
提示
解决方案模型、原型或线框图可以让开发人员和最终用户能清楚地了解预期结果。 创建有效的模型不需要艺术技巧或天赋。 可以使用简单的工具（如 Microsoft Whiteboard、PowerPoint）甚至仅使用笔和纸来阐释设计。
收集技术要求
完成业务设计后，项目团队使用技术设计来验证其结果。 技术设计是一种类似于业务设计的方法。 虽然业务设计侧重于业务数据需求，但技术设计侧重于解决方案的技术方面。 技术设计的一个关键结果是解决方案计划，它描述了最终解决方案设计以及实施解决方案的工作量的明智估计。
注意
与业务设计不同，技术设计在很大程度上是对内容创建者和所有者执行的源数据和系统的独立调查。
技术设计的目的是：
- 验证业务设计的结果。
- 解决当前设计中的技术假设。
- 确定范围内的相关数据源，并为每个数据源定义字段计算和字段源映射。
- 将业务要求转换为技术要求。
- 生成实施所需的工作量的估计。
项目团队与技术或职能利益相关者一起参与有限的重点技术设计会议。 这些会议是与职能利益干系人的互动会议，旨在收集技术要求。 利益干系人负责解决方案有效运作所需的特定职能领域。
技术设计中的利益干系人示例如下：
- 安全和网络团队：负责确保数据的安全性和合规性。
- 职能团队和数据管理人员：负责管理源数据。
- 架构师：特定平台、工具或技术的所有者。
项目团队与利益干系人一起参与技术设计会议，以解决解决方案的技术方面问题。 技术方面可以包括：
- 数据源连接：有关如何连接和集成数据源的详细信息。
- 网络和数据网关：有关专用网络或本地数据源的详细信息。
- 字段源映射：业务指标和属性到数据源字段的数据映射。
- 计算逻辑：将业务定义转换为技术计算。
- 技术功能：支持业务要求所需的特性或功能。
提示
执行业务设计的项目团队还应执行技术设计。 但是，出于实际原因，不同的个人可能会领导技术设计。 在这种情况下，请通过查看业务设计的结果来开始技术设计。
理想情况下，领导技术设计的人员应全面了解结果和业务用户。
下图描述了如何使用技术设计将业务要求转换为技术要求。
该图描述了以下步骤。
| 项目 | 描述 |
|---|---|
|
项目团队通过根据业务设计的结果定义数据源范围来开始技术设计。 数据源范围声明生成解决方案所需的数据。 为了确定正确的数据源，项目团队会咨询业务和职能 SES。 |
|
项目团队确定技术或职能利益干系人，以便稍后参与技术设计会议。 |
|
项目团队规划与职能利益干系人的有限重点会议，以解决解决方案的技术方面问题。 规划涉及通知利益干系人、组织会议和准备可交付结果。 |
|
项目团队研究技术要求。 研究包括定义字段计算和数据源映射，以及通过技术分析和记录来解决业务设计假设。 |
|
如有必要，项目团队将涉及到技术设计会议中的利益干系人。 会议重点关注解决方案的特定技术方面，例如安全性或数据源连接。 在这些会议中，项目团队收集利益干系人和 SME 的定性反馈。 |
|
项目团队使用解决方案计划来准备他们的发现，解决方案计划将提供给利益干系人和决策者。 该计划是业务设计成果的迭代和扩展，包括最终设计、估算和其他可交付结果。 |
 |
技术设计应以与利益相关者和决策者举行最终会议结尾，以决定是否继续进行。 此会议提供了在资源致力于开发解决方案之前评估解决方案规划的最终机会。 |
注意
技术设计可能显示出意外的复杂性，这可能会使解决方案规划在当前资源可用性或组织就绪性的情况下变得不可行。 在这种情况下，应在后续的专属规划期间重新评估解决方案。 根据业务数据需求的紧迫性，决策者（如执行发起人）可能仍然希望进行概念验证，或者只进行计划解决方案的一部分。
技术设计以解决方案计划结尾，该计划包含以下可交付结果。
- 工具和技术：实施解决方案所需的相关技术工具的列表。 该列表通常包括相关的新许可证选项（如 Fabric 容量或 Premium Per User）、功能和工具。
- 定义的业务指标列表：所有范围内数据源的业务指标的计算和字段源映射。 为了生成此可交付结果，项目团队使用在业务设计中创建的业务指标列表。
- 定义的业务属性列表：所有范围内数据源的业务属性的字段源映射。 为了生成此可交付结果，项目团队使用在业务设计中创建的业务属性列表。
- 修订的设计：根据对业务设计的更改或无效假设，对解决方案设计的修订。 修订的设计是业务设计中生成的模型、原型或线框关系图的更新版本。 如果不需要修订，请告知技术设计验证业务设计。
- 工作量估计：估计开发、支持和维护解决方案所需的资源。 估计会告知是否继续实施解决方案的最终决定。
重要
确保项目团队向利益干系人通知技术设计中的任何更改或意外发现。 这些技术设计会议仍应涉及相关业务用户。 但是，请确保利益干系人不会不必要地接触到复杂的技术信息。
提示
由于业务目标总是在不断发展，所以预计要求会发生变化。 不要假定 BI 项目的要求是固定的。 如果难以应对不断变化的要求，则可能表明要求收集过程无效，或者开发工作流未充分纳入常规反馈。
核对清单 - 收集要求时，关键决策和操作包括：
- 阐明谁拥有解决方案规划：对于每个解决方案，确保项目团队的角色和责任明确。
- 阐明解决方案范围：解决方案范围应已记录为 BI 战术规划的一部分。 在开始解决方案规划之前，可能需要花费额外的时间和精力来阐明范围。
- 确定并通知利益干系人：确定业务设计和技术设计的利益干系人。 提前通知他们有关项目的信息，并解释业务设计的范围、目标、所需的时间投资和可交付结果。
- 规划和开展业务设计会议：审查业务设计会议，以从利益干系人和业务用户处获取信息。 请求用户演示他们如何使用现有解决方案。
- 记录业务指标和属性：通过使用现有解决方案和利益干系人的输入，创建业务指标和属性列表。 在技术设计中，将字段映射到数据源，并描述定量字段的计算逻辑。
- 草拟解决方案设计：根据利益干系人输入创建迭代模型，以直观地反映预期的解决方案结果。 确保模型准确表示并满足业务要求。 向业务用户传达在技术设计过程中仍必须验证（可能还会修订）模型。
- 创建解决方案计划：研究源数据和相关技术注意事项，以确保业务设计可实现。 如果相关，请描述设计的关键风险和威胁，以及任何替代方法。 如有必要，请准备解决方案设计的修订版，并与利益干系人进行讨论。
- 创建工作量估计：作为最终解决方案计划的一部分，估计生成和支持解决方案的工作量。 使用在业务设计和技术设计会议期间收集的信息来证明这些估计值的合理性。
- 决定是否继续执行该计划：若要结束要求收集过程，请向利益干系人和决策者提交最终计划。 此会议的目的是确定是否继续开发解决方案。
步骤 2：规划部署
当项目团队完成收集要求、创建解决方案计划并获得批准以继续操作时，即可规划解决方案部署。
部署规划任务因解决方案、开发工作流和部署过程而异。 部署计划通常涉及许多活动，涉及规划和设置解决方案的工具和流程。
计划解决关键领域问题
项目团队应规划解决方案部署的关键领域。 通常，规划应解决以下方面的问题。
- 合规性：确保通过特定操作来解决要求收集中确定的所有合规性标准。 将每个操作分配给特定人员，并明确定义传递时间范围。
- 安全性：决定如何管理不同层的解决方案访问，以及任何数据安全性规则要求。 查看解决方案安全性是否比租户中的标准内容更严格。
- 数据网关：评估解决方案是否需要数据网关来连接到数据源。 确定是否需要特定网关设置或高可用性群集。 规划谁将能够通过网关安全角色管理网关连接，以及如何监视网关。 有关详细信息，请参阅预配网关访问权限。
- 工作区：决定如何设置和使用工作区。 确定解决方案是否需要生命周期管理工具（如 Git 集成和部署管道）以及是否需要使用 Azure Log Analytics 进行高级日志记录。
- 支持：确定谁负责在生产部署后支持和维护解决方案。 如果负责支持的个人与项目团队不同，请让这些人员参与开发。 确保支持解决方案的人了解解决方案设计、它应该解决的问题、谁应该使用它以及如何使用它。
- 用户培训：预计培训用户社区所需的工作量，以便他们可以有效地使用解决方案。 考虑是否需要任何特定的更改管理操作。
- 治理：确定解决方案的任何潜在治理风险。 预测使用户能够有效地使用解决方案所需的工作量，同时缓解任何治理风险（例如，通过使用敏感度标签和策略）。
执行初始设置
项目团队应执行初始设置以开始开发。 初始设置活动可以包括：
- 初始工具和流程：为开发、测试和部署所需的任何新工具和流程执行首次设置。
- 标识和凭据：创建将用于访问工具和系统的安全组和服务主体。 有效且安全地存储凭据。
- 数据网关：为专用网络（虚拟网络或 VNet、网关）上的本地数据源（企业模式网关）或数据源部署数据网关。
- 工作区和存储库：创建和设置用于发布和存储内容的工作区和远程存储库。
注意
部署规划因解决方案和首选工作流而异。 本文仅介绍高级规划和可操作项目。
有关部署规划的详细信息，请参阅规划有关迁移到 Power BI 的部署。
核对清单 - 规划解决方案部署时，关键决策和操作包括：
- 规划关键领域：规划以解决成功开发和部署解决方案所需的流程和工具。 同时解决技术领域（如数据网关或工作区）和采用（如用户培训和治理）。
- 执行初始设置：建立开发和部署解决方案所需的工具、流程和功能。 记录设置，以帮助将来需要进行首次设置的其他人。
- 测试数据源连接：验证适当的组件和流程是否已就绪，以连接到正确的数据以启动概念证明。
步骤 3：执行概念证明
项目团队执行解决方案概念证明 (POC) 来验证未完成的假设并展示业务用户的早期优势。 POC 是一个初始设计实施，在范围和成熟度方面受到限制。 运行良好的 POC 对于大型或复杂解决方案尤其重要，因为它可以识别和解决技术设计中未检测到的复杂性（或异常）。
我们建议在准备 POC 时考虑以下注意事项。
- 目标和范围：描述解决方案 POC 的用途及其将要解决的功能领域。 例如，项目团队可能决定将 POC 限制为单个功能领域或者一组特定要求或功能。
- 源数据：标识 POC 中将使用哪些数据。 根据解决方案，项目团队可能会决定使用不同类型的数据，例如：
- 生产（真实）数据
- 示例数据
- 生成的合成数据，类似于在生产环境中观察到的实际数据量和复杂性
- 演示：介绍项目团队如何以及何时向利益干系人和用户演示 POC。 可能会在定期更新期间或 POC 满足特定功能条件时提供演示。
- 环境：描述项目团队将在何处生成 POC。 一个好的方法是为 POC 使用独特的沙盒环境，并在准备就绪时将其部署到开发环境。 沙盒环境具有更灵活的策略和流畅的内容，并专注于生成快速结果。 相反，开发环境遵循更结构化的过程来实现协作，并专注于完成特定任务。
- 成功条件：定义 POC 成功时的阈值，应移到下一次迭代并进入正式开发。 在启动 POC 之前，项目团队应确定 POC 何时成功的明确条件。 通过提前设置这些条件，项目团队定义 POC 开发何时结束以及迭代开发和验证周期何时开始。 根据 POC 的目标，项目团队可能会设置不同的成功条件，例如：
- 利益干系人批准 POC
- 验证特性或功能
- 在固定的开发时间后，同行对 POC 进行了有利的审查
- 失败：确保项目团队可以识别 POC 的失败。 尽早识别失败将有助于调查根本原因。 它还有助于避免对部署到生产环境时无法按预期运行的解决方案进行进一步投资。
注意
当项目团队执行 POC 时，他们应该对假设和限制保持警惕。 例如，项目团队无法使用一小部分数据轻松测试解决方案性能和数据质量。 此外，请确保业务用户清楚 POC 的范围和目的。 请务必表明 POC 是第一次迭代，并强调它不是生产解决方案。
注意
有关详细信息，请参阅进行概念证明以迁移到 Power BI。
核对清单 - 创建 POC 时，关键决策和操作包括：
- 定义目标：确保 POC 的目标对所有相关人员都是明确的。
- 定义 POC 的作用域：确保创建 POC 不需要太多开发工作，同时仍然提供价值并展示解决方案设计。
- 确定将使用哪些数据：确定用于生成 POC 的源数据，从而证明你的决策合理，并概述潜在风险和限制。
- 决定何时以及如何展示 POC：计划通过向决策者和业务用户展示 POC 来展示进度。
- 阐明 POC 何时结束：确保项目团队为 POC 做出明确的结论，并描述如何将其提升到正式的开发周期。
步骤 4：创建和验证内容
POC 成功后，项目团队将从 POC 转移到创建和验证内容。 项目团队可以使用迭代开发和验证周期开发 BI 解决方案。 这些周期包括迭代版本，其中项目团队在开发环境中创建内容并将其发布到测试环境。 在开发过程中，项目团队会逐步将试点过程中的用户社区加入到测试环境中解决方案的早期 (beta) 版本。
提示
迭代交付鼓励尽早进行验证和反馈，以便在生产发布之前缓解更改请求、促进解决方案采用并实现优势。
迭代开发和验证周期将继续，直到项目团队得出预定义的结论。 通常，当没有更多功能需要实施或用户反馈需要解决时，开发就结束了。 当开发和验证周期结束时，项目团队会将内容部署到具有最终生产版本的生产环境。
下图描述了项目团队如何通过开发和验证周期以迭代方式交付 BI 解决方案。
该图描述了以下步骤。
| 项目 | 描述 |
|---|---|
|
项目团队将每个版本传达给用户社区，描述更改和新功能。 理想情况下，通信包括解决方案演示和问答，以便用户了解版本中的新增功能，并可提供口头反馈。 |
|
在验证期间，用户通过中心工具或表单提供反馈。 项目团队应定期查看反馈以解决问题、接受或拒绝请求，并通知即将发生的开发阶段。 |
|
项目团队监视解决方案的使用情况，以确认用户正在对其进行测试。 如果没有任何使用，项目团队应与用户社区接洽，了解原因。 低使用率可能表示项目团队需要采取进一步的启用和更改管理操作。 |
|
项目团队会及时回应用户反馈。 如果项目团队处理反馈花费的时间太长，用户可能会很快失去提供反馈的动力。 |
|
项目团队将接受的反馈纳入解决方案规划中。 如有必要，他们会审查规划优先级，以在下一个开发阶段开始之前阐明和委派任务。 |
|
项目团队将继续开发下一版本的解决方案。 |
|
项目团队会循环访问所有步骤，直到他们得出预定义的结论，并且解决方案已准备好进行生产部署。 |
以下部分介绍使用迭代开发和验证周期交付 BI 解决方案的关键注意事项。
创建内容
项目团队按照其正常开发工作流开发解决方案。 但是，在创建内容时，他们应该考虑以下几点。
- 在每个开发周期中，更新文档以描述解决方案。
- 在每个开发周期结束时向用户社区发布公告。 公告应发布到集中式门户，它们应提供每个版本中更改和新功能的简要说明。
- 在每个版本中，请考虑组织会议来向用户社区展示更改和新功能，并回答任何口头问题。
- 定义迭代开发和验证周期何时结束。 确保有一个明确的流程来将解决方案部署到生产环境中，包括向支持和采用活动的过渡。
验证内容
每个迭代开发周期都应以内容验证结束。 对于 BI 解决方案，通常有两种类型的验证。
- 开发人员验证：解决方案测试由内容创建者和对等方完成。 开发人员验证的目的是在向业务用户提供解决方案之前，确定并解决所有严重和可见的问题。 问题可能与数据正确性、功能或用户体验有关。 理想情况下，内容由未开发它的内容创建者进行验证。
- 用户验证：解决方案测试由用户社区完成。 用户验证的目的是为以后的迭代提供反馈，并确定开发人员未发现的问题。 正式用户验证期通常称为用户验收测试 (UAT)。
重要
确保在开发人员验证期间（在 UAT 之前）解决任何数据质量问题。 这些问题可能会迅速削弱人们对解决方案的信任，并可能损害长期采用。
提示
执行用户验证时，请考虑偶尔与关键用户进行简短通话。 在使用解决方案时观察它们。 记下他们觉得难以使用的内容，或者解决方案的哪些部分未按预期工作。 此方法可以是收集反馈的有效方法。
项目团队验证内容时考虑以下注意事项。
- 鼓励用户反馈：每次发布时，请求用户提供反馈，并展示如何有效地执行此操作。 请考虑定期共享导致最近更改和新功能的反馈和请求示例。 通过共享示例，你将证明已确认并重视反馈。
- 隔离较大的请求：有些反馈项目需要付出更多的努力才能解决。 确保项目团队能够识别这些项目，并讨论是否将实施这些项目。 请考虑记录更大的请求，以便在以后的战术规划会议中进行讨论。
- 开始变更管理活动：培训用户如何使用解决方案。 请务必在新流程、新数据和不同工作方式上花费额外的精力。 投资变更管理对长期解决方案采用具有积极回报。
当解决方案达到预定义的完整性和成熟度级别时，项目团队就可以将其部署到生产环境中。 部署后，项目团队将从迭代交付过渡到支持和监视生产解决方案。
注意
开发和测试因解决方案和首选工作流而异。
本文仅介绍高级规划和可操作项目。 有关迭代开发和测试周期的详细信息，请参阅创建要迁移到 Power BI 的内容。
核对清单 - 创建和验证内容时，关键决策和操作包括：
- 使用迭代过程来规划和分配任务：为解决方案的每个版本规划和分配任务。 确保规划和分配任务的过程是灵活的，并包含用户反馈。
- 设置内容生命周期管理：使用工具和流程简化和自动化解决方案部署和变更管理。
- 创建一个工具来集中反馈：使用对你和你的用户来说很简单的解决方案自动收集反馈。 创建一个简单明了的表单，以确保反馈简洁且可操作。
- 安排会议以审查反馈：会议简要审查每个新的或未完成的反馈项目。 确定是否实施反馈、谁将负责实施，以及关闭反馈项时要采取的操作。
- 确定迭代交付何时结束：描述迭代交付周期何时结束以及何时将内容发布到生产环境的条件。
步骤 5：部署、支持和监视
准备就绪后，项目团队会将验证的解决方案部署到生产环境。 项目团队应采取关键采用和支持措施，以确保部署成功。
若要确保部署成功，请执行以下支持和采用任务。
- 传达最终版本：执行发起人、经理或其他具有足够权威和可信度的人员应向用户社区宣布发布。 通信应清晰、简洁，并包含指向相关解决方案和支持渠道的链接。
- 对内容使用者进行培训：内容使用者应在发布到生产环境后的头几周内接受培训。 培训应重点介绍如何阐明解决方案范围、回答用户问题以及如何使用解决方案。
- 解决反馈和请求：考虑为用户提供向项目团队提交反馈和请求的渠道。 确保讨论合理的反馈和请求，并酌情在部署后支持期间实施。 在生产发布后对反馈和请求执行操作非常重要。 它表示一个敏捷的解决方案，能够响应不断变化的业务需求。
- 计划与用户社区建立联系：即使在部署后支持期结束后，确保解决方案所有者定期与用户社区会面。 这些会议是修订 BI 策略的宝贵反馈来源。 此外，它们还通过助力用户来帮助支持解决方案采用。
- 移交操作：项目团队的成员可能不负责维护解决方案。 在这种情况下，团队应确定谁负责并执行移交。 移交应在发布到生产环境后不久进行，并且应该同时解决解决方案和用户社区问题。
注意
未能进行有效的移交可能会导致解决方案支持和采用在其生命周期内出现可预防的问题。
部署后，项目团队应计划继续执行优先解决方案积压工作中的下一个解决方案。 确保收集任何新的反馈和请求，并在必要时对包括解决方案积压工作战术规划进行修订。
核对清单 – 考虑解决方案部署时，关键决策和操作包括：
- 创建通信计划：规划如何传达发布、培训和其他解决方案支持或采用操作。 确保在部署后支持期间传达并及时解决任何中断或问题。
- 制定培训计划：培训用户使用该解决方案。 确保培训包括发布后数周的现场培训和录制培训课程。
- 开展移交活动：如有必要，准备从开发团队移交给支持团队。
- 执行解决方案办公时间：部署后支持期结束后，考虑定期举行办公时间会议，回答问题并收集用户的反馈。
- 制定持续改进流程：安排对解决方案的每月审核，以查看随时间推移的潜在更改或改进。 集中用户反馈，并在审核之间定期审查反馈。
相关内容
有关有助于做出 Power BI 实现决策的更多注意事项、操作、决策标准和建议，请参阅 Power BI 实现计划。