亚马逊首次公开：驱动万亿市值巨轮的创新公式

在中国，你无法逃脱微信、支付宝的数字帝国；在美国，你无法逃避的就是亚马逊的电商帝国了。

作为一家万亿美元巨头，亚马逊以惊人的速度颠覆了从零售到软件开发的诸多领域。同时，随着亚马逊的规模不断放大，它的创新速度也在不断加快，看来大象真的可以跳舞?

这一切是怎么做到的？

2019年7月份，在MIT平台战略峰会（MIT Platform Strategy Summit）上，亚马逊云服务（AWS）的物联网总裁Dirk Didascalou阐述了亚马逊大规模创新的成功密码，本文的图片也主要来自大会中展示的幻灯片。

从高层次看，亚马逊有三大文化准则：

关注消费者而非竞争对手

愿意承担失败的建设者和先驱者

着眼于长期而非短期

当然，几乎所有公司都会有上述说法，不过比起亚马逊，它们真的就是说说而已。

不过，价值观好说，如何实施、落地这些价值观呢？Dirk提出一个四因素的成功公式来让一切落地，这四大因素包括：

架构（Architecture）：创造一个支持快速成长和变革的结构

组织（Organization）：让小而有能力的团队拥有他们所创造的东西

机制（Mechanisms）：将行为编码进我们促进创新思维的DNA中

文化（Culture）：雇佣建设者，让他们建设，用信念系统支持他们

针对这四大因素，亚马逊提出了自己的创新公式：

架构——支持，快速增长与变革的结构

在亚马逊整个架构层面，最为知名——很多人也认为是最为「臭名昭著」——的是贝索斯的「API授权」，他要求整个软件团队在搭建应用程序的时候，必须向其他团队通过API公开数据和功能。

当年，贝索斯的原话是，「任何不这样做的人都会被开除。谢谢。祝你今天愉快！」

并非所有的API最终都对外界开放，虽然按照设计，应该这么做。不过，这一切也正是亚马逊云服务的起源。

这种公司级「微服务（Microservice）」架构的好处在于，每个团队都可以快速开发自己的部分，而不用考虑其他团队——他们可以用自己的数据库、自己的技术库、自己的内部设计——只不过，最后必须通过API让其他团队也可以在不了解他们内部原理的情况下调用这些服务。

然后，团队间可以快速、灵活地通过API调用其他人的服务、数据，而不必在跨团队协作会议中互相撕逼。这些API实现了快速、灵活、可复用且松散耦合的特点——这时，团队就可以在内部继续迭代、进化，只要保证API正常对外工作就可以了。

此外，Dirk还提出另一个架构观点，那就是「两个总比零个好」。

也就是说，由于是在高度分布的团队中进行工作，很可能会出现，两个团队在无意中搞出了一样的或者高度近似的东西。

这是没问题的。

因为让几个快速工作的团队做了相同的工作，总比让他们花费数天、数周甚至数月撕逼，最终得出一个通用解决方案要有价值得多。虽然最终出了点冗余的东西，但是总归避开了无价值的会议撕逼。

最后，如果有必要的话，几个项目可以合并，或者随着时间的推移，一个项目战胜/替代了另一个项目。不过，考虑到两个团队同时取得成功的概率实在比较低——毕竟亚马逊鼓励快速、大胆实验，而大部分实验最终以失败告终（还记得Fire Phone么）——其实出现内部团队间的赛马，看看哪个真正能跑出来，也是没问题的。

组织——小型、赋能的团队

两个披萨团队——即two-pizzar team——算是你听说过的亚马逊名词了：团队人数不应该很大，大约2个披萨就可以让每个人吃饱，也就是说，每个团队大约6-8人。当然，这也取决于披萨到底有多大，有时候可能2-4人构成的团队也是没问题的。

为什么要让团队足够小，理由如下：

小团队中，实现彼此坦诚、充分、开放的交流比较容易，随着人数的增加，人与人之间的联系数量就会快速增加——网络效应听说过吧，在小团队中，内部网络效应过大未必是好事。

团队人数较少本身就会限制他们承担的项目的大小——这是好事，因为直接推出一个宏大的项目本身就是风险重重的，很容易直接就失控掉。而小团队更容易采用迭代、叠加的方式快速开发，本质上来说，他们可以针对变化、反馈而快速调整，实现敏捷开发。

小团队会以自己拥有这个项目而自豪，这个过程中形成了创业心态，甚至可以避免浑水摸鱼的「搭便车」情况。

