如何构建有效的数字化平台：收益、挑战和方法 | InfoQ 专访

Equal Experts公开了一份指导手册，详细阐述了构建数字化平台的思路。该手册概要介绍了创建一个成功的数字化平台应该采取的策略，并探讨了数字化平台团队可能面临的挑战。InfoQ 采访了该手册的其中一位作者 Adam Hansrod，更详细地讨论了其思想。

该手册将数字化平台定义为“由人员、流程和工具组成的定制化平台即服务（PaaS）产品，使团队能够快速开发、迭代大规模运营的数字化服务。”

该手册的作者认为，一个有效的数字化平台将缩短组织的上市时间，增加收入，降低运营成本，并促进创新。一个有效的平台是一个差异化的、按产品设计的、有主见的平台。

平台的不同之处在于，它抽象了组织的复杂性和辛苦活，使团队可以专注于推动业务价值。正如《站点可靠性工程》一书中所解释的那样，“辛苦活是一种与管理生产服务相关的工作，它往往是手工的、重复的、可自动化的、战术的、缺乏持久价值的，并且随着服务的增加呈线性增长。”

他们强调了将平台视为产品而不是项目的重要性。这包括配备一名充分授权的产品经理，从客户（使用该平台的数字化服务团队）那里收集反馈。基于来自客户团队的反馈增量地构建平台，强化平台的采用。

反馈信息的收集基于平台团队成员和数字化服务团队之间的双向反馈循环，而后者以双方的信任关系为基础。作者建议利用一些产品管理技术，如对话、调查、能力分析，来帮助团队更好地了解数字化服务团队的需求。数字化平台的有效性应通过交付能力、生产可靠性和用户满意度等指标来评估。

对平台做必要的宣传，帮助提高人们的意识，推动平台的采用。其中一定要包括目前支持和计划支持的特定用法的例子。对于未来计划，重要的是要让数字化服务团队看到，他们的反馈影响了路线图的方向。

正如作者所指出的那样，一个有主见的平台“会提供一套精心策划的高质量构件，使你的团队能够轻松地构建、部署和运营数字化服务”。

与Spotify和Netflix等公司处理这一问题的方式类似，他们将数字化平台描述为一系列铺好的道路，它们是完全自动化的，包含了组织掌握的最佳实践。这些措施加强了平台的主见，有助于推动数字化服务团队走向成功。一个主要的关注点是为数字化服务团队的用户消除复杂性，使他们能够专注于数字化服务业务逻辑和客户需求。

这种方法与“团队拓扑（Team Topologies）”这样的理念是一致的，即平台团队的目标是建立最瘦可行平台（TVP）。以下Manuel Pais和Matthew Skelton在《团队拓扑》一书中对 TVP 的定义：

TVP 是在保持平台小型化和保证平台可以帮助依赖该平台的团队加速和简化软件交付之间寻求一种谨慎的平衡。

该指导手册指出，平台的方向和范围可以“基于团队自己的假设和数字化服务团队用户的反馈，通过小而频繁的平台能力实验来明确”。渐进地构建平台，以小规模增量的方式交付，根据经验和用户反馈进行调整。

虽然该平台的重点是减少数字化服务团队的痛点和辛苦活，但有趣的是，该手册分享了以故意增加摩擦作为保障的想法。这种使次优做法更具挑战性的技术，有助于加强平台的主见和新服务的采用。

该手册介绍了一些可能妨碍数字化平台成功推出的陷阱。其中一个风险是将平台作为一个通用的基础设施解决方案。他们强调，平台要专注于支撑关键服务工作负载的云服务子集。

他们建议，在构建数字化平台时，应该将最初的数字化服务团队作为第一个用户。防止为构建平台而构建平台，因为这个服务团队的需求可以帮助确定实现平台目标的最佳平台组件。作为客户，服务团队要将平台视为一个产品，因为数字化服务团队的用户旅程对于确定平台的路线图至关重要。

InfoQ 采访了 Equal Experts 顾问Adam Hansrod，更详细地讨论了指导手册中的概念和想法。

InfoQ：数字化平台团队如何才能从数字化服务团队用户旅程中获得必要的洞察力？

Adam Hansrod：在构建一个数字化平台产品的早期，平台团队应该与交付团队一起进行探索和启动活动，以建立上下文，识别依赖关系，并了解预期的用户旅程。

当数字化平台开始变大时，平台团队需要与他们的第一批用户保持密切联系，并在服务团队成员抱怨时（无论是抱怨平台还是其他东西！） “呆在房间里”。他们抱怨平台的特性和功能未能满足他们的要求，但可能并没有意识到，这些东西或许是很棒的反馈。

随着使用数字化平台的团队越来越多，关于自助服务功能和文档质量的好坏，来自交付团队的问题和帮助请求可能是一个很好的反馈来源，因为那可以说明：

· 缺失的功能；

· 文档没有发挥应有的作用；

· 可能需要与提问者进行沟通，以填补流程方面的知识空白。

