每一款软件，都是从一行代码开始的，并以此为基础发展起来的。Walmart 网站亦不例外。在过去的几年里，我们推出了一系列的功能，我们的销售额以惊人的速度增长。仅就用户的交易流（购物车和结账）而言，我们工程团队的规模成倍增长，我们的代码库也随之增长。

伴随着成长的阵痛，软件熵（software entropy）也开始出现了，产品开发人员不得不管理几个交叉关注点以及他们的功能工作和时间表。为了提高效率，需要构建通用抽象（common abstractions）、与其他内部平台的接口、修复常见问题，并且不留任何破损的窗户。为此，我们需要从整体上解决问题，来处理多个团队和应用，而不仅仅是手头上的项目。为了更有针对性地解决这个问题，我们成立了专门的团队来帮助完善我们的平台。

译注：软件熵（software entropy）是指软件的无序程度。软件熵可用来说明软件在经过不断修改后，无序程度提高的现象。 Ivar Hjalmar Jacobson 用以下的方式描述 “软件熵”：热力学第二定律说明在一个封闭系统内的无序程度不会下降，只会上升或维持定值，其无序程度可以用熵来表示。此定律似乎也可适用在软件系统内，在系统经过修改后，其无序程度（或称为熵）会上升，这可称为 “软件熵”。Andrew Hunt 及 David Thomas 用破窗理论来说明如何避免在软件开发过程中软件熵的增加。

关键是为我们的开发人员和最终用户扩展我们的平台。

但是，改进这个平台到底意味着什么呢？

这条大道过于宽泛，我需要的是方向和重点。为了帮助回答这一问题，让我们先从这三个简单的问题开始吧。

定义团队的三个问题

Why？——我们的使命（宗旨）

引用 Simon Sinek 的话，以 “Why？” 开头。

“我们的团队为什么会存在？” ——这似乎是一个基本的问题，无需动脑，对吧？

然而，深入挖掘并明确定义你的核心目标和使命，是弄清楚自己在团队中做什么和不做什么的基础。对于每个团队成员来说非常重要的是，明确自己的角色，明确自己存在的理由，从而在工作中找到真正的意义。

What？——我们的目标（重点）

一旦我们知道 “Why？” ，那么下一步就是进一步分解它，找出 “What？”。

“我们重点关注的领域是什么？”

在这个基础上，我们列出了有助于实现我们首要任务的关键目标。这些目标有助于提供亟需的重点，这反过来又转化为确定正确的解决途径。

How？——我们的原则（价值观）

现在，我们已经知道了 “Why” 和 “What” ，那么指导我们执行的关键因素就是知道 “How？”。

“我们如何运作？”

现在，我们定义了核心价值观和运作原则，这些原则有助于我们的团队树立正确的文化和思维方式。

现在让我们看看我们是如何使用 “Why？What？How？” 这些问题来为我们的平台团队奠定基础的。

Why？

我们的使命： “我们的团队为什么存在？”

“使开发人员能够以高速度、高质量和高性能构建可扩展的应用程序。”

What？

目标： “我们重点关注的领域是什么？”

优化迭代速度

“一家公司的创新速度受制于迭代速度。”

——Erik Bernhardsson

这一理念的核心原则是，重要的是快速行动，为用户提供服务，然后基于经验在其上进行迭代。对于开发人员来说，这几乎意味着能够更快、更有信心地交付功能。

开发人员的生产力

为开发者加快不同阶段的软件交付速度。

开发+发布工作流

我们的重点可以分为两部分：

开发工作流：这里的目标是使本地开发和测试尽可能快，尽可能轻松。
基础设施的细节：除了合并一个拉取请求外，将其投入到生产环境，还涉及到使用各种工具和基础设施。这需要团队/平台之间强有力的协作。

降低准入门槛

新员工的入职并不难，但影响却很大。如果做好了，它将促进团队合作，让员工有种归属感，并降低员工流失率。

为了降低新开发人员的进入门槛，构建正确的工具和文档是很重要的，这些能够让我们更快地融入团队，并对 “系统知识” 说 No。

解决常见问题

如果有平台的话，就可以防止团队为解决常见问题并在整体上更有效率而 “重新发明轮子”。

要找出常见的问题，首先要了解开发人员的痛点和导致开发速度减慢的摩擦区域。我们可以通过收集反馈和通过工程关键绩效指标定量地获取这些信息，并结合对产品未来方向的理解，可以帮助形成一幅伟大的路线图，并选择正确的战斗。

