《打造Facebook》摘要与心得 2015年3月10日 注：【】部分为笔者心得，非原文摘抄。 一个人热爱一家公司是因为他对这家公司文化的认同，而并非公司反复在那里强调你要对公司忠诚。忠诚，是文化认同的附属品。 Facebook 绝大多人都很清楚，“我们并不是为某个小组工作的，我们的目标是整个 Facebook 的发展”。而这种理念，让 Facebook 内部的协同作战、互帮互助成了家常便饭，让组与组之间的合作或妥协不再那么困难。 如果需要跨组协作的话，Facebook 会尽可能地让两边直接对接的工程师来沟通，做不做什么时候做、做到什么程度，让他们自己来定，除非涉及的工作量很大，大到会影响到整个组的进度，基本都是把这些工作的计划权和决定权往下“推”，而不是往上“揽”。 每个产品当然要估算一个完成的时间，但是这种做法对工程师的负面影响就在于，更多关注在“时间”上，而不是要把工作“做好”，只是把工程师当作工具。 创业永远是做一件新的事情，文化是新的，问题是新的，方法是新的，但你要借鉴前人的经验，去思考他们的各种做法能不能运用到自己的公司里。 Facebook 面试工程师时都要安排四位面试官，主要考察编程的能力，还需要考察文化适应性问题和系统设计。 Facebook 在招聘中最关心的是如何考察应聘者对一些通用问题的解决能力和交流能力。 Facebook 在挑选面试官方面已经形成了一定的机制，就是找出有甄选能力的人，能与交流者进行顺畅、有效的沟通，可以验证他的长处和优势。 Facebook 的核心价值： 把事情完成比完美更重要，这是最关键的； 要做整体上对公司最有影响的事情，而不是做那些可有可无的事情； 愿意进行团队合作，而不是习惯于单枪匹马； 不要永远只会听你老板的话，要做一些你自己的决定和判断。 编程问题不仅仅是考察解决问题的能力，还有很重要的一点是沟通能力。 在谈论思路的时候碰上思维的断点不要紧张，可以把困扰说出来，把面试当做一个探讨的机会，而不是考试。 在技术讨论中，面试官要把应聘者当作同事，如果讨论之后留下的感觉是“我不想和他共事”，那就不要给他积极的评价。 Facebook 的面试会回避类似脑筋急转弯那种所谓智力型题目，因为那根本体现不出什么智商，重点都放在具体的编程问题上。 要对应聘者学习新东西的意愿和能力的判断要求非常高。 尊重每一个应聘者非常重要。 一流人才喜欢互相挑战。 通过完成艰巨任务，一流人才会互设榜样。 一个互帮互助的一流团队才能真正做到 1 ＋ 1 远大于 2。 Facebook 鼓励不同项目间公开分享他们的苦与乐、成功与教训，从不吝啬对好项目的公开赞美，这样才能让榜样的影响传播开来。 在招人的标准上坚持一点，让面试官明白他们须要招到在某些方面比他们更强，至少不会拖后腿的人。 炒鱿鱼要快（Fire fast）。使用非一流人才就像服用慢性毒药，迟早会出事。Facebook 要求所有的经理人员对员工的表现要特别敏感，经历如果发现员工所分配的任务经常没有完成或者答应的事情经常没有做到，如果是客观原因，一定要尽力帮助解决；如果判断为能力问题，那就要通过合法的程序迅速将人炒掉。 把想法迅速地、高质量地实现出来，然后在实践中不断改进。 如果想找工作，不妨留意你“未来同事、未来老板”经常出没的活动场所之中，尝试去认识他们，让他们对你感兴趣，然后让他们做内部推荐。 熟人推荐无论对于求职者还是用人公司来说相对成本都要低。对于求职者来说，可以通过熟人了解公司内部的真实情况；对于公司来说，熟人的推荐让求职者的质量得到一个保证。 严禁非收购团队的人去和收购目标公司谈条件。 创业企业要想建立起长久的竞争能力，就一定要把招聘当做自身最重要的工作，坚持不懈。 招聘时竞争的第一步。 发动公司里每个人都参与到招聘中，对公司文化的影响会很明显。 Facebook 相信，让工程师融入公司最好的办法是通过代码的交流。毕竟，产生高质量的代码是所有工程师最主要的工作。 至少要在相关代码里花半个小时而没有任何头绪，这时候才适合去寻找导师或者问相关的工程师。 导师关键的是教给新员工方法、理念和文化上的东西。 让一个新人在完全没有知道的情况下去了解每个组，效率太低，也不现实。 优化无止境，产品无完美。 从刚对某一产品进行方向性讨论、选择的时候，工程师就要尽可能地参与其中，提出自己的想法，工程师会参与从产品的构思、设计到打造的整个过程。 在 Facebook，对于工程师来说，公司特别提倡以下几点： 迅速发布，再进行监测（Move Fast and Monitor Closely）; 坦诚对待不确定性（Be Comfortable with Uncertainty）； 不追求极致，应该不断地发布以达到目标（Done Is Better Than Perfect, Stay Focused and Keep Shipping）; Facebook 不允许对一个计划中的产品是否成功有太多纠结，当然会有讨论，在讨论中鼓励大家理性地分析用户可能有的反应，感性地推销自己对某个产品方向的热爱；但对于有争议的产品，很难有一个大家都完全认同的方向。这个时候，公司更愿意相信有能力的产品经理或工程师的判断。 只有不断地进行符合用户需求的改变，才是能够在互联网时代生存下去的法宝。 凡是被很多人不断重复的好习惯，要将其自动化，绑定到工具之中。 工具团队不应该是一个由二线员工组成的“事后诸葛亮”的后勤部门，公司里最有才华的工程是应该用公司自己的工具来工作，并且企业文化里要优先反映这些。编写出优秀的工具并继续加以改善、更新，这比寻找下一个伟大的创意更重要。——黄易山 公司文化中一定要着重反映出：公司将内部工具视为持续的重要投资，以保持公司的领先地位。 招人的出发点必须是有实在的业务需求，把你的招人需求和业务发展方向结合起来，最好有数据来支撑说明。 领导者最重要的事情就是去帮助员工发掘自己的长处，并尽可能创造机会让他们去发挥自己的长处。通过不断的激励和帮助员工，让他们挑战自己，做出比自己想象的更好的成就。而对于其弱点，最重要的是帮助他们去认识到。然后通过培训，或者和别人合作形成互补的方式，来完成任务。 在团队的真实极限中找到一个可持续性的驱动力来激励团队超越自我。 工作的分配通常涉及两个因素： 员工本人的兴趣点； 项目所需要的经验和优势。 让合作竞争保持在一种健康有序的状态，关键是促进人与人之间的亲密感。人的距离近了，事情就容易解决了。 一般来说，对于经理而言和员工之间的一对一交流，在听与说上的比例在 80:20 比较合适，也就是听多说少。对于员工提出的问题，一般不直接给予解决的方法，大部分是通过反复地提出问题引导思考，或者给出指针让他们去和更合适的专家去聊，来鼓励形成自己敢于做困难决定的习惯。除非涉及的问题刚好是在我的专业范围之内，这个时候我是作为这方面的专家来给出意见而不是作为他们的经理。否则给出的建议如果不是专业的，员工在究竟听还是不听之间会陷入两难。 Facebook 非常鼓励员工自己通过研究、通过和专业人士交流、通过思考，自己来做出困难的决定，而不是听经理的话。 关于做一对一会面，有下面几个值得注意的地方： 下属是主角，而非经理； 尽可能让组员感觉到这个会议是给他们获得你的时间和关注的最好机会； 一对一不一定要在会议室； 注意语调和肢体语言； 关注于行动； 一定要事先做准备； 对于建设性的意见，一定要有实际例子的支撑； 对于比较困难的建设性的讨论，一种常见的方法是提出建议、给出具体的实例、根据实例来讨论这么做的利与弊，然后在讨论中逐渐形成共识，得出需要改进或者改变的地方，变成行动方案。 在面对面的谈话中，言语内容传达的信息对于个体态度的影响只有 7%，语调传达达到 55%，形体和表情语言达到 38%。而态度的影响会很大程度上影响对于信息的接受程度。 从工程师到经理，其实更多的是一种职业角色的转换（两者要求的技能、经验、知识结构不一样），而不是要得到某种“地位”。其实像在 Facebook，工程师的地位是很高的，是公司的核心财富，薪酬待遇上也可以体现出来。 包括 Facebook 在内的很多硅谷公司，工程师跟行政管理者是两套不同的体系，即便你一直做工程师，只要你做得很出色，一样可以达到很高的薪酬水平，并不比你向经理、总监、副总裁这么一步步爬上去差。 一旦涉及人事问题，就容易将困难的决定和不舒服的决定混淆。 “老好人”无法做团队经理，经理要习惯于做不舒服但正确的决定。 Facebook 的理念是升职到一个职位上，必须已经在这个新的职位上顺畅地运作了 3-6 个月。 如何去找倒是，并与之相处？下面五点很重要： 双方是朋友； 导师在某一领域能够帮你提高自己的价值； 要积极主动去寻找； 对导师的帮助要心怀感激； 对每次和导师的交流进行总结、记录。 产品开发流程的九大步骤： 描绘远景、设置目标； 收集想法并排出优先次序； 跨团队沟通； 告知所有可能关心的人； 设计产品； 指定项目负责人； 定期碰头会； 了解进度、汇总报告； 发布产品、监测数据。 对于远景的思考，主要围绕三点： 为什么要设立这个目标，而不是另一个目标？ 在做一件事情之前，脑子里应该有这件事情完成之后是什么样子的一个画面，接下来很多事情都是围绕着这个最终画面来进行的。你要做的事情就是让脑子里的画面越来越清晰，自己里这个画面越来越近； 计划做什么来实现这个远景？ S：Specific，详细具体的； M：Measurable，可衡量的； A：Aggressive，有难度、有挑战性； R：Relistic，现实的； T：Time-bound，实现的期限。 工程师不仅要善于写程序，也要有选择想法的能力。 关于时间分配，还有一个“6-2-2”原则，Facebook 的很多组都尽可能遵循这个指导原则：60%左右的时间放在那些能够预测的工作上；20%的时间花在后台架构和产品质量上；20%的时间花在比较有风险、有争议的、可能会带来某种颠覆性后果的那些想法上。 鼓励把资源有意识地预分配到有风险、有争议、但可能会有颠覆意义的想法上。这一步做好了，可以持续性地领导市场，比较难被竞争对手超越。 如何挑选那些接下来要去实现的想法，有几点需要注意： 季度性计划主要是指导性的，不会强求把它们变成必须要遵循的工作计划； 围绕每个想法的影响力进行辩论； 120%规则，挑选出来要做的想法大概是团队可承担范围的 120%左右； 按照之前的讨论，还要保证一些底层架构和产品质量的工作是在这些想法之中的。 月计划是把全局观和实际情况较好地进行结合的一个平衡。而周计划和日计划作为工具，可以让员工自己为了完成月计划去制订。 对于任何一个项目，具体执行中一般都涉及四个维度： 有哪些功能； 预期完成时间； 预算； 完成质量。 Facebook 非常注意不重复开发新的技术系统。一个原则是：有好的开源系统，就用开源的；有好的商用产品，就购买商用的；必须自己开发的或者跟 Facebook 核心竞争力息息相关的，则集中力量开发一套，而不是重复劳动，开发多套类似系统。 对于开源系统，只要有一个优秀的、活跃的开发社区在维护，Facebook 就会积极地利用并且毫不吝啬地给予反馈。 对于一些跟核心数据息息相关的系统，即使市场上有商用系统，Facebook 还是决定自己开发。 如果一个项目最终不成功，那么项目负责人是不能以别人无法提供帮助作为借口的。所以，即使别人答应帮忙，项目负责人还是需要学会去激励别人、监督别人，通过“抒情讲理”甚至“威逼利诱”等各种手段获得及时的帮助。 对于产品设计，有以下一些基本理念可以借鉴： 不要过度设计； 产品越简单越好，但并不意味着简陋； 对于自己做出来的产品，你必须是它的用户； 产品要确实有用，主要流程尽可能顺畅； 不追求完美； 保留最基本的质量底线。 对于每一个项目，都要指定一个明确的责任人，一般都是工程师。 在分配项目的时候要明确：项目成功了，最大功劳归属于责任人；项目失败了，最大的责任也是他的。一个项目可以有多个人参与，但明确的责任人只有一个，这个责任人要负责推动该项目的进展。其他参与的人没有做好应该做的事，责任人要去提醒、督促，督促无效时再告知经理以获得支持。但不能在汇报项目进展的时候，突然抛出一个为失败寻找的借口。 Facebook 不希望一个初级工程师永远做螺丝钉的角色，而是希望每个工程师都能够积极主动地去领导一项任务，推动项目进展。一个明确了责任的项目可以“逼迫”工程师担当起责任。 对于具体战斗在第一线的团队，定期的项目碰头会可以让某个项目的所有战斗人员都能保持对信息获取的一致性，有共同的交流基础。 发布前评估，就是在发布之前，根据具体的产品或者该次发布的特点，做一些诸如发布策略、需监测的核心数据、产品演示、核心算法改变等方面的讨论。 对于发布前评估，有一些这样的经验： 不应超过半小时； 形式可以多样； 人员选择可以多样； 内容可以多样； 不管你在产品发布之前做了什么样的准备，都不可能 100%确保发布是安全的。大家要坦然面对这一点，也不需要在发布之前做出极端的准备措施。 不能藐视发布过程中的风险，一种发布工程的做法是阀门控制式的灰度发布，就是有所控制地选择发布的人群及其比例。 Post-Mortem 会涉及以下几个方面： 发生了什么； 影响多大； 问题的原因是什么； 事件发生的具体时间表； 如何避免将来犯类似错误的行动方案。 员工股份的基本种类分两种： 期权（Options）：需要员工行权后才能购买股票； 期权行权：以员工入职当天的市场合理价格来购买股票，即使员工要行权时的股票价格已经是入职当天的几十倍； 受限股票单元（RSU, Restricted Stock Unit）：直接发放到员工名下，但只能上市之后在公开市场上才能兑现。 期权一般是在股票还非常低时发放，股价较高时，就改成了受限股票单元。 不管是齐全还是受限股票单元一般是分 4 年付清，也有少数公司是 5 年。在第一个周年日之后，1/4（如果是 4 年付清）的期权会发到员工名下，接下来的每一个月 1/48 的期权会发到员工名下，知道第 4 年末，所有期权付清。期权一旦到了员工名下，员工可以选择在任何时候行权，直到离职后的 3 个月。 在 Facebook，定期的业绩评价每年进行两次，年中和年底各一次（这种情况在硅谷的公司中很常见），评价结果都会跟升职、工资、奖金挂钩，而年底评价还跟股份奖励有关。业绩评价由三个部分组成：自我评价、同事评价和老板评价。 评价不能简单地写个结论完事，评价者要进行相关的阐述，用具体事例予以支持。 在评分的同时，决定要不要推荐升值。通常只有在连续两次或以上得到高于“超越了期望”的评价才有可能获得升职机会。 对于评价，不同的组之间要进行校正，以防止各组的评价标准不一致。 除了定期的业绩评价外，意见反馈应该是持续进行的，并及时和员工沟通，真正帮助他们不断获得进步。 关于有效传递意见反馈，有几点要提一下： 意见反馈不见得都是负面的； 意见反馈必须摆事实、讲道理； 意见反馈必须是可操作的； 书面反馈可以适当减少感性冲动。 如果员工为了追寻自己人生最大的价值而离职创业，公司不会勉强挽留。其实，这种不断裂变的循环，正是硅谷的生机所在。 对大多数硅谷技术公司来说，并不强调员工终生就职的忠诚度，只要你在公司期间做出了相应的贡献，离开公司有实现了自己人生的价值，那就是两全其美的结果。 团队质量跟创意质量是等同的。

