关注平台执行差距

商业价值

承诺内部开发人员生产力平台的决定是一个经济决定。支持该论点的依据是，效率、质量和上市时间的好处超过了其构建和演变过程中产生的财务、人才和机会成本。如果您无法阐明平台的商业案例，那么您就没有资格负责任地采用它。您的计算必须考虑市售服务的性能，因为除非您的平台提供市售产品无法提供的功能、特定于您的环境的功能或便利性，否则您最好将其留给市场，避免维护负担——毕竟，您的平台策略依赖于减少非差异化工作，而不是增加它！

构建数字平台的决定仅仅是您为证明数字平台的商业价值而承担的责任的开始。平台策略的动机在高层可能令人信服，但在决定提供哪些功能以及如何提供这些功能方面，涉及许多细粒度的决策。更复杂的是，随着技术进步、组织需求不断发展以及云提供商和其他供应商发布与您的本土解决方案竞争的新产品和改进产品，您功能的商业理由会随着时间的推移而发生变化。

为了向您的组织交付承诺的价值，请计划将持续改进与产品创新相比，在面向最终用户的产品中占据更大的比例。为了使平台保持可管理性和成本控制，可操作性相关项目必须在积压工作中占据重要地位。您的用户会欣赏一致性、稳定性和可靠性，而不是一连串的新功能。此外，您提供的每款产品总有一天都会被市场上的新产品、内部构建的继任者甚至将能力责任交还给您的产品开发团队所取代。弃用是平台产品生命周期的基本部分，未能考虑它可能会破坏您最初希望通过提供它而获得的商业利益。

产品思维

您永远不能忘记，您正在构建旨在取悦其客户的产品——您的产品开发团队。任何阻止开发人员顺利使用平台的东西，无论是 API 可用性方面的缺陷还是文档方面的差距，都会威胁到平台商业价值的成功实现。优先考虑开发人员体验——没有人使用的产品不是成功的产品，无论其技术优点如何。为了实现内部平台的投资回报，您的产品开发团队需要使用它并很好地使用它。为了实现这一点，他们需要欣赏它、理解它并了解它的功能。正如 Max Griffiths 在其关于 基础设施即产品 的文章中所描述的那样，平台产品需要客户同理心、产品所有权和智能测量，就像其他类型的产品一样。

内部产品的优势之一是，您拥有高度投入产品的演变和成功的用户。与任何客户群体一样，您的同事将是怀疑者、中立者和热心者的混合体。利用热心者并帮助他们成为平台的早期采用者和拥护者，将极大地有利于您组织对平台的认知。传达您的路线图、接受反馈并从用户那里收集经验将有助于平台的持续相关性。幸运的是，你们都在同一个组织工作，因此您拥有丰富的沟通渠道。内部平台需要营销。它看起来不像向公众营销产品，但它仍然是营销。

维护善意是采用的关键。因此，如果您有任何不可避免的中断，请进行沟通，并可能调整您的计划以减少对用户的影响。如果出现问题并且您遇到中断（提示：您会遇到），那么道歉和透明度将让他们放心。抵制依赖管理命令作为采用策略的诱惑。您可能拥有被俘的用户，但强迫他们使用据说是为了他们自己的利益的产品并不会培养富有成效的关系。

运营卓越

当您采用内部平台时，您要求您的产品开发团队给予极大的信任。您的平台现在是您的组织用来履行其职能的系统的关键依赖项。您的运营能力需要足够强大，才能证明这种信任是合理的。

这意味着您的平台团队需要对软件基础设施的基本原理有深刻的理解，例如网络、扩展和灾难恢复。如果您的平台工程团队难以处理底层技术，他们将无法为您的产品开发团队构建健壮的产品。此外，现代运营卓越超越了基础设施，扩展到确保可靠性的实践。这本书 站点可靠性工程 很好地描述了该领域的最新技术。如果您的平台组织在 SRE 实践（如可观察性、监控和 SLO）方面缺乏技能，那么您不仅有破坏产品团队信任的风险，而且还有在不知情的情况下破坏信任的风险。

您的平台组织还必须具备成熟度，才能有效地管理事件并从中吸取教训。非工作时间支持、警报系统和无责事件回顾应该是优先事项。您可能需要建立流程、修改雇主合同中的措辞并为公平的补偿预算，以及 使值班成为一种足够愉快的体验，以鼓励广泛参与。它还会影响您的计划。当您需要进行重大更改（例如迁移）时，您需要投资于优雅地进行更改，以最大程度地减少用户停机时间。

软件工程卓越

平台组织不仅仅是运营部门，因此需要超越运营能力。即使您不打算编写大量的自定义应用程序，您的脚本、模板和配置文件也会迅速积累复杂性。如果您想保留快速安全地更改平台的能力，则需要以正确的方式构建它。

我们最喜欢的基础设施环境中软件工程卓越的总结是基夫·莫里斯在他的书《基础设施即代码》中定义的三个基础设施即代码核心实践。

• 将所有内容定义为代码
• 持续测试和交付所有正在进行的工作
• 构建可以独立更改的小而简单的部分

如果您的组织能够始终如一地应用这些实践，那么它更有可能执行您的平台愿景。没有它们，您可能能够在某个时间点将您的基础设施置于良好的状态，但您将无法维持开发团队不断变化的需求所要求的演变速度。

使用内部产品也会对产品开发团队提出要求。优秀的产品开发团队了解其依赖项提供的服务级别，将其纳入自己的设计中，并使用工程实践来减轻可能影响其服务级别目标的风险。当这些依赖项在内部提供时，这一点尤其重要，因为无论您的平台质量有多高，它都不可能达到商业 SaaS 提供商的完善程度。

