你好,我是葛俊。今天,我来和你聊聊,Facebook 工程师文化的第二大支柱:拥有信息和权限。

在上一篇文章中,我与你介绍了 Facebook 通过在入职、日常工作、转岗中的一些实践,来提高开发人员对所做工作的兴趣。有了兴趣之后,接下来就是提供空间让大家能够施展拳脚,在自己感兴趣的工作中自由发挥、充分发挥,也就是 Facebook 工程师文化的第二大支柱了。具体来说,第二个支柱包括让员工拥有信息和拥有权限两个子原则。

在我看来,Facebook 在这两个原则上的实践,对国内公司和团队有很大的参考价值。为什么这么说呢?因为我接触到的国内公司管理都相对保守,可以从与 Facebook 的具体实践对比中汲取经验,提升公司整体的研发效能。

在拥有信息方面,国内公司一般过于严格。信息的不透明,会降低员工的主人翁意识,并会因为信息不通畅导致工作效率和有效性的下降。所以,在我看来,国内公司还可以在信息方面做得更透明些。

在权限和信任方面,我接触到的国内公司,大都偏向于不信任的管理方法。这种方法难以让员工有主人翁的感觉,导致公司和员工互不信任。在这种情况下,又怎么期望员工能积极地为公司创造价值呢?

我始终认为,国内的开发人员和硅谷的开发人员一样,都有很强的创造性,能力也没什么大的差别;只要能给他们创造好的环境,提供信息并给予信任,就可以更好地激发他们的内驱力,从而提高公司和团队的研发效能。

接下来,我们就具体看看 Facebook 是怎么做的吧。

让员工拥有信息

作为知识工作者,拥有信息,是我们能够做出正确判断的一个必要条件。但信息的开放具有两面性,如果暴露过多的敏感信息,势必会对公司造成些负面影响。

面对这样一把双刃剑,Facebook 的态度是考虑风险,但并不是一味地避免风险,而是权衡公开信息的利弊,在确保基本安全的前提下尽量实现信息透明化。

接下来,我们一起看三个具体的案例吧。

案例 1:代码的共享

在 Facebook,几乎所有的代码都是全员共享,开发人员可以非常方便地查看这些代码。这,跟国内很多公司的情况差别非常大。

我在和很多国内公司的管理层谈到 Phabricator 时,对方的第一个问题通常就是如何管控代码仓的权限。比如,如何让前端开发人员看不到后端的代码,如何让后端开发人员看不到算法的代码,等等。

但其实,代码的共享可以在开发、调测时节省很多沟通成本,大幅提高效率。比如,某个前端开发人员发现后台 API 返回值不符合预期,就可以自己去查看对应的代码,即使他没能自己找到问题,也可以在和后端开发人员沟通时提供有价值的信息。

但如果他看不到后端代码的话,就只能直接求助于后端开发人员,一方面会浪费后端开发人员的时间(有可能这个问题前端人员就可以解决),另一方面双方的沟通效率也会因为信息不对称而大打折扣。

国内公司大多对代码权限控制得非常严格,这跟国内的 IP 保护不力有直接关系。不过在我看来,国内的代码管理还是太过严格,甚至有些不分青红皂白就对所有代码进行严格控制的情况。这,不但会降低开发人员的工作效率,还会降低团队之间的信任。

所以综合考虑,**我们应该在可能的范围内,尽量放宽对代码的管控,对于那些即使泄露出去也没有太大关系的代码,要放松管控。**这样做风险不大,但收益却可能会很大。

案例 2:看板(Dashboard)

在 Facebook,很多信息都会展示在公司墙上的显示屏上,包括很多业务的实时监控数据,甚至还有少量在其他公司认为比较敏感而不愿意显示给员工的信息,比如某些敏感服务的实时数据。此外,很多团队还会制作自己团队的看板去显示需要关注的信息。

一些敏感数据泄露出去,的确会给公司造成些许负面影响,而且确实曾经出现过信息泄露。所以,有员工就问扎克伯格,为什么要暴露这些信息

扎克伯格的回答是:这些信息泄露确实会造成少量负面的影响,但这些信息可以极大地方便开发人员的日常工作,能够更好给用户提供价值,比如看板上的某一条信息可能在你做某个决策时起到关键作用,所以权衡利弊,我们决定开放这些信息。