注：【】部分为笔者心得，非原文摘抄。

• 一个人热爱一家公司是因为他对这家公司文化的认同，而并非公司反复在那里强调你要对公司忠诚。忠诚，是文化认同的附属品。
• Facebook 绝大多人都很清楚，“我们并不是为某个小组工作的，我们的目标是整个 Facebook 的发展”。而这种理念，让 Facebook 内部的协同作战、互帮互助成了家常便饭，让组与组之间的合作或妥协不再那么困难。
• 如果需要跨组协作的话，Facebook 会尽可能地让两边直接对接的工程师来沟通，做不做什么时候做、做到什么程度，让他们自己来定，除非涉及的工作量很大，大到会影响到整个组的进度，基本都是把这些工作的计划权和决定权往下“推”，而不是往上“揽”。
• 每个产品当然要估算一个完成的时间，但是这种做法对工程师的负面影响就在于，更多关注在“时间”上，而不是要把工作“做好”，只是把工程师当作工具。
• 创业永远是做一件新的事情，文化是新的，问题是新的，方法是新的，但你要借鉴前人的经验，去思考他们的各种做法能不能运用到自己的公司里。
• Facebook 面试工程师时都要安排四位面试官，主要考察编程的能力，还需要考察文化适应性问题和系统设计。
• Facebook 在招聘中最关心的是如何考察应聘者对一些通用问题的解决能力和交流能力。
• Facebook 在挑选面试官方面已经形成了一定的机制，就是找出有甄选能力的人，能与交流者进行顺畅、有效的沟通，可以验证他的长处和优势。
• Facebook 的核心价值：
  • 把事情完成比完美更重要，这是最关键的；
  • 要做整体上对公司最有影响的事情，而不是做那些可有可无的事情；
  • 愿意进行团队合作，而不是习惯于单枪匹马；
  • 不要永远只会听你老板的话，要做一些你自己的决定和判断。