鼓励最佳实践

性能很重要

默认情况下，让它变得更快：性能优化应该直接在应用程序中进行。这一目标是为开发人员提供正确的能力，让他们开发的功能以最小的努力实现性能优化。

定义指导原则

共同定义最佳实践和架构指南。通过工具、审查、文档来倡导和鼓励他们。提供辅导，参与讨论，并帮助工程师交付高质量的代码。

及早发现问题

确保我们拥有正确的工具/流程，使开发人员能够验证并检查常见的隐患，如代码气味、Bug 和性能下降等，又如回归检查、CI 框架钩子、僵尸程序和性能综合测试。

对团队进行教育和赋权

“成为 10 倍工程师的秘诀就是，帮助你身边的 10 名工程师，让他们的工作效率提高一倍。”

分享知识

通过技术讲座和文档分享你的知识、经验和最佳实践，是激发和提升团队集体专业知识的好方法。

不断尝试

“任何想法都不会因为有人这么说就是真的。要通过观察和实验获得的证据来检验想法。如果一个心仪的想法没有通过精心设计的测试，那它就是错的！”

——理查德・菲利普斯・费曼

控制实验

作为一个平台团队，要尝试不同的解决方案，拥抱更新的技术，跳出框框思考，不断改进和突破，这一点很重要。每当我们发现任何问题的有前景的方法时，我们都鼓励大家通过概念证明进行尝试，然后进行事后回顾结果，并做出相应的选择。在完全推出关键的功能之前，应始终进行 AB 测试和分析。

质疑你的选择

用户在进化，代码也在进化。一年前的模式在未来可能会成为反模式。随着产品的进化，新的需求不断出现，而早期的优秀框架很可能会成为满足新需求的限制因素。为了获得解决问题的最佳方案，能够质疑现有的选择是必不可少的，也是实验性思维的关键部分。

How？

原则： “我们如何运作？”

1. 接受所有权和问责制

像领导者一样思考

“这都是关于从任何岗位、任何方向的领导。当今的整个组织结构，需要人们步入领导的思维模式，从不同的层次推动想法、项目和举措，其不同之处在于规模。”

通过问责制建立信任

问责制就是让自己对自己说过要做的事情负责。它是指贯彻和履行你所拥有的事情。这样做会让你感到被信任，因为团队知道你会兑现你的承诺。这就建立了一个信任链，而信任链是任何成功团队的基础。

理清优先顺序

“很多时候，我们都有很好的想法。但它们还不如我们能为客户做的最重要的事情。我们必须做出艰难的选择。”

——Sheryl Sandberg

与愿景和目标保持一致

了解我们为什么要做我们正在做的事情，以及它给我们的开发人员带来的影响。现在，请理清我们短期目标和活动的优先顺序，使其支持我们的长期愿景。

培养理清优先顺序的思维模式

Sheryl Sandberg 广为人知的一个问题是： “这样做绝对有必要吗？” 这种思维模式有助于我们确定优先顺序，并将重点放在最重要的工作上。在开始任何任务之前，要了解你的约束条件（如时间限制、依赖关系等）并估计投资回报率。

专注影响力

帕雷拓法则（也称为二八定律或 80/20 法则）

你往往会从 20% 的工作中获得 80% 的影响力。

80/20 法则有助于将注意力集中在对我们目标影响最大的事情上。通过专注这些事情，你可以产生更好的影响力。

超越完美的迭代

让开发人员/用户了解情况，从中学习，并在此基础上进行迭代，这一点非常重要。 这有助于我们更快地验证想法，根据需要纠正方向，并最终做到随着时间的推移而不断完善。

专注于你能控制的事情

明智选择你的战斗。虽然这句话是陈词滥调，但却是事实。抱怨自己不能完全控制的事情，只会导致消极和怨恨。当我们不再担心那些因素，而是将注意力集中在我们能够控制的事情上时，成功就会到来。

开放和数据驱动

公开协作

我们搭建的平台就是我们的产品，我们支持的团队就是我们的用户。我们的协作方式就像一个内部开源（又名内源）团队。 我们不希望任何一个人或团队来决定我们如何为所有团队解决问题。关键是与团队成员分享你的计划，并通过设计评审或其他沟通渠道鼓励公开反馈和建议。

