亚马逊的六页纸
亚马逊公司一个很独特的事情就是六页纸的文档，所谓 6 pages narrative，不太好翻译我就管它叫六页纸好了。
先讲个故事，亚马逊早期的会议也是用PPT的，也有人是念PPT的，会议拖沓冗长，大家都踊跃发(che3)言(dan4)。Jeff对于这么开会深恶痛绝，正好看了一篇文章 The Cognitive Style of PowerPoint: Pitching Out Corrupts Within 痛斥PPT给交流带来的障碍和问题，于是Jeff根据这篇文章的建议，要求以后他的S-Team（相当于CEO-D）汇报的时候改成写六页纸的文档，而且这么重要的事情竟然没有搞个共创会，而是直接发了一封标题为 No PowerPoint presentations from now on at S-Team 的电子邮件给大家，这么一封邮件下去显然是遭到了强烈的反对，但是Amazon人都知道Jeff决定了的事情是九头牛也拉不回来的，所以也只好照办。但是把华丽的PPT转换成有内容有细节的论述文字不是那么容易的，有的人试图把PPT直接转换成文档，结局可想而知，还有人发现六页纸根本装不下他NB的想法，于是有聪明（鸡贼）地想到了用6号字体，于是Jeff只好规定必须用10号以上字体，而且还不能用窄字体，毕竟Jeff在内部是以micro management知名嘛！
大家虽然心里都在开骂了，但是也只能硬着头皮适应这个强势老板的要求。有意思的是当大家慢慢习惯了这种六页纸的习惯之后，发现其实效果还挺好的，会议上获得的信息量更大了，扯皮的时间更少了，与会议无关的活动变少了，会议的时间也变短了。最终大家慢慢都接受了，除了那个从一个习惯PPT的公司跳过来的新员工还在懵逼中。
故事讲完了，接下来具体聊聊这个机制：
首先六页纸格式要求必须是不超过6页10号字体的英文，在6页以外一般还会附带一个FAQ，以及一个附录。6页的内容是一个论述文或者述事的结构，需要从读者所能理解的方式描述想要表达的提案，需要尽可能陈述事实和观点，不能有形容词和感性的词汇，比如"very good", "really bad", "I feel"之类的表达。文档中提到的事实需要尽量精确地量化，提出的观点必须明确而坚定，不应该用"we may", "probably"而应该用"I will"这种明确的词汇。所有的逻辑需要以完整的句子来表达，而不能是词汇罗列，或者类似PPT里面的1. 2. 3. 4. 这样bulleted列表。最后一定要有明确的观点和决策，而不是讲个故事就完了。
FAQ部分需要从可能提出问题的角度加以阐述，比如不做什么，比如其他的选项为什么不行。FAQ是一个作者是不是全面思考的一个体现，只有从方方面面都考虑清楚了，才能够写出比较好的FAQ，也就是大部分人可能提出的疑问点都已经被解答了。附录的部分通常是正文提到的关键事实和根据的展开内容，主要是让对于当前话题缺乏背景信息的读者能够得到更加丰富的背景信息，以便更好地理解正文内容。
在会议开始的时候，会议主持人也就是六页纸的作者会把打印好的文档分发给参会者，然后会议的前20分钟就是安静的阅读时间，等所有人都读完了之后，先逐节澄清大家没有看懂的内容，或者数字上的问题，然后再提出疑问和挑战，主持人需要当场回应问题，如果不能当场回应需要记录下来准备下次会议沟通，最后如果大家没有什么明确的问题就形成了决议，如果有问题还需要再次开会解决问题，或者这个提案可能就被砍掉了。
六页纸最重要的好处在于如果能够通过完整地把自己的逻辑表述出来，通过事实和数据来论证观点，能够形成比较好的决策，而决策的过程不依赖演讲者的口头表达能力（忽悠水平）。其次普通人阅读的速度是讲话速度的3倍，所以通过阅读来获取信息的速度会远大于听演讲的速度，同时由于阅读者可以自由选择阅读顺序，所以能够在阅读过程中保证思维的连贯性。对比一下讲PPT的情形，由于整个节奏都是演讲者控制，如果大家理解速度不一致，或者某些人有个疑问的时候，要么需要等演讲者慢慢讲到后面的某一页PPT，要么可能会从某个思考点断开，无法理解演讲者试图阐述的逻辑，如果直接打断又可能导致其他听众需要一起等待。而文档的好处在于整个阅读节奏和顺序由阅读者掌控，既可以直接看附录了解细节，也可以在各章节中跳转或者反复阅读某一段关键文字，从而更好的理解作者的意图，而不需要影响另外一个人。最后由于在整个过程中所有的参与者都需要自己阅读，自己提出意见和建议，所以也就很少有时间去玩手机或者看电脑，保证了注意力的集中。
当然写好六页纸对于大部分来说都是很难的，特别是那些PPT高手来说，要让他们从酷炫的观点罗列转向结构化的逻辑表达，是一个非常痛苦的过程，但是从亚马逊的实践来看这样的付出是有回报的，所以这个模式就被保留下来了。
亚马逊的单线程领导
前面讲了六页纸，这里讲讲单线程领导(Single-Threaded Leadership)，Jeff有个观点：
the best way to fail at inventing something is by making it somebody's part-time job.
Jeff是一个逻辑非常清晰做事很踏实的人，对于创新这件事，他不是给大家提倡一下喊喊口号就结束了，而是会关注到影响创新实现的具体因素。他认为要想搞创新，负责人必须专注一个目标，否则这个事情一定搞不成，所以在开启一个创新项目的时候，他特别强调负责人需要100%投入到这个项目，而不能由某人来兼任。亚马逊出现过这样的案例，想要提拔某个人的时候不是让他去带一个更大的团队，而是让他去带一个更小的团队，原因在于这个小团队做的是一件创新的事情。
Working backwards 这本书给了一个假设场景：
在一个Jeff参加的业务月度汇报会议上，某个新项目状态为红色（停滞），有人问是什么原因导致没有进展？
总监X：这个项目有很多部分，我们已经看到了5个没有解决的问题并且正在解决，这五个问题是……
Jeff(打断)：在我们谈这些具体问题之前，谁能告诉我谁是这个事情的single threaded leader？
业务线VP：是我
Jeff：但是你是整个业务的负责人，我需要你专注整个业务整体结果而不是这个具体项目
VP 1 (汇报给业务线VP)：那应该是我吧
Jeff：这个项目是你和你的团队每天工作的全部内容吗？
VP 1：不是的，我们目前只有一个产品经理是全职负责这个事情，但是我们其他兄弟都在帮他。
Jeff(不耐烦)：这个产品经理是不是有足够的能力和权威，以及团队资源来保证这个项目完成吗？
VP 1：没有，所以我们打算招一个总监来带这个事情。
Jeff：你打了多少个面试电话，做了多少现场面试来招聘这个新总监？
VP 1: 我们还没有开放这个职位呢，我们正在准备JD，还没有开始招聘。
Jeff: 开什么玩笑，这个新的leader不到位这个项目就不会有真正的进展，这才是导致项目停滞的真正原因（而不是那5个问题），让我们先解决招聘的问题。
VP 1：好的，我们先招聘（开始准备招聘文档）
这个故事中需要强调的是 Single threaded leader (STL) 是指只负责一件事情的人，所以在这个对话中，不仅仅每件事情都要有人负责，同时每个人应该有一个，也仅仅有一个负责的方向（在某个颗粒度/抽象层次），这个负责人需要有足够的权威和能力，并且100%的精力来投入这个方向，而不是同时负责多个方向。这样的STL会构建一个和其他业务隔离的，基本自治的团队来达成给定的目标。
但是这样的STL模式并不是一开始就有的，亚马逊最早的系统也是一个大的单体应用Obidos，随着业务增长，团队扩张，大家发现协作变得越来越困难，任何一个小团队要想达成目标，都需要依赖别的团队的合作，而另外一个团队可能会有别的优先级和依赖问题。由于代码都在一个系统里运行，所以一个团队引入的bug可能导致整个系统挂掉。同时由于大家都共享一个关键的数据库acb，而这个数据库是如此关键，所以对数据库的任何改变都需要通过一个DB Cabal专家组（CTO负责）来审核。在这种条件下任何一个变更都变得非常缓慢而困难，如果一个变更看起来有风险的话，那么就很难得到批准，听起来很熟悉不是？那么如何解决这些问题呢？是不是应该提升大家的沟通能力和技巧，设置专职的项目经理，搞一个协同工作组，发起一个战役来解决问题呢？
Jeff的选择是减少沟通和协同，而不是鼓励更多的沟通和协同。所以他决定通过SOA的方式来解决这个问题，为了达成这个目标制定了如下强制规则：
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
- It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
- All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
- Anyone who doesn't do this will be fired.
- Thank you; have a nice day! (原文作者搞笑的)
以上参考某个前Amazon员工在Google的吐槽，请参考https://gist.github.com/chitchcock/1281611
通过以上的方法，亚马逊把一个大的单体应用分拆成为很多小的应用，同时提出了Two-Pizza Team的概念，试图来解决软件工程中的协调问题。所谓Two-Pizza Team是这样的：
团队人数不超过10个
团队自治，团队不需要协调其他团队资源就能完成自己的工作，团队负责的服务通过服务API调用来依赖其他团队的产品。
通过一个好的目标函数来评估绩效
实时监控
成为（一小片）业务负责人
由优秀的复合型人才作为leader
自己养活自己，值回成本
由S-Team批准建立
这里除了人数限制以外，团队自治也是区别于其他公司小团队的一个标志，团队自治意味着不能有跨团队数据库访问，不能有富客户端，除了服务API以外没有后门。一个团队完全负责自己产品的所有设计，开发和运维，不需要和其他团队发生紧密的关系，这一点需要在更大的产品架构上真正做到高内聚，低耦合。这个过程需要通过大量的思考和时间投入，所以这无法由团队主管来完成，而是一个团队中最资深的工程师（通常和这个团队主管平级）来完成。
但是亚马逊的实践发现Two-Pizza Team并不能解决所有问题，比如团队的规模，比如团队的度量机制等等，由于优秀的leader的稀缺，业务的差异导致对更大团队的需求等等原因，实际上好的Two-Pizza Team是很难得的，所以后来亚马逊提出了Single Threaded Team来解决这个问题，这样的团队会但在一些具体的条条框框方面比Two-Pizza Team更少一些。
Single Threaded Team要求一个团队有一个非常专注的目标，同时能够做到比较好的自治的状态。专注目标比较好理解，所谓自治是一个团队在开发和发布变更的时候不会和其他团队耦合，如果一个团队能够在不打扰其他团队，不需要得到其他团队的许可就能完成产品变更，那么这就是一个自治的团队。通过单线程的自治团队，亚马逊获得了快速交付，快速创新的能力，让亚马逊在更大的规模下实现了敏捷和快速响应。
对比一下虽然我们也有小而美的研发团队，但是同时也存在很多大而很难动的产品和团队，因为我们的leader们的职责越来越多，产品的功能也越来越多，产品的耦合也越来越重，一个产品几十上百个分支，产品的发布和协调甚至需要专职的PM来协调，很多一线的同学把大量的时间投入到沟通，尝试发布，测试，回滚然后重头再来的循环中。我们在碰到问题的时候很多惯性思维是设置更多的协调小组，战役项目，PM等来解决问题，但是往往都是一阵风，无法从根本上解决问题，反而让团队感受到了更多的事情和压力，让事情变得更加糟糕了。
需要说明的是，亚马逊的组织方法未必是最好的，也未必适合阿里，但是亚马逊在持续地反思和迭代软件工程组织方式，通过每年一度的Tech Survey来了解一线的工程现状，以科学的态度和严谨的逻辑来思考和探讨软件工程的问题，持续关注和投入工程技术团队的研发效率问题，才是真正值得学习的地方。
在这里我想引用另外一本书 How will you measure your life 里面一段话：
How you allocate your resources is where the rubber meets the road. Real strategy—in companies and in our lives—is created through hundreds of every day decisions about where we spend our resources. As you’re living your life from day to day, how do you make sure you’re heading in the right direction? Watch where your resources flow. If they’re not supporting the strategy you’ve decided upon, then you’re not implementing that strategy at all.
大部分情况下，所有的公司都会说重视技术，鼓励创新，但是却没有把真正宝贵的资源投入到技术和创新上面，不是这些高管们故意撒谎，而是很多人没有意识到嘴上说的策略如果无法落实到实际的资源分配上，就是一句空话。
亚马逊的KPI
这里标题党一下，其实亚马逊是不说KPI的，但是亚马逊会设定指标(Metrics)，可能有人会说，是不是就是KPI换个名字呢？当然不是简单换个名字，主要区别在于亚马逊强调的是Input Metrics，或者叫可以控制的指标，而不是Ouput Metrics，或者叫做结果指标。
举个例子，我们在设定KPI的时候，可能会说产品DAU到多少，收入到多少，高年级的同学可能会有股价到多少，但是在亚马逊的文化里这些都是结果指标，可能和很多不可控因素相关，比如友商烧钱，既然亚马逊的第一条原则就是专注客户而不是友商，所以这个事情就别关注了。那么什么叫作Input Metrics，简单来说就是那些通过评估，能够合理体现业务趋势和状态的量化指标，比如仓库里面的空间利用率，周转率，未完成订单数，对于技术团队来说可能是性能，成本，交付效率等等。亚马逊有个著名的飞轮理论，如下图所示；
飞轮理论本身已经讨论很多就不展开了，但是在这个图里Jeff最关注的不是中间的Growth，因为那是Output Metrics，他更多关心的是让飞轮加速的外面这一圈，也就是Input Metrics，让飞轮转得更快的因素。
但是是不是团队的Input Metrics就是一成不变的呢？当然不是，随着团队的成长，业务的发展，指标也需要调整。所以每个指标都会有自己的生命周期，包括定义，度量，分析，改进，控制这几个阶段。
定义
定义指标是非常关键的一步，和大部分公司不同在于亚马逊强调要区分 Input 和 Output，不是说不关注Output，而是Input更为重要，所以选择只用Input Metrics作为团队指标。有时候指标会比较片面，比如早年亚马逊把品类作为核心指标，但是很快就发现出现了大量的没有实际购买的商品上架，导致大量的垃圾页面和库存浪费，于是亚马逊就从品类指标转向了商品PV指标，然后变成了有库存的商品PV指标，再然后就变成了能够在两天内发货的商品PV指标，可以看出来这是一个逐渐迭代和改进的过程。
度量
由于人性所以团队在选择指标时往往会倾向于那些看起来让自己团队显得有正向进展的指标，所以如何移除指标的倾向性也是一个很重要的问题。为了解决这个问题，亚马逊的业务团队引入了财务团队的意见，只有财务团队认可的指标才会被认为是没有倾向性的指标。然后就需要把这些指标通过软件系统构建出来，变成一个可以线上化监控的指标，通常这样的指标会需要一定的开发工作，但是根据我的个人经验，亚马逊还是有非常优秀的能提供统计刻画和自助配置的监控系统，所以大部分一线团队的指标都是比较容易度量的，这本书里讲的更多的是S-Team的指标，这些需要比较多的软件开发工作。
分析
分析的主要工作是去噪，因为指标经常波动，大量的波动可能仅仅是噪声而已，所以需要通过COE (Correction of Errors)流程，按照5 whys的方法进行根因分析，需要说明的是，COE本身并不是追责（实际上也不一定会追责）。COE的撰写对于团队是一件很重要的事情，需要挖得比较深，找到能够在系统层面解决业务问题的方法，因为亚马逊一般会倾向于在软件系统层面解决问题，而不是引入专职的人员或者新的工作流程来解决问题。
补充一点，5 whys是一种很好的根因分析法，需要注意两点，一方面这个是自己给自己提出问题，自己寻找答案，另外一方面就是需要通过严谨的逻辑和事实根据来分析，不能玩文字游戏。
改进
如果前面的步骤做得足够的扎实的话，这一步是相对容易的，团队能够去除噪声找到真正的问题，并且通过根因分析找到能够落在系统层面的解法，然后就是完成改进。
控制
随着系统的改进指标会变得平稳，这个时候对于指标的日常管理会变得更加关注异常而不是常态。同时有时候前面的人工决策流程也可以变成系统化决策流程，因为亚马逊总是倾向于让系统变得自动运行而不需要依赖人肉管理和运维。
和大多数公司一样，亚马逊也会定期对这些指标数据进行复盘和讨论，这里想提一点就是业务指标图表会同时展现最近6周和全年的数据，以及前6周/前一年的数据作为对比，这样就能够在不同的时间颗粒度上对数据进行观察和讨论。
客户案例
因为指标是统计数据，所以即使是严格定义的指标也无法覆盖所有的情况，所以除了指标以外，亚马逊还喜欢讨论消费者个具体案例，Jeff本人会直接接受客户的电子邮件并且转发给下面的团队，并且只带一个问号，下面的团队收到这样的邮件之后就需要对邮件中提到的问题进行分析和探讨，并且在系统层面解决问题而不是解决这个具体案例。同时团队也有类似阿里亲听这样的活动，让所有的管理者都能到客服一线接触最新鲜直接的客户案例，把问题带回来加以改进。通过结合客户案例和指标，可以从不同的角度来观察系统的健康度，并且及时发现问题加以改进，从而得到一个相对不错的客户体验。
长远思考
关于KPI还有一点就是，在亚马逊年度绩效并不会影响年终奖，因为根本就没有年终奖，但是会影响股票，这一点那个讲书的樊登有类似的观点，他也认为只有“脑子里天天想着钱的人，是干不出漂亮事儿的”，所以他直接给员工开高工资，但是没有绩效奖金。亚马逊的观点是员工不应该关注短期回报，而应该专注长远价值和回报，Jeff是一个特别强调Long Term Thinking的人，虽然在Working Backwards没有专门对长远思考(Long Term Thinking)详细阐述。
Jeff为了表达自己对长远思考的热爱，他甚至投资建造了一个万年钟（10,000 Year Clock），这是一个每年转动一格，可以运行一万年的机械设备。这样一个没有任何实用价值的构建在高山之巅的机械钟的唯一作用就是试图提醒人类换个角度看待时间。
Such a clock, if sufficiently impressive and well-engineered, would embody deep time for people. It should be charismatic to visit, interesting to think about, and famous enough to become iconic in the public discourse. Ideally, it would do for thinking about time what the photographs of Earth from space have done for thinking about the environment. Such icons reframe the way people think.
还有一个著名的例子就是Jeff的致股东信，把早期定义清楚的原则和逻辑反复呈现，不做大的调整，这也反映了这家公司在设立之初对于这家公司定位的第一性思考，从而有能力在不改变基本原则和逻辑的前提下持续发展壮大。
在亚马逊的组织设计，机制设计中，我们也能大量看到Long Term Thinking的影响，除了没有绩效奖，还有对于长远客户价值的执着，对于系统化解决问题的倾向等等。
亚马逊的领导力准则
这一节聊聊亚马逊的领导力准则（Leadership Principles）。Jeff是个独立特行的人，别人家的公司都讲价值观，他不设价值观，非要搞14条领导力准则。这些准则很多都是源自于Jeff对团队的要求，后来由HR通过和大家interview来收集整理出来的，故事我就不讲了，但是把这个14条中有意思的几条展开讲讲。
Customer Obsession
这一条亚马逊中国翻译为“客户至尚”，但是我个人觉得这个翻译也不是很准确，原文感觉有点“偏执”的意味在里面。从字面上来说，大家可能觉得不就是“客服第一”吗？没啥特别的，但是亚马逊是这么解读这一条的：
领导者从客户入手，再反向推动工作。他们努力工作，赢得并维系客户对他们的信任。虽然领导者会关注竞争对手，但是他们更关注客户。
这个解读主要讲得是做事情的方法，所谓反向推动工作（Working Backwards）也是本书的标题，强调的是做事情以终为始，从交付物定义开始去思考如何达成客户价值。同时也强调了对客户的关注应该高于对竞争对手的关注，这是大多数公司都会做的事情，但是亚马逊希望能聚焦在客户身上，避免被竟对带歪了。
Ownership
这一条也是大部分公司都会强调，但是亚马逊给出的解读又是不一样的：
领导者是主人翁。他们会从长远考虑，不会为了短期业绩而牺牲长期价值。他们不仅仅代表自己的团队，而且代表整个公司行事。他们绝不会说“那不是我的工作”。
可以看到亚马逊是把长远思考作为主人翁意识的重要体现，仔细想想确实也有道理，真正的负责是长远的负责，而不是短期利益，关注短期利益都是不负责任的表现。
Dive Deep
这一条我觉得他们官方翻译太差了，还是原文更好懂一点：
Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them.
领导者深入各个环节，随时掌控细节，经常进行审核，当数据与传闻不一致时持有怀疑态度。领导者不会遗漏任何工作。
这里的 operate at all levels 我的理解是在不同的问题层次上深入，因为很多leader只是高高在上地问下属，但是亚马逊希望高阶leader也能下到非常具体的问题上了解具体细节，并且当客户案例和统计数据对不上的时候保持警惕，不会因为某个事情太细节了就忽略掉。
Have Backbone; Disagree and Commit
这一条我个人觉得非常重要，鼓励提出反对意见，允许不同的声音，同时也要求在行动上保持和上级的要求一致。
领导者必须要能够不卑不亢地质疑他们无法苟同的决策，哪怕这样做让人心烦意乱，精疲力尽。领导者要信念坚定，矢志不移。他们不会为了保持一团和气而屈就妥协。一旦做出决定，他们就会全身心地致力于实现目标。
公司不是慈善机构，也不是一个讲民主的地方，所以在行动上当然是要坚决执行组织决定，但是在观点和意见表达上，外企一般是开放的，给大家自由交流观点的便利。但是这一点真正要做到，往往还不完全是敢不敢说，更多地其实取决于leader是否构建了一个足够安全的交流环境，如果leader不能构建一个开放安全的交流环境，就很难听到真实的声音。
小结
这个领导力准则网上很容易找到，其他我就不一条一条解释了，整体来说我觉得亚马逊的领导力准则还是很务实的。首先不仅条数比较多，每一条的解读都是在解释如何做，做什么不做什么，而不是单纯讲道理，有一定的指导性。其次这些领导力准则会在每年的绩效评估中作为非常重要的一部分进行评估，还要求写出非常翔实的事例来证明员工做到的程度。最后在招聘过程中也会专门就其中的部分或者全部准则进行考察，尽可能保证新加入的员工能够符合这些领导力原则的要求。其他的各种做事方法和规则中也会反复提及这些领导力准则，确实是把这些准则作为大家的行事原则。
另外补充一点就是虽然没有明确列为领导力准则，但是也会有要求的一点就是系统化解决问题的倾向，大部分人都认为人肉做一件事是靠不住的，所以会尽可能通过软件系统或者机制（不是人工流程）来解决问题，而不是依赖某个职位或者某个工作小组（虽然也有，比较少）。
参考：https://www.amazon.jobs/zh/principles
亚马逊的文化局限
作为一个工程师的视角看到的亚马逊，前面几篇写的亚马逊做的好的部分比较多，可能会给人一种亚马逊是一家“完美”的公司的错觉。亚马逊当然不是一家完美的公司，也存在很多欧美大公司的通病，包括一些深入骨髓的问题，但是个人观点难免偏颇，这里就不展开了。
