培训
认证
Microsoft Certified: Power Platform Developer Associate - Certifications
演示如何使用 Microsoft Power Platform Developer 简化、自动化和转换业务任务和流程。
了解如何根据 平台工程功能模型确定平台工程工作的目标,演练常见方案,并寻找衡量成功的方法。 通过将目标范围限定为业务目标来衡量成功。
若要开始,请先使用 平台工程功能模型评估组织目前所处的位置。 使用模型绘制组织跨六项核心平台工程功能(投资、采用、治理、预配和管理、接口以及度量和反馈)的位置。 所有组织在某些功能方面都比其他组织更高级。 一旦你知道你的组织今天所处的位置,你可以选择想要增长的功能。 若要了解详细信息,请参阅 如何使用模型。
可以不断规划和更新平台工程目标。 明确希望从投资平台工程旅程中获得什么,这在帮助构建组织支持方面还有很长的路要走。
作为一个平台工程主管曾经说过,“我没有为平台工程做点什么,直到我有一些我可以从平台工程中获得的东西。” - 彼得,平台工程主管,跨国科技公司。
在考虑目标时,请将其范围限定为与平台工程工作相关的业务目标,而不是特定开发团队的具体内容。 常见的高级平台工程目标包括:
选择首要目标至关重要,因为目标会推动你思考优先级的方式。
更好的是,与领导层和内部合作伙伴就目标和关键结果(OKR)达成一致,从而为投资的当前阶段制定可衡量的目标。 (如果组织使用其他方法,其他规划方法具有类似的概念。最好的 OKR 是基于具体度量值设置的,因为它消除了主观性。
确定目标后,选择关键方案以推动积压工作和路线图。 例如,请参阅这些方案和要完成的关联作业。
许多方案适用于多个角色。 考虑如何衡量改进的指标。
接下来,寻求了解开发人员和其他角色面临的最大问题,以及你确定的方案和工作。 开始调查新产品以填补感知的空白可能很诱人,但如果这些产品不能解决一个主要的难题,他们不太可能被采用或欣赏。
有多种方法可以帮助你进行此类调查。 一个是 假设进展框架。 即使你没有使用像假设进展框架这样的正式过程,你也应该采访开发人员,讨论范围,然后确定他们在完成工作方面最大的问题。 一旦你对这些问题有很好的了解,继续提出解决这些问题的计划。 这有助于确保生成开发人员想要使用的功能。
若要快速重复此过程,请确定可以直接在内部开发人员平台团队中代表客户的声音的人员。 此角色通常称为产品经理(即使他们拥有不同的职务),随着知识的增长,他们能够准确预测较小决策的结果,并确定何时需要做更多的面试。 这可保持敏捷性,同时仍确保专注于为内部客户提供价值。
获得一组经过验证的问题和概念后,你便能够确定投资位置。 但是,请考虑评估解决方案时所需的前期投资和长期维护。 解决该问题的最低工作量解决方案往往适合从头开始,但通常是最终决定投资是否成功的维护工作。
换句话说,不要创建面向旅程后期阶段的解决方案,除非你真的需要。
确定最精简可行的平台(TVP)(平台的 MVP)后,请与一组愿意提供反馈的开发团队进行试点。 如果你的试点解决方案解决了这些团队面临的问题,你不应该很难找到有兴趣参与的人。
在试点新功能或更改时,应捕获一些关键指标,以便衡量概念在推出之前是否成功。
衡量你成功程度是产品思维模式的重要组成部分。 即使是投资适度的小成功,也为更大的投资奠定了基础。
例如,对于合规工作,很难获得资金或购买,因为它们可以被视为向提供业务价值的开发团队征收营业税。 产品思维模式可以改变这种感知。 通过产品思维模式,你正在努力确保内部开发人员平台的客户满意,并满足利益干系人的业务目标。 指标使你能够使用事实来证明你提供业务价值。 设置 OKR 可以帮助,特别是如果你有指标,你可以使用这些指标来帮助消除主观偏见。 即使你目前未测量任何适用内容,也可以设置学习 OKR 来设置一个基线,然后在此基线已知后进行优化。
下面是可以衡量的已知指标的示例,以确定你正在使用的团队是否正在从所构建的内容中获取价值。 帮助你衡量你和你的开发团队客户是否正在实现你的目标的人中为零。 例如,下面是一组指标,可帮助你评估平台是否为有效的工程组织做出贡献:
然后,可以按组织、团队或项目细分这些指标。 若要开始,需要测量一些基线,但在改进平台时,可以监视这些指标的变化。
你或发起人可能感兴趣的其他指标包括:
区域 | 示例指标 |
---|---|
软件交付性能 | DevOps 研究和评估(DORA):更改潜在顾客时间、部署频率、更改失败率、还原服务的时间(MTTR) |
Operations | DORA (MTTR),故障平均时间(MTBF),确认平均时间,最终客户可用性,延迟,吞吐量指标,每个团队的成本,每个部署的成本 |
平台功能采用指标 | 一段时间内使用工具或功能的团队或开发人员数、使用平台的存储库百分比、最常用的模板、管道等。 |
收集指标需要时间和精力,因此请务必专注于你确定的核心目标的关键指标,尤其是那些为 OKR 提供支持的指标。 基于 OpenTelemetry 的产品(如 Application Insights )可以帮助。 无论如何,请务必衡量平台易用性和调查,你定期拥有蓬勃发展的生态系统。 对于内部系统,这些指标通常错过,并且是你是否满足更广泛的业务目标的主要指标,因为参与参与对于成功至关重要。 它还有助于了解是否是时候进行进一步的客户开发,以了解下一步要去哪里。
无论如何开始,请记住,你应该计划更改,从试点的新应用程序开始,专注于增强现有用户体验,采用最低特权原则,规划受控试验,并最小化自定义。
目标应用程序平台会随着时间的推移而发展,你可能无法一次性迁移所有现有投资。 思考如何随时间推移支持多个变体并计划更改。
在试点新平台或平台功能时,从大小合理的新应用程序开始。 这还将提供将平台作为产品进行管理的经验。 远离重新平台化项目开始,因为你开始学习,大型现有应用程序通常具有独特的需求,这些需求仅在重新平台工作本身期间才发现。 因此,将成功与这些类型的工作耦合可能会导致预期不匹配或后期中断问题。 从较新的东西开始,你可以对它提供的价值的方向充满信心。 这降低了应对这些更大努力的风险。 换句话说,如果你有信心人们可以开始正确和保持正确,那么通过你从经验中学到的知识推动正确的市场活动变得更加容易。 如果此方法不可行,则需要仔细分析、设置预期并逐步介入,而不是尝试一次性更改所有内容。
开发人员更可能采用并坚持新功能,当他们已经喜欢和使用的东西。 在评估概念以提供新功能时,请务必调查采用扩展现有“重力中心”的选项。例如,编辑器/IDE(Visual Studio、VS Code)、DevOps 套件(GitHub、Azure DevOps)、现有 CLIS 或现有内部门户比全新的门户或其他 UX 更有效。 有关详细信息,请参阅用户体验。
假设开发人员对下游系统的访问权限有限,例如预配基础结构。 你需要一种受控的方式来为自助服务体验启用此访问。
在推出重大或有风险的更改之前进行试验。 并非所有内容都必须完全自动化才能启动。 自动触发的手动工作流是试点理念的好方法。
避免自定义构建应用程序平台功能,这些功能可由软件供应商随时间推移而发布。 例如,运行时托管、服务网格、标识系统等。 如果在怀疑的某个区域中发现迫切需要,请计划多个实施选项,因为长期维护可能会导致你随时间推移而切换。
培训
认证
Microsoft Certified: Power Platform Developer Associate - Certifications
演示如何使用 Microsoft Power Platform Developer 简化、自动化和转换业务任务和流程。