• 编程问题不仅仅是考察解决问题的能力，还有很重要的一点是沟通能力。
• 在谈论思路的时候碰上思维的断点不要紧张，可以把困扰说出来，把面试当做一个探讨的机会，而不是考试。
• 在技术讨论中，面试官要把应聘者当作同事，如果讨论之后留下的感觉是“我不想和他共事”，那就不要给他积极的评价。
• Facebook 的面试会回避类似脑筋急转弯那种所谓智力型题目，因为那根本体现不出什么智商，重点都放在具体的编程问题上。
• 要对应聘者学习新东西的意愿和能力的判断要求非常高。
• 尊重每一个应聘者非常重要。
• 一流人才喜欢互相挑战。
• 通过完成艰巨任务，一流人才会互设榜样。
• 一个互帮互助的一流团队才能真正做到 1 ＋ 1 远大于 2。
• Facebook 鼓励不同项目间公开分享他们的苦与乐、成功与教训，从不吝啬对好项目的公开赞美，这样才能让榜样的影响传播开来。
• 在招人的标准上坚持一点，让面试官明白他们须要招到在某些方面比他们更强，至少不会拖后腿的人。
• 炒鱿鱼要快（Fire fast）。使用非一流人才就像服用慢性毒药，迟早会出事。Facebook 要求所有的经理人员对员工的表现要特别敏感，经历如果发现员工所分配的任务经常没有完成或者答应的事情经常没有做到，如果是客观原因，一定要尽力帮助解决；如果判断为能力问题，那就要通过合法的程序迅速将人炒掉。
• 把想法迅速地、高质量地实现出来，然后在实践中不断改进。
• 如果想找工作，不妨留意你“未来同事、未来老板”经常出没的活动场所之中，尝试去认识他们，让他们对你感兴趣，然后让他们做内部推荐。
• 熟人推荐无论对于求职者还是用人公司来说相对成本都要低。对于求职者来说，可以通过熟人了解公司内部的真实情况；对于公司来说，熟人的推荐让求职者的质量得到一个保证。
• 严禁非收购团队的人去和收购目标公司谈条件。
• 创业企业要想建立起长久的竞争能力，就一定要把招聘当做自身最重要的工作，坚持不懈。
• 招聘时竞争的第一步。
• 发动公司里每个人都参与到招聘中，对公司文化的影响会很明显。
• Facebook 相信，让工程师融入公司最好的办法是通过代码的交流。毕竟，产生高质量的代码是所有工程师最主要的工作。
• 至少要在相关代码里花半个小时而没有任何头绪，这时候才适合去寻找导师或者问相关的工程师。
• 导师关键的是教给新员工方法、理念和文化上的东西。
• 让一个新人在完全没有知道的情况下去了解每个组，效率太低，也不现实。
• 优化无止境，产品无完美。
• 从刚对某一产品进行方向性讨论、选择的时候，工程师就要尽可能地参与其中，提出自己的想法，工程师会参与从产品的构思、设计到打造的整个过程。
• 在 Facebook，对于工程师来说，公司特别提倡以下几点：
  1. 迅速发布，再进行监测（Move Fast and Monitor Closely）;
  2. 坦诚对待不确定性（Be Comfortable with Uncertainty）；
  3. 不追求极致，应该不断地发布以达到目标（Done Is Better Than Perfect, Stay Focused and Keep Shipping）;