健康的团队

个人技能很重要，但长期维持卓越需要强大的团队级纪律。当您的平台系统被业务的其他部分依赖时，仅由少数忙碌的个人掌握维护它们的专业知识是不可接受的。您需要拥有明确任务的自治团队，他们避免个人代码或系统所有权。他们必须投资于知识共享、文档和入职。一个人中彩票不应该成为您平台生存能力的威胁。

为了保持这些平台工程团队的生产力，他们计划工作的系统需要成熟。他们必须拥有根据其价值描述的项目积压，并拥有优先级排序流程，否则紧急事件可能会压倒重要事件。事件和计划外工作是不可避免的，但如果团队的大部分时间都被辛劳所消耗，那么它将永远没有能力投资于其产品的改进。团队不应该尝试同时管理太多平台产品。

我们发现马修·斯凯尔顿和曼努埃尔·佩斯在他们的书《团队拓扑结构》中讨论的认知负荷是一个有用的概念，可以使团队的任务保持可管理。如果一个团队不断地在完全不同的任务之间切换上下文，那么认知负荷就太大了，当这种情况发生时，团队不仅在进行日常工作方面能力下降，而且新团队成员也很难获得他们需要的信心来处理所有系统。

入门

如果您在组织中还没有这些能力，那么这是否会让您无法采用平台策略？您可能会问，您应该如何在没有仅从经验中获得的经验教训的情况下构建这些能力？

秘诀不是妥协执行质量，而是最初在野心的范围上保持谦虚。平台计划，无论大小，都应该产生商业价值，以产品思维为指导，以运营和软件工程卓越为基础，并由能够维持新平台服务的团队结构支持。低于此，您希望提供的提升很可能会成为拖累，损害您组织中开发人员对您新兴平台的声誉。

针对技术资产中易于理解的部分的小型、专注的平台服务难度较低。它们不会让您摆脱从整体角度考虑平台的责任，但它们可以让您开始并从那里构建。例如，提供一个日志聚合集群可以减轻产品团队的运营负担，并提高跨服务的可见性，这具有明确的商业价值，不需要复杂的财务建模来确定。它仍然需要产品思维来确保它为其客户服务（其可用性、新鲜度和搜索 UI 是否满足开发人员的需求？），但这种产品思维不需要像提供统一的开发人员门户那样成熟。它仍然需要软件工程、运营技能和健康的团队才能做好，尽管不像构建组织所有微服务的可观察性侧车那样多。

您要问自己的第一个问题是我们可以构建什么最小的事情[1]来帮助产品团队？第二个问题是如何在时机成熟时升级或迁移到其他地方？技术发展迅速，供应商锁定并不比供应商是您自己的组织更痛苦。如果弃用您的平台服务需要多年的痛苦过渡，那么可能是时候回到绘图板并简化您的产品了。您不需要详细的日历和大量准备好的替代技术，但将现实的寿命（三到五年）和用于替换解决方案的架构缝隙考虑在内，将迫使您的设计更简单、更解耦。

我们建议您的平台采用应该是自愿的。这以两种方式支持您的平台策略。首先，当产品团队能够选择退出平台服务时，它鼓励您保持服务的松散耦合，这将在时机成熟时推出新一代服务或将其替换为商业产品时对平台有利。其次，当您的平台组织依赖于产品团队对平台优势的认可时，它会对您的平台组织施加很大的压力，要求他们始终将客户满意度放在首位。强制迁移到平台是一种捷径，其长期风险是会削弱团队的产品思维纪律。

您可能会发现一个简单的分类系统对设置有关新平台功能成熟度的期望很有用，例如，指示新功能处于测试版。您可能希望将 SLO 和支持层与成熟度分类相关联，因为实验性功能不需要提供与核心功能相同的可用性，或者您的平台不需要提供相同的可用性。例如，它可能不需要全天候支持。一旦功能提升到完全支持，平台用户可以期望 SLO 足够强大，以便他们可以在其之上构建关键任务组件，但在那之前，较低的期望集给了平台团队自由来进行实验并验证他们对产品的假设，然后做出强烈的（和长期的）承诺。

如果您能够牢记以上内容，您将拥有额外的优势。您的平台团队将管理少量非常有效的产品组合。他们的认知负荷将很小，他们的重点将能够始终如一地减少开发团队的上市时间，而不是仅仅专注于保持灯火通明。

结论

数字平台是技术产品的组合。与所有产品一样，平台通过使用产生价值。凭借正确的基础业务理由、细致的产品管理和有效的技术执行，数字平台通过减少产品开发团队的认知负荷和加速组织的创新来取得成功。平台在资金、人才和机会成本方面需要大量投资。它们通过积极影响产品开发团队快速有效地开发高质量面向客户的产品来偿还这笔投资。

开发数字平台是一个战略决策，不可掉以轻心。除了直接的财务考虑之外，数字平台还会对您组织内部的关系施加压力。产品开发人员已经体验过商业云提供商的产品，为了满足这些提高的期望，平台工程团队必须在产品管理和技术实施方面都成熟。产品开发团队还必须学会成为您平台组织的良好合作伙伴，并承担其服务运营的责任。

数字平台是倍增器，因此在开发竞争优势和引入重大生产力阻碍之间存在细微的界限。您在产品生命周期中做出的决定将决定您是走在一边还是另一边。好消息是，就像其他任何类型的软件开发一样，如果您从小处着手，与客户产生共鸣，从成功（和失败）中学习，并牢记整体愿景，您就有成功的可能。