Google公司的软件工程之道 (3)

http://mp.weixin.qq.com/s/6KMFeVlt1QzLkfcYcWC08A

英文原文由Google软件工程师Fergus Henderson 于2017年1月31日所写，文章末尾原文链接。

【本文比较彻底、全面地分享谷歌公司的软件工程之道， 总共分为三部分，前面已经发布了Google软件开发之道：

Google公司的软件工程之道 (1)

Google公司的软件工程之道 (2)

今天发布Google的项目管理之道、人员管理之道。之所以把全文分成三部分介绍，让大家阅读轻松些，一次不要阅读太多，而且能细读，收获更大一些。而且我们认真对待翻译，把每一个疑点搞清楚再翻译，提供高质量的精品。 】

第2部分 Google项目管理之道

1.  20%时间

允许工程师将高达20%的时间花在他们选择的任何项目上，而且无需事先得到经理或其他人的批准。对工程师的这种信任是非常有价值的，原因有很多。

• 这能够让有好点子的人，即使其他人无法立即发现这个想法值得去做，他也有足够的时间去开发一个原型、演示内容或演示文稿，用于展示他们的想法有何价值。

• 它让那些可能隐藏起来的活动变得可见以便管理。在其他没有“允许20%时间”这种官方政策的公司中，工程师有时会参加那种不成形管理机制（informing management）的“特别任务小组（译者注：skunkwork类似于taskforce，为特定任务而设立的团队）”项目。如果工程师能公开这些项目，在报告日常工作状态时也描述这些项目上的工作，就会好得多，即使管理者不认同当前项目的价值也是如此。公司层面支撑这些的官方政策和文化使这成为可能。

• 通过允许工程师将一小部分工作花在有趣的事情上，可以让工程师保持激情和兴奋，防止他们心力交瘁，当他们感觉不得不花100%的时间来处理繁琐的任务时，很容易陷入疲惫。工作上十分投入的、有激情的工程师，与筋疲力尽的工程师相比，在生产效率上的差异远远不止20%。

• 这鼓励了创新文化，看到其他工程师做有趣的实验性20%项目，会鼓励其他人也这么做。

 

2.  目标和关键结果

Google的每个员工和组织都被要求明确记录下他们的目标，并评估目标实现的进展情况。团队会设定季度和年度目标，每个目标带有可度量的关键结果（Objectives and Key Results，OKR），用于展现目标实现的进展。公司的每个层级都这样做，从各个角度定义公司的整体目标。个人和小团队的目标，需要对齐他们所属的更广泛团队的、更高层级的目标，也要对齐公司的整体目标。每个季度末，记录OKR的进展，并对每个目标给出0.0（没有进展）到1.0（100%完成）的评分。OKR及其评分通常在公司内公开可见（对于高度机密的项目等特别敏感的信息，偶尔会有例外），但不直接用于个人绩效评估。

OKR应该设高一点：预期目标的整体平均得分是65%，意味着鼓励团队设置一个比实际能完成的多约50%任务的目标。如果一个团队的得分显著高于这个水平，那就鼓励他们在下个季度设置更高的目标（相反，如果团队的得分显著低于这个水平，则鼓励他们下个季度设定一个审慎一些的目标）。

OKR提供了一种沟通公司各部门工作的关键的机制，并通过社会性的激励（social incentives）来鼓励员工有良好的表现——工程师知道他们的团队将会有一个OKR评分的会议，并且自然而然地想要得到一个好分数，即使OKR对绩效评估或薪酬没有直接影响。

定义客观的、可度量的关键结果有助于确信：人们被引导去做一些对实现共同目标有真实、具体、可衡量的影响的工作，以取得好的绩效。

3.  项目批准

尽管有一个明确定义的启动批准的流程（译者注：第1部分已介绍），Google并没有明确的项目批准或取消的流程。尽管我自己已经在Google待了差不多10年，并且现在已经成为一名经理，我仍未完全理解这种决定是怎么做的，部分原因是批准方法在公司内并未统一。各级经理们对他们团队的项目负责并承担责任，同时行使他们认为合适的自由裁定权。一些情况下，这意味着决策的方式是自底向上的，工程师们在团队范围内，有选择为哪个项目工作的自由。在另一些情况下，这些决策更多的是自顶向下的方式，主管或经理们决定哪个项目继续进行，哪个将获得额外的资源，而哪个会取消。

4.  团队重组

偶尔，当一个主管决定取消一个大项目的时候，就会有许多之前在这个项目工作的工程师，需要到一个新的团队找一个新的项目来做。同样的，偶尔也会有一些“碎片整理（译者注：defragmentation也可翻译“重组”，但这样翻译更生动）”工作，将跨区域的、分离的项目进行整合以减少地域数量。为达到这个目的，某些区域的工程师就会被调整团队和/或项目。这种情况下，工程师们通常在他们本地区可获得的职位内，可以自由选择新的团队和角色。重组时，他们也可以选择换地区以待在原来的团队和项目中。