• Facebook 不允许对一个计划中的产品是否成功有太多纠结，当然会有讨论，在讨论中鼓励大家理性地分析用户可能有的反应，感性地推销自己对某个产品方向的热爱；但对于有争议的产品，很难有一个大家都完全认同的方向。这个时候，公司更愿意相信有能力的产品经理或工程师的判断。
• 只有不断地进行符合用户需求的改变，才是能够在互联网时代生存下去的法宝。
• 凡是被很多人不断重复的好习惯，要将其自动化，绑定到工具之中。
• 工具团队不应该是一个由二线员工组成的“事后诸葛亮”的后勤部门，公司里最有才华的工程是应该用公司自己的工具来工作，并且企业文化里要优先反映这些。编写出优秀的工具并继续加以改善、更新，这比寻找下一个伟大的创意更重要。——黄易山
• 公司文化中一定要着重反映出：公司将内部工具视为持续的重要投资，以保持公司的领先地位。
• 招人的出发点必须是有实在的业务需求，把你的招人需求和业务发展方向结合起来，最好有数据来支撑说明。
• 领导者最重要的事情就是去帮助员工发掘自己的长处，并尽可能创造机会让他们去发挥自己的长处。通过不断的激励和帮助员工，让他们挑战自己，做出比自己想象的更好的成就。而对于其弱点，最重要的是帮助他们去认识到。然后通过培训，或者和别人合作形成互补的方式，来完成任务。
• 在团队的真实极限中找到一个可持续性的驱动力来激励团队超越自我。
• 工作的分配通常涉及两个因素：
  • 员工本人的兴趣点；
  • 项目所需要的经验和优势。
