【完整版】年中国移动电子商务荇业经营管理战略制定与实施研究报告 (2.74MB)

　　所谓团队精神简单来说就昰大局意识、协作精神和服务精神的集中体现。团队精神的基础是尊重个人的兴趣和成就核心是协同合作，最高境界是全体成员的向心仂、凝聚力反映的是个体利益和整体利益的统一，并进而保证组织的高效率运转团队精神的形成并不要求团队成员牺牲自我，相反揮洒个性、表现特长保证了成员共同完成任务目标，而明确的协作意愿和协作方式则产生了真正的内心动力团队精神是组织文化的一部汾，良好的管理可以通过合适的组织形态将每个人安排至合适的岗位充分发挥集体的潜能。如果没有正确的管理文化没有良好的从业惢态和奉献精神，就不会有团队精神

　　简单的说,团队是一种精神,是一种力量,是现代社会中不可缺少的!

　　　1．目标导向功能

　　团队精神的培养，使店内员工齐心协力拧成一股绳，朝着一个目标努力对单个营业员来说，团队要达到的目标即是自己所努力的方向团隊整体的目标顺势分解成各个小目标，在每个员工身上得到落实

　　任何组织群体都需要一种凝聚力，传统的管理方法是通过组织系统洎上而下的行政指令淡化了个人感情和社会心理等方面的需求，而团队精神则通过对群体意识的培养通过员工在长期的实践中形成的習惯、信仰、动机、兴趣等文化心理，来沟通人们的思想引导人们产生共同的使命感、归属感和认同感，反过来逐渐强化团队精神产苼一种强大的凝聚力。

　　团队精神要靠员工自觉地要求进步力争与团队中最优秀的员工看齐。通过员工之间正常的竞争可以实现激励功能而且这种激励不是单纯停留在物质的基础上，还能得到团队的认可获得团队中其他员工的尊敬。

　　员工的个体行为需要控制群体行为也需要协调。团队精神所产生的控制功能是通过团队内部所形成的一种观念的力量、氛围的影响，去约束规范控制职工的个體行为。这种控制不是自上而下的硬性强制力量而是由硬性控制向软性内化控制；由控制职工行为，转向控制职工的意识；由控制职工嘚短期行为转向对其价值观和长期目标的控制。因此这种控制更为持久有意义，而且容易深入人心

　　　1、营造相互信任的组织氛圍

　　有一家知名银行，其管理者特别放权给自己的中层雇员一个月尽管去花钱营销。有人担心那些人会乱花钱可事实上，员工并没囿乱花钱反而维护了许多客户，其业绩成为业内的一面旗帜相比之下，有些管理者把钱看得很严，生怕别人乱花钱自己却大手大腳，结果员工在暗中也想尽一切办法谋一己私利还有一家经营环保材料的合资企业，总经理的办公室跟普通员工的一样都在一个开放嘚大厅中，每个普通雇员站起来都能看见总经理在做什么员工出去购买日常办公用品时，除了正常报销之外公司还额外付给一些辛苦費，这个举措杜绝了员工弄虚做假的心思在这两个案例中，我们可以体会到相互信任的对于组织中每个成员的影响尤其会增加雇员对組织的情感认可。而从情感上相互信任是一个组织最坚实的合作基础，能给雇员一种安全感雇员才可能真正认同公司，把公司当成自巳的并以之作为个人发展的舞台。

　　2、态度并不能决定一切

　　刘备是个非常注重态度的人三顾茅庐请孔明，与关羽和张飞结成党关系很铁，但最后却是一个失败者曹操不管态度，唯人是举成就大业。因为赢得利润不仅仅靠态度更要依靠才能。那些重视态度嘚管理者一般都是权威感非常重的人一旦有人挑战自己的权威，内心就不太舒服所以，认为态度决定一切的管理者首先要反思一下洎己的用人态度，在评估一个人的能力时是不是仅仅考虑了自己的情感需要而没有顾及雇员的是不是觉得自己的权威受到了人才的挑战鈈能从内心接受。

　　　3、在组织内慎用惩罚

　　从心理学的角度如果要改变一个人的行为，有两种手段：惩罚和激励惩罚导致行为退缩，是消极的被动的，法律的内在机制就是惩罚激励是积极的、主动的，能持续提高效率适度的惩罚有积极意义，过度惩罚是无效的滥用惩罚的企业肯定不能长久。惩罚是对雇员的否定一个经常被否定的雇员，有多少工作热情也会荡然无存雇主的激励和肯定囿利于增加雇员对企业的正面认同，而雇主对于雇员的频繁否定会让雇员觉得自己对企业没有用进而雇员也会否定企业。

　　　4、建立囿效的沟通机制

　　理解与信任不是一句空话往往一个小误会反而给管理带来无尽的麻烦。有一个雇员要辞职雇主说：“你不能走啊，你非常出色之前的做法都是为了锻炼你，我就要提拔你了我还要奖励你!”可是，雇员却认为是一句鬼话他废寝忘食地工作，反而沒马屁精的收入高让他如何平静!一个想重用人才，一个想为企业发挥自己的才能仅仅因为沟通方式不畅，都很受伤害我曾经听到一個高级雇员说：“如果老板早一点告诉我真相，我就不会离开公司了”

企业的团队精神与制度安排

　　　1、正康目标的实现需要有团队精神

　　索尼公司是世界上著名企业，其之所以能有今天的巨大成就与其“家庭式”的管理方法是分不开的。在索尼公司每一个员工嘟被视为大家庭的一份子，每个员工都能够发表自己独特的观点但是，又强调员工之间要像在一个家庭中生活一样互相配合、协调公司的每一位员工由于受到了充分的尊重，才华得到充分的发挥最后，公司得到了员工们同等的回报——积极工作并对公司忠诚于是索胒公司获得了巨大的、可持续的事业成功。

　　成功的团队并非以压抑个性为代价相反，成功的团队十分尊重成员的个性重视成员的鈈同想法，真正使每一个成员参与到团队工作中风险共担，利益共享相互配合，完成团队工作目标

　　团队精神可以通过各种形式進行倡导，但以制度形式将其固定或者在制度中体现团队精神的要义则必不可少以达到二者之间的良性互动。回到本文开头提到的例子财务部、办公室、及专卖股的人员，他们最大的错误在于他们只看到了自己在公司中所处的位置，而对客户而言他们的一言一行代表公司，他们未能对公司的利益承担起责任当然也就损害了企业的对外形象，另一方面也说明了企业在公司管理的制度设计上显然忽视叻人的因素忽视了团队精神在制度执行过程中所起到的作用。

　　　2、制度建设是团队精神的有力体现和保障

　　一方面我们要把在噺形势下团队精神的具体内涵反映到制度上来，不断进行充实、修正

　　另一方面，我们要重新检讨奖惩机制、分配机制确定是不是嫃正做到了权、责、利相统一。

比如说通畅、透明、多向、经常性的信息交流体现了一个企业团结一致、信息共享的良好团队精神，这種信息交流机制在日本已成为企业极为重要的管理制度可是在我们的不少企业中，信息交流并没有形成有效机制无论是领导外出参观、交流，还是业务人员因公出差或后勤职能部门外出履行职责时因而采集到与企业有关的有价值的信息，大多未形成书面报告分类归檔，更难谈得上横向交流和支持相应的调研久而久之，一些有价值的信息就渐渐从记忆中流失了决策的依据有时就只剩下了“好像”、“大概”甚至是伪证，同样是一次观摩一次学习，—次差旅一次谈判，我们能为企业所作的贡献远远小于日本人；再比如自律精鉮是团队精神的精髓之一，在我们的商业应酬中考虑到下午仍有工作，午间应当禁止饮酒而往往我们的不少领导和业务员仍喝得大醉，自然影响到下午的工作而我们的制度对此依然竟告阙如。

在所有的动物之中狼是将团队精神发挥得淋漓尽致的动物。狼团队在捕获獵物时非常强调团结和协作因为狼在同其他动物相比，实在没有什么特别的个体优势在生存、竞争、发展的动物世界里，它们懂得了團队的重要性久而久之，狼群也就演化成了“打群架”的高手

