Google软件工程（续）

3 项目管理

3.1 20%时间

Google允许员工花费20%的时间去做他们选择的任何项目，而无需经过他们主管或其他人的允许。这对获得工程师的信任极其重要，有如下几点原因。第一，它允许任何有好想法的人，即使他的想法在其他人看来目前并不是有价值，可以有足够的时间去开发一个原型、示例或者演示去展示他们想法的价值。第二，他提供了管理上的透明性，否则员工会隐藏这类活动，在其他没有正式政策允许20%时间的公司，员工有时会从事“地下工作“项目而不会让主管知道。如果工程师对这些项目持开放态度，这样会好很多，即使他们的主管并不认同该项目的价值，也可在日常状态更新时描述他们在这些项目上做的工作。在全公司范围内有正式的这样一个政策和文化，使得这成为可能。第三，允许工程师在更加有趣的工作上花费一小部分时间，可以使工程师保持主动和兴奋，避免他们变的疲惫不堪，特别是员工感觉被迫花费100%的时间在繁琐的工作任务上的疲惫。拥有高效生产力、热爱工作、充满动力的工程师和疲惫不堪的工程师之间的差距远远大于20%。第四，它鼓励创新文化，看到其他工程师在20%时间做好玩的实验项目会鼓励每个人都这么去做。

3.2 目标和关键结果(OKRs)

Google要求个人和团队都要明确文档化他们的目标和评估达成这些目标的进度。团队设定季度和年度目标，并给出可量化的关键结果以显示目标进度。这在全公司各个层面上展开，直至整个公司的目标。个人和小团队的目标要和他们所属大团队或整个公司的更高层次的目标一致。在每个季度末，会记录每个可量化关键结果的进度，每个目标都会给出一个0.0（零进度）到1.0（100%完成）的打分。OKR和OKR的打分通常是全公司可见的（特别敏感如高度机密的项目是少数例外），但是打分并不是用于员工的个人绩效评定。
OKR应该设定较高的目标，理想的目标是总体平均完成度在65%，这意味着鼓励团队设定比他们可能完成工作量多大概50%的目标。如果一个团队的得分比0.65高很多，鼓励他们在接下来的一个季度中设立更高的OKRs（相反的，如果得分比0.65低很多，则鼓励他们在下个季度设立相对保守的OKRs）。
OKRs提供了沟通公司各个部分工作的关键机制，并通过沟通激励、鼓励员工创造好的绩效。即使OKRs并不影响绩效评估或报酬，当工程师知道自己的团队有OKR打分的会议，也会自然驱动他把该分提高。定义关键结果的目标和可量化性有助于确保员工做真正对目标有可量化影响的工作。

3.3 项目批准

虽然Google有完善的发行批准过程，但是却没有一个完善的项目立项或取消的过程。尽管我已经在Google工作了十年，目前也成为了一名管理者，但是我仍然不完全理解项目决策是根据什么做决定。部分原因是全公司也没有一个统一的规范。各个职级的管理者对他们团队要做的项目负责，并根据他们的判断进行他们认为合适的项目。在一些情况下，这意味着许多决定都是自底向上建立的，因为工程师被充分给予了在他们的团队内自由选择项目的自由。在另一些情况下，决定是自顶向下建立的，由管理层或者管理者决策进行哪些项目，给哪些额外的资源，哪些项目要被取消。

3.4 组织重组

有时当管理层决定要取消一个大的项目时，这时在该项目工作的许多工程师要在新的团队寻找新的项目。同样，有时要进行资源“整合”，即将分散多个地区的的项目整合在几个少数地区，这时为促成整合，其他地区的工程师也要改变团队和项目。在这种的情况下，通常让工程师在他们地区可选范围内自由选择团队和角色，或者在“整合”的情况下，他们也可以选择更换办公地点从而继续留在原来的团队。
除此之外，其他形式的公司重组，例如合并或分解团队，改变汇报线等，在Google都很常见，尽管我不知道Google和其他的大公司相比算不算多。在一个技术驱动的大公司，一定程度上的频繁重组是必要的，可以避免因技术和需求改变时导致的组织低效。

3.5 年度的Hack 周