这个回答,恰恰佐证了公司认同信息对激发开发人员研发效能的巨大作用。

关于信息开放,在国内比较容易落地的部分是,把可以显示的信息用看板显示出来。比如,线上服务使用情况可以拉近员工与用户的距离,让员工更直观地感受到业务的价值,从而提高工作积极性;又比如,当次发布进展的相关数据,可以让开发人员对当前进展更有掌控感,对交付更有紧迫感。

我们在落地看板展示时,需要注意两个问题:

  1. 一是,不要做给外人看,而是应该用来激励内部员工;
  2. 二是,不要展示个人负面排名,比如 Bug 数,这种公开的负向激励方式,容易降低团队成员的积极性。

案例 3:使用 Wiki 来记录信息

Facebook 在公司内部大量使用 Wiki 来记录信息,很多对流程要求不严格的信息都用 Wiki 来记录,包括部分设计文档、团队成员列表、新员工入职手册、个人笔记,甚至有些团队的 OKR 也在上面。

这样一来,我们在日常工作中遇到问题时,首先就是到内部 Wiki 上查找,而且一般都能找到有用的信息。这就使得绝大部分员工愿意在 Wiki 上添加信息,包括一些笔记、心得等。于是,形成了一个良性循环,Wiki 系统的内容越来越丰富,对开发人员的帮助越来越大。

但,我见到的很多国内公司,很多信息都是口口相传,或者是藏到某些文档里,需要花费大量的时间在查找信息上。

在我看来,在公司内部用内部公开的 Wiki 来记录信息,风险比较小,而且可以大幅提升效能,所以比较容易落地。作为管理者,我们可以考虑建立一个全公司的 Wiki,并采取措施鼓励团队进行知识方面的共享。

这里的一个技巧是,把权限设置为默认公开,对需要进行权限控制的内容再特殊处理收紧权限。这跟默认保密,有需要再特殊处理放开权限的操作相比,看似相差不大,却是在传递支持信息开放的基本态度,效果非常不错。你也可以试试这个方法。

让员工拥有权限

在能做感兴趣的事,又拥有了信息之后,最后一条就是让员工能够拥有权限去做事儿。这里,我也与你分享三个具体的案例吧。

案例 1:对于商业软件,先购买再获取授权

Facebook 对商业软件的态度是,相信每个开发人员会从公司利益出发,权衡一个软件是否需要购买,如果需要可以先斩后奏。具体的案例,你可以回顾下第 1 篇文章中的相关内容。

其实,国内有些公司也已经采用类似方式了,员工可以在一定数额下自行决定是否购买。我在跟这些公司的员工聊到这个政策时,能够明显感觉到他们的开心和对公司的认同感。

一般情况下,员工不会擅自做离谱的决定去购买某一款软件,所以这个操作比较安全,你也可以试试。

案例 2:鼓励代码上的互相贡献

在 Facebook,除了几乎所有的代码对全员公开外,公司还鼓励开发人员互相修改和提高对方的代码。比如,前端开发人员发现后端 API 返回结果不符合预期时,如果他能识别出后端代码的问题,便可以去直接去修复,然后提交一个 PR 给后端开发人员,对方接受之后即可入库。

又比如,你发现某一个产品的某一个功能有 Bug,也可以直接修改,只要通过 PR 和测试,就可以上线。

这在内部工具方面尤其明显,也是 Facebook 的内部工具超级强大的一个重要原因。因为内部工具代码上线的风险比较小,所以很多人在看到工具的问题时,会上手去进行提高,甚至自己开发一些新工具。

一个具体的例子是,Phabricator 在开源之前,很多功能和改进都是非内部工具团队的开发者贡献的(你可以再回顾下第 15 篇文章中的相关内容)。

如果你要落地这个实践的话,我有两个建议:

  1. 一是,先从风险小的代码试点,鼓励互相贡献;
  2. 二是,对这种非本职却对公司有贡献的工作,应该体现在绩效考评中。

案例 3:提供宽松的容错环境

Facebook 对待事故的态度是,更关注吸取经验教训,以及将来如何预防,而不是追责。这样的容错环境,能够让开发人员放开手脚,最大限度地释放自己的创造力和潜能,保证公司的持续快速发展。