除此以外，其他种类的团队重组，例如整合或拆分团队、变更报告关系等似乎经常发生，尽管我不知道Google和其他大公司相比如何。在一个大型的、技术驱动的组织中，为了避免技术和需求变化导致的组织效率低下，略微频繁的重组可能是必要的。

 

第3部分 Google人员管理之道

1.  角色

下面将会详细介绍，Google设立了工程和管理的不同的职业发展通道（阶梯），将技术管理角色从管理者中分离出来，将研究嵌入到工程中，以及支持工程师工作的产品经理、项目经理和网站可靠性工程师（site reliability engineers，SRE）等角色。看起来至少有部分实践对于维持由Google开创的创新文化是很重要的。

Google在工程类别下还设立了少量不同的角色，每种角色都有职业发展的可能，有一系列级别和晋升通道（与薪酬的提升相关，例如工资），用来认可进入更高级别的认可。

主要角色如下：

• 工程经理（译者注：Engineering Manager，类似部门经理）

这是本列表中唯一的管理者角色，其他角色中的个体可能会管人，而工程经理一定会管人。工程经理通常做过软件工程师，并且总是具备相当可观的技术专长，以及人员管理技巧。

技术上的领导力与人员管理是有区别的。

工程经理不一定领导项目；项目由技术主管领导，他（指技术主管）有可能是工程经理，但更多的时候是软件工程师。一个项目的技术主管对这个项目的技术决策有最终的发言权。

经理们对技术主管的选择，以及他们团队的表现负有责任。他们负责辅导和协助职业发展，做绩效评估（以同行反馈作为输入，见下），并负责薪酬中的某些方面。他们还负责一部分招聘流程中的工作。

工程经理通常可以直接管理3~30人，最常见的是8~12人。

• 软件工程师（Software Engineer ，SWE）

从事软件开发的大部分人都是这个角色，Google的软件工程师招聘门槛非常高，通过只雇佣特别优秀的软件工程师，避免或尽量减少困扰其他组织的许多软件问题。

针对工程人员和管理人员，Google有各自独立的职业发展序列（译者注：美国科技公司基本类似）。尽管软件工程师进行人员管理，或者转换为工程经理角色是可能的，但人员管理并非晋升所必须，即使在很高的级别上也是如此。在更高的级别上，需要展现领导力，但是可以有多种形式的体现。例如，创建有巨大影响力的、或有大量工程师使用的重要软件，这就足够了。这（译者注：指各自独立的职业发展通道）很重要，因为这意味着有很强技术能力，但缺乏人员管理意愿和技巧的人，仍有很好的职业发展路径，而他们无需走管理通道。这避免了一些组织中存在的问题——人们因为职业晋升的原因最终踏入管理岗位，但却忽视了团队中真正的人员管理。

• 研究科学家（Research Scientist）

这一角色的招聘标准非常严格，门槛非常高，要求通过极佳的论文发表记录*以及*代码编写的能力，来展示其出色的研究能力。在学术界有许多非常有才华的人能够胜任Google的软件工程师角色，但不能胜任研究科学家角色。在Google，大部分拥有博士学位的人都是软件工程师而不是研究科学家。对研究科学家，是通过他们的研究贡献，包括他们的论文进行评价，但除了这一点以及不同的头衔，在Google软件工程师和研究科学家角色之间并没有太大的区别。二者都可以做原创性研究工作并发表论文，都可以实践新点子使用新技术，都可以编写代码、开发产品。在Google，研究科学家通常和软件工程师工作在一起，在同一个团队中，致力于同一个产品或相同的研究。

• 网站可靠性工程师（SRE）

对运行系统（译者注：产品线上正在运行的系统）的维护是由软件工程师团队来实施的，而不是传统的系统管理员团队，但是SRE职位招聘软件工程师要求，略低于SWE职位的招聘要求。SRE角色的性质和目的在SRE手册[7]中已经详细介绍，这里不再进一步讨论。

• 产品经理（Product Manager）

产品经理对产品的管理负责，作为产品用户的支持者，他们协调软件工程师的工作，传递对这些用户很重要的功能特性，与其他团队合作，跟踪缺陷和计划，确信所需的一切都就绪，以开发出高质量的产品。产品经理通常不亲自写代码，但会与软件工程师一起工作，以确保他们写出正确的代码。

• 项目经理/技术项目经理（译者注：Program Manager /Technical Program Manager 直译为“程序经理/技术程序经理”或“流程经理/技术流程经理”，以前微软也要类似角色，但“项目经理”一词更接近该角色的职责）