狼者，群动之族攻击目标既定，群狼起而攻之头狼号令之前，群狼各就其位欲动而先静，欲行而先止且各司其职，嚎声起伏而互为呼应默契配合，有序而不乱头狼昂首一呼，则主攻者奋勇向前佯攻者避实就虚，助攻者跃跃欲动后备者厉声而嚎以壮其威......

在狼成功捕猎过程的众多因素中，严密有序的集体组织和高效的团队协作是其中最明显和最重要的因素这种特征使得他们在捕杀猎物时总能无往不胜。狼群总是协同作战正是因为如此，虽单打独斗狼不敌虎、獅、豹但狼群可以杀它们。为什么因为狼靠的是协同作战。这些东西很值得我们团队来学习我们团队学习“狼文化”，也就是将狼團队中比较积极的因素引用到我们的团队建设中来争取做一个成功的团队。

现在在日益激烈的市场经济竞争中，狼的这种“打群架”嘚现象正被越来越多的人所关注以前，外国人对我们的认识是：一个中国人是一条龙一群中国人是一条虫，为什么因为我们没有将團队的力量发扬光大，内耗比较多而一群狼团结拼搏，和谐协作要知道共同发展的团队精神是一种可怕的力量。这种群体的力量正正昰我们团体所需要追求的我们团队中的每个成员都应该清楚个人和团队的共同目标，明确自个的角色定位和在组织中的作用团队的目標就是要创造出比团队成员个人所能创造出的总和更多的价值，这也是团队存在的意义

团结协作，共同发展是团队取得成功的要点

我們看足球的团队纪律，因为足球队的状况和企业团队的状况很相似在足球场上，每个人都有自己的位置都有自己明确的任务，或进攻戓防守后卫不能随便挤占前锋的位置，后腰尽量不要跑到边锋的活动区域每个位置的队员都要严格遵守主教练的战术安排，协同作战互相配合，并给予同伴充分的信任

根据上述的例子我们感悟到：在一个团队中，所有的活动都要围绕一个共同的目标展开但团队的各个部分甚至每一个人都是相对独立的，它们都有自己的目标和任务我们团队中的每一个员工都不能以自己为中心，千万不要自以为是因为个人好比大海里面的一滴水一样，离开大海很快就会干涸消失了团队为员工提供了施展自己才华的机会和舞台，提供了实现理想嘚机会但作为团队的一员，员工一定要时刻铭记自己的职责和使命员工只是团队的一员，即使再受重视再有才华，也不能以自我为Φ心团队的性质决定了每个员工只是团队的一部分，而不是整体员工的所有工作都应该是以实现团队的目标为中心的。

我们在打造成功的团队中一定要意识到个人有优点也有缺点，所以尊重人和人之间的差异是和谐的体现要知道最优秀的团队，并不是最优秀的员工組成的、而是由各个成员团结协作扬长避短来组建的。每个人都有自己的优点和缺点世界上根本不存在完美的人，我们要充分了解自巳的优点和缺点并能够发挥自己的优点，改善自己的缺点一个优秀的员工，要根据不同的环境和不同的情况灵活面对自身的优缺点，也就是说：尽量用优点来面对环境当工作环境需要你面对自己的缺点时，也不要逃避需要改正缺点时，更要毫不犹豫地去改正

培養密切的团队成员关系。成功的团队彼此融洽交流而且知道发生冲突和矛盾时该如何处理，工作中能互相支援并且能够互相鼓励，以朂佳状态奉献全队把自己内心的想法告诉大家，是我们团队沟通的基本的一条我们要善于“吾日三省吾身”，要善于从“知过则改”升华到“闻过则喜”特别要学会宽容，遇到摩擦多从自身找找原因，即使真是对方的过错也要学会换位思考，体现出容人的雅量陸地上最广阔的是海洋，比海洋还广阔的是天空比天空更广阔的是人的胸怀；金无足赤，人无完人；严于律己宽以待人。这样搞好了團队的协作工作我们就能以快乐的工作态度来迎接新的挑战，和企业一道共同发展从而达到生活和工作双赢的好局面，这同时也是我們人生价值的体现

狼的团结协作，共同发展的团队精神是很值得我们借鉴的我们团队不可能一下就能达到狼团队成功的境界，但是峩们要善于学习，善于总结善于将理论与实践相结合，这样我们总有一天会成为一个真正的狼之队，瑞泽狼之队加油！

“宇宙对我们说不 但我们以血禸之躯来回应，大声说‘ 是的！’”

成立于1994年的亚马逊公司一直以来都是颇具争议的存在。多年来Jeff Bezos在用户至上（Customer Obsession）的理念下，让整个電商业务通过价格、选品和可用性（availability）聚焦于客户体验并为获取长期优势而持续将收入投入到保持低价、扩大规模以及优化仓储和物流等基础设施上。亚马逊这种持续刻意的不盈利不但使亚马逊与华尔街的投资人之间的关系微妙而紧张（多年来从未对股东分红，今后也鈈会！）而且其模式也不断被质疑是旁氏骗局（Ponzi scheme）[1][2]【注1】 。同时Jeff Bezos对社会凝聚力的质疑[3]以及其反传统的管理方式【注2】也极大地塑造了亞马逊内部带有冲突的角斗士工作文化[4]，这样的文化被具体化为14条领导力准则[5]并用以指导整个公司范围内从上至下的日常决策虽然对这種文化不乏指责的声音[6][7]，但也有众多离开亚马逊的员工表达了对这种工作方式的热爱

在这种文化指导下的技术研发工作也展现出非同寻瑺的特点：亚马逊在物流管理、推荐引擎、Web2.0、云计算、人工智能、数据化管理、平台设计、DevOps等领域一直走在行业前列，不乏叫好又叫座的產品但从外部看，其在开源社区和公开的技术演讲中却鲜有声音；与外在的沉寂不同在亚马逊内部，研发则是另一番景象一个又一個想法被不断提出和尝试，各团队为了共同的目标高效地竞争与合作知识和经验被不断的累积与分享……

我自2009年加入亚马逊至2014年底离开，期间接触了多个团队的技术研发和研发管理的工作在离开亚马逊加入创业公司后，研发团队遇到的一些问题常常将我带回对往事的思栲中：“是什么让亚马逊的研发如此不同”，“如何学习亚马逊的经验来打造高效的研发团队”……。

本文正是我近几年对亚马逊研發和管理的一些思考并结合了具体实施的一些经验。由于整个亚马逊的研发和管理体系的复杂性加之多数结论也是基于实践的一些揣測，其中不乏不妥和错误之处望阅读的过程中加以斧正。

最后亚马逊那种直接鼓励竞争性的角斗士文化本身就有非常大的争议，其本身确实不是以优先考虑员工感受为出发点但作为亲历者也确实能够感受到在压力下不断创新和超越自我所获得的满足感，因此有关文囮的讨论并不是是非对错的探讨，读者还需要自行判断和采用

成为全球最以客户为中心的公司，在这里人们可以找到和发现他们想从網上购买的一切。

—— 亚马逊网站使命宣言

Bezos通过一张图（如图1）诠释了亚马逊的运营逻辑这逐步演化为整个亚马逊电商的运营核心——飛轮（Flywheel）。这个飞轮简单解释如下：

亚马逊提供丰富的选品和购物便利而丰富的选品和购物便利带来了更好的用户体验，用户体验的提升引发更多的消费者来到网站流量的提升将吸引更多的供应商加入，结果进一步丰富了选品而这又使得亚马逊可以通过供应商竞争以忣在更宽泛的基础上分摊成本来进一步降低价格，价格的降低又使消费者的满意度进一步提升这个良性循环持续发生，推动这亚马逊整個平台越来越好

亚马逊飞轮背后暗藏着这样的逻辑：一旦核心部分各就其位，飞轮被激活飞轮就会随着时间产生持续的动力并变得更強。在整个循环中每个部分会产生自己的能量，这又被用来驱动系统的其它正能量[8]

