采用 Backstage 作为开发者门户

总部位于英国的 Wise（前身为 TransferWise），通过 Wise 账户，让用户可以在超过 50 种不同货币中发送、花费、接收和持有资金。该公司以完全透明的费用、国际账户和路由号码、与 Apple 和 Google Pay 兼容以及承诺始终使用中间市场汇率（没有隐藏费用）来区别于其他公司。换句话说，公司的“无国界金融”使命需要一个强大的生态系统和人类工程技术。

而让一切井然有序的秘密是高效的工程组织和内部开发者平台。作为其中的一部分，Wise 在 Backstage 之上构建了一个开发者门户网站，高级技术产品经理 Lambros Charissis 正好深入其中。

在最近的一个网络研讨会上，Lambros 解释了工程体验团队在构建开发者门户网站方面的经历。他揭示了他和他的同事如何使用产品管理技术来实现三个关键目标：认识需求、确定 Alpha 版本的范围以及验证结果。如果你无法观看完整的网络研讨会，下面是他所涵盖的内容。

了解你所面临的值得解决的问题对于采取关键的下一步至关重要。那么 Wise 是如何认识到可能需要构建开发者门户网站的呢？

正如 Lambros 所说，线索不少。首先，Wise 拥有数百万客户和数千名员工。专门的平台工程组织和技术产品经理负责确保 Wise 的工程师可以快速、安全地交付产品。

Wise 的工程体验团队聚焦于问题。在对组织的开发者体验进行半年调查后，团队发现了一个趋势。

Wise 的员工在三个关键领域给公司评分很低：文档、可发现性和认知负荷。工程师们也报告了很多挫败感，所以产品经理知道他们有工作要做。

Lambros 表示，下一步涉及确定问题的真正边界：明确定义问题是什么，影响了谁以及为什么值得解决。

工程团队从一种经过验证的方法开始寻找答案：与最懂情况的人——用户互动。

Wise 在工程组织中进行了采访，征求了不同资历和专业的工程师的反馈，包括平台和产品方面。

面试官针对用户的角色和工作职责等不同问题进行了不同的提问。他们深入探讨了典型用户旅程，以了解人们如何使用现有的工具实现工作目标。受访者还分享了他们对工作流程的看法，以及哪些方面存在低效率的问题，为更全面地描绘大局添加了一层上下文。

这种探索性过程具有明确的结构。Lambros 描述了 Wise 总是让面试官组成三人团队：主要的面试官让谈话顺畅进行，旅程规划师提出与用户旅程相关的问题，笔记员捕捉到其他两个人错过的任何微妙之处。

团队进行面试有多重益处。除了确保每个人都能专注于自己的角色外，这种结构还让更多的利益相关者直接参与其中。平台工程师 和最终构建门户网站的其他人可以加入面试，直接与用户交流，为他们的问题建立共情。

关注用户旅程让 Wise 能够绘制出不同的价值流。例如，团队探讨了哪些服务涉及特定任务、工程师通常遵循的常见路径以及可能带来有价值的变化。

通过探索旅程并将其分为不同阶段，Wise 根据任务所增加的价值将常见任务进行分类，形成自然的问题解决优先级。

Lambros 表示，Wise 利用这种方法探索了多个用户角色和用户旅程，生成了大约十个不同领域的 价值流图。这样做以具体的频率术语重新定义了问题，阐明了为什么需要解决这个问题。

Wise 现有的方法导致开发者每个月需要参加两次可避免的会议，并每周浪费两个小时的时间。服务生态系统的低效性还使得入职流程延迟了约两天。

Wise 已经确定了该问题需要解决，但并不总是知道开发者门户网站是否是最佳解决方案。例如，公司可以尝试改进其现有工具。

Wise 通过从价值流地图中建立价值主张画布，按优先级列出用户旅程中的问题，使决策变得更简单。然后，团队根据每个潜在解决方案解决每个用户旅程问题的程度进行评级，以便更容易根据其整体适用性对选项进行排名。

如果你已经看到这里，你应该不会惊讶 Wise 选择了一个开发者门户网站作为解决方案。Lambros 和他的同事们发现，一切都表明这是解决用户旅程问题的最佳价值主张。这也是一个适当的全面文档和发现方法，解决了降低认知负荷的目标——这是最初的用户体验调查中发现的三个主要问题。