另一种在google被激励的文化是“黑客马拉松”活动。在许多的google的办公室中，软件工程师每周花时间以这种例行的黑客活动来工作于创新型的项目上。在启动会后，人们各抒己见，形成小的团队，在新的想法的基础上构建一个demo或原型，在周末结束时展示他们的demo给观众和评委，评委给出小小的奖励给最佳的项目。 最大的奖励，其实是认可度、认同感-一种可以从成功的黑客马拉松项目孵化成真正的真实项目的希望。
尽管所有的工程师被允许或被引导可以参加这样的“黑客马拉松”活动，但许多工程师发现把他们日复一日的工作从中剥离出来还是有困难的，所以参与率通常是相当的低（在5%-20%），尽管许多人有意愿参加了启动会或最终的展示会并且也被好的灵感所激励。

4 人员管理

4.1 角色

如下文所述，Google区分了工程师和管理者的职业发展阶梯，将技术主管从管理者中区分开来，将研究并入工程师，并通过产品经理、项目经理和网站可靠性工程师（site reliability engineers, SREs)支持工程师的工作。目前看来，至少其中的一些实践对于维持Google已经发展的创新文化至关重要。
Google工程师仅有少数的角色。在每个角色内，都有职业进一步发展的机会，其通过一系列的等级和晋升机会（有相应的报酬如薪金等的提高）以认可下一级别的表现。
主要的角色有：
工程师主管
这是这个列表中唯一的管理者角色。其他的角色的个人如软件工程师可能也管理人，但是工程师主管一定管理人。工程师主管通常在早期也是软件工程师，并是全面的技术专家，有卓越的个人技能。
技术主管和管理者有一个主要区别。
工程师主管并不一定要领导项目。项目通过技术主管领导，其可以是一名工程师主管，但更常见的是软件工程师。项目的技术主管有该项目的技术决策的发言权。

工程师主管的责任是选择技术主管，并负责他们团队的绩效。他们指导和协助职业发展，进行绩效评估（使用同事反馈），并在一定层面上负责薪酬，也在负责招聘中的一部分。
工程师主管一般直接管理任意地点的3到30个人，但8～12个更为常见。
软件工程师（Software Engineer , SWE)
从事软件工程开发工作的大多数人都是这个角色。Google招聘软件工程师的门槛非常高。仅招聘最一流的软件工程师，可以使许多在其他公司如瘟疫般的软件问题，在Google都尽可能的避免或者缩小。
Google区分工程师和管理者的职业发展序列。尽管一个工程师可以从事管理工作或者转岗到一个工程师主管职位，但是对于晋升来讲，管理才能不是必须的，即使是在非常高的级别。高级别的工程师职位需要有一定的领导能力，但它可以有多种形式，例如创造了产生了巨大的影响或者被很多其他工程师使用的软件，对晋升来讲就足够了。这非常重要，因为它意味着，对于拥有卓越技术能力但缺乏管理欲望和技巧的人仍然可以有很好的职业发展，并不一定要求这类人走管理者的发展道路。这避免了在其他组织中身处于管理职位，却忽视团队管理，从而失去上升空间的工程师的痛楚。
研究科学家
该角色的招聘标准非常严格，招聘的门槛极其的高，要求已有一系列的发表文章记录以证明其出色的研究能力，并要求写代码的能力。许多在学术届非常有才华的人，他们或许有能力符合Google软件工程师的角色，但不一定符合研究科学家的角色。在Google，大多数博士都是软件工程师而非研究科学家。研究科学家通过其研究贡献包括文章发表等评定，但除了头衔之外，Google的软件工程师和研究科学家并无太大的区别。他们都可以做原始的研究并发表论文，都可以贡献新的产品想法和新的技术，都可以写代码开发产品。在Google，研究科学家和软件工程师在一起工作，即在相同的团队做相同的产品或者研究。将研究科学家嵌入到工程师中对在将发布的产品中融入新研究成果影响巨大。
网站可靠性工程师 (SRE)
系统的运维由软件工程师团队负责，而非传统的系统管理员。但SRE的招聘需求和其他软件工程师职位略有不同（如果有非常专业的其他技术如网络或unix系统管理等弥补，软件工程师相关的技巧可以稍微降低一些）。SRE角色的性质和角色在SRE的书[7]中已经很好很仔细的解释了，这里我们就不继续讨论了。
产品经理
产品经理负责产品的管理。作为产品用户的代理人，他协调工程师的工作，宣传对用户重要的新产品特性，协调与其他团队的沟通，跟踪bug和协调时间，并确保一个高质量的产品所需的所有资源一切就绪。产品经理通常并不亲自写代码，但是会和软件工程师一起工作以确保写出适合产品的代码。
项目经理/技术项目经理
项目经理和产品经理的角色大致相同，但并不管理一个产品，而是管理项目、流程和操作（例如数据采集）。技术项目经理也类似，但是需要和他们工作相关的特定的技术专长，例如处理语音数据的语言学知识。