项目经理是一个与产品经理大致相似的角色，只不过不是管理产品，他们管理项目、流程或操作（如数据收集）。技术项目经理也类似，但需要与工作相关的特定专业技术知识，例如用于处理语音数据的语言学。

 

软件工程师与产品经理和项目经理的比例，在不同的组织内是不同的，不过一般都很高，例如在4:1到30:1之间。

 

2.  设施

Google以其有趣的设施而闻名，像滑梯、海洋球和游戏室之类的。这有助于吸引和留住优秀人才。Google有很棒的咖啡馆，对员工免费，其作用也是一样的，而且这也巧妙的鼓励Google员工留在办公室，肚子饿从来都不是离开办公室的理由。四处放置的“微厨房”让员工可以拿到零食和饮料，这也提供了同样的功能，但它也充当了非正式观点交流的重要资源（译者注：应当理解为“非正式观点交流的重要平台”），因为许多对话都是从这里开始的。健身房、运动和现场按摩帮助员工保持苗条、健康和心情愉快，提升了生产率和保留率。

在Google座位是开放式的，而且往往坐的很密。虽然有争议[20]，但这鼓励了沟通，虽然有时付出了个人专注度的代价，但很经济（译者注：敏捷开发也提倡开放式的座位，有利有弊——沟通方便了，但写代码的效率降低了，*总是*“付出了个人专注度的代价”）。

每个员工都会被分配一个单独的座位，但座位的调整是相当频繁的（例如每6~12个月，通常是组织扩张的结果），经理通过座位的选择鼓励沟通并为沟通提供方便，这比较容易发生在相邻或接近相邻的个体之间。

Google的所有会议室都配备了最先进的的视频（state-of-the-art video）会议设施（译者注：可以参考Google企业版chrome video conferencing），在那里，只要点一下屏幕就可以马上连通事先日程安排所邀请的人员。

3.  培训

Google在许多方面鼓励员工教育：

• Google新员工（“Noogler”）有一个强制性的初始培训课程。

• 技术人员（软件工程师和研究科学家）从做“Codelabs”开始：带有编码练习的个人技术短期在线培训课程。

• Google为员工提供各种在线和面对面培训课程。

• Google还为在外部机构学习提供支持。

此外，通常会为每个Noogler指定一个正式的“导师”和一个单独的“伙伴”，以帮助他们跟上进度。通过与经理的例会、团队会议、代码审查、设计审查和非正式流程，也会进行非正式的指导。（译者注：基本没什么特别，美国公司大多数是这样的）。

 

4.  转部门

在公司的不同部门间调换是被鼓励的。这有助于知识和技术在组织间的传播，并且促进了跨团队交流。在一个位置上工作12个月以上且信誉良好的员工，允许在项目和/或办公地间调换。也鼓励软件工程师在组织的其他部门承担临时任务，例如在SRE（网站可靠性工程师）岗位上为期六个月的“轮换”（临时任务）。

5.  绩效考核和奖励

在Google十分鼓励反馈。工程师可以通过“同行奖励（peer bonuses）”和“荣誉（kudos）”给与彼此明确的正面反馈。所有员工都可以提名任意其他员工获得“同行奖励”——每年最多两次，每次现金奖励$100——以奖励超出职责范围的工作，只需要填一张web表格说明情况就行。获得同行奖励时，通常会通知队友。对员工还可以给予“荣誉”，一种正式的赞美之词，这是对良好的工作给与了明确的社会认同，但没有物质奖励；给与“荣誉”并不要求工作超出正常的职责范围，也没有授予次数的限制。

经理也可以给与包括现场奖励在内的奖金，例如在项目完成时现场奖励。而且，与其他公司一样，Google的员工根据其绩效也会获得年度绩效奖金和股权奖励。

Google有一个非常审慎、详细的晋升过程，包括：自荐或由经理提名、自我回顾、同行评审、经理评估；然后由促进委员会（译者注：应该是评估员工任职能力的专家团队）基于这些输入做出实际的决定，决定的结果可以提交给促进上诉委员会（译者注：应该是由技术专家和人力资源共同组成的，最终决策和处理上诉的团队）进一步审查。确保正确的人得到晋升对于保持对员工的正确激励至关重要。

另一方面，绩效不佳则由经理反馈处理，如果有必要还会制定绩效改进计划，计划包括设定非常明确具体的绩效目标，并评估目标达成的进展。如果这样做没有效果，解雇业绩不佳的员工是有可能发生的，但现实中，这在Google非常罕见。

经理的绩效通过反馈调查来进行评估，每个员工都被要求填写一份针对他们经理的业绩表现调查表，每年调查两次，调查结果是匿名的，并在汇总以后提供给管理者。这种自下向上的反馈对于维护和提高整个组织的管理质量非常重要。