IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

《打造 Facebook》笔记

时光立方 2013-06-02 19:41:12 累计浏览 3,794 次
本机暂存

   我发现雅虎所谓的「公司政治」问题比较严重,没有那么很强烈的「所有人做事都是为了雅虎」的理念,他们内部是以BU(业务单元)这种方式运作的,小组与小组之间存在隔膜,都主要考虑自身那一小块的利益,相互之间的配合支持度较差。……后来到了Facebook,感觉完全不一样,绝大多数人都很清楚,「我们并不是为了某个小组工作的,我们的目标是整个Facebook的发展」。

   比如在雅虎要做一个产品,有十项功能的产品,那产品经理会列出一个表来,让工程师看可不可以做,每个功能又需要多少天完成,还要签字确认,就等于你承诺了多久要做完,并变成了工程师的「责任」,感觉很像是被迫签了一份卖身契。其实,每个产品当然要估算一个完成的时间,但是这种做法对工程师的负面影响就在于,更多关注在「时间」上,而不是要把工作「做好」,只是把工程师当作工具。

   在进行「文化适应性面试」时……让他回答「为什么对Facebook感兴趣」的问题。我们最不想听到的就是强调潜在的财务回报,虽然大家都知道这肯定是一个因素。但在如此宝贵的时间里去强调这一点,而不是其他更有意思的方面,会让面试人员产生反感。如果Facebook的财务表现在短期内不符合他们的想象,这些人会很快走掉。

   针对一段时间内面试的情况,公司每周会召开一个招聘决策会议,所有相关的面试人员和人力资源部门的代表都会参会,所有的应聘者都会被讨论,大家一起讨论应聘者的去留,明显不行的最快,明显行的也比较快,比较费时间的是那种所有人都说行、但没有一个人被震惊到,或者有人说不行、有人说很行的情况。这时候,如果有一个人愿意站出来力挺,一般不会被砍掉,可能会通过,也可能被安排一次后续的面试,再见上1~2个人,专门针对他上次面试中暴露出来的弱点提问题,来看他是如何解决的。总之,整体上的思路就是「请拿亮点来说服我」。

   Facebook就是希望通过这样的程序能找到一流的、合适的人才,这样才能做出最好的产品,成就伟大事业。面试中的技术性问题就是解决「是否一流」的问题,文化性问题就是解决「是否合适」的问题。一流人才只愿意和与自己水平相当的人共事,他们聚在一起会变得更好。一流人才无法容忍二流人才。

   只有你真正重视招聘,你才可能从尽可能广的范围内去搜罗、挑选人才,而不仅仅是从你的「应聘名单」上挑选。你要认识到,招聘是竞争的第一步,业内一流人才如果没有进入你的公司,那他们就在竞争对手的公司服务。这意味着,还没在市场上正式过招,你就输在了起跑线上。

   我在Facebook这四年半,一开始几乎每个工程师都互相认识,但随着人员迅速增长,这一点变得不可能。如何有效地让最适合(潜在)合作的人互相认识,有信任感,以保证项目的高效完成,成了Facebook这些年很大的挑战。等到项目开始时,参与的人员才彼此认识,那么磨合期会更长,磨合成本会更高。

   在产品开发的过程中,工程师的主动性体现在要善于处理不确定性,迅速发布满足可以接受的最低标准(但并非低标准)的产品,再根据监测数据的情况不断完善,最终达到极致。

   不断发展、改进公司的内部工具,可以极大地提高每个员工的工作效率,可以减少运营人员的数量。这样既改善了整体协调,又减少了整体开支。

   成为经理后,并不是说你要去「管」那些工程师,主要是榜样(Lead by Example)的作用,你要向他们展现什么才是优秀的做事方法,怎样能将产品做到极致。作为团队的领导者,你需要设定足够高但合理的期望:足够高得使你的团队成员不会感到没有挑战性,但又合理到不至于使他们油尽灯枯。你要给他们创造出一段经历,使得在「旅程」结束,他们回头看时会说:「哇,我都没想到自己居然做到了,这太牛了!」

   在实践中,对于我不是特别了解的被委托人,我是这么做的:项目开始时,我让被委托人给我一个整体计划以及完成时间,一开始经常会面跟进,然后确定后几天的任务,根据每次的完成状况来估计他能不能「按时按质按量」地实现最终目标。对他逐渐建立起信心后,可以减少关于该项目的细节讨论,此时的委托可以放得开一些。

   Facebook非常鼓励员工自己通过研究,通过和专业人士交流,通过思考,自己来做出困难的决定,而不是听经理的话。在会面中,对于各种问题的讨论,我们会特别关注相关的行动项目(Action Items),为的就是避免谈话变成空谈而非行动。会面之后,下属会要求在当天电邮一个非常简短的会议记录(Meeting Notes),主要就是聚焦在行动项目上,以作为下次一对一碰面的讨论基础。

   让自己的老板做导师是比较难处理的一件事。因为导师给出的建议,是否采纳,如何采纳,都是自己的事。然而,老板作为导师,他的建议究竟是建议还是任务、采纳的结果如何会直接影响他对你的评价,还有你对他的评价。这种利益上的考量,会让双方在交流中有所顾忌和保留。基于这样的原因,我不建议在和自己有业务上下级关系的人中寻找导师。

   如果你想说服其他人采取你的想法,你需要两样东西。一个是故事,或者叫例子,就是为什么这样做有效,能不能让你的说法有感染力,让你的说法给人留下印象;另外一个是数据,让你的说法有数据的支持,那么可信度会高很多。

   很重要的一点是,设计产品时,你要大概知道第一版本(V1)是什么样子的。你可以在设计时构思产品的最终状态,但公司不会允许你花大量的资源去打造一个所谓的终极版本。何况,终极版本通常只存在于臆想之中,用户的反馈会让你迅速明白,你需要的是一个能反映出你想法的第一版本,迅速推出后根据市场反应进行更新。

   通常,为了把第一版本推出去,我们经常用「试验(Experiment)」的理由,是告诉别人我们需要第一版本在有控制的范围中来验证产品,并会严格监测重要数据。如果产品成功,我们会在后续版本中再认真考虑更多的功能。以试验的方式推出新产品,通常阻力要小很多。

同分类推荐文章

  1. 科技爱好者周刊(第 401 期):如何赚到10亿美元 (2026-06-26 08:05:38)
  2. 如何做决策 - 从 Go 的一个 issue 说起 (2026-06-26 08:00:00)
  3. Seven Player:Windows上播放115网盘视频的增强工具 (2026-06-09 00:06:47)

查看更多 开发者 文章 →

建议继续学习

  1. 腾讯敏捷开发及快速迭代 (累计阅读 8,065)
  2. 腾讯抄你肿么办 (累计阅读 7,759)
  3. 给实习生的建议 (累计阅读 7,083)
  4. Git commit 注释格式 (累计阅读 6,922)
  5. 打工仔,天下不是我们的 (累计阅读 6,491)
  6. 应届生选择大公司还是小团队 (累计阅读 6,083)
  7. 在大公司和小公司做产品的区别 (累计阅读 6,079)
  8. 软件公司的两种管理方式 (累计阅读 5,564)
  9. 技术领导要不要写代码? (累计阅读 5,556)
  10. 领导如何应对员工离职 (累计阅读 5,490)