软件工程师与产品经理和项目经理的比例在公司不同团队中各有不同，但一般来讲，该比例是比较高的，一般在4:1到30:1之间。

4.2 设施

Google因其有趣的设施而出名，如滑滑梯，球球堆和游戏室，它有助于吸引和保留人才。Google一流的咖啡免费向员工开放，这也有相似的功能，并且巧妙的鼓励员工留在办公室，饥饿从来不是离开的理由。员工们更常去的地方“微厨房“，可以拿零食和饮料，也有同样的功能，并且这里还成为一个重要的非正式的交换想法的地点，许多聊天都始于这个地方。健身房、运动、和便利的按摩椅帮助员工保持健康快乐，也提高了生产力和保留率。
Google的工位是开放空间的，并且通常是密集的。尽管有争议，但这鼓励了沟通（尽管有时以分散个人的注意力为代价），也很经济。
员工会分配了一个独立的工位，但是工位重新分配相当频繁（如6～12月，通常是组织扩张的结果），主管会重新安排座位以便利和促进沟通，这通常对工位临近的或相对比较近的人是比较容易的。
Google的设施中均有拥有一流的视频会议设备的会议室，和其他组织的开会仅需点击接入屏幕上的一个预先组织好的会议邀请即可。

4.3 培训

Google通过多种方式鼓励员工教育。
Google新员工（“Nooglers”)有强制的入职培训。
技术类员工（SWE和研究科学家）从完成“Codelabs”训练开始：短时间的关于个人技术的编码在线培训课程。
Google提供一系列的在线和线下培训课程。
Google也提供在外部机构学习的支持。
除此之外，通常都会为每个"Noogler"分配一个正式的导师(Mentor) 和独立的伙伴(Buddy)以帮助他们更快的适应。非正式的指导也发生在和主管的例会、团队会议、代码审查、设计审查和其他非正式的工作流程中。

4.4 转岗

