Facebook 工程师文化独特之处

我在 Facebook 工作了 7 年，结合 Facebook 之前和之后的其它公司的经验，我觉得 Facebook 的文化有些独特的地方值得分享一下。尽管我说了「独特」，这不代表其它公司绝对不会这样做，有些公司有相似的文化，有时候相似的文化用力程度不一样得到的结果也不一样。

工程师对产品结果负责任

我见过很多互联网公司只看工程师产出的技术成果，实际产品结果或商业结果在考评中占的比例很大。Facebook 从高级工程师开始，考评主要看对产品结果的产出，而且有时候非常数据驱动。

考评只看技术的公司，或者是 Facebook 没到高级工程师的级别，只要把技术做极致了就行，产品得不到提醒，公司的商业没有变得更成功，工程师都不用负责任，锅可以甩给产品经理。一款新产品一个新功能做出来，代码可靠从不崩溃，性能优化做足从来不卡顿，界面跟设计师出的图完美吻合，等等等等，工程师就算是优秀的工程师了。如果团队的目标是提升用户留存率，这个技术上完美的新功能发布后留存率不仅仅没有上升还下降了，工程师不需要负责任，考评受罚的只有产品经理。

这种模式的问题是工程师和产品经理目标不一致，更容易产生利益冲突。工程师说「我就是要做这个技术上这么复杂的项目，否则晋升委员会觉得我技术不够不让我晋升」，产品经理说「这个项目消耗你很多时间还不太可能提升产品留存率，同样的时间你可以做好几个有可能提升留存率的功能了。」在极端情况下，这会让双方对立。我在百度时就见过一个例子，只是把工程师换成设计师：设计师说这样设计好，产品经理说那样设计好，双方都只是在利用主观判断说服对方，最后产品经理说「如果做你的设计，KPI 掉了你负责任；如果做我的设计，KPI 掉了我负责任。你想要对 KPI 负责任吗？」设计师立即闭嘴。

考评主要看产品结果的公司，把技术做到极致没用，产品完成指定目标才有用。如果团队的目标还是提升用户留存率，留存率提升了，达到预订目标了，工程师和产品经理（以及其它角色）都能考评过关，远超过预订目标的话还能获得奖励；留存率没有提升，或者是提升不够，工程师和产品经理的考评都会受罚。

工程师不能甩锅给产品经理，两者的目标高度重合。工程师知道，「产品经理指错路」不是借口，产品达不到预订的目标就要受罚。因此 Facebook 的工程师往往非常了解自己在做的产品的指标和数据，他们会花时间去看分析产品数据、阅读用户调研报告，而不是等待产品经理搞明白要做什么了再分配任务。如果工程师坚信产品经理指错路，那就必须自己找到正确的方向然后把结果做出来。没有结果就要受罚，可能是不及格的绩效，可能被炒掉，Facebook 不接受任何解释只看结果。

这种模式可以驱动一个产品团队坐下来好好合作，想方设法利用每一个成员的能力，因为只有这样才能达成目标。如果工程师觉得自己擅长做技术且只喜欢做技术，在这种环境下迟早被炒。所有人都在一条船上，要死一起死。「喜欢做什么」有时候就要给「什么必须要做成」让步，因为做不成船就沉了，大家一起死。

这种模式在自顶而下划分任务的公司不可能成功，只有鼓励自底而上解决问题的公司才能成功。自顶而下的公司，就如同只有船长有权向下发布命令，而且很多时候不需要解释命令的意图，所有船员都觉得自己只要执行命令就好，不需要关注其它人在做什么，不需要理解整艘船是如何运作的。如果船快要撞上冰山了，没有船员会觉得自己有能力和责任阻止船真的撞上去，因为只有船长知道船是怎么运作的，其它人只能无奈的等船沉没。

Facebook 的各级经理都鼓励下属自行定义「什么叫做成功」，如果经理觉得成功定义得合理，就放手让下属自己想办法把事情做成，不需要告诉下属「做什么才能成功」、「如何做才能成功」。如果产品团队主动提出「留存率增长 10% 叫做成功」，只要经理觉得这是对公司合理的贡献，产品团队自己想办法把留存里提升 10%。这样做才能要求产品经理和工程师一起对产品结果负责任，因为「当初是谁定义成功就是留存率增长 10% 的？」

基础架构被视为内部产品

有一些公司会强行在内部推广自己的基础架构。基础架构要进行不向下兼容的升级时，所有内部用户必须派人负责升级。据我所知 Google 就是这样做的，例如说 Google 的某个基础架构服务要从 1.0 升级到 2.0，但它们的 API 是互补兼容的，那用到这个服务的所有团队都必须安排工程师负责更新自己的代码，改为调用 2.0 的 API，否则 1.0 一旦下线这个团队就无法使用这个服务。

