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