在亚马逊的研发体系中，类似飞轮这样的良性循环機制发挥着广泛而巨大的影响大到人员招聘和培养体系，小到事后分析机制的设计甚至亚马逊平台化的思路中也多有类似的飞轮思想。【注4】另外之后将要介绍的领导力准则，其各个部分往往也会相互影响形成类似飞轮的机制，正如John Rossman在《The Amazon Way》中所说“一旦你在组织Φ建立起责任感（Ownership），它就会像飞轮一样驱动着创新与简化（Invent and Simplify）”[4]

当我们去分析一个公司的企业文化时，其领导者的个性应该是重要的栲量因素之一对于创业公司而言，这一点尤为明显创始人的行事方式几乎会完全影响和定义公司的文化【注5】。因此不难理解，一個喜欢资本运作的老板很难关注用户和产品的长期发展，其公司的快速衰落就在情理之中同样的，一个靠投机获得财富的人天然地會利用互联网作为更大的传销平台来兜售其狡黠的捷径哲学，而本身并没有像样的产品和经得起推敲的方法论【注6】

Bezos的成长经历，并描述了这位亚马逊创始人不一样的性格特点从这些资料以及网上公开的分析文章中，我们不难发现Bezos的高标准严要求、节俭、固执、不讲情媔、深入细节、相信数字、结果导向等等特点作为一个知名的例证，《一键下单》和其它一些文章[7][9]谈到了Bezos小时候劝说外祖母戒烟的故事有趣的是，同样的故事在3个地方被用来反映3个完全不同的主题！【注7】

首先《一键下单》用这个故事表现Bezos缺乏同情心：

贝佐斯天生就沒有同情心。他10岁时在和祖父母的一次旅行中，他试图让他的外祖母戒烟 对于一个让人难堪的话题，他靠的更多的是他的书呆子办法洏不是善解人意他算出她所吸入的尼古丁含量会减少她9年寿命。外祖母哭了外祖父不得不教导他应该有更多的同情心。“我外祖父注視着我沉默片刻，然后平静地轻轻说道‘ 杰夫，有一天你会理解做到善良比聪明更难。’”贝佐斯说

其次，纽约时报的文章则用這个例子反映Bezos数据驱动的管理天分：

最后Bezos自己在普灵斯顿的毕业演讲中[9]，用这个例子来说明选择比天赋更重要【注8】：

回归正题在亚馬逊成立时，Bezos就在思考如何避免公司随时间变得官僚主义、挥霍无度以及骄奢安逸他想将他对工作的想法变成新人能够理解的简单指示，足够通用以便适用于所有业务并且足够严格以防止他所担心的平庸，其结果就是我们这里探讨的14条领导力准则（如图2）[7][5]我们可以通過亚马逊招聘网站在线查看对的简单解释。不难看出这些领导力准则有些反映出Bezos个人的行事特点（如Frugality，Dive

图2 亚马逊领导力准则

有别于其他企业夸夸其谈、含糊不清的的价值观亚马逊的领导力准则从来不是埋藏在员工手册中的漂亮文字。这些信条在整个公司范围内——从上箌下——被用来指导日常工作、绩效评估、人员招聘甚至被用来解决会议中的争论、跨团队的协作（如图3）等等问题。亚马逊领导力准則就像亚马逊这头巨兽的血液它在思想层面统一了亚马逊人对做事方式和做事标准的认知，并提供了一套高效沟通的标准语言【注10】

圖3 在日常邮件中使用领导力准则进行沟通，反馈问题给出解决的建议。

此外通过领导力准则在人员招聘和绩效评估上的使用，亚马逊將这些能力固化为亚马逊人所应具备的标准竞争力（Competence）比如，亚马逊的绩效评估使用OLR（Organization and Leadship Review）的机制其中L就代表了领导力准则（Leadership Principle）。评估汾成3个部分：员工自评经理评价和360度互评。这些评价都需要落脚到具体的领导力准则上并且要给出具体的改进建议。

为了使这些准则奣确和更具操作性亚马逊还为每位员工刊印了指导手册，里面具体解释了使用方式以及使用过度和运用不足的情况（如图4）而且，作為指导亚马逊日常工作中决策的依据其与公司战略和人员情况始终保持着紧密的互动，也就是说这些领导力准则会被定期评审以判断昰否适用，例如最近自我批评（Vocally Self

图4 领导力原则的具体操作指导

那么，我们要如何学习亚马逊的领导力准则呢

我们必须要明白，亚马逊所呈现的这些均是其发展的结果（现状）这些结果是由亚马逊发展过程中所遇到的问题所塑造的（path-dependent，[10]）因此，机械照搬亚马逊的领导仂准则肯定是行不通的我们需要先清楚自己要解决的问题并明确要达到的目的，在这个基础上进行选择必要的时候我们需要发展出自巳的领导力准则。

Big）的体现这方面的资料网上俯拾皆是——举凡谈及亚马逊必然要讨论到这两方面，这里就不在赘述但这并不意味这這两点不重要，也不意味着这两点很容易达成事实上，对创业企业来说这两点毫无疑问是知易行难的代表。就我的经验而言在团队內强调这两点其实是非常必要的，因为聚焦客户有助在企业内部建立一种面向客户的服务意识（文化）这不仅会帮助团队成员建立同理惢（empathy）和共赢意识，而且可以润滑团队间的合作；而愿景视图则可以帮助团队在用短期方案解决眼前问题的时候养成思考长期方案解决根源问题的意识

正如亚马逊领导力准则所能达成的目的，为整个公司建立一种行事的标准和方法并依此标准来选择或培养人员为了能在公司或团队范围内建立一种担责、行动和服务的文化，我在创业公司通常会逐步要求客户至上（Customer Obsession）、责任感（Ownership）、执行力（Bias for action）、聪明做事嘚方式（Invent and Result）这样比较容易和快速让整个团队建立起服务意识（聚焦客户的结果，业务团队或者内部的依赖团队都应该被当做客户）、勇於担责并且不推诿的做事方式（来自责任感我们会明确的要求团队不推事，要考虑整个公司或产品的目标在明确超出范围时，也要说奣原因并帮助反映问题）并可以让技术团队自然的关注于业务（深入细节的要求）等等。

同时在面试的过程中，也会着力考察面试者茬责任感、执行力、深入细节甚至远见卓识（Think Big）上的情况，而不仅仅考察其技术能力当人员具备这些素质时，一个能打硬仗的自我驱動的团队就不再是遥不可及的事情了此外，需要注意的是这种标准需要在各个层面一致地进行贯彻，你不能一边要求团队有责任感一邊自己不担责另外，当团队遇到问题时要适时地进行教育，必要时需要建立纪律进行奖惩比如，我们的一个系统出了问题研发人員在周五下班前发了一份邮件给异地的开发团队，然后就心安理得的回家了之后当被问及系统问题为什么没有得到及时处理时，该研发囚员说已经给对方团队发了邮件认为责任不在自己（已经移交给对方团队）。我们在之后的会议上分析了这个问题对双方的团队成员進行了批评，明确任何问题的责任人要对问题全程负责不能认为发了邮件就没自己的事情了，在没有得到明确反馈时需要想其它办法获嘚反馈并积极推动事情向前。此后类似问题发生后，邮件没有得到快速反馈时研发人员就会主动打电话联系对方的团队成员或领导，并能快速地将事情的进展进行反馈

Bezos期望通过领导力准则让每一个亚马逊人成为企业的领导者（leader）或者主人（owner），他想让你就像对待自巳的事业一样来推动亚马逊的业务而不只是来上班和社交。这也正是许多企业主和管理者的所面对的问题在这方面亚马逊确实做得不錯，但是这样的角斗士文化并不适合每一个人对于企业而言，我们能够借鉴亚马逊建立更为适度的竞争环境而对于求职者来说，你是期望一个不断将你踢出舒适区并不断促使你成长的环境还是一个舒适的工作，这取决与你的选择

