平台团队必须设计和营销内部开发者平台，以吸引开发者使用它。以下是如何做到这一点。
译自 Platform as a Product in 4 Steps，作者 Aeris Ransom。
平台工程正在席卷云原生世界，但关于构建成功平台的知识仍有待学习。这个挑战一开始可能让人不知所措，但有一种强大的方法可以简化入门：平台即产品方法。
平台工程 是设计和构建内部开发者平台 (IDP) 的学科。根据云原生计算基金会 (CNCF) 的 平台白皮书，IDP 是：“……自助式 API、工具、服务、知识和支持的基础……以引人注目的内部产品形式排列。自主交付 团队可以使用该平台 以更快的速度交付产品功能，并减少协调。”
要取得成功，平台团队必须构建一个既有效又引人注目的 IDP。有效的平台为开发者、经理和高管解决实际问题。但仅靠有效性不足以推动采用。平台团队必须设计和营销 IDP，以便开发者愿意使用它。平台即产品方法帮助平台团队确定对他们的组织而言有效且引人注目的 IDP 是什么样子的。
平台应该被视为产品的想法可以追溯到 Evan Bottcher 2018 年的文章“谈到平台时我在谈论什么”:
“找到这种平衡的关键因素是平台必须引人入胜，它们不能仅仅依靠授权。”
“团队拓扑” 的合著者 Manuel Pais 和 Matthew Skelton 扩展了平台产品管理。
平台即产品方法涉及定义你的使命、进行用户研究、使用最小可行产品 (MVP) 和最薄可行平台 (TVP) 来有效分配内部资源，以及在内部营销你的平台 以确保支持。以下是平台工程社区的从业者分享的关于他们经验的内容。
新的平台团队经常会遇到关于其领域职责、如何与其他团队协作以及成功是什么样子的相互矛盾的观点。 创建使命宣言 可以帮助定义平台团队的身份。在 Doma，Michael Galloway 的团队采访了开发者，与其他利益相关者群体交谈，并评估了定量绩效指标，以确定他们的目标：“快速轻松地构建出色的产品”。
有力的使命宣言就像好的流行歌曲：它们简单、有意义，能让人产生共鸣。Galloway 说：“要让一个目标发挥作用，你必须感受到它，而不仅仅是知道它。”
构建一个解决实际问题并赢得开发者青睐的平台需要深入了解他们的工作流程、挑战以及现有解决方案的不足之处。成功的平台团队使用各种类型的用户研究和反馈来为其 IDP 路线图提供信息。他们通过选择低接触和高接触研究方法来平衡反馈的数量和质量。
- 低接触： 调查可以快速有效地收集广泛的情绪，并从大量的开发者群体中识别出常见的痛点。
- 中等接触： 征求意见 (RFC) 和个人访谈更耗时，但使开发者能够详细阐述具体问题并提出解决方案。
- 高接触： 将平台倡导者或支持团队直接嵌入开发团队中，可以提供最丰富的反馈和背景。这种方法允许实时观察工作流程和第一手体验开发者的挫败感。
根据 OpenCredo 的 Nicki Watt 的说法，技术平台产品经理在这里扮演着至关重要的角色。他们充当翻译，将潜在的相互矛盾的观点综合成可操作的路线图。他们将努力了解开发者想要什么，并构建开发者需要的东西。
记住，用户研究不应是一次性的活动。它是整个平台生命周期中的一个持续过程。通过持续收集反馈，平台团队可以确保平台保持相关性并满足不断变化的业务需求。
平台具有无限潜力，但平台团队的资源有限。最小可行产品 (MVP) 和最精简可行平台 (TVP) 是有助于优化分配这些资源的概念。
采用 MVP 方法，平台团队可以创建获取用户反馈所需的最基本版本的产品。MVP 帮助平台团队验证核心假设，避免将资源浪费在不必要或无效的功能上。自助文档 可以是 MVP。
TVP 是 Skelton 和 Pais 引入的一个补充概念：
“加速开发现代软件服务和系统的最少 API、文档和工具集。”
随着时间的推移，构成 TVP 的内容自然会发生变化。随着第三方解决方案变得与组织的内部工具具有竞争力，平台团队必须在维护构建组件或外包给供应商之间做出选择。采用 TVP 方法，平台团队仅将内部资源分配给提供独特业务价值的内容。
构建 IDP 是一项重大任务。平台团队必须推广其工作，以维持整个组织中利益相关者群体的支持。
在 2023 年 PlatformCon 演讲“ 如何传达平台工程的业务价值”中，Gartner 的 Manjunath Bhat 指出，许多平台团队难以解释平台工程的价值，而不仅仅是 DevOps。当从不了解工程改进如何影响更广泛的业务优先级的非工程利益相关者那里获得支持时，这会带来问题。平台团队在传达业务价值时应学会使用不同利益相关者群体的语言。
灵感来源： https://www.youtube.com/watch?v=ApEOiNC4GrA
使产品方法具有挑战性的一件事是，许多团队认为自己在遵循该方法，但实际上并非如此。以下是 Watt 在她的演讲中提出的关于该主题的一些常见误解：
- “我们的用户就像我们一样！” 平台工程师更接近他们的用户，并且经常无意中对他们做出更多假设。但是，构建有效且理想的产品需要相同的流程，无论用户是内部用户还是外部用户。
- “我们可以强制使用该平台！” 强制采用平台会阻止开发人员自愿提供反馈，并且总体上会造成更多安全漏洞。
- “我的方式或高速公路！” 一些平台团队认为最好强制执行一种正确的方法来做事。但是，过于规范的平台可能会迫使开发人员采用次优解决方案。
- “我们不需要平台产品经理！” 一些组织不愿为内部工具专门配备一名 PM。但是，PM 专注于了解开发人员的挑战，并以工程经理或平台工程师无法做到的方式维护平台团队与相关利益相关者之间的关系。
- “让我们立即开始构建！” 先构建的问题在于，它假设最佳解决方案是技术性的。成功的平台团队会在适当的时候使用不同的支持形式。
平台即产品方法对于构建成功的 IDP 至关重要。通过将 IDP 视为具有明确使命、用户研究和目标营销的产品，平台团队可以确保他们构建的不仅是开发人员需要的，而且是开发人员想要使用的产品。
这种方法并非没有挑战。平台团队必须避免对内部用户做出假设、强制使用或将技术解决方案优先于用户支持的诱惑。这就是平台工程社区可以提供帮助的地方。
有关更多平台工程资源，请访问 Mia-Platform 博客。了解平台工程中的其他热门话题，例如对开发者生产力的影响、内部开发者平台的七个核心组件以及铺设黄金路径。