• 让合作竞争保持在一种健康有序的状态，关键是促进人与人之间的亲密感。人的距离近了，事情就容易解决了。
• 一般来说，对于经理而言和员工之间的一对一交流，在听与说上的比例在 80:20 比较合适，也就是听多说少。对于员工提出的问题，一般不直接给予解决的方法，大部分是通过反复地提出问题引导思考，或者给出指针让他们去和更合适的专家去聊，来鼓励形成自己敢于做困难决定的习惯。除非涉及的问题刚好是在我的专业范围之内，这个时候我是作为这方面的专家来给出意见而不是作为他们的经理。否则给出的建议如果不是专业的，员工在究竟听还是不听之间会陷入两难。
• Facebook 非常鼓励员工自己通过研究、通过和专业人士交流、通过思考，自己来做出困难的决定，而不是听经理的话。
• 关于做一对一会面，有下面几个值得注意的地方：
  1. 下属是主角，而非经理；
     • 尽可能让组员感觉到这个会议是给他们获得你的时间和关注的最好机会；
  2. 一对一不一定要在会议室；
  3. 注意语调和肢体语言；
  4. 关注于行动；
  5. 一定要事先做准备；
  6. 对于建设性的意见，一定要有实际例子的支撑；
  7. 对于比较困难的建设性的讨论，一种常见的方法是提出建议、给出具体的实例、根据实例来讨论这么做的利与弊，然后在讨论中逐渐形成共识，得出需要改进或者改变的地方，变成行动方案。
