在Google管理一个软件团队

标签: 程序员 管理 Google Matt Welsh 团队 | 发表时间:2013-04-22 01:46 | 作者:老码农
出处:http://blog.jobbole.com

伯乐在线注:2003年到2010年期间,原文作者 Matt Welsh 是哈佛大学工程和应用科学学院的计算机科学系教授。 2010年加入Google。

在我离开学术圈之后,我常常被问及我在Google的工作是怎样的。我猜想从终身教授到 软件工程师的转变听起来像是个巨大的落差。抛开职位不说,我现在比起前面在哈佛的8年,工作更快乐也更高效,尽管做教授和管理软件团队有很多相似之处。


像个老板

我在Google的西雅图分部领导了一个团队,负责移动互联网性能方面的一批项目(想了解更多有关我的团队的工作背景,请查看我更早的 有关博客)。其中之一是最近宣布的为 Chrome Mobile提供数据压缩代理支持的项目。我们还承担了 PageSpeed 技术套件的研发,它是专门针对移动互联网优化的,此外还有一堆很酷的东西我现在还不能说。

我的正式头衔只是“软件工程师”,这是在Google最普通(也是最令人垂涎的)角色。(我说到“令人垂涎”是因为大部分的重要决定都是工程师们拍板的)在非正式场合,我的角色是所谓的“技术主管经理”,其含义是我不仅要负责团队的技术方向,也要承担人员管理工作。(有些人用另外一种调调说成“上头的技术主管”,不过对我来说这个说法有点变味了)技术主管经理在Google不是一种常见的角色,大部分团队都有单独的人来承担技术主管和人员管理的工作。我之所以双肩挑是因为我们在西雅图上班,要让我的团队向一个可能在山景城总部的经理汇报工作不太靠谱。而且我也很愿意做这两份工作,喜欢这种多样性。

我工作的四个主要方面是:

  • (1)规划整个团队的技术性方向,并确保我们能够实现;
  • (2)写我自己的代码;
  • (3)作为我们团队和Google其他小组之间的联络人;
  • (4)进行团队的人员管理工作,诸如招聘、业绩评估、提升人员等等。

学术圈同行们马上可以发现这里和做教授类似的地方。在一个科研小组里,教授规划小组的技术范围,并且辅导和指导研究生们的研究工作。这里有个很大的区别就是我不会像教授看研究生那样,把团队成员看成是我的“学徒”。实际上,在我团队里的大部分人都是比我更强的软件工程师,在开发稳定可靠的软件工作上,我非常需要仰仗他们的努力工作。我的工作是为团队里的工程师们排除干扰保驾护航,让他们在工作中获得成功。

当然在这里和学术环境有很多不同之处。我无需像教授那样总是要跑经费才能让项目维持进行。我也很少分心于应付各种委员会、差旅、写推荐信和漫无目的的会议。当然,我也不用教书。(我喜欢教书,不过要教好书,呐所要做的工作量是相当的大哦。)最重要的是,我的团队成功与否不再需要通过 那种随意而且往往是低劣的同行审议过程来决定,而这种过程在学术圈里所有重要的事情上都是绕不过去的。这是最好的一点。只要我们进展顺利并产出有 影响力的产品,我们就赢了。我们不再需要通过 调整提交论文中的字体间距来让三个脾气暴躁的课题委员会成员感到满意。呃,我是不是跑题了……

我用50%的工作时间写代码。我每天都需要几个小时连贯的时间用来写代码,这样才能保持思路清晰。因为我没有团队其他人那么多的编码时间(而且会被打断的次数更多),我倾向于承担那些更通俗的任务,比如写MapReduce代码来分析服务日志并生成性能报告。实际上我很喜欢这种工作,因为它意味着和海量数据打交道,用各种有意思的方法去切分它们。目前我也不需要展示我英雄般的编程技巧来得到提升,所以我会让那些更强的黑客们去实现性感的新功能。

对于我们团队的技术方向,诸如整体设计和架构方面,我的确发挥了很多影响力。主要是因为我在考虑系统设计方面比我团队里的一些伙计们要更有经验,虽然这也意味着在很多我不熟悉的实现细节上我需要服从那些写具体代码的人们。我工作的一大部分就是确定优先级,并在我们为了解决某个问题而被迫在几个不理想的选项中进行抉择的时候作出决定。(这也意味着,如果我做出了错误的决定,被放在火上烤的人也是我。)

我想我承担的人员管理工作是业界标准的:我定期给我的直接下属做业绩评估,参加薪酬规划,参与招聘新人加入团队,在团队成员申请升职时帮他们说话。当然我也会和我的每个直接下属定期面谈,帮助他们确定优先级,清除工作中的障碍,规划职业发展。

我工作中最多样化的部分是作为我们团队的代表,并和Google其他团队合作来创造美妙的东西。我的团队是更大的Chrome项目中的一部分,但我们和很多遍及世界的负责Google各种技术平台的其他团队也都有联系。我也经常被叫到一些会议里讨论如何把我们团队的工作和公司里在进行的其他工作协调起来。所以我从来不会觉得无聊。幸运的是,我们的会议效率很高(半个小时几乎足以 搞定所有事情),就算有这么多事,我的会议负担也只有在做学者时的一半。(另外,这些会议基本都是有产出的,相比之下,学术会议只有10%能产生实际的成果)