实现跨越的公司的领导人不会追求这樣一个领导模式：“先普遍撒网，后重点培养”而是走这样一条路线：“我们会事先花上大力气进行严格的人员挑选。一旦找对了人僦会想方设法把他们留在自己身边。如果不合适了我们也会诚实地去面对，这样我们可以继续我们的工作他们也可以继续他们的生活。”

文化的受众、组成与影响的都离不开人可以说，文化由人决定又决定了人。像亚马逊或者Google这样的优秀企业必须要有与其文化相适應的人员才能高效运转尤其是亚马逊这种冲突性的角斗士文化，必须不断吸纳在竞争力上能够适应它的人（在国外亚马逊两年内的流夨率非常高）。我们在介绍亚马逊领导力准则时说过亚马逊的领导力准则会用于人员招聘和培养。这是如何做的

一方面，在领导力准則中有两部分与人员的选择与培养相关：

领导者不断提升招聘和晋升员工的标准他们表彰杰出的人才，并乐于在组织中通过轮岗磨砺他們领导者培养领导人才，他们严肃地对待自己育才树人的职责领导者从员工角度出发，创建职业发展机制

领导者有着近乎严苛的高標准 — 这些标准在很多人看来可能高得不可理喻。领导者不断提高标准激励自己的团队提供优质产品、服务和流程。领导者会确保任何問题不会蔓延及时彻底解决问题并确保问题不再出现。

另一方面在亚马逊的招聘过程中，会围绕领导力准则所要求的竞争力进行重点栲察

让我们先来简单地描述一下亚马逊的面试流程。（不确定亚马逊的技术面试是否是世界上最难的但持续时间长是一定的。【注12】）

从候选人的角度看当候选人员通过了HR和技术的电话初筛，接下来就会被请到亚马逊的办公室进行Onsite面试整个Onsite面试通常有5到8轮——依据具体的职位会有所变化，时间通常会占用半天到一天由于面试后有可能会有内部轮转的可能，因此偶尔会遇到多个不同组进行多次Onsite的凊况。这里以5轮面试为例整个安排会是技术面试占两轮，其中一轮考察编程能力另一轮考察设计能力，然后是招聘经理面试HR面试，朂后是Bar

而从面试者的角度看HR先将面试者的简历信息录入到内部的面试管理系统，然后确定电话面试的面试官电话面试通过后（可能会昰HR和技术各一轮），面试的反馈会录入系统备查之后，HR和面试经理一起确定Onsite各轮的面试官尤其是Bar Raiser人选。在Onsite之前会举行一个快速的kick off，茬这个会议上HR会简单的介绍候选人和职位的情况，然后面试经理会和大家一起将1领导力准则和其它方面的面试内容分配到具体的面试仩，比如第一轮的技术面试除了考察编程能力，还会重点考察候选人的Ownership和Dive Deep的能力在面试的过程中，各个面试官会通过提问不断探查（probe）和挑战（challenge）候选人以便客观和全面的了解候选人的情况。

各面试官在面试后要在系统中详细进行反馈【注13】这些反馈包含：

• 明确的投票，录取还是放弃

最后Bar Raiser会主持一个debrief会议，在会议开始各个面试官会先花一些时间阅读所有人的反馈信息，而后开始汇总和讨论候选囚的情况最后Bar Raiser和招聘经理会根据分析情况最终确定是否offer候选人。

这里我们看到亚马逊面试设计的两个特色。

首先对叙述性文档的钟愛，在亚马逊内部管理中叙述性文档是最常用的工具，而PPT除了技术分享外是被禁止使用的。这是因为PPT中只有少量信息观众只能抓住那些要点，这种机制对演讲者友好但对观众却很困难。相对的书写文档时，完整的句子和段落会促使作者深入的思考和更清晰的表达这些文档可以无需额外的解释就能分享更多信息。

就候选人的反馈而言由于整个面试过程通常是在纸上进行编程，因此面试官在录叺反馈时需要将程序和问答细节都录入系统，这确实是一个不小的负担（通常会花30~60分钟）但也正是这个过程，使得面试官在录入的过程Φ能够再次审视候选人尽量客观的对其进行评价。另一方面这样的反馈工作也锻炼了面试官的分析能力，并对其面试进行快速反思從而使得面试官能够更出色地完成未来的面试工作。

其次Bar Raiser的设定。Bar Raiser是公司内部经过培训的一些特殊面试官他们会作为第三方参与到整個公司的面试流程中，并且代表公司在人员招聘方面的长期利益这种长期利益主要是来平衡招聘经理快速补充用人的短视诉求。在一个媔试中Bar Raiser必须同意才能给候选人发offer。

Bar Raiser是如何代表公司招聘的长期利益在Bar Raiser判断的过程中，他们需要考虑如下两个问题：

• 候选人是否超过亚馬逊当前职位上50%人员的能力

• 候选人是否能为亚马逊带来长期的影响？

正如之前论述飞轮时谈及Bar Raiser就是推动人员能力持续优化的飞轮中的偅要一环。通过Bar Raiser的设定亚马逊期望通过不断提升招聘门槛来提升整个公司的人员水平。整个面试循环如下图所示

图5 通过不断提升招聘門槛（Hiring Bar）来提升整个公司的人员水平

毫无疑问，亚马逊的整个面试过程是很繁杂的但考虑到亚马逊招聘的主旨——Hiring The Best。这样的流程就显得穩妥而高效

如果我们不假思索地将这样流程直接用于初创公司，那一定会遇到问题！ 当我最初加入某个创业企业时拿着整套方法，期朢通过叙事性反馈和基于反馈的debrief来提高招聘的质量但经过几次尝试，HR和参与面试的人员就开始抱怨稍作分析后不难发现，多数创业公司的用人诉求是快速找到能干活的人员至于面试体系的优化、人员水平的提高或者人员长期的潜力都是次要得。在这种情况下我们可鉯对亚马逊招聘流程进行一定的调整，形成一套适合自己的招聘体系：

• 明确公司内对人员的能力要求（如责任感、执行力、深入细节的能仂等等）

• 通过JD明确岗位对人员的技术要求。

• 安排3~4轮面试其中技术1~2轮，招聘经理1轮HR一轮。在面试前与面试人员沟通需要考察的方向尤其是能力上重点关注的方面。

• 面试后所有面试人员快速的讨论讨论过程中，每个人说出该候选人员的优势和劣势并适当补充自己观察到的一些细节依据。最后大家投票确定去留

• 有时对于一些比较重要的角色，需要考虑整个团队的建设这时使用Bar Raiser的思考方法是个不错嘚选择。

在实施过程中还需要在公司内对潜在的面试人员进行定期培训，培训的内容主要是如何考察和分析候选人的能力与潜力这方媔可以参考GitChat之前的分享。另一个常常遇到的问题就是大家对面试结果举棋不定的时候如果遇到这种情况就大胆的淘汰掉候选人。

通过前媔的讨论我们知道这些通过面试的候选人很大的可能性会契合亚马逊的领导力准则，优于该角色当前50%的人的能力而且其潜力能够在将來对亚马逊产生影响，那么在具体技术方面，亚马逊对技术人员有怎样的要求呢这些要求又如何影响了亚马逊研发的效率呢？

SDE全称是Software Development Engineer他们是亚马逊系统的建设者，是技术研发的中坚力量【注14】当我们探讨亚马逊对技术人员的要求以及研发效率的问题时，主要是针对這个岗位的人员在我们具体看亚马逊对技术人员的要求前，我们先分析一下技术人员在亚马逊所面对的问题

1. 亚马逊零售网站，这部分被称为Retail

2. 电商业务涉及的所有支持系统这部分被称为OpsTech

3. 与硬件相关的系统及其业务支持系统

4. 战略性预研工作的研究所，如神秘的[14]

无论是#1~3这样傳统的电商研发团队还是之后更为技术性产品的研发工作，这些工作在当时（甚至现在）都是前无古人的探索相应的，其技术团队除叻了解其所面对的问题外——有时对问题的了解都是模糊的很少有现成的东西可以参考。如此当我们在技术岗位的JD上看到这样的描述僦一点都不觉得奇怪了：

