全文共6258字，预计学习时长18分钟
图源：news.ctoy.com.cn
亚马逊作为美国最大的一家网络电子商务公司，是网络上最早开始经营电子商务的公司之一，目前已成为全球商品品种最多的网上零售商和全球第二大互联网企业，也是无数有志青年向往的工作平台。
但伴随着“逃税、恐吓、域名、取消订单、员工罢工、抹黑中国”等争议事件的频频爆发，人对于亚马逊越来越迷，它究竟是怎样的一家公司？在里面工作会是怎样的体验？我应该选择亚马逊吗？
下面一位在亚马逊工作快3年的软件工程师从他亲身所见所闻所感，向我们介绍这家“传奇企业”。（下面开始启用第一人称）
自2017年7月起，我成为了亚马逊云服务（AWSCloudFormation）的前端工程师。这是我在软件工程领域的第一份工作，也是唯一的一份工作，我想也许我应该写下一些我在亚马逊经历的感受。在亚马逊不同项目组以及其他公司，我有很多朋友，这也让我对在亚马逊工作的独特之处有了一些了解。
我觉得有必要把这些想法表达出来——我的言论和观点仅代表我个人，我绝不是在代表亚马逊。
图源：kuaibao.qq.com
让我们先来谈谈团队，还有尽管亚马逊是一个如此庞大的公司，以及随之扩张的管理机构，但它如何能够像小型创业公司那样快速创新。
大多数亚马逊组织都很庞大。并且，每个组织内部都有许多子组织，每个子组织内部都有许多团队，依此类推。我所在的团队由4名工程师和一名经理组成，经理还负责监督他产品领域内的其他小团队。
我们有许多相邻的姐妹团队，他们与我们的团队进行着相对密切的合作。每个团队都有一个精简的工作环境。在决策过程中，我们是相对独立的，因为对客户问题的快速反应是亚马逊任何团队的首要任务。这意味着，高级主管脱离市场的“拍板式”的决策和执行方式，在亚马逊非常罕见，不得不说这些异想天开的想法会导致很糟糕的决策。相反，每个工程师都被授权，我们可以客户想要的方式来推进产品。
同样，企业文化也是从职员出发的。无论是如何处理测试、运营工作、进行社交活动等等，都没有一个单一的“这就是 Amazon 做……的方式”，即使同一个伞状团队中较小的子团队也是如此。一些团队在特定的日子里在家工作，一些团队在星期五有固定的食物和零食。
关键是，由于亚马逊或亚马逊网络服务与文化相关，因此很难以任何特定的方式概括它们。有些团队有更多的操作工作，有些团队有更多的新特性工作，有些工程师发现自己要工作很长时间，有些一周工作时间很少超过35小时，这都要看情况。
领导力原则之所以适用于每个人，甚至包括那些通常不被视为“领导者”的职位，是因为我们都被期望成为领导者。这意味着公司必须授权员工发展他们所属团队的文化。同样，公司应该为平稳和准确的决策产出提供良好的企业架构和方式，而亚马逊在这方面做得很好。
图源：Unsplash
我确信对任何人来说，是否拥有对自己工作的所有权是工作满意度的一个重要因素。没有了所有权，你就失去了动力。因此，亚马逊的软件工程师们的任务就是拥有他们各自的服务。很少会出现“这不关我的事”或“这不是我的工作”的情况，作为一名软件工程师，我不仅仅拥有一小部分代码库，我拥有我们服务的全部经验。
这也意味着不能孤立地评估我的工作。我们产品数据的高潮和低谷以实实在在的方式影响着我们的团队。有些人喜欢拥有和维护他们自己的“空间”，然而，以我的经验来看，亚马逊不是这样的。作为回报，你可以将你的名字与你提供给客户的功能联系起来，从而成为主题专家。
这种所有权原则的一个特点是，运营工作是亚马逊软件工程师工作描述的一部分。亚马逊没有雇佣一个独立的开发团队来测试、部署和支持我们的产品。软件工程师被期望在“编代码”的基础上完成所有这些工作。
工程师通常是团队全年待命轮换的一部分，这是一个24小时全天候的运作系统，可以应对高度重要的订单，管理者也不例外。许多工程师和管理人员经常参与其中。软件工程师拥有、甚至获得操作支持背后的基本原理是所有权原则的延伸：事情出错时，我们不能简单地将工程师制造的问题“踢”到一个单独的团队。考虑一下吧，如果应用程序中存在bug，那么问题的根源最好留给编写程序的人。
此外，它还提高了编码水平和测试标准，以确保产品在生产时不会出现问题。责任是双向的。工程师不能将代码直接市场化，以获得这样做的满足感，却避免可能出现的问题的后果。诚然，这可能不是每个人的菜，然而，它提供了对先进的分布式系统和架构中涉及的权衡的宝贵见解（即使是入门级的软件工程师在现场的面试循环中也经常被问到一个系统设计问题）。尽管这可能是在亚马逊工作中最不受欢迎的方面之一，但其基本原理是干净而简单的——从产品的实现到维护，你都拥有这个产品。
工作满意度的另一个组成部分是工作必须让你感觉有意义。就我而言，我的工作对客户的影响很大。作为一个拥有亚马逊网络服务控制台的前端工程师，我的工作不仅仅是为小部件添加样式，而是为我们的用户想象一个更好的体验，并将其带入生活。在我的任期内，我亲自设计和应用了我们大部分的代码库。
像上文提到的那样，团队精简。一个小型的工程师团队，或者在我的例子中，只有一个就可以完成整个特性的实现。这使我们能够拥有充满意义的项目，这些项目不仅能够丰富你的简历内容，而且能够让你学到只有深入产品生命周期中才能学到的东西。
人们常常认为，在大公司工作会让你感觉自己像是机器上的一个齿轮。尽管在任何一家大公司都是如此，但我怀疑，成为“齿轮”的问题，与其说是因为你只是人海中的一个齿轮，不如说是因为担心成为众多人中的一员，会减少所有权和有意义的工作。
正如前文提到的，亚马逊做了很多事情来确保你拥有适当的所有权和有意义的工作。如果你的工作与你的目标不一致，亚马逊有几百个团队欢迎内部转移。许多人参与了多个产品组，以发现自己的兴趣所在：网络服务、 Alexa、零售、VR/AR或我们众多的机器学习团队中尝试云计算的移动性，给他们带来了不小的益处。
毫不夸张地说，亚马逊所有职位的面试过程中，有很大一部分是基于领导力原则的，即使对软件工程师来说也是如此。我敢说，大约40-60%的面试内容是基于对行为问题的回答。由于亚马逊的这种“领导力”招聘条例，内部调动可以信心十足地根据这些共同原则进行。这些原则是首要关注的，而相关技术经验等方面的潜在差异则是次要的。
图源：Unsplash
在过去的几年里，亚马逊的领导力原则一直是企业文化中最具影响力的原则之一。许多公司都采用了相同的原则（融合自己的企业文化），以期望复制亚马逊自成立以来取得的成功。
一个公司在短短的25年里，以如此多的方式扩展其核心业务并取得巨大成功是多么的罕见！
想想看: 自从亚马逊成立以来，它从一个线上书店变成了一个“什么都有”的商店。因为亚马逊实际上将云计算发明作为核心业务，重新定义了客户服务，甚至冒险进入拥有独特技术的设备，如 Alexa，Fire，Kindle 等。亚马逊的商业模式和思维，即顾客过度利润，甚至颠覆了传统的商业原则。相比之下，那些名噪一时却因为无法有效地转变或扩大核心业务而濒临灭绝的公司，比如百视达，宝丽来，玩具反斗城，等等。
不管外界的传言，我想说亚马逊和它们的区别并不在于天赋。蓝筹股公司并不缺乏人才，但在上世纪90年代中期，
一家以线上书店为主导的小公司，却能够让自己与当时的零售业巨头抗衡。即使与当时的主要科技公司苹果和微软相比，亚马逊网络服务在过去的十年中仍然占据了云计算市场的大部分份额。
现在，你可能认为，自从我在亚马逊工作以来，我差不多就已经变成亚马逊的头号粉丝了，我并不能说这种想法是错的。然而，是因为看到了亚马逊的运作方式——即使作为一名入门级工程师，这些领导力原则也不仅仅是人们在会议上鹦鹉学舌般的说教——它们是亚马逊思考和制造所有产品的基础。任何看到这家公司成长的人都可以告诉你，亚马逊自成立以来取得成功并不令人惊讶。如果亚马逊继续坚持“第一天战略”，而不是第二天方案，它将持续获得未来的成功。
以下内容，都是领导力原则在我作为一个软件工程师的工作中的体现方式。我不会全面地或结构严谨地来进行讨论，但是你会看到这一原则如何使我们的工作和思考更有效。
图源：Unsplash
亚马逊一个众所周知的特色，就是它对顾客喜好的高度关注。如果我们可以把领导力原则想象成一棵树的不同组成部分，那么顾客喜好就是所有其他原则从中分支出来的主干。没有顾客，亚马逊就是一只无头苍蝇。
我们喜欢说，“从客户开始，然后反向工作。”诸如“这对我们的用户有意义吗? ”，“它为我们的客户带来了什么价值?”这些问题，推动着我们的思考。为了证明这一点，我们的用户有多种渠道与我们联系——通过我们的产品经理、我们的控制台反馈系统、社交媒体渠道（如Reddit、Twitter、Slack）等。我们阅读这些反馈，进行分组，然后工作中对其进行优先排序。
有些时候我们错过了重点，这也就是为什么我们不断地重复这个过程的原因——一遍又一遍地对标反馈。
新特性通常以这样的问题开始: “我们的用户想要什么? ”或者，“什么样的改变会减轻我们用户的不适? ”我们的产品经理就坐在离我们办公桌不到3米的地方，他们的存在就是为了回答这些问题。
他们参加我们的设计会议，帮助测试产品特性，提供措辞方面的建议，以及想象，甚至是重新想象更好的客户体验。此外，从一个特性的概念到市场营销和最终发布，不仅仅只有管理层参与了，还包括无数的工程师。在与客户的这种共生关系中，我们都是利益相关者。
软件工程师不仅仅是旁观者，而是协调客户期望的积极参与者。我定期阅读客户反馈，审查产品营销草案以发掘新功能，积极改善客户体验，还有我们的后端服务，甚至我们的公共文件。从技术完美（下文中会解释）到开发新功能，“客户服务”是我们在亚马逊都要戴的帽子。
作为亚马逊云计算部门AWS 的一名雇员，有些方面我认为是理所当然的。其中一个方面就是我工作的地方正是云计算开始的地方。
在这里工作过的工程师们设计和构建了AWS现在向全球客户提供的众多服务。你可以打赌，因为亚马逊是一个文档驱动的文化，先驱们留下的无数资源在世界上无与伦比。在任何事情上都很难保持“第一”的地位。这不仅需要运气和创新，还需要坚持不懈。AWS坚持不懈地缩小云基础设施中客户需求的差距。
虽然它可能不会永远持续下去，毕竟竞争孕育创新，但 AWS 率先做到了这一点，也做到了最好，并且旨在保持领先地位。能够而成为独一无二的AWS其中的一部分是十分令人兴奋的。
图源：Unsplash
亚马逊的任何提议都可能以这样的问题开头: “客户想要什么? ”然而，快速的跟进必须是，“数据说明了什么? ”无论数据是直接的客户反馈还是点击分析，亚马逊的决策都必须由足够的数据来驱动。俗话说“量两次，切一次”，亚马逊则是“量十次，切一次”。
文档是所有优秀工程团队都重视的部分，但我怀疑许多公司这样做是出于任务，而不是作为其运营的核心。亚马逊热爱写作。六页纸的描述是商业决策不可或缺的组成部分。为什么？考虑一下:“写作是一种自然的方式，它让你知道你的想法有多草率。”人们被要求通过写作来说服别人时，他们不得不考虑数据，原始材料，来证明他们的观点。在亚马逊不存在盲目实验。没有数据，产品或新功能不会投入研发。如果没有足够的数据，就去找到更多的数据点。在亚马逊，人们期望你运用批判性思维能力来客观地解释数据，然后提出正确的问题，从而获得做出正确判断所需的数据。
与此相关的是使用数据进行操作工作。每周，我们团队都会召开一个会议，回顾包含我们服务中成百上千个数据点的图表。我们讨论每一个峰值或下降值，以确定我们在正常的轨道上运行。同样，数据驱动着我们的思考。仅仅去猜测问题产生的原因就像在黑暗中拍摄。我们会说“这些图表看起来像什么? ”，然后我们先从数据开始，再反向工作。
要想了解这一思路有见地的案例研究，可以查看来自亚马逊20多年资深高级首席工程师Andrew Certain的 Twitter 帖子:
任何具有弹性的基础设施都应该具有很高的故障容忍度。例如，你的网站可能由跨越多个区域的多个服务器托管，这样如果一个区域出现故障，你的业务就不会跟着出现故障。这是基本的系统设计。我在这里谈论的不是那种失败容忍度（因为它与分布式系统有关)），而是亚马逊如何处理“失败”，比如产品发布、错过要点的功能，甚至是影响了许多客户的产品缺陷。
举个例子，2017年2月的一天，S3崩溃了，互联网的很大一部分也跟着崩溃了，结果是什么呢？有一件事是肯定的，事故发生后，亚马逊网络服务没有关闭。据我所知，可能有一个“COE”。
COE。我第一次问这个缩写代表什么时，一位同事开玩笑说它代表“停止就业”。他很快澄清这只是“纠正错误（Correctionof Error）”的意思。直到今天，我仍然相信这一流程为亚马逊创造了巨大的价值。流程常常使事情复杂化，COE有时也不例外。然而，编写良好的COE旨在确保同样的问题不再发生。COEs还给高级领导层进行介绍，以分享不同组织的经验教训。它们作为一种“失败”的学习机制而存在。
当我编写自己的第一个COE时（由于我不小心将一个 bug带到了生产环境中），我被要求“拥有”一个COE记录。我的经理向我保证，这是为了每个人的成长，而且投入生产的东西不是任何一个人的错。在我发布代码评审之后，这个bug经过了多次检查，例如，两个队友评审并批准了代码，我们的集成测试在部署管道中通过，图表直到客户报告之后才显示故障。COE旨在提供一个有说服力的概要，说明发生了什么、它是如何发生的（时间线）、为什么会发生，以及最重要的是，接下来会发生什么。COEs在许多不同的场景中自由地编写和呈现。它们不是羞耻的标志，而是团队可以集中注意力在如何避免将来发生类似问题上的过程。
这个世界没有足够的时间去找出该责怪谁，或者为什么这不是他们的错。有人拥有COE，他们呈现它，并且设置了操作项以确保它不再发生。亚马逊容忍失败，不仅因为它有能力这样做，更因为有太多的东西可以从失败中学习。
图源：Unsplash
亚马逊有它自己的问题，这已经不是什么秘密了，但我不打算在这里谈论它。我希望通过分享一个工程师的经验，可以让你看到亚马逊做对了什么，或者至少在什么事情上做得很好。我不知道我会在这里待多久，因为我不能保证亚马逊会让我在这里待很长时间，也不能保证我的兴趣会让我去别的地方工作。
我只知道在这里工作的两年半是一个特殊的机会，它深刻地改变了我思考工程、商业、企业文化以及许多其他与编码无关的东西的方式。
最后，新年到，祝大家都能找到一份称心如意的工作~
Amazon Spheres （亚马逊新总部） 在亚马逊工作：软件工程师
留言点赞关注
我们一起分享AI学习与发展的干货
如转载，请后台留言，遵守转载规范
