谷歌是一家足够牛逼的公司，想必大家都知道。前几年有一本书［重新定义团队：谷歌如何工作］，让我对Google的行事方式有了一些了解，今天结合其它材料聊聊Google的工程师文化。


聘用比你更优秀的人

Google招聘的1个原则：只聘用比你更优秀的人 ，特点是基于数字化分析。具体看一下招聘的策略：

• 严格控制出身[斯坦福、哈佛、麻省理工及类似学校] --创始初期，简单粗暴、高效，通过学校进行筛选
• 区分工种，不一味追求名校，如也雇佣韧性和克服困难能力强的应聘者，不问出处
• 招聘通过率0.25%
• 员工推荐:推荐你想和他一起工作的最牛的人
• 全员招聘（Google+,FB ,linkedin等渠道）

不同阶段采取不同策略，这背后是数据，Google通过分析进入公司的招聘者在岗位的表现情况，不断分析和挖掘—我们需要什么样的人，并按照这些特征去 持续找人。 同时，通过数据的反馈可以调整策略。2010年，他们通过对30万份被拒的软件工程师简历做筛选，再访10000位应聘者，最终录用150人（聘用率1.5%看似很低，但已是0.25%的6倍）。

让员工塑造自己的工作和公司

• 20%时间原则
• 足够的透明性

一个有趣的案例。HR曾推出员工幸福度调查问卷，但只有不到一半的人参与调查；而一些工程师设计了一种他们认为[更好的方案]--心醉神迷调查。最终hr用了1年的时间，与工程师、销售人员以及其他人合作，推出了Googlegeist。Googlegeist每年会询问约100个问题，包括当年热点问题，公司的变化，大家的感受，包括绩效，对价值的认同感等。采取保密或者匿名模式。同样的是基于这些问卷，可以形成数据--评估薪酬满意度情况、不同岗位的离职风险、幸福指数等。

其实，Google也不是一步就这样的，中间也有踩坑和调整。2007到2008年，不少技术人员认为他们虽然重点，但从事的不是“聚光灯”下的项目，没有得到足够的认可。他们后续采取了一系列措施：技术演进、内网文章、代码检查、公民奖（奖励那些为健康代码做出贡献，让其他人受益的人）、把代码质量作为绩效管理和升职作为核心内容之一等等。4年之后的调查，工程师对于改善代码健康部分，信心提升了34%。

透明管理

重大决策进行反馈收集。如果管理得当，决策应该在一个组织中尽可能低的层级中做出；而上报的意义在于[在同样的数据和信息下]，更高级别的领导者会做出与下级不同决策的问题 。可以学习一些 Googlegeist的做法，通过数据为依据来探讨问题，这样即使反对者依然反对，也能理解事情的始末，尊重最终的决策。

绩效管理

具体“术”的层面有几条，供大家参考：正确地设定目标收集同事的反馈意见通过校准流程确定考评结果把奖励分配谈话与员工发展谈话分开

谷歌按照它自己的文化设定了相应的管理策略，激发潜力，创造，降低考核成本同时一切通过数据化决策管理做改进和优化。

他们有一位叫杰夫.胡贝尔的高级副总裁为谷歌研发战略意义的产品亲自招聘过２５名高级工程师，其中有一位跟踪了１０年，历经３家公司最终才说服加入谷歌。无独有偶，阿里巴巴在发展过程中为了招募人才，跟踪１－２年并保持联系的案例也是很多的。

总之，学习先进经验不能观其行而应该察其神。鞋子的尺码合不合适，只有脚知道，而且得在正确的姿势之下。

软件工程实践
谷歌的软件工程师 Fergus Henderson 在 2017 年发表了一篇文章，描述了谷歌的软件工程实践，他认为这些实践对公司的成功和软件开发人员对该公司的喜欢程度做出了巨大贡献。

文章中涵盖了软件开发的源码库、构建系统、代码审查、测试、错误跟踪、编程语言、调试和分析工具、发布工程、启动批准、事后分析和频繁的改写；还包括了项目管理的20%的时间、目标和关键结果（OKRs）、项目批准、公司改组和年度黑客周。

有一个关键实践是使用代码存储库：大多数开发人员的代码都存储在一个统一的源代码库中，所有软件工程师都可以访问这些源代码。写访问权限是受控制的，但是工程师可以访问任何代码并进行修改，只要这些修改可以获得代码所有者的批准就能够提交入库。在Google，代码评审需要两种批准：一种是来自工程师（任何工程师）的LGTM（Looks good to me，即代码是正确的）；另一种是来自代码库目录的拥有者的批准，即它属于这个目录，并且他们愿意维护它。代码评审是非常耗费时间的工作，鼓励高频、小步的评审活动。

