通过最小可行平台和最精简可行平台，平台团队可以优化分配资源，快速交付功能并最大化业务价值。
译自 Platform Teams: Start Small to Win Big，作者 Aeris Ransom。
这是每个平台工程师最可怕的噩梦：你的开发人员讨厌你的团队花费数月（或数年！）构建的内部开发人员平台。平台采用率低，关键利益相关者准备放弃平台工程。哪里出了问题？你的平台团队如何避免这种不幸的命运？
从业者很快了解到，在平台工程中，更大并不总是更好。相反，成功属于从小做起并保持精益的平台团队。正如“团队拓扑”的合著者 Manuel Pais 所说，“一个好的平台足够大，但不会更大。”
这并不意味着偷工减料，而是使用两个关键概念：最小可行产品 (MVP) 和最薄可行平台 (TVP)。使用这些方法，平台团队可以优化分配内部资源，确保他们快速交付正确的功能并最大化平台的独特业务价值。
“精益创业”的作者 Eric Ries 将 最小可行产品 (MVP) 定义为“新产品的一个版本，它允许团队以最小的努力收集最大数量的 关于客户的经过验证的学习。”
换句话说，MVP 是 获取用户反馈所需的最简单的产品版本。通过从小做起，平台团队可以验证核心假设，避免将资源浪费在开发人员既不想要也不需要的功能上。
遵循 MVP 方法，平台团队首先与他们组织的开发人员交谈。他们进行用户研究以识别和了解开发人员面临的最重大挑战。开发人员很可能已经找到并实施了针对持续问题的不同解决方案。平台团队应识别现有解决方案的局限性，并设计一个引人注目的替代方案。MVP 应该是一个学习工具，而不是一个成品，因此它不应该试图支持所有用例。平台团队应构建解决痛点的所需最小功能。
Mia-Platform 的交付经理 Francesca Carta 建议将 MVP 部署到一个小型“先锋团队”进行测试。然后，平台团队可以使用先锋团队的反馈在向更广泛的用户群发布之前对解决方案进行迭代。
开发 MVP 通常需要一到三个月。这个缩短的时间表使平台团队能够快速了解开发人员的需求。平台团队可以根据早期反馈进行调整，并以最小的投资创建有效且引人注目的平台。
根据 Carta 的经验，平台团队还可以使用 MVP 方法成功实施第三方工具：
“不要从自动化所有事情开始；从解决团队的主要问题开始。例如，如果部署是一个巨大的痛点，你应该专注于使其成为一种自助服务功能。然后，在第二阶段，你可以添加基础设施配置的插件。”
因此，平台团队可以迭代新工具更有限的实现的成功。快速的反馈仍然很重要，因为将开发人员迁移到第三方解决方案可能会产生与将开发人员迁移到内部工具一样多的摩擦。
构建 MVP 不仅仅是为了让开发人员参与进来。太多平台计划失败，因为平台团队无法足够快地向利益相关者证明其价值。Carta 说，当平台团队一开始就尝试设计所有用例而不是专注于 MVP 时，这个问题最常出现。她建议团队通过快速但有意义的胜利来锁定利益相关者的投资，然后进行迭代。
虽然 MVP 方法帮助平台团队开发新功能，但最薄可行平台 (TVP) 方法帮助团队在平台的整个生命周期内优化分配内部资源。Pais 和他的合著者 Matthew Skelton 将 TVP 定义为：
“加速开发现代软件服务和系统的团队所需的最少 API、文档和工具集。”
随着时间的推移，组织的 TVP 会发生变化。随着第三方工具变得更具竞争力，平台团队必须在改进自定义组件或从供应商处购买之间做出选择。Carta 在定义 TVP 时说：“您必须作为一家公司做出选择：您将在公司内部构建什么？您将维护什么？”通过 TVP 方法，平台团队仅将内部资源分配给提供独特业务价值的内容。
Syntasso 的 Abby Bangser 分享了 MOO 的自定义可观察性工具是如何在担心浪费之前的投资和供应商锁定恐惧的情况下被供应商提供的选项取代的。在转换后的几个月内，好处显而易见：
“由于 MOO 现在为另一家公司支付费用以在跟踪方面进行创新，因此我们作为内部平台工程师可以浮到堆栈的更高位置，专注于提供更多 MOO 特定的好处，而不是维护现在过时的内部服务。”
在他的 PlatformCon 2022 演讲中，“平台的魔力”，作者 Gregor Hohpe 从浮动平台与下沉平台的角度讨论了平台的精简性。想象所有平台都基于 Kubernetes 等基础平台。随着时间的推移，此基础平台获得了新的特性和功能。Hohpe 将其比作上升的水位。无法适应涨潮的平台将下沉；它们将继续复制基础平台提供的功能。使用浮动平台，平台团队会战略性地外包或淘汰冗余特性。这释放了内部资源，以便专注于创新，构建基础平台提供的功能之外的功能。
根据 Hohpe 的说法，这两个选项本身没有优劣之分。关键在于主动决定您的平台是浮动还是下沉，然后将计划传达给利益相关者。在构建浮动平台（即维护 TVP）时，平台团队应公开外包或淘汰内部开发特性的可能性。否则，当数月甚至数年的工作被第三方解决方案取代时，利益相关者可能会感到不安。
同样，平台团队应注意维护 TVP 如何影响开发人员。在她的 QCon 演讲 中，Kognic 的 Jessica Andersson 解释说，当平台团队缓解痛点并遵循产品思维时，他们会获得“信任积分”。相反，迁移（即使是不可避免的）也会消耗信任积分。平台团队应有意平衡收益和支出。
简而言之，维护 TVP 使平台团队能够专注于其组织特有的工具和特性。但是，设定准确的期望对于维持利益相关者的支持和保持开发人员的满意度至关重要。
当今的平台团队是平台工程的先驱。由于没有一刀切的 内部开发人员平台，团队必须找出如何提供适合其组织的解决方案。伟大的平台可以 构建或购买，但大多数组织都使用构建、购买和开源组件的组合。他们使用 平台即产品方法 来了解开发人员的需求、获得利益相关者的支持并推动平台采用。MVP 和 TVP 是产品管理概念，可确保平台团队快速且大规模地提供独特的业务价值。
平台团队可以通过采用“从小处着手，保持精益”的理念来最大化效率和影响。MVP 确保开发工作针对开发人员真正想要和需要的特性，避免在不需要的特性上浪费资源。这种快速反馈循环促进了持续改进和以用户为中心的创新。
TVP 是一个补充概念，它鼓励平台团队在平台的整个生命周期中战略性地分配内部资源。通过专注于构建提供独特业务价值的内容，并为其余部分利用第三方解决方案，平台团队可以维护一个领先于曲线的 TVP。
Mia-Platform Console 是一个内部开发人员平台，允许平台团队在一个地方管理和监控其云原生软件的生命周期。平台团队使用 Mia-Platform 快速且大规模地创建自助服务功能。 了解 Mia-Platform 如何提升您的平台。