• 在面对面的谈话中，言语内容传达的信息对于个体态度的影响只有 7%，语调传达达到 55%，形体和表情语言达到 38%。而态度的影响会很大程度上影响对于信息的接受程度。
• 从工程师到经理，其实更多的是一种职业角色的转换（两者要求的技能、经验、知识结构不一样），而不是要得到某种“地位”。其实像在 Facebook，工程师的地位是很高的，是公司的核心财富，薪酬待遇上也可以体现出来。
• 包括 Facebook 在内的很多硅谷公司，工程师跟行政管理者是两套不同的体系，即便你一直做工程师，只要你做得很出色，一样可以达到很高的薪酬水平，并不比你向经理、总监、副总裁这么一步步爬上去差。
• 一旦涉及人事问题，就容易将困难的决定和不舒服的决定混淆。
• “老好人”无法做团队经理，经理要习惯于做不舒服但正确的决定。
• Facebook 的理念是升职到一个职位上，必须已经在这个新的职位上顺畅地运作了 3-6 个月。
• 如何去找倒是，并与之相处？下面五点很重要：
  1. 双方是朋友；
  2. 导师在某一领域能够帮你提高自己的价值；
  3. 要积极主动去寻找；
  4. 对导师的帮助要心怀感激；
  5. 对每次和导师的交流进行总结、记录。