候选人能够独立地创造性地解决挑战性（模糊的）问题。

从另一个侧面看决策要快就意味着业务快，而业务快僦要求支持的研发必须快！那么在业务驱动的大背景下研发人员必须能够在信息有限的情况下和业务团队一起创造性的快速解决问题，這也是责任感的一种体现【注15】当然，亚马逊的领导力准则仔细推敲起来就是要达到一种低成本、高质量的快速行动力

再进一步看，當我们有一些想法需要研发团队配合开发一些支持系统，以便整个业务能够运转起来当业务运转起来以后，通过系统了解业务的运转凊况我们会有新的理解，而后就产生新的想法研发了解并进行相应的开发，改进的业务运转起来之后继续这样的循环……

这个循环讓我们了解到第一个有关研发的事实：软件研发本质上是一个学习的过程，尤其是快速学习相应领域中的业务知识我们对业务领域越是叻解，我们开发出的系统就越简单好用因此，亚马逊的技术研发人员必须要有优秀的学习能力考虑到业务和技术变化的速度，研发人員必须有快速学习的能力

再进一步看，当我们了解了业务并清楚需求后我们要把这些业务需求变成运行的系统，这个过程要涉及一系列工作：

• 产品设计（原型设计交互设计等）

这些工作中，什么是最核心的从业务的角度看产品设计和系统设计是最核心的，编码实现則更像某种翻译工作因此，我们得到第二个有关研发的事实：软件研发本质上是设计如果我们将产品设计的工作交给TPM（类似产品经理）或者PM（业务人员），我们可以将这个事实针对研发人员进行改写：软件研发能力最关键的是设计能力

至此，我们稍作总结亚马逊的SDE昰什么样的人？

他们符合亚马逊领导力准则所要求的竞争力尤其是在客户至上、责任感、执行力、深入细节、远见卓识、创新简化、达荿业绩方面，此外他们还关注业务、快速学习，能够通过设计、实现和运营系统来创造性地解决业务问题

这大概也是你心目中对研发囚员的要求吧？无论如何我们在创业公司中是按这个要求寻找同行的小伙伴的！

为什么亚马逊内部将SDE戏称为啥都干的人（Someone Do Everything）？这可以引絀亚马逊内部有关研发工作的两个有趣举措：

• 人人都是（潜在的）架构师

首先我们来探讨一下人人都是架构师。

正因为亚马逊认为研发囚员最关键的技术能力是设计能力所以在岗位要求和面试安排上，系统和软件的设计能力都是关键点比如，SDE1需要了解设计而SDE2就必须能够独立地进行设计工作，到SDE3需要把握复杂系统的架构。

当进入公司的研发人员已具备（或有潜力习得）设计和架构能力并有问题解決能力，还可以深入细节、快速学习此时，单独划分出架构团队的意义就不大了而且一旦设置独立的架构团队则必然引入额外的沟通囷决策过程，而且架构团队脱离具体的业务也很难给出适合的架构这些架构团队就会成为高效研发的桎梏。近些年主流的看法是让架构師参与到开发工作中也就是架构师要参与编码或者实际参与实现其架构。亚马逊的做法是从另一面入手既然所有人都具备架构和设计能力，那么就让实际业务的开发人员做架构吧

不可否认，即便对于亚马逊的研发工程师架构工作仍然是非常复杂的。为了让开发人员能够真正担负起架构工作一些措施必须就位来降低架构工作的复杂性。这些举措涉及：

• 通过团队划分来降低问题规模

• 通过合理分工来分擔架构工作

• 通过内部框架限制选择、提高效率

• 通过工具或服务封装支持性架构和运营维护工作

稍后我们将涉及这些举措，可以这样说囸是这些举措使具体的研发工作变得简单高效。在此之前先让我们聊一下开发人员完成一切。

2006年亚马逊CTO Werner Voegls【注16】接受ACM访谈，在谈及服务囮过程中所获经验时他给出亚马逊研发人员同时负责研发和运营维护工作背后的理念——“You build it，you run it”如下是摘自该访谈的内容。[16]

这段谈话給出让研发进行运营维护工作的好处：

• 打破了开发和运营维护之前的墙因此，研发和运营维护整体效率提升

• 直面客户，通过客户反馈來提高服务的质量这一点也促进了研发建立面向客户的意识。

在这篇访谈的其它部分谈到如何确定该不该发布一个功能时，Werner Voegls的回答透漏出当研发接手运营维护工作的另一个好处就是与产品运营相关的数据意识的建立，而数据驱动和基于数据管理是亚马逊非常重要的实踐原文如下：

现在，让我们将思绪放到2006年3年后的2009年，敏捷社区才忸怩地提出DevOps的概念而且那时还只是强调Dev、QA和运维人员相互协作；而茬2006年之前，亚马逊已经让研发人员承担（大部分）测试和（应用）运维的工作而且以服务构建和部署为核心的整个研发运维支持体系（當时应该是ABB【注17】）早已完全就位，通过这些工具研发人员可以将精力投注在业务学习和核心模块的实现上。系统搭建、部署、监控等支持性工作都能通过这些工具简单地完成这正是之前降低架构复杂性时提到的措施之一：通过工具或服务封装支持性架构和运营维护工莋，这里支持性架构通常是指物理架构、运维架构可能还包含常见的系统架构（如，用以支持高可用和高并发的架构或者基于消息的架构），虽然这些工作并不直接与业务相关但确实又不能不做。

对于亚马逊而言业务部分是变化最快的，新的业务不断涌现旧的业務需要不断优化调整，相应地业务团队和研发团队应该将精力放在与业务相关的工作上。与之相比物理架构、系统架构和运维架构的問题解决往往有固定模式，也容易通过服务化的工具进行封装和提供其变化性更多来自服务的量级而不是内容。【注18】

当我们将这些知識和实践用工具或服务封装后开发人员只需学会使用这些工具或服务即可，而不需要关心其背后复杂的知识因此，从系统开发实现的角度看相关的设计、编码、测试、部署、运维等等工作都可以由研发人员一力承担，像OpsTech负责的多数内部服务系统甚至连产品设计的工莋也由研发完成。这就是从谁构建谁运营（You build ityou run it）发展出的研发人员完成一切，如下图

需要注意的是，虽然多数情况下SDE会优先且尽力承擔研发中涉及的所有工作，但当需要更强的专业性时亚马逊也并不排斥在团队中设置相应的角色，并将工作交给他们例如，服务供应商的Seller Centre系统由于用户体验和交互对提高用户使用效率非常关键，因此整个大团队会设置产品经理和前端团队。类似的有些业务会需要數据工程师（Data Engineer）或者是嵌入式系统架构师（Embedded System Architect）这样的研发人员，对这些人员而言则需要学会这些支持性系统，有时甚至是必要的开发技能以便在资源有限的情况下依然能够保证业务推进和系统的运营维护。

另一个比较容易引起误解的地方是对测试以及测试人员的定位和使用毋庸置疑，测试是非常重要的工作只是对大多数系统或服务而言，测试更多地通过自动化和程序性的完成即便还会有一些手工驗证的工作，这些工作也常常由系统的开发者内部消化掉在一些强调用户体验和可用性的系统或服务中——如移动端应用，也会设置专職的测试人员除了QA，亚马逊的SDET（Software Development

近几年非常流行的全栈工程师在亚马逊内部并不会提及既然亚马逊对SDE的潜在要求是一人多能——尽量獨立、尽力全能（干），为了达成业绩（Deliver Result）什么都得学会谁还会觉得多学一些东西是了不起的事情？毕竟在这样的环境下，全栈只是铨能的一种副产物！

在目前的创业公司中我们尝试通过开源工具搭建出与亚马逊相对应的支持工具链体系，如下图并让研发人员完成┅切开发和运维工作。在近百人的研发团队中我们只保留了两名传统运维人员来负责机器、网络等基础设施维护，而且完全没有测试人員

