对话 | 谷歌VP谈工程生产力（一）

Engineering Productivity，中文译为“工程生产力”。据我所知，将其正式引入组织的企业是谷歌。2016年3月，谷歌将原来的质量保障团队（QA or Testing）正式更名为“工程生产力团队”(打开“原文链接”查看官宣)。

众所周知，自2005年底开始，谷歌启动了一个项目，我们就叫它“工程质量文化项目”。其当时目标就是：从“依赖测试人员的大量手工测试保障服务质量”转变到“让每个工程师都担负质量责任”。

方法就是：让软件开发工程师编写自动化测试，并且做持续集成。这个项目一直持续到2010年才算告以段落。

为了在团队规模和应用规模不断扩大的时候仍旧能够稳步快速前进，这个“QA部门”不断在扩大自己的工作范围，最终发展为EP部门。

现任谷歌的Engineering VP的Michael Bachman，之前是EP部门的Senoir Director。他加入Google 有十六年之久，是这个部门最早的员工。

下面是他在2018年4月，在湾区某社区交流中的分享记录（PPT与现场问答）。

一、PPT如下：

若想获得完整PPT内容，请关注公众号“持续交付2.0”，并在公众号留言“EP-PPT”。

二、现场问答：

---

1、EP团队在整个公司中的组织架构是什么样的？

    在第一阶段（2008年之前）是统一的一个部门，整个谷歌只有一个。现在每个产品领域都有自己的EP部门，通常由总监或高级总监领导。

2、如何考虑整个公司层面的EP呢？

    有一个水平横向的组织，来负责拉通整个谷歌的基础。如在安卓基础方面，就有一个团队聚焦于移动端的基础设施和工程生产力。

3、用什么样的指标衡量开发人员的生产力呢？

    有很多相关指标，并不是一个指标。例如：

• 一个CL需要多长时间才能提交到代码仓库

• 有多少次是 -f （ force ），绕过了正常的提交流程

• 发布频率如何

• 一个部署包要花多长时间才能部署到生产环境上

• 有多少次cherryPick（Hotfix），有多少次回滚

• 代码测试覆盖率是多少

• 线上出现问题导致的outage是怎样的

• 有多少次Pager

• Code Review所花费的时长

• 多少缺陷被部署到了生产环境上

这里的问题是要看整体视图，如何更容易地发现问题，定位到根本原因，真正提高生产力。

（未完，更多内容，本周四见……）

重磅推荐

《持续交付2.0》

硅谷顶级互联网公司的产品研发方法。

在未来十年里，

快速提升工程生产力，打造有战斗力的团队，

应对激烈的市场竞争，

这一本书就够了~

《持续交付2.0：业务引领的DevOps精要》

扫码购买

京东 77.5元

本书“重新定义”了持续交付，增补了组织管理和架构两个维度，辅助以真实案例，对诸多持续交付的原则和实践加以解读，并对持续交付过程中的取舍原则加以论述。 

持续交付2.0是实现组织战略目标的组织能力，并引入双环模型理论，以及基础工作原则、组织原则和架构原则；

通过多个互联网公司案例的解读，阐述如何根据组织的当前状况，应用原则，并对最佳实践进行取舍，快速达到组织能力目标。

关于作者

乔梁

持续交付2.0 创始人

专注于软件企业组织管理

DevOps顶级大神

著有《持续交付2.0》

译有《持续交付》《软件沉思录》

关注公众号查看其他原创作品