• 产品开发流程的九大步骤：
  1. 描绘远景、设置目标；
  2. 收集想法并排出优先次序；
  3. 跨团队沟通；
  4. 告知所有可能关心的人；
  5. 设计产品；
  6. 指定项目负责人；
  7. 定期碰头会；
  8. 了解进度、汇总报告；
  9. 发布产品、监测数据。
• 对于远景的思考，主要围绕三点：
  1. 为什么要设立这个目标，而不是另一个目标？
  2. 在做一件事情之前，脑子里应该有这件事情完成之后是什么样子的一个画面，接下来很多事情都是围绕着这个最终画面来进行的。你要做的事情就是让脑子里的画面越来越清晰，自己里这个画面越来越近；
  3. 计划做什么来实现这个远景？
     1. S：Specific，详细具体的；
     2. M：Measurable，可衡量的；
     3. A：Aggressive，有难度、有挑战性；
     4. R：Relistic，现实的；
     5. T：Time-bound，实现的期限。
• 工程师不仅要善于写程序，也要有选择想法的能力。
• 关于时间分配，还有一个“6-2-2”原则，Facebook 的很多组都尽可能遵循这个指导原则：60%左右的时间放在那些能够预测的工作上；20%的时间花在后台架构和产品质量上；20%的时间花在比较有风险、有争议的、可能会带来某种颠覆性后果的那些想法上。
• 鼓励把资源有意识地预分配到有风险、有争议、但可能会有颠覆意义的想法上。这一步做好了，可以持续性地领导市场，比较难被竞争对手超越。
• 如何挑选那些接下来要去实现的想法，有几点需要注意：
  • 季度性计划主要是指导性的，不会强求把它们变成必须要遵循的工作计划；
  • 围绕每个想法的影响力进行辩论；
  • 120%规则，挑选出来要做的想法大概是团队可承担范围的 120%左右；
  • 按照之前的讨论，还要保证一些底层架构和产品质量的工作是在这些想法之中的。
• 月计划是把全局观和实际情况较好地进行结合的一个平衡。而周计划和日计划作为工具，可以让员工自己为了完成月计划去制订。
• 对于任何一个项目，具体执行中一般都涉及四个维度：
  • 有哪些功能；
  • 预期完成时间；
  • 预算；
  • 完成质量。
• Facebook 非常注意不重复开发新的技术系统。一个原则是：有好的开源系统，就用开源的；有好的商用产品，就购买商用的；必须自己开发的或者跟 Facebook 核心竞争力息息相关的，则集中力量开发一套，而不是重复劳动，开发多套类似系统。
• 对于开源系统，只要有一个优秀的、活跃的开发社区在维护，Facebook 就会积极地利用并且毫不吝啬地给予反馈。
• 对于一些跟核心数据息息相关的系统，即使市场上有商用系统，Facebook 还是决定自己开发。
• 如果一个项目最终不成功，那么项目负责人是不能以别人无法提供帮助作为借口的。所以，即使别人答应帮忙，项目负责人还是需要学会去激励别人、监督别人，通过“抒情讲理”甚至“威逼利诱”等各种手段获得及时的帮助。
• 对于产品设计，有以下一些基本理念可以借鉴：
  • 不要过度设计；
  • 产品越简单越好，但并不意味着简陋；
  • 对于自己做出来的产品，你必须是它的用户；
  • 产品要确实有用，主要流程尽可能顺畅；
  • 不追求完美；
  • 保留最基本的质量底线。
