/ 产品经理

Building Facebook

虽然今天周一起了个大早,科目三(驾考)也还是挂了,但这段等待考试的时间有了另一个收获,读完了《打造Facebook》,感觉Facebook的团队组成和我所在的团队非常相似,从王淮的经历里汲取了很多有营养的东西。强烈推荐大家都买来看看,尤其是工程师可以了解到工程师驱动的文化是什么样子。

这本书在多看豆瓣都有。分享一些简单的书摘,希望这些能对大家的团队有所帮助。

Facebook受到创始人扎克伯格的影响非常大,形成了一种特别的黑客文化,他们通过严格的面试筛选一起工作的人,在早起迅速成长的过程中将面试做为第一优先级,这个和MIUI的状况非常类似。新人必须参加前6周的“新兵训练营”,他们要求工程师第一天就配置好编程环境,第一天就提交代码。工程师在“新兵训练营”中会接到修复bug的工作来融入公司和熟悉流程,新人的代码是会被灰读发布出去的,给新人感觉很有成就感。作者也聊了很多Mentor的角色对新人的帮助,这些其实大家在微软和Google都也已经了解,就不多说。

据王淮所说,在Facebook,工程师和PM的影响力比重大概是60:40,在后台系统方面甚至达到100:0,他们很晚才设立PM这个岗位,最初甚至是工程师转过去的居多。这一点和小米就非常不同,这样的做法确实才能激起工程师的责任感,围绕产品进行全方位的思考,真正对自己开发的产品负责。从我们团队的情况来看,工程师参与产品决策的情况实在不够多,PM团队之前都在小圈子里讨论,而只在方案几乎确定后才加上工程师讨论。这样其实造成了一些隔阂,我第一天搬过来的时候,便签的工程师杨亮说:“你搬过来了,我来看看你们PM每天都做点什么。”,这让我更加觉得工程和产品之间真的需要更多的沟通和交流,培养团队默契,建立信任。

对于产品开发的原则,王淮的总结很全面:

一、迅速发布,在进行监测

有意思的是,最开始极端的Facebook文化提倡的是Move Fast and Break Things。后来由于用户量实在太大,扛不住老Break,最终改为了Move Fast and Monitor Closely。这个原则的前半部分MIUI的大家们都应该很熟悉,快速迭代发布,但我们现在慢了,因为做决定开始要说服一系列的人,大家越来越追求一个完美的解。团队内部早也意识到这个问题,现在我们也在调整。但我们后半部分距离Facebook就有很大差距,这可能是服务器端网页产品和手机端产品开发的特性导致的。我们现在也在不断进步着,相信MIUI也一定会在这个方面成长起来。

二、坦然面对不确定性

简单地说,就是做错了没关系,尽快调整方向,马山改正。

三、不追求极致,应该不断地发布以达到目标

这个也是说快速迭代发布,但强调了不追求极致这一点。我觉得对产品和工程师都适用,产品不要视图寻找一个完美极致的方案才肯罢休,很多时候完美的方案可能不存在,只有最适合。工程也需要照顾项目进度,不能过分追求完美。我们可以通过一步一步的改进来完善产品。

Facebook的产品开发流程,其实还是经典的那一套。流程不是目的,关键是团队中对这些事情都有一个统一的理解和认识,并长期坚持,不断总结和打磨,非常不容易做到。他提到:

  1. 描绘愿景和设定目标(经典的SMART原则)
  2. 收集想法并排出优先级
  3. 跨团队沟通
  4. 告知所有关心的人
  5. 设计产品
  6. 指定项目负责人
  7. 定期碰头
  8. 了解进度 汇总报告
  9. 发布产品 监测数据

王淮对每一条流程中Facebook的情况进行了详细的介绍,总体来说,流程在Facebook并没有成为一种累赘或障碍,而是不断为流程背后的目标而不断优化,起到了非常积极正面的作用。感觉对其中很多的细节,我们都有可以借鉴的地方,点太多,我就不细说了。

印象深刻的是,王淮的观点:工程师不仅要善于写程序,也要有选择想法的能力。还有一个是他们追踪项目的“温度计”,好带感。

整本书读完,收获很多,用Facebook做的一些事情来看我自身,发现不论是做事还是沟通方面都还不够成熟。马上过年了,正好有机会好好总结过往,计划未来。非常期待新的一年和团队一起成长! :)

康上明学

康上明学

理想主义者,想得太多,做得太少。欢迎关注微信公共号「明学的白板」

Read More