谈谈工程师文化

Facebook最著名的工程师文化之一是bootcamp。每个新入职的员工，不管是应届生，还是老油条，都需要在bootcamp里接受洗礼：

6周的训练，每个人都会有一个mentor，会被分配很多技术任务，mentor和你每周1:1，他会帮你引荐做一件事所需要打交道的人。每个人的任务和正式员工的一样，只不过略简单，且不紧急。这些任务来自各个组，可以切身和各个组的人打交道，review代码，评估和组里的人是否有化学反应，组里人也可以评估你，双向选择。 任务可以来自任何组，mentor也会问喜欢做什么，前端, 后端（c++/java/php），web，mobile HR也会在内网发表high prio（高优先级）的组，一般他们会建议high prio，因为这都是目前快速发展，极端缺人的组。

在这个过程中，员工会发现自己感兴趣的组，而各个组也会寻找他们感兴趣的新员工。每个组的manager会跟新员工pitch这个组的特点，以及为什么你要过来工作（你能从中获得什么）。有点像创业者给VC pitch idea一样，只不过是反过来的。

把这个抽象一下，我们不难寻到这样的工程师文化：

一、将每个工程师的passion，能力和所做的工作连接起来

Simon Sinek说：

working hard for something we don’t care about is called stress; working hard for something we love is called passion.

如果要发挥一个人的最大能力，要想办法让他爱上他所做的事情，或者在最大可能的前提下（与公司的目标align），让他做自己最想做的事情。大部分的公司，人员的选择更多的是单向的，应聘者很难挑选公司内部的团队，而团队和团队见也尽量避免竞争同一个应聘者，以和为贵嘛。在这点上，facebook在bootcamp的过程中，让工程师有机会去选择他感兴趣的团队，便显得弥足珍贵。

「让一个人尽量有机会去做他最想做的事情」的重要性，相比每个人都能理解。

二、组织架构的Inversion of Control

一个组织在不断壮大的过程中，有一个使命必达的中层（大概是从manager到director这个级别）非常重要。中层管理者承上启下，所谓的执行力，基本体现在他们身上。但中层恰恰是最容易出现肖申克救赎里Red口中的insititutionalized，在岁月的磨砺中变得僵化而固守成规。有多少公司，一个团队之所以在哪里，仅仅是因为历史的原因，曾经需要有那么一个团队做某件事而已？而这个团队随着公司的发展，变得不在重要甚至不再有用的情况下，却照样在人离开的时候有replacement，在公司发展的过程中不断有新的headcount？随后一直这样惯性运作下去，直至有天管理层发现财报实在hold不住了，需要裁人来降低cost，一股脑将整个团队好的人不那么好的人一气裁光？

公司和人一样，在发展的过程中需要有新陈代谢。裁员/重组这些都是自上而下的手段，是外科手术，有如刮骨疗毒，或者断臂求生；而新陈代谢，在生物领域统统是自下而上的。让工程师有机会选择他感兴趣的团队，让智力资源在公司内部比较自由的流动，便是一种新陈代谢。然而，这种自下而上的代谢需要组织结构上的手段来保证，这便是Inversion of Control：团队发展所需的资源并非固定可得，而是需要团队的manager去努力吸引别人的加入，努力证明自己团队的价值。

传统意义上manager手上的headcount，是上头拍脑门分发下来的，用不掉会有丢失的风险，所以manager在headcount失效的前夕，就像各部委年底突击花钱一样，即便找到庸才，也凑合要了，否则人「财」两空，这是弊端之一：招可能并不需要的人；因为headcount是从上面分下来的，那自然而然地，跟上面的老板搞好关系（我并不是说跟老板搞好关系不重要），会有助于资源的倾斜。这是弊端之二：上面的老板有了不小的寻租空间。

好的做法是resource planning公司统一，比实际需要略少一些，争不争取到资源，要看团队和manager的功力；而且争取资源的方向从manager的老板变成了新入职的工程师，manager需要反过来向工程师去pitch自己团队的价值和发展方向。

