第六章 规模优先
始终保持决断力，始终保持离开，始终保持扩张
始终保持决断力
更好地权衡。作为一个领导，你需要决定你的团队每周都做什么。有时权衡很明显（如果我们做这个项目，那另一个项目可能会有延期），还有的时候这些权衡会有不可预料的结果，回过头来会反咬一口。
在最高层，你的工作是作为一个领导-一个小团队或一个更大的组织-引导人们解决棘手的、模糊的问题。模糊意味着这个问题没有显而易见的解法，甚至可能没有解法。另一方面这个问题需要被探索、指引、摸爬滚打到一个可控的状态。如果把写代码比作砍树的话，你作为一个领导的工作就是”拨开树木见森林”，找到穿越森林的路径，指引工程师找到最重要的树。首先，你需要找到专家；然后识别权衡；然后在解决方案上反复地决定并迭代。
找到盲点
当你初次接触一个问题时，通常你会发现有很多人已经在这个领域摸爬滚打很多年了。这些家伙在这个领域呆了很久，以至于他们好像戴着眼罩-他们无法”拨云见日”。对于这个问题（或解决方案），他们会做一系列的假设，但从不会去重新认识这个问题本身。他们会说，”我们一直是这样做的”，他们已经失去了思考问题现状的能力。有时，你会发现一些奇怪的应对机制或合理化建议，这些都是为了证明现状的合理性而演变的。这就是你的优势所在-你有一双新的眼睛。你可以看到这些盲点，提出问题，然后考虑新的策略。（当然，对问题不熟悉并不是好领导的要求，但它往往是一种优势。）
确定关键的权衡要素
没有一劳永逸的解决方案，只有当下的最佳答案，而且几乎肯定涉及到在某些方向上的权衡。你的工作是指出这些权衡，向大家解释，然后帮助决定如何取舍
做决定，然后反复迭代
在你了解这些权衡以及它们如何运作之后，你就被赋能了。这个月，你能利用这个信息来做最佳的决定，然后下个月你可能需要重新评估和权衡-这是一个反复迭代的过程。
不过这里也有风险。如果你不给你的分析过程定一个边界的话，你的团队容易陷到寻找”最完美的解决方法”的漩涡中，这样使团队进入所谓的”分析瘫痪”的状态中，你需要使你的团队习惯于这个迭代过程。一种方法是每次把这个变更和风险降低，然后尝试给团队成员解释”我们将尝试这个方案看看效果，然后下个月我们可能撤销这个变更或做出不同的决定”，来使他们冷静下来。这使团队成员变得敏捷，并能从他们的选择中得到成长并进度
好（质量），快（延迟），便宜（容量）只能选两个
两方面开销：
第一个开销是对用户：更好的质量意味着需要更多的工作来生成这些数据，也就意味着更多的延迟
第二个开销是google本身：更好的质量意味着需要更多的工作来生成这些数据，这将消耗我们更多的服务器CPU时间，也就是我们说的”服务容量”。
始终保持离开
你的任务不仅仅是解决边界不清晰的问题，而是还要引导你的组织在没有你在场的情况下自己解决问题。如果你能做到这点，将释放一部分精力去解决新的问题（或去管理新的组织），在你身后留下一个个能自给自足的团队
划分问题域
搜索延迟
定位延迟的现象
挖掘延迟的根本原因
与此同时仍有数千名工程师增加系统的复杂度和搜索结果的”质量”，使对系统延迟的优化刚上线就被抵消掉了。因此我们还需要人关注一个平行的问题域，从一开始就防止增加延迟的变更。
委托子任务
你是唯一一个能解决这个问题的人吗？除非这件事真的迫在眉睫，你要硬着头皮把这件工作指派给一个你觉得能够完成，但可能会花费更多时间的人，并且你需要给与适当的指导。你需要创造机会来让你的团队成长；他们需要学着”升级”，然后自己解决这个问题，这样你就不在关键路径上(约束点 布伦特)了。
有什么事情是除了我以为团队里的其他人做不了的？
确保你的领导能够知道你的团队做的怎么样，以及确保在公司规模较大时团队不与公司脱节。但通常最常见也是最重要的答案是：”透过树木见森林。”换句话说，你能够制定一个高层次的战略。你的战略应该不仅包含技术战略，还应该包含组织战略。你的构建一个关于如何解决边界不清晰的问题，以及如何让团队能够长久地解决问题的蓝图。你持续性地在森林中规划砍树的路线，而把砍树的具体问题交给别人。
对于不足的地方反复迭代
管理的意义：95%是观察和倾听，5%是在适当的位置做关键性的调整
重要和紧急
当一个团队遇到苦难的问题，往往会显现出一个标准的解决模型-一个特殊的解决模型
分析：首先，你收到一个问题，然后开始尝试解决它。你找出相关的盲点，找到所有权衡点，然后为如何解决他们在团队内达成共识
挣扎：你开始着手工作，无论你的团队是否已经准备好。你准备好了迎接失败、重试和反复迭代。从这点上讲，你的工作就像。鼓励你手下的团队和专家们坐下来整理观点，然后仔细倾听，制定全局战略，哪怕最开始你不得不”编造一个战略”
前进：终于你的团队开始把事情搞清楚了，你做的决策越来越明智，问题也有了实质性的进展。士气得到了鼓舞。你开始反复迭代权衡，组织开始自驱地解决这个问题。干得漂亮！
奖励：你的上级把你叫到一旁然后祝贺你的成功。然后给了你一个新的问题去解决。是的：对于成功的奖励往往是更多的工作和更多的责任。通常是一个类似的，或者关联的问题，但是同样困难。
所以现在你陷入了困境。你呗分配了一个新的问题，但通常并没有更多的人力。这意味着原来的问题仍需要被解决，但只有一半的人力和一半的时间。我们把这最后一步成为压缩阶段：你需要处理所有你正在处理的事情，而且需要把它的规模压缩到原来的一半。
当你在管理岗工作后，你可能慢慢察觉到了，你的工作模式变得不可预测，天天都在救火。你的工作变得被动，更多的是响应别人的诉求。你的岗位越高，这个现象越明显。你成了一堆代号的最终负责人。你的所有通信手段-邮件、聊天室、会议开始让你感觉就像是你时间和精力的”ddos”。事实上，如果你不留心，最终你将花费你的全部时间在被动响应别人的需求上。
美国总统艾森豪威尔：我有两类问题，紧急的问题和重要的问题。紧急的问题并不重要，重要的问题从不紧急。
这两者直接的关系时威胁你作为领导的工作效率的最大的危险之一。如果你放入自己变成纯被动响应式的工作模式，你将会花费你全部的时间和精力解决紧急的事，但是这些东西在宏观层面几乎都是不重要的。
一定要记住你作为一个领导的工作是要做那些必须由你来做的事，比如规划穿越森林的路线。构建这些”元策略”是非常重要的，但几乎从不紧急。相比起来，回复下一封紧急的邮件永远更简单
那么，怎么才能强迫你自己花更多精力在重要的事情上，而不是紧急的事情上呢？
委托
安排专注时间
找到一个有效的进度跟踪系统
学会丢球
找到20%最重要的，20%最不重要的丢掉它，中间60%的也抛弃，如果中间这堆球中有真正重要的事，它最终无论如何都会回到你这里，然后转换到顶部20%那堆球里。
第七章 测量工程效率
人们提出这个问题越具体，他们就越有可能从这个过程中获益。
然后我们要求他们考虑以下问题：
你期望的结果是什么？为什么？
如果数据支持你的预期结果，将采取什么行动
如果我们得到一个负面的结果，是否会采取适当的行动？
谁将决定对结果采取行动，以及他们何时采取行动？
目标/信号/指标
目标是一个期望的最终结果。它是根据你希望在高层次上理解的内容来表述的，不应包含对具体测量方法的引用
信号是你如何知道你已经实现了最终结果。信号是我们想要衡量的东西，但它们本身可能是不可测量的
指标是信号的代表。它是我们实际上可以测量的东西。它可能不是理想的测量，但它是我们认为足够接近的东西
保持可追溯性
第八章 风格指导和规则
规则就像法律。它们不仅仅是建议或提议，而是严格的、强制的法律。因此，规则具有普遍可执行性-不得无视规则除非在需要使用的基础上获得豁免。与规则相反，知道提供帮助建议和最佳实践。指导值得遵循，甚至是高度建议能够遵守，但与规则不同的是，指导通常允许出现一些变化的空间。
创建规则
当定义一组规则时，关键问题不是”我们应该有什么规则?”我们要问的问题是:”我们想要实现的目标是什么？”当我们关注规则将服务的目标时，识别哪些规则支持这个目标，可以更容易地提供有空的规则集。
指导原则
我们需要维持一个对规模和时间都有扩展的工程环境
在这种情况下，我们规则的目标是管理开发环境的负责性，保持代码库的可管理性，同时仍然允许工程师高效地工作。我们在这里做了权衡：帮助我们实现这一目标的大量规则确实意味着我们在限制选择。我们失去了一些灵活性，甚至可能会冒犯某些人，但权威标准所带来的一致性和减少冲突的收益是最重要的
规则必须发挥其作用
一个工程师需要记住多少规则
一致性（命名、格式、结构）
如果惯例已经存在，那么一个组织与外界保持一致通常是一个好主意。
一致性是非常重要的，适应更是关键所在
规避风险的规则
执行最佳实践的规则
确保一致性的规则
始终保持决断力，始终保持离开，始终保持扩张
始终保持决断力
更好地权衡。作为一个领导，你需要决定你的团队每周都做什么。有时权衡很明显（如果我们做这个项目，那另一个项目可能会有延期），还有的时候这些权衡会有不可预料的结果，回过头来会反咬一口。
在最高层，你的工作是作为一个领导-一个小团队或一个更大的组织-引导人们解决棘手的、模糊的问题。模糊意味着这个问题没有显而易见的解法，甚至可能没有解法。另一方面这个问题需要被探索、指引、摸爬滚打到一个可控的状态。如果把写代码比作砍树的话，你作为一个领导的工作就是”拨开树木见森林”，找到穿越森林的路径，指引工程师找到最重要的树。首先，你需要找到专家；然后识别权衡；然后在解决方案上反复地决定并迭代。
找到盲点
当你初次接触一个问题时，通常你会发现有很多人已经在这个领域摸爬滚打很多年了。这些家伙在这个领域呆了很久，以至于他们好像戴着眼罩-他们无法”拨云见日”。对于这个问题（或解决方案），他们会做一系列的假设，但从不会去重新认识这个问题本身。他们会说，”我们一直是这样做的”，他们已经失去了思考问题现状的能力。有时，你会发现一些奇怪的应对机制或合理化建议，这些都是为了证明现状的合理性而演变的。这就是你的优势所在-你有一双新的眼睛。你可以看到这些盲点，提出问题，然后考虑新的策略。（当然，对问题不熟悉并不是好领导的要求，但它往往是一种优势。）
确定关键的权衡要素
没有一劳永逸的解决方案，只有当下的最佳答案，而且几乎肯定涉及到在某些方向上的权衡。你的工作是指出这些权衡，向大家解释，然后帮助决定如何取舍
做决定，然后反复迭代
在你了解这些权衡以及它们如何运作之后，你就被赋能了。这个月，你能利用这个信息来做最佳的决定，然后下个月你可能需要重新评估和权衡-这是一个反复迭代的过程。
不过这里也有风险。如果你不给你的分析过程定一个边界的话，你的团队容易陷到寻找”最完美的解决方法”的漩涡中，这样使团队进入所谓的”分析瘫痪”的状态中，你需要使你的团队习惯于这个迭代过程。一种方法是每次把这个变更和风险降低，然后尝试给团队成员解释”我们将尝试这个方案看看效果，然后下个月我们可能撤销这个变更或做出不同的决定”，来使他们冷静下来。这使团队成员变得敏捷，并能从他们的选择中得到成长并进度
好（质量），快（延迟），便宜（容量）只能选两个
两方面开销：
第一个开销是对用户：更好的质量意味着需要更多的工作来生成这些数据，也就意味着更多的延迟
第二个开销是google本身：更好的质量意味着需要更多的工作来生成这些数据，这将消耗我们更多的服务器CPU时间，也就是我们说的”服务容量”。
始终保持离开
你的任务不仅仅是解决边界不清晰的问题，而是还要引导你的组织在没有你在场的情况下自己解决问题。如果你能做到这点，将释放一部分精力去解决新的问题（或去管理新的组织），在你身后留下一个个能自给自足的团队
划分问题域
搜索延迟
定位延迟的现象
挖掘延迟的根本原因
与此同时仍有数千名工程师增加系统的复杂度和搜索结果的”质量”，使对系统延迟的优化刚上线就被抵消掉了。因此我们还需要人关注一个平行的问题域，从一开始就防止增加延迟的变更。
委托子任务
你是唯一一个能解决这个问题的人吗？除非这件事真的迫在眉睫，你要硬着头皮把这件工作指派给一个你觉得能够完成，但可能会花费更多时间的人，并且你需要给与适当的指导。你需要创造机会来让你的团队成长；他们需要学着”升级”，然后自己解决这个问题，这样你就不在关键路径上(约束点 布伦特)了。
有什么事情是除了我以为团队里的其他人做不了的？
确保你的领导能够知道你的团队做的怎么样，以及确保在公司规模较大时团队不与公司脱节。但通常最常见也是最重要的答案是：”透过树木见森林。”换句话说，你能够制定一个高层次的战略。你的战略应该不仅包含技术战略，还应该包含组织战略。你的构建一个关于如何解决边界不清晰的问题，以及如何让团队能够长久地解决问题的蓝图。你持续性地在森林中规划砍树的路线，而把砍树的具体问题交给别人。
对于不足的地方反复迭代
管理的意义：95%是观察和倾听，5%是在适当的位置做关键性的调整
重要和紧急
当一个团队遇到苦难的问题，往往会显现出一个标准的解决模型-一个特殊的解决模型
分析：首先，你收到一个问题，然后开始尝试解决它。你找出相关的盲点，找到所有权衡点，然后为如何解决他们在团队内达成共识
挣扎：你开始着手工作，无论你的团队是否已经准备好。你准备好了迎接失败、重试和反复迭代。从这点上讲，你的工作就像。鼓励你手下的团队和专家们坐下来整理观点，然后仔细倾听，制定全局战略，哪怕最开始你不得不”编造一个战略”
前进：终于你的团队开始把事情搞清楚了，你做的决策越来越明智，问题也有了实质性的进展。士气得到了鼓舞。你开始反复迭代权衡，组织开始自驱地解决这个问题。干得漂亮！
奖励：你的上级把你叫到一旁然后祝贺你的成功。然后给了你一个新的问题去解决。是的：对于成功的奖励往往是更多的工作和更多的责任。通常是一个类似的，或者关联的问题，但是同样困难。
所以现在你陷入了困境。你呗分配了一个新的问题，但通常并没有更多的人力。这意味着原来的问题仍需要被解决，但只有一半的人力和一半的时间。我们把这最后一步成为压缩阶段：你需要处理所有你正在处理的事情，而且需要把它的规模压缩到原来的一半。
当你在管理岗工作后，你可能慢慢察觉到了，你的工作模式变得不可预测，天天都在救火。你的工作变得被动，更多的是响应别人的诉求。你的岗位越高，这个现象越明显。你成了一堆代号的最终负责人。你的所有通信手段-邮件、聊天室、会议开始让你感觉就像是你时间和精力的”ddos”。事实上，如果你不留心，最终你将花费你的全部时间在被动响应别人的需求上。
美国总统艾森豪威尔：我有两类问题，紧急的问题和重要的问题。紧急的问题并不重要，重要的问题从不紧急。
这两者直接的关系时威胁你作为领导的工作效率的最大的危险之一。如果你放入自己变成纯被动响应式的工作模式，你将会花费你全部的时间和精力解决紧急的事，但是这些东西在宏观层面几乎都是不重要的。
一定要记住你作为一个领导的工作是要做那些必须由你来做的事，比如规划穿越森林的路线。构建这些”元策略”是非常重要的，但几乎从不紧急。相比起来，回复下一封紧急的邮件永远更简单
那么，怎么才能强迫你自己花更多精力在重要的事情上，而不是紧急的事情上呢？
委托
安排专注时间
找到一个有效的进度跟踪系统
学会丢球
找到20%最重要的，20%最不重要的丢掉它，中间60%的也抛弃，如果中间这堆球中有真正重要的事，它最终无论如何都会回到你这里，然后转换到顶部20%那堆球里。
第七章 测量工程效率
人们提出这个问题越具体，他们就越有可能从这个过程中获益。
然后我们要求他们考虑以下问题：
你期望的结果是什么？为什么？
如果数据支持你的预期结果，将采取什么行动
如果我们得到一个负面的结果，是否会采取适当的行动？
谁将决定对结果采取行动，以及他们何时采取行动？
目标/信号/指标
目标是一个期望的最终结果。它是根据你希望在高层次上理解的内容来表述的，不应包含对具体测量方法的引用
信号是你如何知道你已经实现了最终结果。信号是我们想要衡量的东西，但它们本身可能是不可测量的
指标是信号的代表。它是我们实际上可以测量的东西。它可能不是理想的测量，但它是我们认为足够接近的东西
保持可追溯性
第八章 风格指导和规则
规则就像法律。它们不仅仅是建议或提议，而是严格的、强制的法律。因此，规则具有普遍可执行性-不得无视规则除非在需要使用的基础上获得豁免。与规则相反，知道提供帮助建议和最佳实践。指导值得遵循，甚至是高度建议能够遵守，但与规则不同的是，指导通常允许出现一些变化的空间。
创建规则
当定义一组规则时，关键问题不是”我们应该有什么规则?”我们要问的问题是:”我们想要实现的目标是什么？”当我们关注规则将服务的目标时，识别哪些规则支持这个目标，可以更容易地提供有空的规则集。
指导原则
我们需要维持一个对规模和时间都有扩展的工程环境
在这种情况下，我们规则的目标是管理开发环境的负责性，保持代码库的可管理性，同时仍然允许工程师高效地工作。我们在这里做了权衡：帮助我们实现这一目标的大量规则确实意味着我们在限制选择。我们失去了一些灵活性，甚至可能会冒犯某些人，但权威标准所带来的一致性和减少冲突的收益是最重要的
规则必须发挥其作用
一个工程师需要记住多少规则
一致性（命名、格式、结构）
如果惯例已经存在，那么一个组织与外界保持一致通常是一个好主意。
一致性是非常重要的，适应更是关键所在
规避风险的规则
执行最佳实践的规则
确保一致性的规则