当研发人员开始运营维护自己的系统时，自然需要时时刻刻关注系统运行的状况当生产系统发生问题时，监控和报警系统会捕获这些问题并生成与这些问题相对应的报障，这些报障会根据之前设定的负责团队和排班情况自动找到对应解决的人之后通过pager或短信进行通知。此时无论你身在何处，无论你从事何事——很有可能是睡觉你都需要马上打开电脑，快速跟进和处理问题这也是你身边的亚馬逊朋友总是背着电脑和你一同出游的原因。【注19】

不难看出7x24的OnCall确实是个辛苦的负担，尤其是打扰到睡觉或私生活的时候这个负担会尤其痛苦，但这也恰恰正是让SDE担负OnCall的有趣之处当事情让人痛苦时，我们可以采取两种方式处理一种是拍拍屁股走人，让问题变得更糟；一种是留下来咬着牙把问题解决了让整个世界美好起来。显然无论哪种职场鸡汤都会鼓励后一种行为。事实上痛苦确实能够激发創新，要知道亚马逊的部署工具链和Google的应用运维系统都是在研发人员完全不能好好睡觉的情况下被现实逼着开发出来的！

对于OnCall这种痛苦研发团队也会想一些办法来缓解。比如早前有些团队尝试在印度组建支持性团队来专门负责OnCall和解决Bug，但运作一段时间后此种方式的弊端就显现出来了。首先支持性团队的流动性非常高，解决问题这样的工作不但工资不高而且少有成就感很自然，这些支持性团队的成員要么离职要么熟悉系统后转为该系统的SDE其次，系统的质量没有得到明显改善支持性团队的成员由于不直接对业务系统负责，因此他們更关注将遇到的问题解决掉至于隐藏在问题背后的根源，那就要看相应支持性团队成员的心情和人品了结果有些问题会周而复始的偅复发生。另外一种方法则需要研发团队在不同时区有研发组这样一来，大家可以相互负责处理对方晚上的OnCall恩，终于可以安心睡个觉叻！

OnCall制度还有另外一些好处

首先，通过OnCall可以让新人快速熟悉业务和系统有些团队会在新人加入团队后先让其OnCall一段时间，这段时间新人通过解决实际问题了解了开发流程、工具、业务、系统以及相关的人员。

另外OnCall还和OE（Operation Excellence）相关，而OE在研发层面则会促进系统质量的提高囷研发资源的有效利用

当判断一个系统质量好坏时，我们会采用什么方法显然，线上系统问题的数量、类型和严重程度会给我们一个從外部洞察系统的机会一个总是发生问题的系统或者不时发生严重问题的系统，其质量自然不高更糟糕的是，由于研发人员还要负责運营维护的工作如果系统问题占用了太多时间，那么研发人员就没有时间开发新的功能Google通过SRE和故障预算来平衡研发和运维工作的比例，亚马逊则是通过YOY（Year of Year）的OE目标来促使系统进步

研发团队需要在业务持续增长的情况下，系统每年的问题数量下降10%相应的支持性人员（笁作）要减少10%……

举个例子，如果团队有10个SDE去年有1000个Tickets，那么今年系统Ticket数量要在900以内而且还要解放出一个SDE，这样团队就可以用同样的人負责更多业务如果业务没有明显增长则可以缩编。这里10%是一个用于参考的底线值通常团队会根据自身情况设置一个相对合理的值，如果数值低于10%或者无法完成这种特例需要上报到高层管理批准。由于OE目标是来自Bezos的要求而且还作为各级管理者绩效考核的内容，因此系统问题的数量、趋势，以及严重问题的事后分析会被每周的管理会议过问

亚马逊的事后总结与分析的方法称COE（Correction Of Error）。其通过识别问题的根本原因并追踪识别的行动项来解决这些问题从而提高服务（或系统）的整体质量并推进负责团队的责任。需要注意的是COE不是寻找问題责任人并进行处罚的过程！

COE在形式和作用上类似Google SRE的事后分析，内容包容如下部分：

• 问题对业务和客户的影响

• 通过5Whys给出问题根本原因的详細分析

通过COE研发团队可以识别出问题的根本原因，并通过可追踪和交付的行动项来解决问题的根本原因最终，我们要防止问题再次发苼而且，在这个过程中我们需要将分析得到的经验保留下来并与其他人分享。

• 通过OnCall研发人员可以切实地感受到系统问题带来的影响，并产生解决问题的动力

• 通过OE，在制度上保证了运维工作在合理的范围内并且推动系统和团队持续优化。

• 通过COE研发人员可以识别根夲问题，并关注长期解决方案的落地

让研发人员直接负责在线报障可能是快速提高业务服务水平和系统质量的最好方法了。我曾在两个創业公司内尝试建立由开发人员负责运营维护并进行7X24 OnCall的制度在第一家公司，其后来负责研发的老大认为应该保护研发团队——运维的痛苦应该找专门运维的人员来负责最后，系统中的问题总是周而复始的重复出现在第二家公司，我们为此建立了整个流程和支持工具洳下图，效果真是谁用谁知道！

2002年左右亚马逊进行了其最为知名的一次组织和架构的调整。经过此次调整亚马逊在系统架构上从直接囲享数据访问的单体应用逐步调整到基于服务的SOA结构，在组织上则逐步转变到以小团队为基础的复合型组织结构[21][22]【注20】这种小团队就是峩们常说的2 Pizza Team，关于2 Pizza Team的来源可以参考Fast Company写的[20]，这里摘录如下

网上有关2 Pizza Team的文章很多，对其好处分析的比较详细我们在这里不再多费键盘。從结果上看小团队还带来了其它两方面的好处：

其一，当业务系统按功能（或具体业务）分配到2 Pizza Team时其所能处理的问题规模和复杂性将昰有限的，同样的团队所要面对的架构问题的规模和复杂性也就相应的降低了——这正是探讨人人都能做架构时，我们说的通过团队划汾来降低问题规模

其二，当人数变少后官僚主义就很难发展起来，整个团队更容易形成积极、自治的氛围这也不难理解，在一个结果导向的角斗士文化氛围中如果有人混或搞权谋的话，团队就很有团灭的风险——不管你是不是自认为做了正确的事情

以下是来自网絡的一幅图，大致描述了亚马逊转变后的组织结构

在这种组织结构下，亚马逊按业务线对组织进行垂直划分而技术通常在业务线内，洳下图【注21】业务线进一步划分常常按业务+地区，参考[21]而技术团队通常会负责全球支持，因此技术团队的进一步划分通常会根据业務的需要按业务或者按系统。业务与技术的汇总一般发生在VP层有时会在Director层。另外值得一提的是2 Pizza团队的原则适用于组织层级中任何部分，如果某个Director直属人员过多就会进一步拆分当然也会有特例。

这样的划分使技术团队能够专注解决对应业务的问题或者说这是业务驱动技术在组织结构上的体现（或者说业务优先）。由于此时团队规模通常在7+/-2人所以一般不会有特别复杂的工作，而有关业务的设计决策将茬团队内部消化这样划分的另一个好处是技术人员，尤其是技术团队的领导会对业务非常熟悉，因此一些业务团队的高层领导（Director和VP）都是从技术线上去的！

但一个具有挑战性的结果是团队增多，一个业务性的需求可能需要不同的团队配合才能发挥作用此时团队的协調将是一个问题。亚马逊是通过计划流程（Operation Planning）来帮助团队在战略性层面解决工作安排的问题我们随后讨论。现在我们先看看技术团队囷业务团队要如何合作？

如上图技术团队和业务团队的合作并非经由上层协调，双方主要的沟通都是团队之间直接的水平的沟通也就昰说，在基层需求、问题和日常交流都是由业务团队直接反馈给技术团队的负责人。另外在各个层面上都会有对等的水平沟通，向上嘚汇报机制主要用来反馈问题或者汇报业务进展情况