Wise 选择了 Backstage 作为开发者门户网站 Alpha 版本的基础。它似乎满足了所有重要的条件，例如补充了公司的技能，拥有强大的社区，是一个 CNCF 孵化项目，包括一个健康的生态系统，并且可以自定义。

接下来，团队需要定义 Alpha 项目的预期范围。整个目标是获得早期反馈并了解他们是否走在正确的轨道上。这意味着新门户网站需要超出仅仅功能的范畴：它还必须告诉 Wise 关于它的可行性和成本效益。

Alpha 版本还必须保持足够小，以便管理，但又足够大，可以验证。换句话说，实验需要保持可管理，但仍需要足够的样本量进行分析和审查。

这不是一项容易的任务。Lambros 说：“这很难做出权衡，但我认为定义假设有助于解决问题。”

从他们的价值流地图、用户个人资料和用户旅程出发，Wise 团队确定了一些假设。例如，它假设该门户网站可以：

• 加速开发者入职流程，

• 缩短寻找帮助的时间，

• 提高工具和最佳实践的发现能力。

自然而然地，工程师们也设定了一个目标。他们希望在全力推进新的开发者门户网站之前验证他们的五个假设。

明确目标假设使平台团队了解了应该在 alpha 版本中包含什么 - 将这些猜测与价值主张画布和其影响排名的用户旅程相结合，有助于他们确定需要解决的有用细节。在这种情况下，工程师们专注于三个功能：

• 增强工程实践、工具和新闻的可发现性，

• 创建一个软件目录，澄清如何使用服务并找到它们的所有者，并且

• 使用搜索工具和友好的呈现页面，更容易使用文档。

使用 Backstage 简化了确定符合要求的、具备工作 GUI 功能的 alpha 门户网站的过程。团队遵循了一种方法论的架构策略，包括：

• 避免方案偏见，根据客观特点平等评估每个选项，

• 使用线框图来创建对齐并在处理不同元素时让每个人都能理解，

• 决定是建立一个可以在初步测试后放弃的一次性 Alpha，还是一个可以在验证后持续改进的渐进式 Alpha。Wise 选择了后者，原因稍后解释。

仅仅假设新的开发者门户网站能够解决问题是不够的。Wise 需要验证这个假设，通过确认假设来证明门户网站确实解决了问题。

为了验证假设是否成立，Lambros 和他的团队选择了另一批用户进行调查。在这种情况下，他们选择了 20 名不同资深级别的工程师，并将他们分成两组：一组使用 alpha 版，另一组使用现有的工具。

这种实验设计使数据收集变得简单。团队负责人可以通过测量每组完成不同任务所需的时间来量化 alpha 版的有用性。

团队还收集了后续调查问卷。在让大约 40 人试用了一周后，项目负责人询问这些测试者认为开发者门户网站在实现假设方面表现如何。

这种有组织的评估是判断工作是否真实有效的一种有见地的方式，结果显示这个 alpha 版本只验证了五个目标假设中的四个。结果也突出了最初的解决方案在某些方面存在问题，如文档质量和搜索用户体验。

Lambros 对验证过程的最大收获相当直接——但仍然富有启示性：

• 假设的方法使得更容易关注和界定初始版本。

• 通过保持测试目标的一定程度的分离，可以避免用户测试偏差，保持过程的客观性。

• 测试本身并不足以验证：用户调查同样具有说明性。

有趣的是，没有达到假设验证目标并没有使 alpha 版本的门户网站完全失败。

由于团队选择了增量方法，他们在组装 beta 版本时已经有了一个良好的起点；产品经理们知道该集中精力使门户网站更有用。这种认识激励了 Wise 的工程师实现改进，比如添加质量分数和文档评级工具。

Lambros 的故事证明了精心设计的迭代方法在构建平台、门户和其他关键工程工具方面的价值。以有组织的方式构建这些组件可以将大问题分解并为重要问题提供解决方案。考虑到现代软件开发实践和工具链的复杂性，这是一个深刻的教训。

但这只是开始——在一个有趣的问答环节中，这次演讲还分享了许多其他见解，所以为什么不看完整个会议呢？

作者简介：

Lambros Charissis，Wise 高级技术产品经理。

原文链接：

https://platformengineering.org/talks-library/adopting-backstage-as-developer-portal

声明：本文为 InfoQ 翻译，未经许可禁止转载。

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！