PDF《你真的懂企业服务么？》

4 2. 一对一 3. 一对多 4. 多对多 受众多少体现了一个信息的价值,如果一个信息其受众是全员,那它的送达率会受到关注, 而一个信息受众是一个人,可能大家会对它的送达效率有兴趣. Table 1. 信息类型 信息类型 产生 送达 消费 服务 合同、法律文 书 法务、HR、采 购等 传真、Email、 快递 合同管理 商机、销售线 索 购买、抓取、 电邮、推广活 动 下达、分配 跟进,售卖 CRM 文档 撰写 检索、查找 阅读 Wiki、Google Docs 任务、协作 项目会、站立 会、任务分配 邮件、IM、工具get things done IM、项目管理 工具、KPI 绩效 考核 邮件、系统 升职加薪 eHR 招聘 简历 邮件 入职 招聘系统 公告、红头文 件 下发 下发 领悟精神 你真的懂企业服务么?

5 为什么 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的代码评审严格到有时让人觉得苛刻的境界, 与大多数其它公司的 代码评审 有很多本质上的不同: 为什么 Facebook 使用 Workplace 而 Google 用 G Suite?

6 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 把所有项目(除了个别开源项目外)放在一个代码库中,那么这个代码库有多大呢? 看看中提供的数字(这还只是截至