前Facebook资深员工王淮给技术创业团队的十点建议

前Facebook资深员工王淮给技术创业团队的十点建议

CSDN报道(付江/文)3月20日下午,CSDN CTO俱乐部北京交流会 第94期活动上,前Facebook元老王淮(@王淮Harry 公共微信:h1fool)分享了《亲历Facebook爆发的5年——互联网产品研发实战》的主题演讲,他以Facebook为例,谈到了互联网产品开发的九大流程和注意事项,包括豆瓣网技术副总裁、机锋网CTO、国开行技术负责人等近百位技术精英参加了当天的交流活动。

王淮是Facebook的早期员工、Facebook内部第二位中国籍工程师和第一位研发经理,曾经负责支付后台和安全系统,担任反欺诈部门的技术经理,同是也是 《打造Facebook》一书的作者。他当年加入Facebook的时候公司总体不到150人,离开的时候达到了3200多人,而如今Facebook的人员规模有5000多人。

致景投资创始合伙人、Facebook前研发经理王淮

王淮介绍了在Facebook产品开发的九条操作流程(注意事项):(1)明确目标;(2)如何收集想法并划分优先级;(3)跨团队之间的协作;(4)公司的透明文化,让他人知道你在干什么;(5)产品设计;(6)指明第一负责人;(7)迭代开发;(8)同步&报告状态;(9)发布产品&持续监控。随后王淮逐条以产品开发实例展开,本文仅摘取了部分精彩观点做简单回顾,并提供相关演讲资料PPT的下载

  • 多做月度计划 超过6个月的计划基本不靠谱

Facebook以往做产品开发经常做两类计划,一种是季度性的,一种是按月来做。季度性计划是引导性的,不一定严格按照它来执行。互联网领域变化很快,6个月之后很多事情可能已经天翻地覆了,因此如果做超过6个月的计划基本没有必要。1个月的计划是应该重点做并完全可以支持实现的。

  • 要么说服我们 要么回答一些问题 但决定权仍然在我

和大多数公司一样,Facebook每个项目团队在公司内部都有很多合作的团队。这些团队都有自己的想法,从他们的角度来看,会觉得一些东西很重要,例如某些功能是必须添加或去除的。但是在Facebook的规则是,负责项目的工程师团队有决定权。我们有一个确定的东西之后,其他团队的东西要进来的话,要么说服我们,要么回答一些问题,这上面哪个东西你觉得可以替换你的东西。

 

  • 错误的决定不应该由某一个人负责

 

如果另一个项目团队的工程师没有成功的说服你,你没有做,最后证明是你的错误,那么谁来负责?

做这种决定错误的时候多的是,不需要谁来负责。我们会思考,当时为什么没有听取别人的,坚持了自己的。做决定的时候,最好的决定不是事后来看的,是当时根据所有的信息和理解,你是不是做出来的对团队最有利的决定,即便事后错,可能是当时思考问题的信息和逻辑出现了问题,我们看看那这次错误能否帮助下次更好的选择。不会找责任人。但是如果是重复性的错误就不一样了。

有一些是对方的逻辑,我们当时没有理解,后来理解了,那下一次交流是不是得让沟通变的更充分一点。目的就是为了将来做更好的决定,但是决定权还是在工程师。

CSDN CTO俱乐部第94期活动现场

 

  • 不过度关注某一个用户的反馈

在谈到对用户反馈的考量时,王淮认为如果关注的只是个体用户,非常容易被误导,更要关心的是主流用户,从数据上来分析是最合适的。Facebook在调研需求的时候也做实验,把人放在实验室,上网的时候通过眼球分析,看看产品是不是以最简单、最舒适的方式呈现给用户。反过来分析在产品设计上应该做什么样的改进,不是去直接问用户,而是通过观察用户行为,工程师做出分析并得出结论。所以相信的还是工程师的判断。

 

  • 产品设计简单不简陋 初版不要追求完美主义

