本文翻译自A Platform Team Product Manager Determines DevOps Success。

在其最新的“DevOps 现状”报告中，Puppet 发现拥有一名内部布道者会对平台工程计划产生重大影响。

11 年来，Puppet 的“DevOps 现状”报告一直在跟踪公司交付和开发软件的方式。那么，过去十年我们到了哪里？对于大多数组织而言，答案是：介于两者之间。

事实上，前四期 Puppet 年度报告显示，处于 DevOps 成功这个目标的中间阶段的被调研公司数量变化不大，徘徊在 79% 左右。

然而，也有一些好消息：报告中所谓的“高度进化”DevOps 组织的比例稳步攀升，从 2018 年的 10% 上升到 2021 年的 18%。

进行“DevOps 状态”报告的研究人员注意到一个趋势：在 DevOps 方面取得成功并从中获益的公司很可能采用了平台工程模型。周三发布的报告深入探讨了这种做法。在采用平台工程的调查参与者中：

• 几乎所有人（94%）都同意拥有一个平台团队可以帮助他们的组织更好地实现 DevOps 的好处。
• 超过三分之二 (68%) 的受访者表示，他们公司的开发速度有所提高。
• 大多数拥有平台团队的受访者表示，他们看到了更好的系统可靠性 (60%)、更高的生产力和效率 (59%) 以及更好的工作流程标准 (57%)。

正如报告所说，平台工程是“设计和构建自助服务功能的学科，以最大限度地减少开发人员的认知负担并实现快速的软件交付流程。”

“平台”或自助服务模型以某种形式存在多年，早于 DevOps。但是，正如 Puppet 的技术顾问 Nigel Kersten 告诉 The New Stack 的那样，它们通常是“一种隐藏复杂性的抽象，而不是一种仍然允许你深入了解实际情况的抽象。”

他继续说，现代平台反映了一个事实，即世界之外的世界越来越多地提供自助服务，并认识到包括开发人员在内的用户是“一个市场，你需要构建对这个市场有吸引力的东西。”

更深入地研究最新报告，该报告收集了全球 430 多位 IT 领导者和专业人士的回复，我们发现了另一个惊人的事实。在拥有三年或更短时间的平台团队的组织中，60% 认为需要产品经理；在维护平台团队三年以上的人中，有四分之三的人也是这么认为的。

正如报告所述，平台方法的最初好处相对明显，并且在整个组织中都得到了很好的理解。但是，它写道，“一旦这些能力到位，确定下一个最有价值的能力并确定其优先级是一个更困难的问题——而且需要产品经理的专业知识和奉献精神。”

这对 DevOps 意味着什么？ Kersten 警告说，说 DevOps 在企业中“失败”了可能太过了。但是，他继续说，公平地说“事情很糟糕，对大多数人来说还不错，但并没有那么伟大。”

他认为，其中一个原因是 DevOps 开拓者对“框架”和标准化的过度怀疑。一方面，DevOps 推动了自助服务是必经之路的理念，同时促进了开发人员应该使用他们想要的任何工具的理念。

但 Kersten 表示，围绕 DevOps 的最大迷思之一是团队必须选择自己的工具，因为考虑到不断增长的选择范围，“在规模上，这是一场噩梦”。

标准化有明显的好处，他说，尤其是因为“根据我的经验，如果你能减轻人们的负担，他们会写出更好的代码，你会产生更好的结果。”

企业可以获得更广泛的回馈。 “每次你在组织内从一个项目跳到另一个项目，都会有不同的做法，”Kersten 说。 “你以不同的方式构建软件，以不同的方式测试它，以不同的方式发布它。你对事件的反应不同。”

虽然大部分 DevOps 对话可能都由云原生主导，但 Kersten 指出，该平台模型同样适用于管理更传统的、基于虚拟机的基础设施，这是 Puppet 的一个重点。

他说：“仍然非常需要通过完全重写并迁移到云端的相对传统的应用程序来解决这些问题，这些应用程序永远不会得到投资。”

那么，如果您还没有明确遵循这条道路，那么您从哪里开始呢？

一些组织可能在没有意识到的情况下实施平台工程。同样，如果没有明确分配该角色，某人将滑入产品负责人的角色。

例如，根据云原生转型咨询公司 Container Solutions 的合伙人 Ian Miell 的说法，“你可能会从两三个想要构建 Kubernetes 集群的技术人员开始。他们很快意识到他们有利益相关者，他们有要构建的功能，他们需要制定路线图。有人不小心最终成为了产品负责人。”

Kersten 说，当你在整个组织中构建平台时，重要的是要确保反馈回路相应地扩展。

“如果你首先为自己的团队建立自助服务，这往往是一个更简单的问题，”他说。 “你已经有了反馈回路。在一个团队中，你们应该互相交谈。考虑一下您作为自助服务所做的事情并尝试为自己构建这些抽象概念，那么您就有希望腾出时间。”

随着该平台拥抱其他团队，“如果您无法与实际将要使用您构建的服务的人交谈并找出他们的实际问题是什么，那么您就无法进行平台工程，因为他们的问题将与你的不同。”

“DevOps 现状”报告的调查结果强调，需要具备这些“软技能”的产品经理才能使平台工程取得大规模成功。 61% 的受访者表示，强大的沟通技巧是平台团队取得成功的最重要的产品管理技能。

在其他备受推崇的能力中：

成功的平台团队最重要的产品管理技能是什么？

“DevOps 现状”研究的结果表明了为什么需要产品经理来帮助平台团队取得成功的一个原因：许多 IT 专业人员不仅认为他们的高级管理层不了解平台工程的价值，而且许多人承认自己没有完全理解。

第一张图表的标题，“我所在组织的高级管理人员不了解平台工程可以提供的价值。”答案：强烈同意，12% 一定程度同意，21% 有点同意，16% 有点不同意，29% 强烈不同意，23% 第二张图。标题是：“我（受访者）有时会觉得平台工程的概念很混乱。”回答：非常同意，10% 一定程度同意，21% 有点同意，20% 有些不同意，28% 非常不同意，22%

资料来源：Puppet，“2023 年 DevOps 状况报告”。

在这样的环境中，产品经理可以在团队内外充当平台工程的传播者。

Kersten 说，采用明确的产品管理方法可以让平台工程计划更上一层楼：“产品经理要解决的问题是提高意识、设定切合实际的期望、在用户群中区分不同的优先事项。”

Miell 回应了这种情绪。 “当你揭开这些项目的面纱时，它们总是充满了依赖性、困难和不确定性，”他告诉 The New Stack。 “而且必须有人将其转化为，‘我们计划在未来三个月内为该平台的消费团队交付下一个产品。’”

他说，这与简单地成为一名工程师是一种截然不同的技能，但这是一种互补的能力：“如果不了解技术上正在发生的事情，就很难做好。”

谈到软件，Kersten 指出，“我们正在构建的是社会技术系统。”

他说，问题在于招聘仍然倾向于技术方面。 “我们不看我们有点轻蔑地称之为‘软技能’的东西。我们倾向于将世界分为技术和非技术，并专注于一个，最终导致更糟糕的产品。”

这是否意味着成熟的技术专家不是担任此产品管理角色并启动其组织发展的最佳人选？不一定，Miell 和 Kersten 都说。

但这可能需要领导者发挥一些想象力，克尔斯滕说。 “有些工程师真的很擅长这类工作，”他说。 “而且我认为组织并不总是认识到他们可以聘请多技能的强大技术人员并投资于他们以教他们如何做其他事情。”

他预测，结果是“最终，他们生产的技术会更好”。