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