在数字化平台的整个生命周期中，每天从平台团队中抽出一个人专门回答问题或帮助交付团队使用数字化平台的能力和功能，可以帮助他们积累关于如何使用这些平台的知识。再辅以定量方法（如调查）或以用户为中心的练习（如用户角色或用户旅程图），使平台团队更好地了解他们的用户试图实现什么以及面临的挑战。

InfoQ：平台团队应该什么时候决定将用户旅程推向不同的方向？

Hansrod：当用户旅程与平台团队所鼓励的原则背道而驰（或将来会背道而驰）时，平台团队应该做出改变用户期望旅程的决定。

一个常见的例子是分支策略，如果平台团队试图鼓励有关持续交付的原则，那么他们可能会在用户旅程中引入摩擦，即团队创建长期存在的功能分支，并减少基于主干的开发过程所需的工作量。

InfoQ：您能详细介绍下初始阶段（Inception Phase）吗？

Hansrod：初始阶段是一系列合作开展的交付前活动，目的是保证有足够的信息来开始交付，并最大化成功的几率。如果初始阶段只有一项工作要做，那就是降低交付风险。

这一系列的活动包括（但不限于）验证和调整预期结果；明确范围；识别依赖关系；定义工作方式；探索技术可行性；以及规划后续交付。

初始阶段类似于传统的项目启动，但重点是合作以及验证围绕倡议成功所做的假设。通常，在开始阶段收集的信息会促成一项决定，即继续、调整或停止倡议。

InfoQ：在指导手册中，您说应该把“公有云供应商视为软件即服务（SaaS）而不是基础设施即服务（IaaS）”。这在数字化平台团队的决策中是如何体现的？

Hansrod：把云供应商当作 SaaS 而不是 IaaS，你的思维方式就会转变为利用云工具和服务组成平台能力，释放将来的时间，而不是将来投入更多的时间做维护。什么东西都基于云供应商的 IaaS 产品从头开始构建，只会增加将来要做的 BAU 工作。

InfoQ：对于一个被困在端到端测试范式中的组织，你会给它什么建议？数字化平台团队应该首先解决哪些问题来帮助组织转变方向？

Hansrod：我的建议是：

1、从端到端测试下移至集成或契约测试；

2、为每个服务构建存根，以便在编译/测试时提供有效的测试数据，而不是要求使用环境中运行的服务来测试；

3、探索将测试内容沿测试金字塔进一步下移至单元测试。

数字化平台团队应该简化非端到端测试，为上述转变提供支持。该团队可以进行的活动包括：提供 Pact 服务器以实现契约测试，或提供实际的例子，说明如何在管道中针对存根而不是整个环境运行测试。

InfoQ：建立数字化平台团队的要求之一是同质化工作负载。一个拥有跨团队异质工作负载的组织如何着手实现数字化平台？

Hansrod：当一个组织有多个具有异质工作负载的团队时（即每个团队有不同的工作负载类型或几乎没有共同点），平台团队可能很难为每个团队都提供高质量的体验，因为他们不会投入那么多精力围绕每类工作负载提供流畅的用户旅程。

在这种情况下，试图建立一个支持多种工作负载的银弹平台，将很快滑向支持工作负载所需的最小公分母特性，而不是有针对性地努力为每个工作负载提供流畅的用户旅程。

根据我的经验，在这种情况下，最好是直接投资于每个团队，以确保他们获得所需的工具，并让他们认识到，与共享同质工作负载、有平台团队支持的团队相比，他们的旅程不会那么顺利。

InfoQ：在宣传和建立对数字平台愿景的认同方面，您认为哪些方法最成功？

Hansrod：主要是与负责的利益相关者和用户建立信任并尽早展示价值。我发现，每周或每两周一次的展示会是展示平台能力以及获取交付团队和利益相关者认同的好方法。

利益相关者希望了解，数字化平台的愿景将如何帮助他们实现为组织提供帮助的目标，并可能需要通过展示让他们看到，平台当前如何帮助他们实现自己的目标。我发现，虽然每个组织都有不同的优先事项，但数字化平台所能提供的共同价值包括：通过消除重复劳动和提高标准化来帮助节省资金，通过提高服务上市速度和质量来创造收入，通过提供工具和流程来降低所提供服务的安全风险。

嘉宾简介：

Adam Hansrod 是 Equal Experts 的一名顾问，他的主要工作是帮助组织以可持续的方式解决规模化带来的挑战。在实践中，他一半的时间在和人交谈，一半的时间在构建服务。Adam 曾花时间构建高性能的金融交易系统，迭代数字工具和流程为大量的团队提供支持，并帮助组织从头建立工程文化。他领导的平台团队曾获过奖，帮助其他团队在更短的时间内提供更多的服务，降低总成本。

作者简介：

Matt Campbell 是 InfoQ DevOps 编辑团队的负责人。他是教育科技公司 D2L 的云平台副总裁，负责其基础设施和云平台团队。他关注的领域是 DevOps 和 SRE 及其企业级实践。

原文链接：

Building an Effective Digital Platform: Adam Hansrod on the Benefits, Challenges, and Approach