小团队更加扁平，没有过多等级制度。小团队的领导可以清楚地了解团队中发生的每一件事，并可以为成员提供实际的帮助和支持。

小团队可以快速做出决策。

亚马逊坚持每个小团队必须为他们建立的东西承担责任：他们不可以随手建个什么东西，然后就丢给外界。无论是好是坏，团队都「拥有（own）」在设计和实现中所做出的一切决策，并且为结果负责。

因此，你必须为团队选择优秀的人才：亚马逊在招聘时就将「提高门槛」印在基因当中，你招募的每一个新人都必须比你现有的人强50%。

换句话说，亚马逊内部早就「孵化」了海量创业小组，通过招募优秀的人才，让小组做出更强大的东西，以应对外界挑战，这就是亚马逊万亿美元市值的核心原因。

机制：将行为编码到可操作的DNA当中

为打造产品，亚马逊有一套古怪的习惯，但却非常有效。他们将之称之为「机制（mechanism）」。

其中一个机制就是「新闻稿」。

这并不是说亚马逊发明了新闻稿，而是说，在开始一个项目之前，就要写一个模拟新闻稿并附带一个FAQ文件——文件中阐明记者、用户可能会提出什么问题——而不是常见的，在开发成功后，为了发布会才撰写。

通常情况下，亚马逊甚至会要求这些新闻稿要能得到资金或者认可后，才可以真正开始这个项目。

这种机制的本质就是让亚马逊员工聚焦于消费者、客户需求，而不是上来就谈论基本原理和技术术语。如果你能解释清楚为什么用某种方法就可以吸引到特定的客户，并且能回答所有相关问题，那么你就有理由去开始做这件事了。

亚马逊将这一切成为「从消费者真正的需求进行逆向工作」。

另一个机制也很有趣，为了让每一个人都将用户放在心中，亚马逊就在会议室里放一把空椅子，每个人都可以想象，当一个真正的消费者坐在那里的时候会怎么样、会问什么问题、会如何看待他们的决定。

总的来说，内部进行决策的时候，亚马逊更喜欢书面表达，比如预先写好新闻稿和FAQ——而不是写PPT。这时候他们还会有一项机制，叫做「6页备忘录（6-page memo）」，在开会做决策之前，会撰写一份6页的文字来阐述想法，在会议开始的前半小时，每个人都会默默阅读这份备忘录，然后进行讨论。

奇特但是又很有效。这些备忘录使得作者必须仔细思考他们，并且能清晰地阐述、论证他们的想法，这一切避免了漫无目的的嘴炮，让每一个人都可以专注于决策真正的内容。

这些机制都真实地发生于每一次工作完成之前，亚马逊还有一套明确的机制来处理未来可能出现的问题。他们通过「错误纠正（Correction of Error，简称COE）」来分析根本原因，并确定将采取哪些措施来防止这些问题发生。

为此，团队/组长必须回答以下问题：

发生了什么？对你的客户、业务有什么影响？根本原因是什么？你有什么证据来支持这一观点？关键影响是什么，特别是安全方面？你学到了什么？你会采取哪些纠正措施来防止此种问题再次发生？

文化——雇佣：建造者，让他们建造

在Dirk的分享中，亚马逊的文化主要就是雇佣「建造者（builder）」，并且让他们在共同的信仰体系中创造事物。亚马逊的核心就是寻找那些喜欢尝试、完成事物的程序员和思考者。

对亚马逊来说，最重要的就是赋能建造者们，让他们以最小的管理费、最少的繁文缛节来创造事物。

但是，亚马逊有如此大量的独立团队来做决策，亚马逊如何处理这个问题？

很简单，部分原因在于，并非所有决策都是平等的。

在Dirk最后的分享中，他表示，亚马逊对于「双向门（two-way door）」和「单向门（one-way door）」的态度是不同的。大部分决策本质上都是「双向门」，也就是说是可逆的，如果不成功，退回去重来就是了。对于这类决策，团队可以非常敏捷，自己去做决策，而且风险也不会很大。

真正需要关注和分析的，是那些大型的、单向的、不可逆转的决策。一旦进入这扇门，就没有回头路了。

由亿欧公司主办、粤港澳大湾区研究院（广外）联合主办的“2019大湾区国际科创峰会（BATi）”结合湾区科创和青年特色优势，将第二届大湾区国际科创峰会的主题定位于“科技赋能、青年引领”，将围绕5G生态、硬件创新、工业数字化、AI企服、科技出海等热点展开探讨，欢迎科技创新的观察者参与！

报名链接：https://www.iyiou.com/post/ad/id/875