在第 33 篇文章中,我提到在持续进步方面,Facebook 提供的宽松容错环境,只要不是故意犯错或者重复犯相同的错,一般不会被追责。Move Fast and Break Things,就是一个有力的证明。

我刚进入 Facebook 时,曾见过一个事故:有一个开发人员错误操作,把公司最大的 SVN 代码仓给搞挂了;公司找来两个 SVN 专家,花了一天半的时间才把整个代码仓恢复。这给公司造成了很大损失,但这个开发人员并没有因此被裁掉。还有些人因为误操作造成线上事故,影响了 Facebook 网站的功能,但只要不是故意犯错或者重复相同的错,也基本不会被追责。

如果你想落地宽松的容错环境这个实践的话,我推荐你尝试 Facebook 的 SEV 复盘。我在国内公司实践过 SEV,效果不错。

你可以再回顾下第 4和第 20篇文章中关于 SEV 的相关内容,以及出现问题之后,到底应不应该追责、应该怎样追责的问题。

“软件先购买再获取授权”“鼓励代码上的互相贡献”,以及“容错文化”三个实践,我都在国内一个 50 开发人员左右的创业公司引入过,效果都还不错。引入时,注意些上面提到的问题就可以了。

Facebook 之外的落地经验

接下来,我再与你分享两个,我在其他公司采取的让团队成员拥有信息和权限的实践吧。

案例 1:促进信息上下流通的实践

在 Facebook,每周五都会举办一个内部的 Q&A,员工可以通过现场或者线上提问的方式,问扎克伯格以及高管们任何问题。扎克伯格和其他高管都非常坦诚,尽量把可以公开的信息都坦诚相告,对公司信息上下流通的效果非常好。

离开 Facebook 之后,我在一个团队内,采用类似 Facebook 的方式进行了 Q&A,使用尽量坦诚的、开放的问答形式,不说套话。这个团队的特点是,执行力很强,但氛围有些沉闷。在坚持了两三次 Q&A 之后,气氛逐渐活跃,大家逐步敢问一些敏感的问题了。

事实证明,开发人员的思维非常活跃,也都很喜欢用活跃的方式进行沟通,以获取到更多的信息。这样做的好处是,加强了员工对公司、对团队的主人翁的精神,进而提高整体的研发效能。

落实 Q&A 还有一个小窍门是,大家可以用匿名写纸条的方式去提问。这个方法,在国内效果更好,很多人更愿意用这种方式去问一些敏感的问题。

案例 2:信息共享的相关实践

这个实践是,我在一个创业公司,采用 Wiki 的方式来推动全公司范围内的信息共享,内容权限默认设置为公开,只有特殊情况才可以设置为只对某些人公开。

落地这个实践,的确是一个长期的过程。我见到,国内很多开发人员,都不太习惯做分享,所以我推行 Wiki 时的两个方法,是坚持和以身作则。

在推广 Wiki 的第一个月,90% 的新内容都是我写的!后来,大家逐渐看到了这种信息共享的好处,也看到了我的坚持,就开始主动向 Wiki 中增加内容。半年后,我的贡献降到了 10%。

小结

今天,我与你分享了 Facebook 工程师文化落地实践的第二大原则,让员工拥有信息和权限。

因为软件开发,是知识性工作,所以拥有信息是高效开发的前提。Facebook 在这方面的实践,包括代码共享、看板和公司范围内公开的 Wiki 等。

而让员工拥有权限和信任,可以让员工以主人翁的感受去施展拳脚,最大限度地激发其内驱力。这方面,Facebook 的实践包括,信任员工进行一定额度下的软件自行采购、鼓励互相贡献代码,以及建设宽松的容错环境等。

从我个人在国内推行文化的实践经验来看,国内大多数软件公司,是适合让员工拥有更多的信息和权限的。而且我也看到,国内越来越多的公司意识到了这一点,在逐渐放开信息和权限,从而提高员工的内驱力和团队的研发效能。

我相信,我们会逐步找到更合适自己环境的平衡点,打造高研发效能的公司。

思考题

信息开放的确会导致信息泄露。今年 10 月份,Facebook 出现了一次 Q&A 被录音并泄露的事件,你知道扎克伯格是怎么处理的吗?你还能想到更好的处理方式吗?

感谢你的收听,欢迎你在评论区给我留言分享你的观点,也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见!