另外一个案例，也可能说明一些问题。从2006年开始，为了鼓励开发工程师做好自动化测试实践，Google的工程师自发地成立了一个专项建设组。其中有一个“测试级别认证（Test Certified）”，在其中扮演了非常重要的角色。

我们如何才能建立一个伟大的软件团队？
《谷歌软件工程：文化、实践与工具》一文刊发了采访采访《谷歌软件工程》一书作者们的一些观点。对于“如何才能建立一个伟大的软件团队”，我们看看Manshreck的回答。

Manshreck：开发好的软件所需要的技能与（在某一时期）大规模生产汽车等所需要的技能是不同的。我们需要工程师做出创造性的反应，并不断学习，而不是重复做一件事。如果没有创造性的*，他们将无法随着行业的快速变化而发展。为了培养这种创造力，我们必须允许人们成为真正的人（而不是工具），并培养一种信任、谦逊和尊重的团队氛围。信任是为了做正确的事情；谦逊会让你认识到你不能独自完成，可能会犯错误；尊重团队成员，而不是依赖几个人。你根本不可能用几个按自己的规则行事的 "摇滚明星 "工程师来组成一个好的软件团队。这在短期内可能有效，但从长远来看，它将会失败。你需要让人们不断地发展并为组织做出贡献，而且他们需要成为团队的一部分。

对于如何看待犯错， Winters的观点：根据我的经验，最关键的一点是领导者要承认自己的错误。将犯错正常化，让人们摆脱完美是可预期的（或可实现的）错误想法。一旦我们不再将错误视为失败，而是将其视为一个学习的机会，你的团队就会加快很多。而且，反其道而行之，当你明确表示犯新的错误是可以的时候，从长远来看，你就会减少犯错误。对我的团队来说，这的确是个好例子。

F家（Facebook）和G家（Google）文化上有哪些差异？

王淮2013年在某网站有一个回答，大抵是：1、G更加Engineering Driven；F更多是 Engineering + PM +Designer Driven。换言之，Facebook的PM和Designer起的作用很大，F家是产品导向。谷歌的核心是算法导向。2、在2013那会，F家还没那么大，而那个时候在F家，很多工程师都可以直接影响千万级亿级用户，这种影响力带来的对自己重要性的“错觉”很重要。3、G的manager很容易变成1对20+，讲究自管理，而F一般要求direct report不超过7、8人。笔者想，离2013年，已经过去了8年，F家或许在业务规模上发生变化的同时，组织也会遭遇更多的挑战。

找到适合自己的路

齐白石对弟子许麟庐说的：“学我者生，似我者亡”。郗夫人对王羲之说，人各有体。对于Google乃至F家的工程师文化绝不能照搬。这些文化的背后是提倡创新，发扬工程师的特质：自我驱动、灵活的办公时间/场地、开放透明、追求效率等等。一家业务成熟度不高的公司，CEO都还在找业务方向，依赖于工程师去判断哪些需求该做，哪些不该做，无异于“东施效颦”。

笔者之前和一位沪上创业团队CTO交流，他列了几条他看重的工程师文化：

• 以业务为导向，尽量不留坑、管理技术债务
• 知其然而知其所以然的讨论，不欺下、不唯上
• 测试自动化、持续集成、持续交付
• 工程师要充分理解战略、业务，不只是执行者
• 工程师自测，不要把责任延迟到测试团队

笔者也整理过几条，供各位读者参考

• 技术服务业务是基础目标 、平台发展要略超越业务规模
• 工具化，自动化，提升效率
• KPI(自上而下) +自管理型组织(自下而上)
• 用技术拓展边界
• 持续改进、精益求精

业界标杆案例实践

著名作家马尔科姆·格拉德威尔在《异类》一书中提到，如果没有机遇、文化和环境因素，即便是智商超过爱因斯坦，也只能做一份平庸的工作。由此可见，坚实的企业文化不仅需要员工以最清晰透明的方式去判断工作，还要求其勇于探索技术趋势、提升研发战略视野，向早期实践者学习前沿实践经验，进而实现为组织技术演进降本增效，提高研发效能。

「Top100Summit」  每年甄选全球100个值得借鉴的前沿技术案例，邀请国内外知名一线技术专家分享全球软件研发最新实践，讲述他们在知名企业的成功案例与宝贵经验，是业界年度最具影响力的技术峰会。2022年邀请到来自Youtube 搜索团队高级工程师韩梦在1月6-9日在北京举办的《第十届全球软件研发案例研究峰会》上带来工程文化的前沿实践分享：