尽管工作量很大而且有很多救火任务,但我在Google的工作时间主要还是9点到5点。我很少在晚上和周末工作,除非有什么事情我真的急着想做。在非工作时间里我收到的电子邮件数量几乎为零。(尽管我正在负责我们团队的值班任务,最近也曾经在半夜花了几个小时修复一个产品Bug。)这是从教授们普遍承受的工作、工作、再工作的永恒压力下的巨大的解脱。我也感觉我用更少的时间完成了更多的事情,这要归功于更少的干扰以及保持了清晰的专注点。我现在是这样看待工作的:如果有人要求我完成比我在思维清晰的状态下所能做的还要多的工作,我们就需要招聘更多的人手。幸运的是,这基本都不是问题。

声明:本文所有内容均为本人个人观点,不代表本人所在公司看法。

 

英文原文: Matt Welsh,编译:  @老码农的自留地

译文链接: http://blog.jobbole.com/38567/

【非特殊说明,转载必须在正文中标注并保留原文链接、译文链接和译者等信息,谢谢合作!】

相关文章

在Google管理一个软件团队,首发于 博客 - 伯乐在线

相关 [google 管理 软件] 推荐:

在Google管理一个软件团队

- - 博客 - 伯乐在线
伯乐在线注:2003年到2010年期间,原文作者 Matt Welsh 是哈佛大学工程和应用科学学院的计算机科学系教授. 在我离开学术圈之后,我常常被问及我在Google的工作是怎样的. 我猜想从终身教授到 软件工程师的转变听起来像是个巨大的落差. 抛开职位不说,我现在比起前面在哈佛的8年,工作更快乐也更高效,尽管做教授和管理软件团队有很多相似之处.

iGoSyncDocs – 在本地管理的 Google Docs 客户端 | 小众软件 > 桌面工具

- Chinaxingwei - 小众软件
尽管 Google 倡导把所有的操作放在浏览器中,但是某二狗还是喜欢客户端的方便与快捷,就像 Gmail 可以用邮件客户端收取一般, Google Docs 现在也有了管理用的客户端 iGoSyncDocs ,可以方便的对在线文档进行增删改查和分享、加星、隐藏. 程序为 Java 写成,运行前需要 JDK1.6 以上版本支持,另外有鉴于国内网络环境,在第一次运行前请自行修改包内 \barrywey\igosyncdocs2011\resource\config\settings.pro 中的网络设置.

Google管理层不用Google+, 你呢?

- redhobor - 36氪
公司管理层关心自己的产品,并且每天使用,这几乎是任何伟大产品的必备条件. 从Facebook到Twitter,到苹果莫不如此. Google CEO Larry Page上次登录Google+是在3个多月以前,只发表过7个公开帖子,自从8月中旬以来只发过一条. 即便是这样,他也比执行总裁Eric Schmidt发的帖子多7条.

Planner – 项目管理软件 | 小众软件 > 办公软件

- HICU - FeedzShare
来自: 小众软件 - FeedzShare  . 发布时间:2011年09月12日,  已有 3 人推荐. Planner 是一款开源、易用、跨平台的项目管理软件. 二猪用了 OpenProject 几年,现在已经受够了它的各种问题. 前段时间发现了 Planner,这个也算有些历史了,可是完全不如 OpenProject 名气大.

Android必备电源管理软件

- iBeyond - Tech2IPO
相信很多使用Android手机用户都会有相同的烦恼:手机电池耗费太快,常常撑不过一天,上班不得不带跟USB线充电,一出门就担心电力不足……实际上,如果你连着Wifi或者3G网络,所有的桌面Widget,后台更新的程序,短信电话等等会让你的手机根本撑不过一个白天. 当然,你可以在电力紧缺的时候手动关闭3G、流量、GPS、杀掉所有程序……但不是每个人都有时间手动去做这些设置.

桌面管理软件那点事

- Kindy - FeedzShare
来自: Tencent CDC Blog - FeedzShare  . 发布时间:2011年08月30日,  已有 2 人推荐.   最近收集和整理了一些桌面管理软件,才发现到桌面世界之丰富精彩,无奇不有. 下图的ICON大家能叫出几款软件的名字呢. 下面就几款比较有特色的软件做些简单的分析,和大家分享下.

软件缺陷的有效管理

- - 博客园_新闻
“这次发布之前怎么这么多的缺陷,是不是需要分析一下啊. ” 答案是肯定的,可是这个时候才想起要分析已经有点晚了,有可能这些缺陷很难分析了. 这是发生过的一个真实场景,所记录的缺陷包含信息很有限,很难有效的做好分析. 本文就来聊聊如何有效的管理和分析缺陷. 曾经有个项目是在 QC (Quality Center)里记录缺陷,需要填写很多必填属性字段,加上 QC 服务器在国外,访问速度非常的慢,每次记录缺陷成为了大家极其痛苦的一件事情.