How are staff and funds allocated to platform capabilities?
对平台和平台工程的投资是分配预算和人员以建立和维护通用能力的过程。通常情况下，各种举措被描述为自下而上的有机建设，或通过自上而下的举措来推动。无论哪种情况，都是持续投入的能力推动了高影响力的工作。这一方面体现了投资规模和广度如何影响平台的成功。
第一阶段，临时性——基于自愿或临时安排
单个能力的存在可能是为通用或关键功能提供共同的基础。这些能力的建立和维护是出于需要，而不是有计划的和有意资助的。
这些能力由被临时或自愿指派的人员构建和维护；没有专门为它们分配集中的资金或人员。它们依赖于用户当前的战术需求。
特点
为应对紧急需求，会组建“打击”或“突击”团队。这些团队的存在时间很短，既没有被指派也没有被给予进行长期规划和支持的时间。
迁移、改进或增强通常被视为“锦上添花”的工作项，依赖于“研究”或“黑客松”等方式的努力。
在处理新需求时，例如紧急安全补丁，可能会引入流程改进或自动化，但没有支持以可复用或可持续的方式构建解决方案。
员工抱怨因在其核心角色之外的工作量而感到疲惫和沮丧。
示例场景：
有一名特定的雇员被视为测试环境专家。虽然这位员工意图良好，但他们在有限投资下努力改善测试环境的尝试导致了风险增加，因为他们的解决方案没有得到维护，且没有共享关于如何处理坏掉的测试环境的理解。
当管理层对产生收入的功能没有施加压力时，工程师们被鼓励投资于提升能力的改进。这意味着在一些sprint的最后几天，他们会优先考虑自动化和改进他们CI/CD流水线的某些部分。这些改进往往是突发性的，因为可能有几个月的冲刺任务过于繁重，不能再在这些方面花费时间
第二阶段，可操作 — 专职团队
为持续的人力和资源支持分配预算和人员。被指派的人员负责提供一系列常用的能力，以加快软件交付。这些小组往往把重点放在满足被动技术要求上。他们可能被称为DevOps、工程支持、开发者体验（DevEx 或 DevX）、共享工具、卓越中心，甚至是平台。他们的资金来源是集中分配的，被当作一个成本中心来对待；而他们对直接产生价值的流程和应用开发团队的影响并没有进行评估。在这个级别上，平台团队对组织及其价值流的影响可能难以衡量， 这可能使维持和继续为这种小组提供资金变得很困难。
特点
团队几乎全部由技术通才组成。
团队预算可能包括与他们的工作相关的基础设施成本，这通常是预算讨论中的一个关键点。
待办事项涵盖多种技术，导致频繁且大规模的上下文切换。
这个团队通常是首个填补尚未解决的空白的团队，即使这不在团队声明的范围内。这个团队接管了无主的资源。
被指派的人员很少有时间或经验进行客户研究，以验证他们的设计或实现。
示例场景：
- 应用开发者提出他们的应用开发时间过长的问题。一个核心的团队被指派任务，要将构建时间缩短50%。他们通过将CI runner的大小和数量增加一倍来解决这个问题，因为他们离软件太远，无法单独改进应用构建。这给他们的核心团队带来了预算上的担忧，因为生产力的提升无法直接与增加的基础设施成本进行量化对比。
第三阶段，可扩展 — 作为产品
对内部平台及其功能的投资类似于对企业外部产品和价值流的投资：这基于它们预期为客户提供的价值。产品管理和用户经验得到明确考虑并投入使用。收费制度可用于反映平台对客户本身直接价值流和产品的影响。企业使用数据驱动的绩效指标和反馈循环，为适当的举措分配资金和员工。平台团队最终可以优化业务本身，并有助于提高盈利能力。
特点
平台团队配置的角色不仅限于传统的内部服务或技术团队，例如产品管理和用户体验。
团队向组织内部公布路线图，指明提供的价值和高层次的功能目标。
在设计、交付和部署后，功能都要经过实施质量和用户体验的测试。
功能移除是讨论的关键部分，目标是拥有一套受到良好支持、良好使用的能力，而不是一片可能无法维护的庞大领域。
示例场景：
- 从平台使用度量表中得出的数据为决定将资金和工作人员分配给影响最大的举措提供了依据。
第四阶段，优化-已启用的生态系统
平台小组设法提高全组织超出基本能力的效率和效益。核心平台维护者有意致力于优化新产品的上市时间，降低企业整体成本，实现新服务的高效治理和合规，快速且轻松地扩展工作负载，以及其他横向需求。这些核心维护者专注于使专业能力方面的专家能够无缝地将他们的需求和产品整合到平台的现有和新部分中。此外，本组织集中精力利用安全、业绩等专门领域的人员和资源。通过参与提供的平台框架以引入高级功能，使产品团队能够在不依赖集中团队积压的情况下加速实现公司目标。
特点
示例场景：
Why and how do users discover and use internal platforms and platform capabilities?
采用不仅描述了一个组织使用平台功能的方式和程度，还描述了他们这样做的动机。在早期阶段，许多目标用户可能根本没有意识到他们在使用一个平台。相反，他们将他们的工具视为来自各种内部资源的功能的临时集合。随着时间的推移，这可能会发展成为一组能力，并由一个或多个平台进行统一管理并呈现给用户。随着功能的日益完善和可发现性的提高，平台的驱动力通常会从更多的外部动机（如授权或激励）中转移出来。这导致用户自主选择平台功能，甚至在理想情况下将自己的精力投入到更广泛的平台生态系统中。
第一阶段，临时-不稳定
对共享平台和功能的采用是不一致的。在选择和整合所需的技术能力和支撑服务方面缺乏组织范围内的战略或指导思想。个别团队可能会利用平台实践来改进自己的流程，但整个组织内没有协调或实现标准化。这个阶段采用的特点是缺乏一致的方法论，认为外部工具比内部工具更有效。
特征：
由组织内不同团队或部门分别管理和使用一次性的工具、服务或能力。
由于内部配置很难被找到或使用，供应商管理（又称“云”）服务的采用和使用前后不一致，没有标准做法和策略。
应用程序和服务团队探索工具和功能的方式五花八门，都是通过传言和偶然的对话，而不是通过更集中的流程。
即便组件和能力的协调和复用方式存在，也只能由最终用户（应用团队）来驱动。
每个产品团队各自维护一套脚本或工具来部署自己的应用程序。
示例场景：
- 假设一个银行服务需要一个数据库。一个开发者从另一个团队的朋友那里打听到他们可以通过请求创建一个AWS帐户并初始化一个RDS数据库实例。从另一个团队那里他们打听到可以使用Terraform脚本来实现该需求。为了使用CloudWatch来监控这个实例，在运行Terrafrom脚本之前，他们需要手动将AWS控制台中的密码复制到Hashicorp密码库中保存。
第二阶段， 可操作化——外在驱动力
组织认识到共享平台和能力的价值，并加以鼓励以实现不断演进和发展。内部指令鼓励甚至要求在某些场景中使用共享平台服务 一些产品团队比其他团队更多使用平台功能；功能涵盖组织中的典型案例，但不包括特殊案例；很难将这些特殊情况添加到共享平台中。
用户对能力的发现以及如何使用这些能力并不一致；除非由平台团队指导，否则产品团队的用户可能不会发现平台所支持的功能
特征：
在一定程度上的外部驱动力导致平台能力的使用，例如：
激励措施，如个人审查等
任务规定，如要求用于生产发布或接受赞助等
对平台功能的利用是分散的–用户可能会利用一种功能，但可能不知道或没有兴趣采用其他可用的功能。
用户学习如何使用平台功能的积极性不高，在很大程度上依赖于在工作时间内通过服务台等渠道与供应商进行合作。
鼓励平台用户加入非正式实践社区，以分享问题和解决方案，但参加人数可能有限。
示例场景：
- 一个工程组织决定采用一种符合标准的部署工具，并推广所有团队使用这一工具。新的流程（发布说明的沟通等）都是围绕该标准建立的。各团队被要求停止使用其他类型的部署脚本，转而使用通用工具。这对一些团队来说很困难，因为新流程无法满足他们的需求，但他们又不理解或不允许扩展新流程。
第三阶段，可扩展——内在拉力
产品和服务团队的用户之所以选择使用平台及其功能，是因为它们在减轻产品团队的认知负担、提供更高质量的支持服务方面具有明显的价值。文档和符合人体工程学的界面使产品团队用户能够快速配置和使用平台功能。用户会选择内部平台实现，而不是自行开发功能或雇佣供应商。
特征：
平台的采用是自我维持的 - 核心驱动力不是强制用户使用平台产品的外部动力或激励措施，而是这些平台本身的价值吸引用户使用它们。
在使用并理解了一个或一些平台能力后，用户会寻找其他功能，并发现不同功能的体验是相似的。人们期望某一项功能不是孤立的，而是一个较大的平台功能集中的一项功能。
平台团队通过收集用户反馈、分享规划蓝图和维护与用户对话的开放论坛，鼓励平台的自然演进。
应用和产品团队对平台功能的重视程度足以为其付费，例如通过付费系统。
用户可以通过公开论坛和共享路线图分享反馈和了解即将到来的功能。
自助服务门户、黄金路径模板和其他文档可以快速使用。
示例场景：
- 一个应用程序团队之前曾成功申请过一个新数据库。他们的流程简单易懂，几乎不需要等待时间。此外，还包括备份和监控等关键功能，使该团队能够顺利地将其使用交付到生产阶段。这种成功经历意味着，当团队后面需要一个消息队列时，他们的第一反应就是查看内部平台选项是否支持。尽管他们最初打算使用特定的队列技术，但最终还是选择了使用内部提供的技术方案，因为他们知道该解决方案将如何很好地集成到他们的组织中。
第四阶段 优化——参与
产品团队的用户通过加入生态系统并为其做出贡献，进一步投身于平台功能发展。有些贡献是对现有功能的改进和修复，有些则是为解决新的使用案例而引入新的功能和特性。已定义的流程和服务使用户能够确定需求，并在多个产品和平台团队之间进行协调。新的功能通过统一的界面和门户发布，并配有完整的文档和标准版本。
特征：
应用/服务团队的用户有权为平台能力提供修复、功能和反馈。
战略性地利用外部项目和标准，以降低维护成本，加快新功能的交付，并最有效地使用组织人员。
新功能和增强功能通过 Issue 和 PR 进行协调。文档和核对表使贡献者能够进行自我驱动的开发。
开发人员倡导者和项目内部领头人建立和维护一个内部用户社区，将平台所有权扩展到应用程序和服务团队贡献者。
领导层和个人贡献者都将使用平台功能视为在组织工作的最佳方式。
平台工程师参与产品团队规划，了解需求并提出相关的现有功能建议。
示例场景：
- 一个团队想要一个备份计划。在将其作为一般提案提出后，由于复用程度极低，该方案被认为优先级较低。提议团队选择将其解决方案集成到平台框架中，并提供给本组织使用。该方案最初只是一个辅助方案，但一旦满足了所有业务要求，就可以提升为平台核心功能。
How do users interact with and consume platform capabilities?
平台提供的接口会影响用户与这些平台进行配置、管理和观察的方式。接口可以包括工单系统、项目模板、图形门户以及可自动API和命令行(CLI) 工具。
一个接口的关键特征包括在关键用户流程（如初始请求、维护或故障排除）中的可发现性和用户友好性。较高的成熟程度反映了更加一体化、一致、自动化和支持的接口。
第一阶段：临时–自定义程序
有一组不同的程序来提供不同的能力和服务，但没有考虑接口的一致性。即使定制化程序提供者使用了一些自动化的执行脚本，定制程序能满足个人或团队的眼前需要，但是程序也需要人工干预。
对于如何获得这些程序问题的解决方案都是靠人们口口相传。这些创建这些的自定义程序的过程缺少标准化和一致性。配置和使用平台服务可能需要能力平台开发者的大力支持。
在公司尚未能明确记录程序未来需要做到什么程度的时候，这种缺少一致性要求和标准是可行的。这种自定义程序对处于早期阶段的公司或平台工作中的团队是极其有效的。在这些情况下，小组可以自由地根据自己的需要发展各种过程和能力。只有在必要时在做标准化， 以便能够更快地交付。
属性：
用户互动不是讨论的一个关键主题，很少（如果有的话）在设计和交付新能力时对互动进行测试。
能力主要是通过手工请求提供的，但平台开发者可能会选择将提供用户请求所需的部分或全部活动自动化。
表面上的“简单”请求变得复杂，是因为找出了遵循的正确过程。
有时候一个流程似乎是经过认可的，但是当不同的部门或团队介入时，用户会就遇到问题。
示例
一个应用程序团队想要测试他们的新更改。要做到这一点，他们需要一个包含足够测试数据的孤立环境，以便获得准确的性能读取。上次他们使用这个请求时，是一名前队员能够进入这个环境。但是自从环境变化了之后，就没有人知道怎么创建这个请求了。最后，他们与基础设施小组的一名工程师联系起来，后者能够在几天内为他们提供一个环境。
在产品开发的探索阶段，一个团队使用定制流程来提供新的云服务，而无需验证他们的解决方案是否需要进一步投资
第二阶段：可操作性–标准工具化
由于存在一致且标准的接口来提供和监控平台的功能，并这些接口满足了广泛的需求。用户能够确定现有哪些能力，并能够要求具备所需能力。
现在就有了通过文档和模板形式提供的所谓的”铺装路面“和“黄金路径”。这些模板资源定义了如何使用合规且经过测试的模式来配置和管理型的功能。虽然有些用户能够独自使用这些解决方案。解决方案往往仍然需要深入的领域专业知识，因此平台开发者的支持仍然至关重要。
属性：
技术解决方案是专门针对其问题领域内的工具，并非总是用户熟悉的工具。
在公共路径上进行了投资，但是一旦偏离这条路径，很快就会发现定制选项很少，因为重点是构建单一选项。
由于标准化，非正式内部小组能够组织聚集在一起，团队内可以交流良好做法，克服共同的问题。
在团队采用模板、进行定制化后，可能会出现实施的偏离，并且无法将来自核心团队的更改合并进来。
示例
第三阶段：可扩展–自定义解决方案
提供解决办法的方式为用户提供自主权，几乎不需要维护者的支持。组织鼓励并支持解决方案提供一致的接口，以实现用户体验在不同能力之间的可发现性和可移植性。虽然是自定义解决方案，但是这仍需要团队的能有对应的认知和实现 为了快速提升这些经验，在组织内部可能有指导性和简化的内部语言，使用户能够更快地适应和整合平台能力。这样的平台将产生以用户为中心、可自定义和一致的能力。
属性：
提供的解决办法是“一键式”的实施方案，使团队能够从平台的能力中受益，而不必了解如何这些能力是如何实现的。
尽管解决方案的创建过程可能相对容易，但在解决方案的日常管理和后续阶段可能没有充分考虑可用性的建设。
用户在面临独特需求时可能会感到困惑，因为可用的解决方案仍然相对有限。
示例
- 提供一个 API 来提取数据库的创建和维护，并为用户提供它们所需要的任何信息，以利用平台能力，例如连接字符串， 保密数据的位置和带有观察能力数据的仪表盘。
第四阶段：优化–可管理的服务
团队已经毫无阻力的降平台能力集成到了日常的流程与工具中。有些能力是自动提供的，例如部署服务的观察能力或身份管理能力。由于平台的模块化构建方式，当团队在遇到超出平台能力的情况的时候，可以根据自己的需求进行定制，而不需要脱离内部提供的服务 这些构建模块被用来构建透明自动组件，以满足更高级别的用例，同时在必要时实现更深层次的定制化
属性：
清楚地了解哪些能力是组织的差异化能力，哪些能力不是，使得内部团队能够在无法利用行业标准的地方专注于定制解决方案的投资。
虽然能力以一致的方式呈现出来，但并没有一种固定的使用方式。有些工具最适合作为CLI工具用于脚本，而另一些工具则更适合用户在编辑器和IDE中。
通过关注软件开发和发布的流程，将个别能力的价值扩展，从而将重点放在如何将能力组合成更高级别的产品或服务上。
虽然能力往往以一揽子方式提供， 但是超级用户能够按需提供能力，以便能在需要的时候优化。
示例
每个工作负荷都注入了可观察的agent，并将一个可观察的代理置于所有应用程序的前面。
默认情况下，每个新项目都会在任务运行器（pipelines）中获得一个空间和一个运行时环境（K8s命名空间）。然而，项目可以选择其他选项，如无服务器运行时。
从现在的服务门户中的目录，用户选择"提供数据库"。自动化提供了一个RDS数据库，并且发送一个 URL 和地址给用户获取账号密码。
How are platforms and their capabilities planned, prioritized, developed and maintained?
平台的运营意味着在其整个生命周期内运行和支持其功能及其特性，包括接受新请求、初始发布、升级和扩展、持续维护和运营、用户支持，甚至废弃和终止。组织及其平台团队选择要创建和维护的平台和能力，并可以优先考虑最有价值和最有影响力的项目。
值得注意的是，提供功能的大部分工作都是在其最初发布后进行的——包括提供无缝升级、新功能和改进功能、运营支持以及用户的启用和培训。因此，一个有影响力、有价值的平台将提前计划并管理他们的平台，以实现长期可持续运营和可靠性。
第一阶段，临时-不稳定
平台和能力是根据临时的产品团队请求和需求进行反应性开发、发布和更新的。产品团队甚至可能需要规划和构建他们所需的能力。
那些构建新能力的团队，无论是专门的集中团队还是满足自身需求的应用团队，只对支持其他人使用该能力承担非正式的责任。他们不需要积极维护它，并且很少有流程用于评估该能力的质量。在这个级别上，实施通常被忽视，直到发现安全漏洞、错误阻止使用或出现新需求时，才会迅速实施另一个反应性计划。
特征：
为满足各个应用团队的紧迫需求而创建的
重点是初步提供核心能力；没有为持续的维持和可持续性制定计划。
能力实施通常已经过时，等待更新。
突发性的工作量增加是为了应对对能力的重大变化，例如发现了漏洞。
变化可能导致计划内和计划外的停用。
每次升级都以定制方式进行，需要时间和研究来设计每次升级的流程。
示例剧情：
示例场景：
- 发布了Log4Shell安全漏洞，该组织成立了一个专门的团队来调查组织可能存在脆弱性并进行修补。一旦团队确定影响范围，他们必须与多个不同的团队紧密合作，因为每个团队都以不同的方式管理其服务器和升级流程。即使完成了此项工作，对于不会出现更多的漏洞实例，信心水平仍然相当低。
第二阶段，运营化 — 专职团队
平台和能力的信息都有集中的文档记录和可查找性，并且规划和管理能力生命周期的流程至少有轻微的定义。每个服务和功能的责任和所有权都有文档记录。针对不同的能力，生命周期管理流程会因其所有者和优先级而有所不同。一个集中的团队负责维护现有能力的待办事项清单，或者可以根据需求生成待办事项清单，以提供当前能力的维护状态。这使得组织可以追踪能力提供和升级要求的合规性的进展情况。
特征：
应用小组根据需要建立新的能力，以满足迫切的需要。
一个中央小组负责登记整个组织现有的共享服务。
对于功能，采用宽松的标准，例如要求具备可自动化的API和使用文档。
基础设施即代码（Infrastructure as Code）的目的是为了实现更轻松地追踪部署的服务。
符合PCI DSS或HIPPA等合规性法规的审计是通过服务清单来实现的。
迁移和升级工作是根据火焰图进行跟踪，使组织能够跟踪合规率和完成时间。
跟踪不表示支持水平；通常在此阶段升级仍然是手动的，定制化的。
示例场景：
- PostgreSQL 11将于年底结束生命周期。组织已经意识到哪些数据库需要升级，并正在安排每个团队的工作，以完成升级。
第三阶段 可扩展-集中启用
平台和能力不仅是集中注册的，而且也是集中协调的。平台小组负责了解本组织的广泛需要，并相应地确定平台和基础设施小组的工作优先次序。负责某项能力的人不仅需要在技术上对其进行维护，还需为能力与组织中的其他相关服务进行标准用户体验的整合，确保安全稳定的使用，并提供可观测性。
建立和发展新能力的标准进程已经存在，使本组织的任何人都能够提出符合预期的解决办法。平台能力和功能的持续交付流程使得能够正常推出和回滚。计划和协调大规模的变革，因为它们将用于客户面对的产品变化。
特性：
示例场景:
- 该组织将升级到RHEL 9。在这样做的过程中，每个应用程序团队都需要验证他们的软件是否继续正常运行。为了实现这一测试阶段，中心计算团队为每个团队建立了正确的软件和操作系统版本的测试环境。
第四阶段：优化–可管理的服务
每个能力的生命周期都以标准化、自动化的方式进行管理。功能、特点和更新将持续不断地提供，不会对用户造成任何影响。由平台提供商发起的任何大规模变化都包括对现有用户的迁移计划，其中包括明确的责任和时间表。
平台能力提供商肩负起大部分维护责任，但存在着一个明确的合同——“共同责任模型”，该模型描述了用户的责任，并使双方能够基本上独立运作。
特性
示例场景：
- 虚拟机的用户不需要管理与版本升级有关的任何事情。他们唯一的要求是在交付流程中包含一个具有代表性的冒烟测试阶段。然后，他们被要求将他们的应用程序声明为具有较低的风险承受能力，以等待一个完全稳定的升级或更高的承受能力来成为早期采用者。虚拟机功能随后负责自动发布升级版本的管理，包括在烟雾测试或金丝雀发布失败后执行回滚操作。
What is the process for gathering and incorporating feedback and learning?
通过对用户的明确和隐式反馈做出反应，组织可以提高用户满意度并确保长期的平台可持续发展。组织必须在创新和满足用户需求之间取得平衡，以保持平台的相关性。随着科技和用户偏好的改变，能够灵活而及时响应这些变化的平台将脱颖而出。定期重新审视和完善反馈机制，可进一步优化平台开发，改善用户参与。
第一阶段，临时-不稳定
对于每个平台和功能，使用情况和满意度指标都是以自定义方式收集的（如果有的话）。不同能力的结果和成功衡量标准并不一致，因此没有收集相应的见解。可能不会收集用户反馈和平台使用情况，即使收集了，也将是非正式的。决策是根据轶事要求和不完整的数据做出的。
特征：
示例场景：
平台技术负责人希望通过在下一个季度计划中添加关键主题来改善与用户的协作。他们决定对用户希望看到的内容进行调查。反应是压倒性的，这令人兴奋，但也导致难以组织和回应所有想法。虽然某些想法会影响季度计划，但用户并不认为他们的想法被接受，并且不太愿意回复下一次调查。
该团队希望自动捕获更多数据，因此他们寻找轻松收集的机会，例如 CI 中的测试失败。然而，并非每个团队都使用相同的 CI 自动化，因此数据仅适用于 Java 应用程序，尽管有些团队已开始使用 Scala 编写服务。
第二阶段 可操作——一致的收集
此级别的组织有一个有意的目标，即验证平台产品是否满足其内部用户市场的需求。可操作的、结构化的用户反馈收集受到重视。可能会指派专门的团队或个人来收集反馈，以确保采取更加一致的方法。反馈渠道（例如调查或用户论坛）是标准化的，并且反馈是分类和优先级的。除了用户反馈之外，还期望用户体验能够随着时间的推移生成使用数据。
将反馈转化为可操作的任务仍然面临挑战。尽管用户数据存储库不断增长，但组织可能需要帮助有效地理解这些反馈并将其集成到平台路线图中。可能很难确保用户看到由他们的反馈驱动的切实变化。
特征：
示例场景：
平台团队将 20% 的时间分配给用户定义的功能，这些功能是他们根据调查和其他访谈技术确定的。他们的发现被收集到一个工具中，该工具可以进行额外的投票和评论，以进一步完善优先事项。在实施过程中，我们会联系提出请求的用户，以就早期设计和实施进行协作。一旦实施，就会发布公告，确保请求用户了解新功能并支持采用它们。
专注于软件交付功能的团队希望自动捕获更多数据，包括他们通过构建工具自动化从提交到生产的周期时间。有一种理解是，周期时间可以包括其他活动，如审阅，但目前尚未包括在内。
第三阶段，可扩展——内在拉力
虽然已经存在强大的标准反馈机制，但在此阶段，数据是通过精心设计的方式收集的，以产生具体的战略见解和行动。确定期望的结果和结果，然后选择标准指标来表明实现这些结果的进展 行业框架和标准可用于从对某些行为影响的行业研究中受益。
采用专门的团队或工具来收集和审查反馈并总结可行的见解。平台产品与其用户建立了共生关系。反馈被视为指导平台运作和路线图的战略资产。可以定期举办反馈审查会议，让跨职能小组聚集一堂，根据用户的见解进行讨论和制定战略。
特征：
在提供任何新的平台功能之前，该小组讨论如何评价其工作成果。
该组织在表明平台计划成功的衡量标准上有着广泛的一致性。
[产品管理员]({https://deploy-preview-754–tag-app-delivery.netlify.app/zh/wgs/platforms/glossary/#platform-product-managers})或专职团队成员推动持续和一致的反馈收集和分析进程。
该组织制定了衡量尺度和目标，以观察和确定目标来表明成功。
示例场景：
- 本组织一直在追踪构建时间和周转时间。然而，他们现在认识到，虽然很容易收集，但仅仅收集这些数据并不能全面反映软件的交付情况。考虑到这一点，该小组对服务的可靠性和稳定性进行衡量。
第四阶段 优化 — 定量和定性
反馈和计量已深入融入本组织的文化。整个组织从高层行政人员到整个工程师组织都认识到收集数据和对产品演变反馈的价值。数据实现了民主化，其中包括平台用户和企业领袖。积极参与确定平台改进的假设，在设计过程中提供反馈，然后衡量影响后的交付情况。在规划平台举措时将考虑到所有这些衡量标准。
不仅标准框架得到了利用，而且人们认识到，从多个角度进行衡量可以产生一种更全面的情况。需要投入精力了解定性指标如何随着定量指标的改进而变化。重点是确定领先的措施，这些措施可以预测支持用户需求、减轻他们的挑战并领先于行业趋势和业务需求的功能。
特征：
平台小组不断设法改进他们观察的衡量标准及其收集数据的方式。
该组织熟悉
Goodhart的定律并对其敏感：“当一项指标成为目标时，它不再是一个良好的衡量标准。”
对收集到的指标和遥测数据进行持续评估，以获得真正的洞察力和价值。
指标数据管理得到良好支持，例如用于管理数据湖和获取见解的标准平台功能。
鼓励跨部门协作，以避免数据孤岛，并能够建立有效的反馈周期。
示例场景：
- 随着时间的推移，该组织收集的数据表明，构建时间增加了15%以上。这会引发负面的开发者体验，一旦触发，即使构建时间缩短到原始时间以下，开发者仍然感到沮丧。这种洞察力促使构建团队设置和遵守服务级别目标 (SLO)，这使得能够在引发与其成员的负循环之前尽早识别和改进。