这会给manager制造一种良性的压力：热门的，焦点的团队，能够获得更多新员工的青睐，冷门的团队，如果manager发掘不出来其中的价值所在，可能招不到人。这压着团队在技术上，在marketing能力（非常重要！）上，要不断精进。团队的manager如果能力不足，又不能快速学习，很容易连着整个团队都被边缘化，成为新陈代谢的牺牲品。

继续拿facebook为例，我猜想这两年facebook内部应该有不少团队在做前端的类似react的framework。react起来了，被广泛接受，其实也就宣告了那些团队的死亡。团队里的精英会纷纷出走（到公司内部其他团队），又吸引不来新鲜血液，自然就消失或者转型了。

据说腾讯内部也有类似的机制，小团队自然生长，靠能力争取资源，胜者为王，败者出局。很公平。至少要比所谓的5%强制末位淘汰要公平地多，寻租空间小得多。

公平之外，这种反向的压力能带来急智，间接促成一些创新。因为一个公司里，大部分的产品（或者项目）都是那种显得不太有趣，不在舆论中心的产品（项目）。对此，作为manager，如果你再找不到一个让工程师感觉热血沸腾解决方案（或者问题，或者方向），那么你的团队必然是渐渐边缘化的。很多时候，一个产品功能不那么有趣仅仅是大家没有从中发现一个更广泛的问题，或者更大的内在价值而已 —— 星爷借他人的嘴对自己说就算是一条底裤，一张厕纸，都自有它的用处。manager和团队需要被逼着自我发现和自我实现。

Inversion of Control还带来一个效应，就是：好不好，用户说话，数据说话，而不是向老板汇报的PPT说话。react的成功不在于Zurk说这玩意牛B，而是facebook团队内部自下而上地在他们各自的生产环境里使用react，而外部的react使用规模也是越来越大，几乎所有流行的UI库，都被react component化了。同时，内部/外部的工程师在使用之余，还向其提交大量pull request，形成了一个良性的eco system。这便是真正意义上的成功。而我所见的一些大公司的做得不那么成功的内部项目，都只能靠着上层凭借着自己的权威强推，在一线使用这些工具的工程师即便是如鲠在喉，厌之弃之，声音却传达不上去；更可笑的是，这些不那么优秀的内部项目的团队（及其老板）还能得到嘉奖和高度评价。

『管子』里「夫国有四亡：令求不出谓之灭，出而道留谓之拥，下情求不上通谓之塞，下情上而道止谓之侵」虽然「灭」，「拥」，「塞」，「侵」四个字在讲「法之不立」的严重性，但上情下达，下情上通，说的都是中层的问题。而组织架构上的Inversion of Control，能有效防止这种公司做大之后的僵化，促进资源有效地配置和流动，让公司像肌体一样新陈代谢，自下而上地淘汰不好的东西。

三、拥抱开源文化

几乎每家互联网公司都会号称自己拥抱开源文化，可是大部分公司嘴上说得甜，实际上也就是用了几个开源项目，然后顶多把自己的一些代码公开而已，并非真正理解开源文化。一家公司内部要拥抱开源文化，先得看看这几件事做好了没有：

• 每个团队都有自己的一个或者多个项目或产品（及对应的repo），并对此负责（proud to be the owner）
• 公司内部的每一个人，都能看到任何项目或产品的代码
• 任何团队，如果依赖于其他团队的工作，那么，都会被鼓励直接向那个团队的repo发pull request，提交期望修改的代码