鼓励在公司不同的部分之间转岗，这有助于知识和技术整个公司传播，提高跨组织沟通。在同一个岗位工作满12个月后就可以在不同项目和办公室间转岗。鼓励软件工程师做其他组织内的临时性工作，例如SRE (Site Reliability Engineering，书名).中的六个月的“轮岗”(临时工作）。

4.5 绩效评定和奖励

Google非常鼓励反馈。工程师可以通过“同事奖金”(peer bonuses）和“勋章”（kudos）给其他人直接的积极评价。所有的员工都可以提名其他人获取”同事奖金“——100美金的现金奖励，每年最多两次，以奖励其超额完成任务，仅需要通过网页填写并描述原因即可。通常当获得“同事奖金”时，组内同事们也会收到通知。员工也可以给其他人“勋章”，即正式声明表扬，以期对他们出色工作的社会认可，但是没有经济上的回报。“勋章”没有超额完成工作的限制，也没授予次数的限制。

管理者也可以奖励奖金，包括立即奖金（例如完成了一个项目后）。和多数其他公司一样，Google员工每年有绩效奖金，根据他们的绩效公平的奖励。
Google有非常仔细、详尽的晋升流程，晋升需要主管推荐或自我推荐、自我评价、同事评价、主管评估，最终由晋升委员会根据以上信息决策结果，结果可以由晋升上诉委员会进一步审核。确保优秀的员工获得晋升对保持正确激励机制至关重要。
另一方面，差的绩效，根据主管的反馈处理，必要时制定绩效提升计划，绩效提升计划中设置了非常明确具体的绩效目标和如何评估达到该目标的进度。如果提升计划失败了，因为绩效差可能会被终止合同，但实际上，这样的情况在Google非常罕见。
主管的绩效通过反馈调查评定。要求每个员工一年填写两次对他们主管的绩效的调查，结果会匿名收集并提供给主管。这种形式的向上反馈对提升整个公司的管理质量非常重要。

5 总结

我们已经简要地描述了Google的大多数核心软件工程实践经验。当然，Google现在已经是一个体量巨大并且多样化的公司，公司的一些部门可能有不同的实践经验。但是这里描述的是大多数团队目前遵循的实践经验。

有着大量软件工程的实践经验，以及众多与软件工程实践无关Google的制胜之道，想要客观地定量地证明个人的实践和提升结果之间关系非常困难。尽管如此，这些实践经验在Google都经受住了时间的考验，经受了成千上万的优秀软件工程师的集体主观判断。
对于其他的公司，假如他们所倡导的软件工程实践也在本文中有所描述，或许，这有助于说明“这在Google已经实践证明足够好了”。

致谢
特别感谢Alan Donovan的极其详细和建设性的反馈，感谢Yaroslav Volovich、UrsHölzle、Brian Strope、Alexander Gutkin、Alex Gruenstein、Hameed Husaini在本文初稿时给出非常有用的评论意见。

引用
[1] Build in the Cloud: Accessing Source Code, Nathan York, http://google-engtools.blogspot.com/2011/06/build-in-cloud-accessing-source-code.html
[2] Build in the Cloud: How the Build System works, Christian Kemper, http://google-engtools.blogspot.com/2011/08/build-in-cloud-how-build-system-works.htm
[3] Build in the Cloud: Distributing Build Steps, Nathan York http://google-engtools.blogspot.com/2011/09/build-in-cloud-distributing-build-steps.html
[4] Build in the Cloud: Distributing Build Outputs, Milos Besta, Yevgeniy Miretskiy and Jeff Cox http://google-engtools.blogspot.com/2011/10/build-in-cloud-distributing-build.html
[5] Testing at the speed and scale of Google, Pooja Gupta, Mark Ivey, and John Penix, Google engineering tools blog, June 2011. http://google-engtools.blogspot.com/2011/06/testing-at-speed-and-scale-of-google.html
[6] Building Software at Google Scale Tech Talk, Michael Barnathan, Greg Estren, Pepper Lebeck-Jone, Google tech talk.
http://www.youtube.com/watch?v=2qv3fcXW1mg
[7] Site Reliability Engineering, Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, O’Reilly Media, April 2016, ISBN 978-1-4919-2909-4.
https://landing.google.com/sre/book.html
[8] How Google Works,Eric Schmidt, Jonathan Rosenberg.
http://www.howgoogleworks.net
[9] What would Google Do?: Reverse-Engineering the Fastest Growing Company in the History of the World, Jeff Jarvis, Harper Business, 2011. https://books.google.co.uk/books/about/What_Would_Google_Do.html?id=GvkEcAAACAAJ&re dir_esc=y
[10] The Search: How Google and Its Rivals Rewrote the Rules of Business and Transformed Our Culture, John Battelle, 8 September 2005. https://books.google.co.uk/books/about/The_Search.html?id=4MY8PgAACAAJ&redir_esc=y [11] The Google Story, David A. Vise, Pan Books, 2008.
http://www.thegooglestory.com/
[12] Searching for Build Debt: Experiences Managing Technical Debt at Google, J. David Morgenthaler, Misha Gridnev, Raluca Sauciuc, and Sanjay Bhansali.http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/37755.pdf
[13] Development at the speed and scale of Google, A. Kumar, December 2010, presentation, QCon.
http: //www.infoq.com/presentations/Development-at-Google
[14] How Google Tests Software, J. A. Whittaker, J. Arbon, and J. Carollo, Addison-Wesley, 2012.
[15] Release Engineering Practices and Pitfalls, H. K. Wright and D. E. Perry, in Proceedings of the 34th International Conference on Software Engineering (ICSE ’12), IEEE, 2012, pp. 1281–1284.
http://www.hyrumwright.org/papers/icse2012.pdf
[16] Large-Scale Automated Refactoring Using ClangMR,H. K. Wright, D. Jasper, M. Klimek, C. Carruth, Z. Wan, in Proceedings of the 29th International Conference on Software Maintenance (ICSM ’13), IEEE, 2013, pp. 548–551.
[17] Why Google Stores Billions of Lines of Code in a Single Repository, Rachel Potvin, presentation.
https://www.youtube.com/watch?v=W71BTkUbdqE
[18] The Motivation for a Monolithic Codebase, Rachel Potvin, Josh Levenberg, to be published in Communications of the ACM, July 2016.
[19] Scaling Mercurial at Facebook, Durham Goode, Siddharth P. Agarwa, Facebook blog post, January 7th, 2014. https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
[20] Why We (Still) Believe In Private Offices, David Fullerton, Stack Overflow blog post, January 16th, 2015.https://blog.stackoverflow.com/2015/01/why-we-still-believe-in-private-offices/
[21] Continuous Integration at Google Scale, John Micco, presentation, EclipseCon, 2013.http://eclipsecon.org/2013/sites/eclipsecon.org.2013/files/2013-03-24%20Continuous%20Integr ation%20at%20Google%20Scale.pdf