小程序
扫码打开微信小程序
APP下载
扫码下载市场部网 App
只要说起当前的数字经济，你就无法不提亚马逊。如今，这家价值数万亿美元的公司已经颠覆了从零售到软件开发的各个领域，其灵活性和干劲儿令人惊叹和震惊。实际上，随着企业规模的扩大，它们似乎在加快自己的创新速度，这与我们印象中的「大公司效应」不符，毕竟巨头们通常最后都会被自己的体量拖垮。
那亚马逊是怎么打破常规的呢?
一周前，在麻省理工学院平台战略峰会上，亚马逊网络服务（AWS）物联网副总裁Dirk Didascalou阐述了他们大规模创新的方法。这是一个长为30分钟的演讲，我认为对Martech领域感兴趣的每个人都值得学习一下。
我也将分享我的笔记和一些他幻灯片里的照片，都是现场翻拍，看上去有些接地气，但了胜于无。
在高层战略层面，亚马逊在他们的企业文化中有三个核心原则：
关注消费者对产品的忠诚度而不是竞品动向
创建者和开拓者对失败有包容度
关注长期效果而非短期效果
现在，有一些持怀疑论者可能会说，「真的吗？这就是他们统治世界的「炼金术秘诀」吗？因为这听起来有点像很多其他公司多年来一直在说的话。」
这就是问题的关键。很多公司都这么说。实际上，能这样做的人并不多。亚马逊坚持这些原则，这一点至关重要。这就是给某人发一个简单的心形表情符号和真正地、深深地、疯狂地恋爱之间的区别。
不过，这些都是相当崇高的价值观。让我们来看看它们是如何运作的！
Dirk将他们的方法描述为四个因素的函数（在这篇文章的开篇有画了一张草图），然后他对每个因素进行了具体的分析：
架构——创建一个能够助推快速增长和变革的组织架构
组织——让小而强大的团队掌控他们所创造的东西
机制——将行动编码到促进创新思维的基因中
文化——雇佣「创建者」，让他们大显身手，用信仰体系来支持他们
他给每个因素都做了一页摘要幻灯片，大家可以看我拍的现场照片。
架构：用于助推快速增长和变革的结构
其中一个关键的架构决策是Jeff Bezos著名的API命令，要求亚马逊的每个软件团队都应保证他们的应用程序可提供能通过API向其他团队公开其数据和功能的服务。（「任何不这样做的人都会被解雇。谢谢。祝你有愉快的一天！」）
并不是所有这些API都对外开放，尽管它们的设计应该像要对外发布一样。很难不将这种架构视为许多亚马逊网络服务(AWS)的起源。
这种跨公司的「微服务」体系结构的好处是，每个团队都可以快速推进自己的项目，而不必与其他团队进行深入的协调。他们可以使用自己的数据库，自己的技术堆栈，自己的内部设计。但是他们必须为其他团队提供一个API来使用他们的项目成果，而不需要了解这些内部的东西。
然后，团队之间可以通过各自的api在自己的项目中快速、轻松地利用彼此的服务和数据，而不会在跨团队设计会议中陷入困境。它是快速的、灵活的、可反复利用的并且「松散耦合的」——只要这些服务能维护它们面向外部的API，它们的内部就可以发展。
随着微服务和营销技术中的「无服务器」功能的发展，这在营销操作系统中越来越常见。
Dirk提出的另一个架构观点是「两个团队PK总比没有人可用强」。
这意味着，是的，对于并行工作的高度分散式团队，两个团队很可能无意中做出了相同的东西（或基本相似）。
让两个快速发展的团队重复工作要比让这两个团队在实际开始干活之前浪费几天、几周或几个月的时间来协商一个共同的解决方案要好得多。它完全避开了阻碍委员会会议的因素，付出的代价只是造成了一些冗余。如果需要，可以合并这两个项目，或者随着时间的推移，其中一个可以征服另一个。但由于两者成功的几率都很低——亚马逊鼓励大胆的实验，而这些实验往往会失败——所以最好让它们各自快速运行，看看如果最终能有一个走向成功，那又会是谁呢？
如果双方都取得了巨大的成功，那么你必须消除歧义，这在整体胜利的背景下被认为是一个很小的代价。
对于忌惮在自由放任技术下产生冗余的人，合理尝试利用一些martech方法或尝试martech新产品的「敏捷」方法（至少那些风险相对较低且依赖性很小的方法），我隐隐感觉亚马逊的「两个PK比没有强」这个理念的架构源于同样的初心。这似乎对他们很有效。
组织：小型、授权的团队
Two-pizzateams是你之前可能听说过的亚马逊模型之一：团队应该足够小，你可以用两个大披萨来喂饱整个团队。所以团队里大约是有6-8个人，这当然取决于他们有多喜欢披萨了。（有些团队可能会把人数缩减到2-4个，但这更多地说明了大家对披萨真是十分热爱，而不是一支「敏捷」团队的有效上限。）
为什么要保持住团队的小规模？下面有几个很好的理由：
小规模团队很容易彼此进行全面、开放的沟通。随着团队的成长，人与人之间的沟通连接点数量（与不同的人交谈的数量）以指数方式增长——可以用n（n-1）/2表示，其中n是团队中的人数。所以一个由6人组成的团队有6（5）/2 = 15个连接点，一个40人的团队有40（39）/2 = 780个连接点。小团队能高度协调，协调成本很低。
小规模团队在他们同时接手大项目时具有内在的局限性——这是一件好事。体量巨大的项目在进入落实阶段之前可能会失控。如果只是出于必要性，小团队更有可能采取迭代增量的方法，这实际上是快速反馈和适应变化的一种「敏捷」实践。
小规模团队可以更自豪。团队会萌生一种初创心态，每个人本身都是团队成功的重要因素。如果有人对项目没有贡献，那在小团队里就显而易见了。
小规模团队往往在组织上保持扁平，没有很多层级结构。这样的小团队中，领导角色与整个团队正在推进的项目具体进展紧紧地联系在一起，他们几乎能为自己职责范围内的方方面面提供直接的支持。
小规模团队可以果断快速地做出决策。
亚马逊坚持要求每个团队要对他们创造的项目成果负责到底，积极地承担起所有环节的权责之务。他们不能只把它们创造出来之后，就扔到另一边，甩给其他的运营团队做管理。无论好坏，团队都「拥有」他们在设计和执行落地中所做的决策权，并且必须处理项目运行后跑出来的结果。
因此，你肯定希望你的团队中有真正优秀的人才。亚马逊将「提高门槛」纳入了他们人才招聘的实践，原则是他们雇佣的每一个人都应该比半数以上的现有员工要优秀。
现在，你可能一边读这篇文章一边会想，「哎呀呀，一个小规模团队快速发展，每个人都拥有自己的工作，就像一个松散的初创企业联盟，所有人都在不断提高标准，雇佣更优秀的人才……这模式是不可能推广的。」如果你真是这样想的话，请随我深呼吸，记住这是一家价值上万亿美元的公司。
机制：将行为编码到执行DNA中
亚马逊开发了一些「古怪的产品创建仪式」。但行之有效。他们把这些构建出他们企业文化核心的行为称为「机制」。
其中之一就是「新闻公关稿」。写新闻公关稿不是亚马逊发明的，但亚马逊首创要求团队编写一份模拟的公关稿，并附带FAQ（记者和客户会问关于它的什么问题），这份文字作为在开始创造产品之前，为它创建的一种故事讲述的方式。通常，这些新闻稿甚至需要获得资金或批准才能进行一个项目。
他们的目标是通过这种机制嵌入的原则将重点放在对客户重要的事情上。忘记内部的原理和技术术语吧。如果你能解释你为什么要以一种对潜在客户有吸引力的方式构建某种东西——并回答他们可能会有关于它的所有问题——那么你就有了一个很好的理由来说明你计划创建什么。
亚马逊将这个过程描述为「从客户真正的需求开始，逆向而行，着手工作」。
这表明了他们如何将消费者的产品依赖和忠诚度放在他们所做工作中最前沿的一部分。即使是软件开发团队成员，他们也很容易与真正的客户失去联系。
亚马孙用来让团队每位成员都把消费者放在心里的一种机制是，在会议中放一把空椅子，鼓励每个人想象出一位坐在那里的真正的消费者。消费者会如何看待他们的决定？他们会问什么？
（嘿，我在这一节的开始就把这些行为称为「古怪的仪式」。）
总的来说，亚马逊更喜欢陈述书面化——比如「规范动作」的新闻公关稿和常见问题回答——而不是用PowerPoint的演示文稿来进行内部决策。
他们使用的另一种机制是「六页备忘录」法。在参加产品决策会议之前，会议的主持人要写一篇六页的文章来阐明他们的观点。在会议刚开始的30分钟里，每个人都静静地阅读和思考这份文章，然后大家再进行讨论。
听着有点古怪哈？但没错，它们的效果真是立竿见影。备忘录的文本形式迫使作者要认真思考他们的想法，并能够清晰地解释和证明他们的观点。在共同阅读产品备忘录这件事上所用的时间迫使会议中的每个人在开始讨论之前真正吸收这些想法。这样做避免了很多杂乱无章的东西，让每个人都把注意力集中在决策的实质内容上。
除了这些机制（通常发生在工作完成之前）之外，亚马逊还有一个明确的机制来解决发生在未来阶段的质量控制问题。他们应用纠错（COE）流程来分析根本原因，并确定将来可如何防止这些问题的发生。领导或是整个团队必须回答：
到底发生了什么？
对消费者和团队业务有何影响？
问题发生的根本原因是什么？
你有什么数据来支持这个结论？
关键影响因素是什么，尤其是影响安全的因素？
你从中吸取了哪些教训？
你采取了哪些纠正措施来防止这种情况的再次发生？
错误是会发生的，特别是在一个被鞭策驱使着要快速行动和大胆尝试的文化中。COE是亚马逊的一种机制，用于确保能用一致而全面的方式处理错误——以及同样的错误不会发生第二次。
文化：聘用「创建者」，大显身手
Dirk关于文化这一部分的幻灯片几乎完全在谈亚马逊雇佣「创建者」并让他们在共同认知的信仰体系背景下创造有自我风格的产品。亚马逊一直寻找喜欢尝试和能完成任务的程序员和战略家。
Dirk描述的以及我在本文中分享的许多原则都是为了让那些「创建者」能够以最少的开销和不必要的繁文缛节来打磨产品。同样，如果您对这种理念的可适用范围感到怀疑，请记住亚马逊是一个规模庞大的公司。我们几乎可以推断出，在今天的环境中，这些方法对于扩张是必不可少的。
但是，亚马逊是如何让这么多「半独立团队」做出如此多的决策，还用多种不同的方式给公司带来影响的？部分原因是认识到并非所有的决定都有相同的权重。
Dirk分享的最后一条亚马逊「套路」是，亚马逊对「双向属性决定」和「单向属性决定」的看法有差异。很多决定都是「双向性的」，因为它们可逆。如果不成功，大不了走回去重新开始。对于这类决策，团队可以反应非常敏捷，并且可以自己决定多次调教调用，风险比较有限。
实际上，只有那些重大的、单向的、不可逆转的决定才应该得到大量的关注和讨论。一旦公司像那样走进一扇门，他们想要再回去就不那么容易了。
我从Dirk的演讲中得到了很多启发，希望与大家分享、共勉和交流。
来源：chiefmartec
作者：Scott Brinker
翻译：Sibyl
