Equal专家出版了一份说明书，详细阐述了搭建数字化平台的思路。本手册概述了创建成功的数字平台应采用的策略，并讨论了数字平台团队可能面临的挑战。InfoQ采访了本手册的作者之一亚当·汉斯罗德，并更详细地讨论了他的想法。

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

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

该平台的不同之处在于，它抽象了组织的复杂性和艰苦工作，使团队可以专注于促进商业价值。正如《现场可靠性工程》一书中所解释的，“艰苦工作是一种与生产服务的管理有关的工作，往往是手工的、重复的、自动的、战术性的，缺乏持久的价值，并且随着服务的增加而线性增加。”

他们强调了将平台视为产品而非项目的重要性。这包括拥有完全授权的产品经理来收集客户的反馈(使用该平台的数字服务团队)。根据客户团队的反馈逐步构建平台，并加强平台的采用。

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

在平台上进行必要的宣传，帮助提高人们的认知度，促进平台的采用。请确保包含当前支持和计划支持的特定用途的示例。对于未来的计划，重要的是让数字服务团队看到他们的反馈已经影响了路线图的方向。

正如作者所指出的，一个独立的平台“将提供一套规划良好的高质量组件，让你的团队可以轻松地构建、部署和运营数字化服务”。

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

这种方法与“团队拓扑”的思想是一致的，即平台团队的目标是构建最薄的可行平台(TVP)。Manuel Pais和Matthew Skelton在团队拓扑中对TVP的定义如下:

TVP在保持平台小型化和确保平台能够帮助依赖平台的团队加速和简化软件交付之间寻求一个谨慎的平衡。

使用手册指出，平台的方向和范围可以“根据团队自己的假设和数字服务团队用户的反馈，通过小规模和频繁的平台能力实验来确定”。一步一步搭建平台，小增量交付，根据体验和用户反馈进行调整。

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

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

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

InfoQ采访了Equal Experts的顾问亚当·汉斯罗德(Adam Hansrod)，更详细地讨论了指导手册中的概念和思想。

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

亚当·汉斯罗德:在构建数字平台产品的早期阶段，平台团队应该与交付团队一起探索并开始活动，以建立上下文，确定依赖关系并了解预期的用户旅程。

当数字平台开始做大的时候，平台团队需要和他们的第一批用户保持密切联系，当服务团队成员抱怨的时候(不管是关于平台还是别的！)“待在房间里”。他们抱怨平台的特性和功能达不到他们的要求，但他们可能没有意识到这些东西可能是很大的反馈。

随着越来越多的团队使用数字平台，交付团队的问题和帮助请求可能是自助服务功能和文档质量的良好反馈来源，因为它可以显示:

缺少函数；

文件没有起到应有的作用；

...可能需要和提问者交流，填补流程知识的空白空。

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

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

汉斯罗德:当用户的旅程与平台团队鼓励的原则背道而驰时(或者将来会背道而驰)，平台团队应该做出改变用户预期旅程的决定。

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

InfoQ:你能告诉我们更多关于下一个初始阶段的事情吗？

汉斯罗德:初始阶段是一系列合作的交付前活动，目的是确保有足够的信息开始交付，并最大化成功的机会。如果初期只有一项工作要做，那就是降低交割风险。

这一系列活动包括(但不限于)验证和调整预期结果；范围明确；确定依赖关系；定义工作模式；探索技术可行性；并计划后续交付。

初始阶段类似于传统的项目启动，但重点是合作和验证围绕计划成功的假设。通常，初始阶段收集的信息将导致继续、调整或停止该计划的决定。

InfoQ:在说明手册中，您说“公共云提供商应该被视为软件即服务(SaaS)，而不是基础设施即服务(IaaS)”。这在数字平台团队的决策中是如何体现的？

汉斯罗德:把云提供商当成SaaS，而不是IaaS，你的思维模式就会转变为利用云工具和服务形成平台能力，腾出未来的时间，而不是未来花更多的时间在维护上。一切都是基于云提供商的IaaS产品从零开始构建的，这只会增加未来要做的BAU工作。

InfoQ:对于陷入端到端测试范式的组织，你有什么建议？数字平台团队应该先解决哪些问题，才能帮助组织改变方向？

汉斯罗德:我的建议是:

1.从端到端测试转向集成或契约测试；

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

3.浏览以进一步将测试内容从测试金字塔下移至单元测试。

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

InfoQ:建立数字平台团队的要求之一就是同质的工作量。具有跨团队异构工作负载的组织如何开始实现数字化平台？

汉斯罗德:当一个组织有多个工作负载异构的团队时(也就是说，每个团队都有不同的工作负载类型或几乎没有共同点)，平台团队可能很难为每个团队提供高质量的体验，因为他们不会花这么多精力围绕每个工作负载提供流畅的用户旅程。

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

根据我的经验，在这种情况下，最好是直接对每个团队进行投资，确保他们获得所需的工具，并让他们意识到，与分担相同工作量并得到平台团队支持的团队相比，他们的旅程不会那么顺利。

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

汉斯罗德:主要是与负责任的利益相关者和用户建立信任，尽快展现价值。我发现每周一次或每两周一次的展览是展示平台能力并获得交付团队和利益相关者认可的好方法。

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

游客个人资料:

亚当·汉斯罗德是Equal Experts的顾问，主要工作是帮助组织以可持续的方式解决规模带来的挑战。实际上，他一半时间与人交谈，一半时间建立服务。Adam花时间建立了一个高性能的金融交易系统，迭代的数字工具和流程来支持大量的团队，并帮助组织从零开始建立工程文化。他领导的平台团队获奖，帮助其他团队在更短的时间内提供更多的服务，降低总成本。

关于作者:

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

原文链接:

建立一个有效的数字平台:亚当·汉斯罗德谈优势、挑战和方法