为什么 Facebook 使用 Workplace 而 Google 用 G Suite?

钉钉、企业微信、Workplace、Google G Suite、微软 Team 等企业沟通协作工具被密集推出,各大重量级玩家纷纷入场企业沟通协作市场。

仅 10、11 两个月,Facebook、Google、微软就密集发布三款沟通协作工具:Facebook 的 Workplace、Google 的 G Suite、微软的 Team。其实,这三款工具不仅仅是对外的沟通协作工具,巨头们的日常工作也是基于各自推出的工具。

既然如此,我们可以从它们推出的协作工具来『揣测』一下巨头们在日常工作中对沟通协作工具的关注点。 企业沟通协作工具服务于企业信息的流转,让企业的信息更方便的产生、传递、消费。

Workplace

Workplace 号称工作版 Facebook,与 Facebook 非常像,Facebook 的用户上手没有任何困难,有时候甚至无法区分这两者。在形式上相比 Email、Docs 更像是曾经的 Yammer。

G Suite

Google Apps 改名为 G Suite,改进其实并不大,沟通协作这块还是 Gmail/Inbox 和 Google Docs。

据说 Facebook 的员工日常工作时大部分时间都在用 Workplace,邮件等用得非常少。而 Google 虽然有企业 Google Plus 和 Hangout,但是邮件(组)是日常工作的重点,其他的工具只是辅助。

这两个公司在企业沟通协作工具的选择上有着巨大的差异。 造成这种差异的原因是多种多样的。 本文尝试从文化的角度分析。

文化

笔者没有去过 Google,仅是从一些介绍 Google 的文章里获得一些关于 Google 企业文化的信息,对其文化理解比较肤浅。

从Google的单代码库模式看Google工程文化一文中提到了 Google 在研发工程上的『文化』,这里摘录两段内容,一段是关于制度的,一段是感慨:

制度一:严格的 Code Review

前面说过,Google 的工程文化是开放、协作的。但如果没有严格的代码评审制度,开放带来的就不是好处了,而是灾难。事实上,Google的代码评审严格到有时让人觉得苛刻的境界,与大多数其它公司的“代码评审”有很多本质上的不同:

  1. 未经评审的代码无法被提交到代码仓库。

    非常多的公司和团队是没有代码评审制度的,或者团队有代码评审制度,但所使用的代码仓库和 code review 工具却通常不是有机结合的整体,不能从技术上保证只有通过评审的代码才能被提交入库,久而久之代码评审容易半途而废或者『做不做看心情』。在 Google,系统保证了只有经过 Critique 评审通过的代码才能被提交进代码仓库 Piper。整个 Google 的代码库是树状目录结构,根节点下是各个大产品、基础模块的目录,下面又分各子模块目录,依此类推。 每个目录都有几个『owners』,通常是相应产品或模块的 Tech Lead 或者资深开发人员,所有发生在这个目录下的更改必须在 Critique 中发送给他们进行 review。一次更改通常会因为评审来来回回修改多次,直到 owners 在 Critique 中 LGTM(『looks good to me』,是 Google 的文化之一)方能提交。 惟其如此,单代码库下跨团队、跨项目开发协作的安全性才有所保障,开放的工程文化才能在无边界的代码库中驰骋。

感触

说了这么多,其实 Google 的单代码库模式只是冰山一角,这背后是 Google 工程的一整套制度与文化。在这套制度与文化的土壤之上,团队与团队之间可以近乎无边界的协作,同时保持稳定、有序和坚如磐石的工程质量。这套制度与文化是如此的与众不同,正像 Google 两位创始人在IPO时说的『Google is not a conventional company, we do not intend to become one』。这就不得不让笔者感叹,也让笔者敬仰逐步奠定这套体系的 Google 工程师先贤们。有时,这竟让笔者联想到美国开国制宪的先贤们是如何在美洲大陆上奠定了一个与众不同又长盛不衰的国家。

然而正如所有制度与文化都有其对应的土壤,Google 的制度要学习也未必就是那么容易的。就以最简单的单元测试为例:Google 的工程师都有这个感触,每次花在写单元测试上的时间几乎总是和写『生产性』代码的时间差不多,有些时候甚至还超出不少。再算上 code review 一般来来回回三四趟的时间,在 Google 开发一行『生产性』代码用的时间可能是『写完逻辑就提交』公司的几倍。 这在大多数公司可能就是冒天下之大不韪了,因为在同一家公司里通常很难通过对比去证明上线前用于工程质量的确定性时间投入会比上线后遇到 bug 和解决问题所需的可能性时间投入要少。 所以大家通常的选择是避免确定性的投入,习以为常的是『先尽快上线,有问题在线上去发现和解决』的工作方式。

从上文可以看出 Google 对研发工程质量是非常重视的。做过 code review 的人都了解,这个过程基本是来来回回在系统上进行对话,与 Email 这种场景非常像,事实上,在 GitHub 诞生之前,很多开源软件就是采用邮件列表进行 code review 的。

另外,Google 喜欢使用搜索来解决问题,下文摘录了他们在研发工程上使用搜索手段来解决工程问题。

Google 把所有项目(除了个别开源项目外)放在一个代码库中,那么这个代码库有多大呢? 看看中提供的数字(这还只是截至 2015 年 1 月的):

  • 9 百万个代码文件

  • 20 亿行代码

  • 共 3500 万次提交,工作日日均提交 4 万次

  • 所有数据 86 TB

如此巨大的规模,必须有相应的配套设施和制度才能玩得转:

……

设施三:代码浏览与检索系统 CodeSearch

与通常的代码仓库一样,CodeSearch 提供了一个代码仓库的 Web 访问界面。除此之外还提供了语法解析和索引功能,支持正则表达式搜索和类似IDE中的点击跳转到定义功能, 给工程师们在庞大的代码库中寻找需要的信息提供了有力的支持。另外还支持在 Web 界面上对代码进行评论、吐槽:)

因此在内部沟通协作工具上,也体现了它们的这些文化:重视质量,注意积累,异步沟通,通过搜索来解决问题等

而 Facebook 恰恰相反,早期的企业文化中有一句『Move fast and break things』,快速行动,允许犯错,这种文化和 Google 极大重视工程质量的文化是不同的。不过,Facebook 在后期经历了一系列了事故之后把后面一句划掉了,只保留了『Move fast』。 但是这种文化对公司内部沟通协作还是有比较大的影响,邮件这种沟通方式确实是有点太重了。 有时候我只是想快速地表达出一个小想法,但是实在是不想整理出一封逻辑完备的邮件发出来抄送大家;

Facebook 的文化是开放透明、关注个人及影响力、极客快速,这也是为什么它的员工会在日常工作中使用 Workplace 这种沟通协作工具。

Google 的 Google Plus 和 Workplace 非常像,但是在 Google 内部用不起来的一个原因可能也与文化有关系。

results matching ""

    No results matching ""