• 对于每一个项目，都要指定一个明确的责任人，一般都是工程师。
• 在分配项目的时候要明确：项目成功了，最大功劳归属于责任人；项目失败了，最大的责任也是他的。一个项目可以有多个人参与，但明确的责任人只有一个，这个责任人要负责推动该项目的进展。其他参与的人没有做好应该做的事，责任人要去提醒、督促，督促无效时再告知经理以获得支持。但不能在汇报项目进展的时候，突然抛出一个为失败寻找的借口。
• Facebook 不希望一个初级工程师永远做螺丝钉的角色，而是希望每个工程师都能够积极主动地去领导一项任务，推动项目进展。一个明确了责任的项目可以“逼迫”工程师担当起责任。
• 对于具体战斗在第一线的团队，定期的项目碰头会可以让某个项目的所有战斗人员都能保持对信息获取的一致性，有共同的交流基础。
• 发布前评估，就是在发布之前，根据具体的产品或者该次发布的特点，做一些诸如发布策略、需监测的核心数据、产品演示、核心算法改变等方面的讨论。
• 对于发布前评估，有一些这样的经验：
  • 不应超过半小时；
  • 形式可以多样；
  • 人员选择可以多样；
  • 内容可以多样；
  • 不管你在产品发布之前做了什么样的准备，都不可能 100%确保发布是安全的。大家要坦然面对这一点，也不需要在发布之前做出极端的准备措施。
• 不能藐视发布过程中的风险，一种发布工程的做法是阀门控制式的灰度发布，就是有所控制地选择发布的人群及其比例。
• Post-Mortem 会涉及以下几个方面：
  • 发生了什么；
  • 影响多大；
  • 问题的原因是什么；
  • 事件发生的具体时间表；
  • 如何避免将来犯类似错误的行动方案。
• 员工股份的基本种类分两种：
  1. 期权（Options）：需要员工行权后才能购买股票；
     • 期权行权：以员工入职当天的市场合理价格来购买股票，即使员工要行权时的股票价格已经是入职当天的几十倍；
  2. 受限股票单元（RSU, Restricted Stock Unit）：直接发放到员工名下，但只能上市之后在公开市场上才能兑现。
• 期权一般是在股票还非常低时发放，股价较高时，就改成了受限股票单元。
• 不管是齐全还是受限股票单元一般是分 4 年付清，也有少数公司是 5 年。在第一个周年日之后，1/4（如果是 4 年付清）的期权会发到员工名下，接下来的每一个月 1/48 的期权会发到员工名下，知道第 4 年末，所有期权付清。期权一旦到了员工名下，员工可以选择在任何时候行权，直到离职后的 3 个月。
• 在 Facebook，定期的业绩评价每年进行两次，年中和年底各一次（这种情况在硅谷的公司中很常见），评价结果都会跟升职、工资、奖金挂钩，而年底评价还跟股份奖励有关。业绩评价由三个部分组成：自我评价、同事评价和老板评价。
• 评价不能简单地写个结论完事，评价者要进行相关的阐述，用具体事例予以支持。
• 在评分的同时，决定要不要推荐升值。通常只有在连续两次或以上得到高于“超越了期望”的评价才有可能获得升职机会。
• 对于评价，不同的组之间要进行校正，以防止各组的评价标准不一致。
• 除了定期的业绩评价外，意见反馈应该是持续进行的，并及时和员工沟通，真正帮助他们不断获得进步。
• 关于有效传递意见反馈，有几点要提一下：
  • 意见反馈不见得都是负面的；
  • 意见反馈必须摆事实、讲道理；
  • 意见反馈必须是可操作的；
  • 书面反馈可以适当减少感性冲动。
• 如果员工为了追寻自己人生最大的价值而离职创业，公司不会勉强挽留。其实，这种不断裂变的循环，正是硅谷的生机所在。
• 对大多数硅谷技术公司来说，并不强调员工终生就职的忠诚度，只要你在公司期间做出了相应的贡献，离开公司有实现了自己人生的价值，那就是两全其美的结果。
• 团队质量跟创意质量是等同的。