帮助团队完成平台变更

通过对团队的支持，来让变更不那么痛苦。平台级的变更在很大程度上依赖于沟通来宣布新的功能和突破性的变更。对于任何可能影响多个团队的重大更改，请始终研究提供渐进迁移路径的方法。

数据驱动的思维模式

“没有数据，我们只有一个观点。”

——Edward Deming

强大的团队是由数据驱动的。捕获数据并指定度量标准，以驱动决择、优先级和评估权衡。重视数据和事实，而不是假设和观点。

保持好奇，不断学习

问题和答案一样，都非常值得尊重。

没有问题是没有意义的，没有问题是不好的问题。团队达成共识的唯一方法就是提出问题，并区分事实和假设。这种对话至关重要，因为这样才能对做什么和如何做有一个明确的理解，并有助于推动构建更好的产品。

强见解，弱坚持

“让你的直觉引导你到一个结论，无论多么不完美 —— 这是 “强见解” 的部分。然后证明自己是错的 —— 这是 “弱坚持” 的部分。用创造性的方法进行怀疑，从中寻找那些不自洽的信息，或指向一个完全不同方向的指标。最终你的直觉将和一个新的假说将从这些废砖烂瓦中复现，准备着再次被无情地颠覆。你会惊讶的看到，这一系列错误的预测将会以多快的速度给你提供一个有用的结果。”

——Paul Saffo

在接受变化的同时拥有强见解的能力：鼓励不同的观点，并使矛盾的观点浮出水面，这些观点可能会给我们当前的选择带来漏洞，并是我们能够更快地学习和迭代。

快速试错，学得更快

这不仅仅是 “快速试错”，同样也是 “学得更快” 。目的是进行快速、廉价的实验，一伙的宝贵的见解，并在整合新学到的知识整合到系统的基础上改变路线。

保持学习

重要的是，我们要把自己的技能当作是动态的东西，需要不断地维护和提升。关键是要不断学习，不断进化，以适应新的情况。简而言之就是：阅读、倾听、接受自己不知道的东西，做事情、并传授解惑。

感同身受，尊重他人

共情

我们是一个团队。我们应该经常设身处地地为其他开发人员着想。在这里，问题可以帮上很大的忙，例如：

这个技术决策对我们的开发人员有什么影响？
我们如何才能让其他团队更容易采用这种变更？

建立一支多样化的团队使我们能够从不同的角度提出问题，更好地理解问题，并帮助我们的开发人员做出正确的选择。

尊重人类，而不仅仅是尊重代码

归根结底，我们只是一群人类在一起工作，创造出一系列由 0 和 1 组成的模式，以便计算机能够理解。重要的是要看到人性的一面，要做到 “求大同，存小异”。最优秀的产品总是由伟大的团队打造的，而不仅仅是伟大的个人。

结语

自从组建平台团队以来的过去几年里，我们所做的一切都是以我们的使命、目标和原则为指导。它确实为我们提供了明确的重点和方向，无论组织一级的优先事项如何变化。将站点速度提高 50% 以上就是我们的主要成就之一。我们这样做，既没有影响现有的功能，也没有进行任何影响其他项目的大规模重写。你可以在这场演讲中了解所有这一切。其他一些关键贡献包括通过新的 mono repo 设置，实现了更快的本地开发、故事书集成、自动的 perf（软件性能分析）和无障碍功能（Accessibility，缩写 a11y）检查，简化了跨 Web 应用的日志/监控，在 10 分钟内就能找到问题的根源，以及改进工具。

我想给大家留下最后一句话：平台和软件在不断发展，我们今天构建的东西，肯定也会随着时间的推移而改变、过时。这只是进步，我们最终要继承的是我们的学习、友谊和回忆，这些都将伴随我们前进。重要的是，要在团队中树立正确的文化，让工程师们能够快乐，为他们的工作而感到自豪，并作为一个团队共同成长。努力工作，但也别忘了要有乐趣。干杯！

作者介绍：

Vasa，Walmart 实验室 FE 平台技术经理，专注 JS 和 Web 性能分析，爱好健身、电影、背包旅行、园艺，信奉终身学习的信念。

原文链接：

https://medium.com/walmartlabs/building-a-platform-team-d915221d5654

创作场景

万丈高楼平地起：Walmart 如何打造平台团队