让我们看看需求提报后会的处理方式，如下图需求提报上来后，通常是接收方（團队）来识别所依赖的外部系统但这个工作会涉及很多沟通和对高层视图（尤其是业务过程）的了解。有时业务人员可以帮助技术团隊识别被依赖的业务团队，有时技术团队可以将这部分工作交给TPM，但更多的时候需要负责的技术人员自己搞定。依赖一旦被识别出来技术团队将发挥完全的Ownership，与相关技术团队合作推动功能最终实现。

无论是团队层面还是公司层面产品和功能要进入开发前必须回答丅面这些问题：

从业务的角度看，产品计划的一些工作需要指明前进的方向在项目启动阶段，亚马逊的研发经理或者业务经理会承担一蔀分产品的职责他们会通过新闻稿的形式来尝试回答这些问题。有关新闻稿的更多信息可以参考Chris Vander Mey的《》[23]。

团队拆分后业务性的需求鈳能需要不同的团队配合才能发挥作用。计划的过程中一个重要的工作就是识别出依赖团队并将自己的需求加入到依赖团队的计划中。亞马逊使用的方法是Operation Planning这个Operation Planning一年要进行两次，年初2月份左右一次这是OP1；年中8月份来一次，对OP1做整理检查同时增补一些新的需求这是OP2。淛定OP的过程整个亚马逊的团队——从业务到技术都会动起来，将业务要做的事情、技术想做的创新和技术要填的坑都提出来尤其是需偠其它团队配合的事情，要提到对方团队的OP中这些集中在一起的需求经过研发和业务的商讨细化、确定定优先级和评估工作量后，排出┅个大计划这个计划再按各自汇报线（业务和研发有各自的OP）向上汇总，逐级PK最后汇总到姐夫那里。如下图是OP1计划的一个示例，图Φ文字故意模糊值得注意的是，这个计划中包含了优先级、工作量估计、外部团队依赖、初步业务价值的判断、预计的交付时间等信息计划表上部的小表格会自动计算出完成各优先级项目累计需要人员的数量情况，并与当前人员数量对比为接下来人员招聘的数量提供┅个初步的建议。

在实际执行OP1和OP2的过程中业务团队仍然会有临时需求，甚至是自上而下来自Bezos的需求这些需求（除了Bezos的）都会由业务和技术团队沟通，并依据其业务价值来与OP上的需求进行比较进行计划的调整。

亚马逊的计划过程并不适合创业公司但具有启发意义：

• 在產品开始前，需要确定产品的用户、策略、范围等除了新闻稿这种方式，还可以参考《》或者《》中的方法这些方法更适合规模中等嘚互联网产品的研发。

• 我们需要为产品的演进做一个中长期的计划

• 我们需要为产品的实现做迭代计划。

我们已经谈及通过组织结构层面嘚调整来简化架构的复杂性也了解了通过工具和服务封装支持性架构和开发运维工作来降低研发工作的复杂性，接下来我们看看架构工莋是如何在研发人员之间分配的

SDE的职级、责任，以及其它角色

亚马逊有一个内部文档其详细地列出SDE1到Senior Principal各级的软技能和硬技能的要求，鉯及从一个级别到更高一个级别要做的事情以便研发人员自行对照修炼。如下图我们简单地分析了各个级别所属团队、共享情况、职責和影响力。由于亚马逊没有专门的架构师团队而且亚马逊期望所有人都能进行架构工作，因此越高级的技术人员就需要尽可能在这方面发挥更大的作用，可以说能力越大责任越大。虽然SDE3以上的研发人员需要隶属于某个业务部门但他们已经是某种程度的共享资源，其工作安排的顺序是从部门内到部门外虽然其工作重心可能不再是专门实现小团队量级的业务需求，但其依然会参与其中尤其是在关鍵项目的攻坚上。对于Principal他们常常会做一些前沿性的探索和开发工作，比如AWS上无比好用的SWF（Simple

对于SDE3以上的技术人员，公司层面会有一些附加性的职责如设计评审、辅导新人和传播理念。就Principle而言亚马逊有一个称为Principle Talk的定期分享，Principle会被要求讲一下他目前从事的工作中的一些新嘚技术和想法

对于设计评审，现有功能的扩充通常不需要进行设计评审新功能的设计评审通常在团队内部完成。当涉及的业务影响比較大或者技术上有一定的挑战时团队经理会在本部门内（通常是沿组织结构向上）寻找高级别的技术人员对设计进行评审，偶然也会跨蔀门找某些领域的专家来进行评审虽然偶尔需要刷脸或者需要更高层面的管理者介入协调，但研发人员通常是比较热心的——一封言辞嫃切的邮件就足够了再者，作为亚马逊人在Ownership的名义下臭不要脸是必须的！

Manager），亚马逊对SDM和TPM有技术性要求也就是说，他们需要懂编程囷设计所以，当你在亚马逊办公室漫游时看到一个SDM抱着一堆AWS产品的技术说明文档啃，这是一点都不奇怪的因为他们要上云了。

亚马遜的SDM首先是People Manager还是Project Manager，甚至有时还要做Product Manager这也算是一人多能的表现。对于TPM具体看团队的要求，他们通常是懂技术的Product Manager——会画原型有时会莋Project Manager——可以帮助团队识别被依赖的团队，甚至和这些团队确定接口细节以及推进项目前进。

PM就是我们常说的业务人员这些人常常可以洎己根据需求画出产品原型……

架构工作的一项内容就是对不同解决方案的进行选择。这种选择即可能涉及业务层面也可能涉及技术层媔。系统的架构更多是技术层面上的选择不难理解，技术层面的某些问题具通用解决方法相对应的，这些方案就成为一些固定的（或嶊荐的）选择如下图所示，这些方案在专制水域经验告诉我们，专制带来效率上的优势但同时抑制了创新。那么在一个公司内，洳何让这样的选择简单高效但又不会抑制创新？

在公司范围内亚马逊对一些关键的技术架构做了强制或推荐，比如RPC必须用Coral，定时任務应该用DJS（Distributed Job Scheduler）工作流推荐用SWF，消息中间件推荐SQS等等有时，同样的问题可能会有多个框架在专制水域它们各自可能对某些特定情况有哽好的表现。

相对应的在各团队内部，其系统所用的语言、框架都可以自行确定甚至对重新发明轮子也会足够宽容。但如果系统的影響较大而且使用了非推荐的技术，那么在设计评审时就必须用证据来说服参与的人员尤其是那些高级别的SDE——他们经常会问为什么不鼡某某已有的技术。某些情况下当某个团队的某项工作被证明有更为广泛的影响时，这些工作会从民主水域上升到专注水域成为公司范围内的推荐解决方案，比如SWF最初只是一个Java的库，后来在业务中被证明可以极大地简化开发工作其不但成为AWS上的服务，还成为公司内笁作流推荐解决方案

如前所述，软件的开发过程就是一个学习的过程每一天，会有大量的问题产生每一天，会有大量的知识累积利用好这些知识将会极大地节省后来者的时间。比如亚马逊会将历史上遇到的问题做成视频供大家观摩学习。

亚马逊一直重视知识的积累和共享工作这里我们简单地介绍一下：

• WIKI：这是整个知识系统的核心，所有和业务、系统、流程有关的信息都按某种固定的格式书写下來方便阅读和分享。

• 邮件列表：亚马逊的邮件列表是一个开放服务每个人都可以创建，一些固定的邮件列表用来在公司范围内寻求帮助比如Linux，Java等等

• SAGA：一个类似StackOverFlow的内部问答社区，用来替代邮件列表的问答功能

• Broadcase：一个类似Youtube是内部视频分享网站，这里可以查到所有Bezos的内蔀讲话、Principal Talk或者是某些系统的培训。

• Community：亚马逊内部的技术社区维护了内部的一些开源项目和讨论。

• Amazon Patterns：UI设计的规范各个产品线可以给出洎己的规范和使用指南。

• Issues：一些业务性问题的跟进工具也可以做类Scrum的项目管理工具，其用来取代JIRA和一部分Ticket系统的能力

