平台即产品

第 2 章. 平台即产品

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

平台 和 内部开发者平台(IDP) 这两个术语既可以描述单个现成的平台即服务 (PaaS) 产品，也可以描述组织为内部使用而定制的工具集合。这些定义可能会强化这样一种观念，即平台是基础设施项目，有一个开端、一个交付里程碑，以及一个模糊的希望，即开发人员将使用所构建或购买的东西。然而，这种方法很少能带来持续的价值。

不仅仅是一堆工具

平台不仅仅是工具、模板或工作流程的集合。它是一个不断发展的系统，必须持续响应用户需求。要做到这一点，就不能将其视为一个项目，而必须将其视为一个产品。

采用产品思维首先要不断评估业务环境，以管理 "构建还是购买 "的决策。规模、合规性要求或员工技能基础和技术堆栈的多样性等背景因素往往要求企业放弃现成的解决方案，转而投资于一套针对其特定需求而设计的集成功能。由此产生的平台拥有用户，需要设计、迭代、反馈和明确的价值主张。如果没有考虑到这一切的思维模式，平台团队就有可能成为追逐功能要求的内部服务提供商，而不是注重成果的战略推动者。

本章将探讨向产品思维的基本转变，并概述平台团队如何才能带来超越第一天的价值。

实践中的产品思维

合著者 Colin Humphreys 将平台产品定义为 "一套不断发展的可重复使用的服务，与现有系统集成，为企业创造有价值的成果。它不是一次性交付。它是一种持续的努力，通过有意识的、以用户为中心的设计来支持和加速软件交付（这里的用户是指与平台交互的任何人，主要包括但不限于工程师）。

如图 2-1 所示，这种产品思维需要在可行性（技术上可行的）、可行性 （对业务有意义的）、可用性 （开发人员实际想要使用的）和价值（平台为企业带来的可衡量的成果）之间取得平衡。它还需要传统上与基础架构无关的技能：产品管理、用户体验设计和用户研究。

图 2-1. 产品思维

采用这种方法取得成功的平台团队往往会做到以下几点：

• 直接与用户合作，观察他们与平台的交互方式，找出真正的痛点。

• 建立反馈回路，经常推出小改进，并根据使用情况进行调整。

• 建立内部品牌，将平台定位为可识别、可靠的开发人员体验。

通过从项目交付转向持续改进，平台团队可以获得更大的采用率和更长远的成功。

避免 "一刀切 "陷阱

平台工程中最困难的挑战之一是找到正确的抽象。与解决业务问题相比，应用程序开发人员往往要花费更多时间在非核心开发任务上（如布线环境、管理 CI/CD 或处理 YAML）。精心设计的平台旨在通过合理的抽象和可重复使用的服务来减少这种辛苦。

但是，并不存在适合每个团队的通用 "黄金路径"。强加一种僵化的、自上而下的方法（有时被贬义地称为 "金笼子"）会产生摩擦，导致影子平台或重复劳动。在这种情况下，用户往往会采用附加工具、使用未经批准的第三方服务或寻找其他变通办法来完成工作。相反，抽象应该是可组合和可选择的。抽象应该是指导性的，而不是限制性的。它们应该在降低复杂性的同时不隐藏关键细节。

平台团队应集中精力开发组织独有的功能，并使用现成的解决方案，无论是开源项目、托管服务还是商业产品。毕竟，市场上会不断出现新的功能。您的平台应 "浮于 "现成的功能之上、¹适应和整合这些功能，而不是试图从头开始重建。 ...