第一点和第二点是第三点的基石，而第三点可以说是开源文化的精髓。在我们日常工作中，经常听到这样的借口：我的feature没做完，是因为依赖X团队的feature，可他们还没做好呢。公司越大，产品线越多，功能之间的依赖关系越复杂，这样的X先生就越多。很多公司把团队切割成若干的平台组（infrastructure team）和产品组（product team），产品组A的一个新功能可能依赖平台组X，Z两个team的功能x1，z2。这两个功能在X，Z的roadmap上属于不那么紧急的功能，还没排上日程。这时候，扯皮的事情就发生了，最后只能escalate到管理者的层面去协调做各种各样的tradeoff，才能让项目推进下去。然而，tradeoff是件可怕的事情，因为有人得，便有人失；而且这样的事情严重依赖管理者的协调谈判能力和手上的筹码，多到一定程度，他们很容易成为系统的瓶颈，且有很多诱因去动用手上的寻租空间。大公司里的所谓文山会海，很多就是在做这样累心累人的沟通协调。如果说来来回回的tradeoff/negotiation引发的文山会海仅仅是拉低了团队的效率，尚可原谅；那tradeoff渐渐演变成了公司政治 —— 里面的寻租空间成为了某些管理者建立山头，打压同僚，向上爬升的利刃，则是非常糟糕的情况，不可饶恕。

反观开源社区，一切事情都是自下而上发生的。每个项目有每个项目的优先级，大家基本是平等的关系，并太不会因为某个人的意志而更改自己的roadmap。比如小明期望他使用的某个组件A提供某个新功能，他并不需要等待A的owner小红实现这个功能，而是在双方沟通一下思路后，小明fork小红的代码，自己实现，然后给小红发一个pull request请求添加这个功能。作为A的owner，小红对于A的理解是最为深刻的，所以她能非常合情合理地提供一些修改意见（比如，做得更通用一些），一来二去之后，功能得到比较好的实现，并成功merge。在这个过程中，小红并未调整自己的优先级，只是作为一个gatekeeper，额外多花一些时间做review（比自己写省事多了！）；小明并不需要花时间等待小红完成这个功能，而是「自己动手，丰衣足食」，让自己的项目得以继续进行。大家得到了双赢。

当然，一个公司内，不是所有的团队间协作都能以这种方式完成。比如产品团队要求平台团队提供更高效的消息分发平台，涉及到architecture层面的改动，这时产品团队可能没有能力或者没有精力去完成这样的改动，那么，协调优先级依旧是优先考虑的事情。

另外，要想达到这个层次的协作，划分产品逻辑，以及设计合适的组织架构就很重要。一个适合于此的组织架构不能是UI一个团队，前端一个团队，后端一个团队，iOS一个团队，android一个团队…这样的组织架构根本无法相互之间像开源软件那样协作，只能互相依赖，等待别人的进度；反之，应该是产品A是一个团队，产品B是一个团队，团队里面配备各种人才，能独立完成各自产品，最好一路从用研，产品设计，功能开发，测试直到部署整个闭环全部涉猎甚至包圆。只有这样的团队才会对所做的事情有ownership，从根子上不太可能互相推诿，互相等待。

如果一家公司工程团队内部的大多数合作关系是这样一种模式，那么可以减轻很多内耗。

上面说的开源文化的三件事其实还隐含很多内容：

• 每个项目要有完善的，高度自动化的流程：UT/CI/codereview/CD/etc. ，如果一个pull request里一些基础的功课没做好，很快就被自动化工具捕捉到了
• 有详尽的文档。至少有：
  • contribution guide告诉别人如何提交代码，要满足什么规范
  • installation guide/getting started告诉别人怎么运行，以及项目的基础知识
• 项目的owner是reactive的，让对方得到反馈的速度非常快（无论是通过工具还是人的反馈）

好。先写这么多。这篇文章多次提到了自下而上的驱动力，我们回过头来看文中所述的工程师文化：

• 将每个工程师的passion，能力和所做的工作连接起来
• 组织架构的Inversion of Control
• 拥抱开源文化

实际上就是在组织结构上和思想上使自下而上的驱动力成为一种可能。我曾经看过一段话，大概是：agile at scale is trust at scale。类似的道理。