Facebook 正好是相反的，基础架构在一定程度是也被看作是产品，只是用户是内部用户而已。那作为产品，当然自己要想办法找到自己的用户，自己要想办法把用户留住，自己想办法扩大用户基数，等等等等。一个新的基础架构出来，没有名气，没有成功案例，必须自己想办法推广和招揽用户。潜在的客户可能说，「你这东西看起来不错，但我不是很确定用了是不是真的对完成我的目标有帮助，我也没空学习和使用你的东西」。遇到这种情况，Facebook 的基础架构团队就跟外面的 SaaS 服务提供商一样，要想办法讨好用户，例如说「没关系，我们团队派专人来帮助你们学习和使用我们的东西，觉得好用的话你们接着自己维护，不好用的话也不浪费你们资源」。

当初 React、React Native 等技术出来时也经历同样的过程，在没有名气之前作者就要想办法推广、说服别人来用自己的东西。外面只看到它们发布时的光环，没看到早期推广的各种困难。2016 年我曾经负责调研 React Native 是否适合用户增长部门使用，因为用户增长主要靠做实验，实验周期受客户端升级周期限制，React Native OTA 升级可以突破客户端升级周期限制。在我做完调研后，我给了大大的一个「NO」，因为 Facebook 主要的用户增长来源自 Android 而当时 React Native 的 Android 版性能（加载速度和内存消耗）实在是不行，和内部其它服务的整合也满地是坑。

基础架构不仅仅新品需要推广，升级也需要推广。「你们出个 2.0 跟 1.0 不兼容？我们一个高级工程师需要花三个月时间改写我们的代码才能兼容 2.0？那我们不升级了。你们准备准备暂停 1.0 的服务？没关系，我们自己出机器，我们自己跑一个 1.0 的实例，反正公司内所有组可以访问所有代码。你们准备把 1.0 代码改得面目全非？我们现在立即 fork 你们的代码！之后我们自行维护一个 1.0 的 fork。」

不向下兼容的基础架构升级往往还是要想方设法讨好已有用户。「你们可以继续用我们的 1.0 服务，但 2.0 性能更好哦。你们组的目标不是转化率吗？你们之前也做过实验，证明了转化率和性能高度相关，提升性能就能提升转化率。我们来算一下，提升这么多性能就能提升这么多的转化率，这绝对值得你们一个高级工程师花三个月来做啦。」工程师既要做销售又要做客服，实在不容易。

既然基础架构被视为内部产品，那产品有的压力基础架构也有。新的基础架构如果在一定时间内无法获得充足的用户，那就很可能被要求终止。已经垄断内部市场的基础架构也不能松懈，如果服务不稳定，内部用户不开心，他们会用脚投票。这些用户团队可能会自己做一个仅适用于他们的服务来取代你的基础架构，也可能有其它人做一个跟你竞争的基础架构然后趁机挖你的用户。

救火比防火更容易获得回报

Facebook 的文化有优点也有缺点。因为公司非常数据驱动，考评倾向于用数据说话，没有数据等于没有干活，完全不看你有没有苦劳，这导致防御性措施很难吸引人去做，因为成功阻止了坏事发生时你没办法收集数据说你成功阻止了多少件坏事、它们可能有多坏。

喜欢写测试的工程师进入 Facebook 往往会因为多写测试而受到惩罚。「你能证明这些测试实际带来的好处吗？你能量化这些好处吗？不能的话你还不如去做新功能，至少新功能能帮助提升产品指标。」不能量化的事情在 Facebook 是很难吸引人去做的。很多工程师技术非常好，但用数据讲故事的能力不行，这种事情就没办法做。

懂得用数据讲故事的话，好像测试这种不能直接量化的东西，可以找参考数据间接量化。「我们分析了去年的每一次事故并且确定其中 n 次是可以被测试防范的，考虑到今年我们团队多了 50% 的人，如果有测试的话我们今年可以防范了 1.5n 次事故。」如果经理认同这种推理的话，你就可以安心写测试了。（如果真的有人明年回来分析今年的事故的话，你最好能证明其中没有一次事故能被测试防范。」）

这种间接量化还是必须等坏事发生过了才能使用，如果你在坏事尚未发生之前就成功阻止了这一类坏事的发生，你没办法证明你工作的价值。这就导致了一个很不好的现象，我往往用以下的比喻来解释：

假想你是一个小镇的消防队队长，你四处去检查镇上有没有违反消防规范的地方，有你就叫负责人整改。这个小镇上所有人都狠你，见到你来检查消防就叫你滚，因为你给大家制造麻烦而没人觉得这些麻烦带来了任何好处。小镇的商户联合起来说每年这百分之几的成本都是你造成的，没有你的话就能有更高的利润。

在消防队队长这个职位上，你只能默默地等待火灾发生。一个房子烧着了你还不要着急去救，救了大家就会说「火灾的损失也很有限嘛，不知道花那么高的代价去防火」。你利用这个时间着手准备灭一场大火。等房子烧了一片了，小镇居民在路上奔跑呼喊了，你就去救火吧。（当然这一切的前提都是你真的有能力救火。）之后你要颁布什么新的消防规范，所有居民都会主动配合。

这就是为什么 Facebook 内部那么多问题处于起火状态，因为不起火就没有救火英雄。