所有的项目在整个计划中无非是在以下四个维度上纠结:(1)项目支持什么样的功能;(2)从产品到面向市场需要多长时间;(3)人力;(4)产品的质量。你发现要延期的时候只能在这四个里面做调整。例如是不是应该增加人手来按时发布,比如本来要满足10万人在线,是不是可以满足按1万人的时候先发初步的版本,如果都不行了,我就把产品初版本的发布往后推。产品发布的时候,不要一上来就把你想要的最终状态做出来,不要追求完美主义,尤其是做互联网的。 
谈到产品设计,王淮比较推崇的原则是不要过度设计,产品要简单不简陋。区别在于,简单的方式、步骤,把用户的问题解决了。你的步骤可以很简单,但是最后用户安完之后要完成的支付功能没有解决,那是简陋。功能最基本的要求是能够把事情完成了。为了完成这个事情,你的产品设计需要花一定的功夫,做简陋容易,做简单不容易。

  • 除了周例会 所有其他讨论会默认都是可选择是否参加

至于会议,每个项目团队都可以采取自己的节奏,有一些是每天聚一下,有一些是每周不同时间聚几次,具体情况要根据产品的情况来定。但一般超过30分钟的会议是不应该的,10-30分钟。这种会议很好,比较傻的借口很快就会暴露出来,重点在于在这个问题上我们做了什么事情,和之前预定好的差异情况,是不是能够按照原计划完成。要么是定计划太急了,没考虑好,要么就是执行的时候有太多问题。

Facebook很少有强迫性参加的会议,所有的讨论会默认情况都是可选择的,如果你认为自己参加这个会议不能获得价值,或者会议给你的价值不值得花半小时的话,可以把它拒掉。但是要给会议邀请人发一个邮件解释一下。周例会是少数强迫性的会议,内容都坦白的记录在Wiki里,每周都会总结进度并群发邮件。

  • Facebook的透明文化是自上而下 扎克伯格的带头作用很有意义

公司逐步成长起来后,不同部门和团队彼此之间如何知道对方在做什么。透明度是Facebook一直坚持的,甚至是发生了几次泄密事件之后仍然坚持。这种文化要在公司里面有一个基础,具体的做,有理论基础和文化基础,需要不同途径去强化它。这一点与公司领导人的风格和带头示范作用关系很大。扎克伯格会每周五下午在内部开公开会,花一小时讲讲公司一周发生的事情,之后大家可以随意提问和交流,这已经形成惯例。有一些具体的做法,所有的会议,默认的都是可以直接参加的,即使没有邀请你,也可以旁听。但理论上是没有邀请你,可以不发言。工具上,所有的产品发布,发布之前产品经理要发一个简要的产品介绍,和如何激活使用它的方法。

  • 公司内任何事情至少有两个人知道

在谈到如何减少因为人员流动对项目造成的影响时,王淮谈到,硅谷惯例,离职提前两礼拜通知公司,在此期间做好交接工作。Facebook强调任何事情都是至少有两个人知道,可以降低因此带来的损失。公司不会因为缺少某一个人而带来巨大损失。

  • 创业公司不建议建立单独测试团队 要强制工程师养成测试的习惯

王淮谈到了测试团队,以往Facebook并不把它叫做测试团队,Facebook的“测试团队” 由其最优秀的工程师组成。他强调了在产品开发系统的时候测试工具的重要性。他建议创业公司不建立测试团队,强制工程师养成测试的习惯。

豆瓣网技术副总段念

对此,现场的豆瓣网技术副总段念同学对此也发布了自己的看法。豆瓣一开始没有测试团队。目前有7个左右的测试工程师,主要工作是为开发工程师让自己写的东西持续产生价值。比如推动开发工程师前端的代码。真正落在用户上,有相当一部分是靠PM完成和工程师自己完成的。而不是由测试工程师自己完成的。他认为测试人员的人数上不能超过工程师的1/10。

会后交流 机锋网CTO黄晓东和王淮在讨论移动互联网产品开发

此外,王淮在分享中还谈到了一些重要观点,例如对工程师绩效的考核采用Product Metrics代替传统KPI;尽量重用内部代码,虽然这会导致更多团队卷入产品开发,但好处在于能够帮助改进其代码质量等等。

发表评论

电子邮件地址不会被公开。 必填项已用*标注