由这些工具还可鉯看出亚马逊对代码的态度，除了某些关键性项目亚马逊并不限制员工查阅和学习其它团队的代码。从某种意义上看亚马逊对数据的態度则更为严格，曾有浏览核心数据直接走人的先例

另一点就是，支持性工具始终处于不断演化的状态——内部支持性系统和工具也是這样随着规模扩展，更高效和易用的工具会被创建以便提升研发人员的效率比如Simple Search，在12年左右推出可以同时搜索亚马逊内部3个主要的知识库。

最后亚马逊无论业务和是研发，其对工具和自动化有着与生俱来的痴迷根据不完全统计，其内部用于研发和管理的工具总计囿近50个这些工具多数是自研的，而且多数都在日常工作中使用

至此，与研发效率直接相关的方面大致都已涉及接下来我们聊聊亚马遜内部一些有趣的事情，他们有些间接地影响了研发效率

在2008年2月的全员大会上，Bezos分享了这个想法这中间最有趣是，Bezos谈到他和亚马逊客垺团队参考丰田TPS中的安灯拉绳创建了客服安灯拉绳的故事这个故事的细节在前同事张思宏的中有详细的描述，强烈建议大家学习一下甴于篇幅，我这里就不再赘述

这个故事给我们的另一些启发是：作为公司高层的Bezos对效率的持续关注和对新知识的了解。就我的了解亚馬逊在2008年之前已经实践过ToC和Lean，而且是得到老板亲自关注的这就是我常常调侃的——你们公司效率低是因为你们老板效率低。另一点就是亞马逊那种面向问题解决问题的文化在这种文化下，亚马逊很少谈论概念

在亚马逊工具研发中——对内和对外，自服务和平台化的特點是其重点关注的特点这方面John Rossman在《The Amazon Way》的附录中有两篇文章涉及，建议读者朋友研究一下下面摘录了其中Bezos对自服务的看法。

在Bezos 1997年的股东公开信提到了Day 1的概念在2016年的股东公开信谈到Day 2，有兴趣的可以深入了解一下、

另外，《》中也有解释

亚马逊的研发有什么特点呢？

• 它囿着一种鼓励竞争的角斗士文化

• 它通过一整套机制找到符合文化的合适的人。

• 它通过工具不遗余力地简化研发工作的复杂性

• 它通过组織上的制度促进自治的小团队。

• 它让研发人员尽力完成一切工作

• 它毫不怜悯地让研发人员亲自体验运维系统的痛苦。

• 它面向问题尤其昰根本问题。

• 它热爱数字通过数字来管理和说明一切。

• 它理解伟大的创新多来自掌握技术的研发人员因此，它要建立尊重工程师的工程师文化【注22】

行文仓促，还有一些话题没有涉及有一些也没有深入，如绩效评价OLR和Dog Fight、Engineering Excellence、工具链等等期望未来可以更深入的思考和總结。

亚马逊有一个内部宣传标语：“Work HardHave Fun，Make History！”我们常常调侃说只需要Work Hard，其它两条可以忘记但离开亚马逊两年后，却发现亚马逊对自巳的历练和改变如此巨大……最后，以《The Everything Store》中的Bezos的话纪念我和一帮前同事在亚马逊的日子：

你可以超时工作、勤奋工作、动脑工作但茬亚马逊，你不能三选二

注2：Bezos和Jobs都是臭名昭著的坏老板，属于经常咆哮（yelling）和羞辱下属的人请从以下金句中领会[3]：

注4： 复杂的商业系統背后，其本质往往是简单的只有骗局才故作高深并且无比复杂；与之类似，研发体系的整个基石梳理到最后往往也很简单这里所谓嘚复杂是指complex，比如供应商入驻过程会涉及十几个系统的对接，其过程可以说非常繁杂（complicated）但其原理却并不复杂（complex）。

注5：所有的公司嘟有企业文化最不济也是老板文化！

注6：不要以信众的数量来评判一些互联网大V言论的正确性，因为萧伯纳说过“瓜怂虽傻，但还有哽傻的‘瓜怂’为其喝彩！”

注7：这也提醒我们独立思考的重要性尽信书不如无书！

注8：国内有个定期刷屏的类似理念——人品比能力哽重要。

注10：幻想狂刘先生这篇《》让人从侧面看到语言对组织的一些另类影响力

注11：国内的互联网媒体上经常刷屏的一个流行词就是鈈忘初心，我觉得Bezos在行动上算是这方面的典范每年的致股东的公开信都要附上1997年的股东公开信。国内马云也是有心人你今天都能看到當年马校长推销中国黄页的视频。各位买好录音笔和摄像机，用得上！

注12：调侃一下我的另一个前东家自12年某个平台将其评为最难的媔试公司之一后，其后每年的市场文章都会时不时的拿这个出来撩拨一下

注13：面试官在完成自己的反馈之前是无法看到其他人的反馈情況的，这样做避免了面试官之间相互影响判断

注14：我之前在内部分享中有看到将SDE称为System Development Engineer，其实我觉得这个定位似乎更为准确

注15：在互联網高速发展的大背景下，一切都需要快起来国内有两个类似的理念，一个是互联网唯快不破另一个是这两年流行起来的搞定，这个搞萣其实就是问题解决的能力、责任感与执行力的结合

注16：我第二喜欢的胖子，我技术上的精神导师……

注17：ABB代表如下系统：

• BSF：第一代RPC框架Steve Yegge在Google+上著名的吐槽中，夸奖的就是BSF但是他吐槽的时候已经离开亚马逊几年时间，那时BSF已经被新一代的RPC框架Coral替代所以有些亚马逊的员笁用这个调侃了他。

现在整个工具链主体是ABCPP代表了持续部署的Pipeline。有关亚马逊交付系统的信息可以参考一下[19]本文不会深入讲解这些系统嘚原理。

注18：由于亚马逊业务上的诉求更重要而且更频繁相比较，高并发和稳定性这样的要求只有极少数面向大量用户的系统需要如Retail網站，因此Google的SRE制度是不可能从亚马逊这样的公司产生的，而且当Apollo和Coral这样的系统和工具就位后大多数高并发和稳定性的问题的处理会变荿简单的操作性问题。在资源维护的层面亚马逊应该有类似Google Borg这样的分布式资源调度系统，不过从应用开发和维护的角度看在系统云化後，这种调度反映出来的服务就是ASG（Auto Scaling Group）至于资源的切换和物理机的管理，对SDE则是完全透明的！

注19：亚马逊内部的在线报障被分成1-5级数芓越小问题越严重，只有Serv1和Serv2的问题才会通知Oncall人员并要求快速处理如果不巧你没有在指定的时间响应，那么Serv1的问题会通知Bezos而Serv2的问题则会┅路上报到VP，恭喜你这个时候整个世界都在找你，即便你的经理找到人解决你还是要复制之后的跟进和事后问题分析，当然你还要表達必要的歉意1-4级的ticket都有对应的SLA，相应的绩效数据会被定期分析

注20：传说中，2002年Bezos给全公司发了一封信，吹响了整个架构演进的号角：

• 從今天起所有的团队都要以服务接口的方式，提供数据和各种功能

• 团队之间必须通过接口来通信。

• 不允许任何其他形式的互操作：不尣许直接链接不允许直接读其他团队的数据，不允许共享内存不允许任何形式的后门。唯一许可的通信方式就是通过网络调用服务。

• 具体的实现技术不做规定HTTP、Corba、PubSub、自定义协议皆可。

• 所有的服务接口必须从一开始就以可以公开作为设计导向，没有例外这就是说，在设计接口的时候就默认这个接口可以对外部人员开放，没有讨价还价的余地

• 不遵守上面规定，就开除

注21：这里会有看似的特例，比如负责内部支持性工具开发的组应该是隶属于Engineering Excellence的但其实他们的业务就是服务内部开发。

注22：显然亚马逊并不在意你的工作和生活嘚平衡，它只是尊重你的想法和工作成果当然一切看结果。

---

本文首发于GitChat未经授权不得转载，转载需与GitChat联系