Twitter 工程总监陈尔东：硅谷没有产品经理

在国内，产品经理是非常核心的角色，然而在硅谷，工程师才是灵魂，拥有产品设计的决策权。谷歌的比例大概是1比8，一个产品经理配8个工程师。Facebook在200个工程师的时候，只有不到10个产品经理。

本文经混沌研习社(微信公众号：dfscx2014)授权转载，研习社是一所线上商学院，致力为创业公司培养具有互联网思维和全球化视野的创新人才。

演讲人|陈尔东(Twitter 工程总监)

我曾经在Facebook工作，现在在Twitter担任工程总监，在硅谷工作生活了很多年。

在国内，产品经理是非常重要的角色，在硅谷反而没那么重要，工程师才是最核心的角色。今天我想跟大家分享，在硅谷，工程师文化对于独角兽公司是多么重要和普遍。

国内，产品经理是非常重要的角色，在硅谷，工程师才是最核心的角色。

小团队大杠杆

工程师常常兼具产品思维

产品经理同时开发多个项目

硅谷独角兽公司的文化特点是小团队大杠杆(Huge Impact With Small Teams)，精英小团队，一个一个把攻坚战打下来。

有两个数字比例非常重要，一是平均一个工程师，服务多少用户。

以Facebook为例，在2007年第三季度的时候，1个工程师大概服务50万的用户，到了2009年第三季度，1个工程师大约服务126万用户。

听起来是不是太不可思议了?你如果招到了好的工程师，而这些工程师有好的产品思维，你的公司组织就精简了，会议沟通就少了，效率就随之提高了。

后来Facebook这个高效纪录，被WhatsApp打破了，WhatsApp在4年内涨到了4亿多用户，而当时它的工程师只有不到30个。

我当时加入facebook的时候，它有2亿月活用户，而我们只有200位工程师，不到10位产品经理。WhatsApp在去年达到了10亿月活用户，它只有57个工程师，1个产品经理。

所以另一个数据也很重要，就是团队中产品经理和工程师的比例，平均一个产品经理有几个工程师。

软件行业老大微软的模式，就是一个产品经理带两三个工程师，再带一两个测试人员，大部分的工作流程是瀑布式开发：

产品经理写好要求

▼

工程师编写代码

▼

程序出来以后测试员去测试

▼

如果功能有问题，返给工程师修改

&

如果设计有问题，返给产品经理重新讨论

所以基本上，微软每个季度或者每一年只能推出一个新的产品。

谷歌的比例大概是1比8，一个产品经理配8个工程师，所以谷歌每天或者每周都有新的东西推出。

因为只有一个产品经理，他没有那么多时间和每个工程师沟通产品设计细节，所以这8个工程师就必须具备产品经理的思维，自己做产品决策。

Facebook在200个工程师的时候，只有不到10个产品经理。很多项目没有产品经理，只有工程师自己去思考产品问题的解决方案。

这样的比例有什么好处呢?硅谷的一个产品经理往往要同时开发好几个产品项目，于是产品之间的协同度非常好，一看就知道是同一个公司的产品。

全栈式代码管理方式：所有人轮岗，任何人都可能成为任何系统的专家。

招最好的A级工程师

代码重构不能轻易做

否则可能错过产品的最好时机

怎么样才能做到小团队大杠杆?在硅谷，非常重要的环节就是寻找A级工程师。

在人才的招聘上，业务领导不能依靠招聘网站发来的简历，而是应该亲力亲为地去定点挖掘，因为优秀的人才是不会缺少工作机会的。

关于产品经理和工程师之间的配合，很多互联网公司都会遇到这个问题：

产品经理要求工程师添加新的功能，工程师说，我们不能再加新功能了，因为代码太乱了，如果我们要添加新功能，会出现很多错误。我们必须要代码重构。

代码重构可以做吗?我谈一点我自己的经验。代码重构是要做的，但一定要选一个非常好的团队，不需要兴师动众，选一个非常小的精英团队，把它快速做好。

我们知道，很多公司都是因为重写代码而错过了产品发布的最好时机，包括Facebook的竞争对手，他们觉得以前用的编程语言不好，后面换了另一种语言，结果耗时太长，过了几个月之后，发现Facebook的产品已经走在他们前面了。

这里还要谈到代码管理和维护方式。我知道大部分公司都是这么做的：每个工程师会负责固定的一些系统，每个系统都有明确的界限。

这里面有一个很大的问题：假如有新的优秀人才加入，他有一些很好的想法想更新一些东西，他就必须说服每个系统的负责人，这个沟通要花很多时间，也非常困难。

现在有一种更好的全栈式代码管理方式，Facebook就是这样做的：所有人轮岗，任何人都可能成为任何系统的专家，任何一个人都能够对任何一个系统提出更好的框架和方法。

你以前改变一个产品，需要把每个系统的人叫来，但是全栈式管理，让三五个全栈工程师，就能把这10个系统全改了，然后推出产品，这是自组织的代码管理方式。