用google三大利器提升团队的工作能力

用google三大利器提升团队的工作能力

标签（空格分隔）： 拨云见日

---

什么是谷歌三大利器

其实标题说的高大上，实际上谷歌三大利器就是谷歌的文档、邮件和日程。 这里打算说说这些零软件成本的简单工具，早期对海洋公司运维团队提高效率起到的作用。

在海洋公司运维发展的过程中，谷歌在线的工具在他们日常工作，非常低成本且快速的起到了提高效率的作用。

谷歌工具到底有什么特性能够让海洋公司选择它。

下面是海洋公司在使用中发现的，谷歌工具对运维工作非常有帮助的关键特性：

各个工具好用的特点

• 谷歌文档（doc、ppt、excel）

  • 支持多人同一时间点 同时协同编写同一个文档

  • 支持针对文档进行评论，评论的组织思路类似 issue，讨论形成结果以后，可以标记为已解决。

  • 基于帐号的随时可以授予和收回编辑文档的权限

• 谷歌日历

  • 可以建立多个日程专题，并且共享给指定的人或者邮件组

  • 可以支持标准的日程共享导入

  • 日程的邀请机制简单，需要分发日程的相关文档时能够很容易添加基于谷歌硬盘上的文档

• 谷歌邮件

  • 轻松处理10w级的邮箱

  • 能够轻松在10w级的邮件中进行精确搜索

  • 针对邮件的标签、过滤器、重要性分级功能的支持非常强大

三个工具共有的关键特性

谷歌工具的共有特性，在日常工作中也提高了团队成员的工作效率。

• 搜索的能力很强，依靠工具内部的搜索，可以找到所有相关的文档，准确率很高（这些是谷歌的最强项）。

• 三者是基于浏览器的应用，只要可以上网并且有浏览器的终端就可以使用这些工具。

• 基于统一的谷歌帐号进行管理，同一个谷歌帐号，在任何电脑上都可以看到完全一样的内容，包括各种使用偏好设置与使用记录等数据。

原有工作方式中的一些小场景

初创的前两年，海洋公司主要依靠svn+本地file的方式来共享文件资料，文件的存档和分发依靠邮件附件，偶尔依赖网盘。这使得文档的最新版本经常有一个不算短的时间处于单机状态，这带来两个坏处：1.合作的同事不太容易得到最新版; 2.最新版本文件有丢失的风险。

下面是海洋公司生产中真实碰到的案例，这些是在传统模式中容易碰到的场景。

案例一：

某次线上发生紧急故障（运维经常碰到），晚上11点左右发生，修复的过程需要用到一个关键信息写在某个工程师公司电脑的文档上，而文档没有提交到svn中，只有工程师的电脑上有这份文档，但是线上故障的处理必须依赖那个信息。

最后不得已，他们只能派最快可以到达公司的人专门去公司查看这个文档。最后总结报告看出，总共60分钟的服务中断，10分钟讨论方案，45分钟用于得到这个文档信息，处理问题仅花了5分钟。

在这个案例中，因为信息共享问题，从故障感知到问题修复所花费的时间扩大了很多倍。而且在这个过程中需要额外的运维工程师的工作时间（去公司的人还需要返回），这个工程师第二天的各项工作产出受到较大影响，对团队来说非常不划算。

案例二：

在初创的较长一段时间里，海洋公司的线上报警，主要依赖邮件的方式进行通知。Info级别的报警非常多，需要人工对这些报警进行判断后，才能确认是否为真实报警（这本身是问题，监控章节详述了他们针对这种问题进行的改进）。他们核心线上运维工程师会收到这些Info邮件，每天有3000封以上。突然某一天，一个工程师发现他的邮箱无法正常收发邮件，检查后居然发现，他的邮箱配额空间满了。虽然很细碎的问题，却让这个工程师当天花了很长时间在处理他的邮箱问题上。

他们同时还发现了两个问题：

1. 邮件供应商提供的界面，无法处理10万封级别的邮件。界面上一旦提交这种超大量的删除操作后，界面就会报错。估计是后端job响应超时导致的，最后还提交工单找邮件供应商的工程师额外处理才解决掉这次意外。

2. 而另外有一个工程师抱怨，虽然他的邮箱没满（因为他outlook收下来以后邮箱中会删除），但是他无法使用outlook。每当他搜索邮件的时候就会出现卡死状态，等很久才出结果，而且更关键的是，搜索出来的邮件都不是他要找的。他郁闷的抱怨，无法从邮箱中找到想要的东西，会使他无法正常工作。

案例三：

运维工程师会经常处在碎片化的工作状态下。在改进运维工作方法的过程中，海洋公司发起过一个优化工程师工作时间的项目。当刚开始进行这个项目时，他们发现运维工程师根本不知道自己的时间花到哪里去了，每天只是感觉很忙。无数紧急性的干扰事件，毫无过滤的插队到运维的工作列表中，完全打乱已有的工作安排。

往往工程师白天的工作时间结束时，不得不需要重新安排，确定哪些是需要晚上半夜进行，哪些是需要排进第二天日程。他们在刚开始的时候感觉无从下手，最后决定，第一步需要先知道“工程师的时间去哪了”。

三大利器帮助运维改变工作的模式

传统的基于文件传递的合作方式，在信息传递的过程中产生很多版本，对于可以存档的定稿文件，这种使用方式不会有什么不妥。但对于正在编写中，需要多人一起合作编写的内容，会比较麻烦。边写过程中，参与者经常需要确认当前正在编写的文件“是否是正确”的版本。即使是对的版本，如果其他人也在同时编辑，又需要考虑合并的问题。编写代码的人很容易理解这种问题。

海洋公司一开始通过svn+file传递的方法，团队成员能够勉强合作，但是碰到了效率太低的问题。他们经常需要开会来讨论文档，开完会以后还需要专人整理文档。下一次更新以后，又再次开会，继续确认。他们发现这种会议本身也产生了更多的问题，于是决定要解决这个问题。

他们发现协同能力强大的谷歌工具，能够快速有效的提高他们的工作效率

针对案例一的改变

他们全面使用谷歌文档以后，所有的变更编辑都直接在云端进行。在编写过程中，谷歌工具会高频率的自动保存变更图N.1标识了自动保存的信息)。每个自动保存的时间点都会产生一个版本，使用者甚至可以回退到任何保存点。这就意味着编写人每时每刻都在进行版本提交，理论上达到了一种持续集成的效果，只不过这种持续集成已经融入到软件的使用中，让人无缝的就可以享受到持续集成带来的好处（随时提交，随时修正，随时可回滚，服务不中断）。

这带来的好处就是他们在编写文档时，不会再有未提交到版本库的文档，案例1中半夜需要紧急从家里跑到公司查文档的事情不会再出现了。只要找一台能够上网的电脑，随时可以安全有效（google的双因素认证等可以有效保障）的查到想要的信息，无缝地开始工作。这个改变的代价还蛮低，以前用于版本同步，信息确认的工作全都没有了，在信息共享和获取上花费的时间比原来少了很多，且信息的准确度问题带来的重复工作，也大幅减少了。

图N.1 谷歌文档界面图例

前后对比，他们在工作中编写文档的方式，只是换了一个工具，编写工作量本身没有变化，同时少了文档版本提交与同步的额外动作，工作中自然的实现了文档同步。甚至海洋公司的团队成员因为这种合作方式的顺畅性，变得非常愿意采用组合的方式来分解工作，这是件很酷的事情(找3-5个人，一起写个文档，试试就知道了)。

在他们使用谷歌工具的过程中，谷歌更好的合作编写方式，给团队带来了很多好处。多人同时编写文档时，成员间可以看到其他人的光标处于什么位置，看得到别人正在输入的内容。这种使用模式，在对文档编写没有任何阻断的情况下，就所见即所得地实现了内容的合并。

换句简单的话来说，就是他们坐在各自的电脑前就实现了以前需要开会来完成的沟通。如果是在会议上，有新想法的人，甚至可以直接打开文档，一起来编写这个文档。开会时各自的电脑不再是一个摆设或者是其他工作的干扰，而是围绕会议主题的头脑风暴工具。当会议完成时，文档需要修改的地方已经由参会人共同在文档上完成了编写，剩下的整理工作已经很少了，需要的人可以直接使用文档继续工作，工作会议的产出效率提高了非常多。

下图是一个海洋公司在协同合作案例中使用的谷歌表格图例：

图N.2 团队在协同合作案例中使用的表格

海洋公司在发展的前2年，很多工作没有实现工具自动化。在这个阶段，经常需要在凌晨做各种线上变更，且当时的变更操作步骤往往非常多。由于工作量大而复杂，且不能出错。他们已经无法仅仅由一个运维工程师来进行操作，否则由于疲劳的问题，错误率会非常高。于是他们把工作拆解成了很多个小步骤(steps)，抽调几个不同技能的工程师，共同合作完成这些复杂的步骤(大部分临时开发的数据处理操作)。

在那个阶段，他们的线上架构采用的是类似企业部署的方式，每个用户部署一个实例。线上操作的实例(instance)数量在几千量级，并且每个实例处理的时间可能长达几个小时，甚至某些特别实例会达到20几个小时，这让整个过程变得很长。由多个人员来合作完成的方法，更适合这样的马拉松式的工作。工作小组的成员，通过合作记录图N.2的谷歌表格，能够快速实现多步骤多人员的协同工作，小组成员根据前面步骤的状态，确定什么时候执行后续的动作，不用通过开发的手段，就可以半异步的进行协同工作了。这种方法，在当时取得了非常好的效果。那个时候他们线上的变更次数实在太多，没有时间去完整的开发自动化的程序，这种快速的合作方法，非常适合他们。他们可以分散在各自的住处进行协同合作，而不用所有人都一起在公司等待。如果是那样，他们每天都无法回家睡觉了。他们因为使用了这样的方法，能够让一个复杂的持续工作，分片成很多细碎的工作，由整个团队分担完成。

在整个团队内部，由于谷歌文档使得协同合作变得很快乐，刺激了成员更愿意主动去合作，这种良性循环给团队在合作方面带来了非常正向的促进作用。

针对案例二：全面切换到Gmail

当海洋公司的运维工程师因为邮件太多(5w以上)，无法使用邮箱时，当组内越来越多人因为在邮箱里找不到想要的存档文件或者附件时，当他们每次更换电脑迁移以往接近20G的邮件文件时。他们开始琢磨，有没有办法解决这个“严重”的问题。

他们测试了各种邮件客户端工具，当碰到上面这些场景，都会碰到类似的问题。于是他们开始尝试以数据处理能力强著称的Gmail进行邮件处理。
下面是他们最想要达到的目的：

• 能够有效处理10w封以上邮件

• 能够找到想要的邮件，希望能够搜索附件

• 需要较强的邮件分组功能

• 需要保持工作的平顺性（收件方无感知）

当他们使用了Gmail以后，发现这些需求都可以实现。

Tips-如何达到平顺过渡：
在办公邮件的系统中设置自动转发规则，把所有邮件自动转发到Gmail中，然后在Gmail中设置使用公司自己的SMTP服务器，并设置默认使用公司的SMTP来发送邮件。这样就可以在Gmail中平顺实现公司邮件的收发了。

切换后，他们所有的邮件收发都不在本地处理。Gmail快速以及精准的搜索，很快提高了他们的工作效率。搜索时甚至能够非常准确的定位附件中的内容。再加上灵活的过滤器和邮件重要性分组，使得他们处理邮件的效率提高了非常多。

精准的搜索功能甚至让他们感叹，要是早些切换Gmail，过去的邮件就很容易整理了，天生成了一个快速索引库。他们可以放心的把文档留在邮箱中，再也不用担心需要的时候找不到资料。

同时Gmail强大的数据处理能力，使得处理速度不再是他们的烦恼，快速且超大量的邮件删除或者搜索效率，使他们能够轻松处理10w封以上的邮件，完全感觉不到任何处理的瓶颈。

他们又可以快乐的使用邮件了，这使得他们非常愿意去使用邮件。这很重要，因为这会带来很多主动的动作。

针对案例三的场景，如何用谷歌日程来工作

海洋公司运维团队当时面对的问题是，所有人都感觉自己的时间碎片化了，工作被打断的情况非常多。无法有效专注，每天的工作产出非常低，团队的效能不足。

当他们开始改进工作时，首先想到的方法是，记录工作日志。他们试行了2天，发现日志确实记录了下来了，但是整理分析的工作比较难做。先不论怎么去分析工作安排是否合理，就工作量而言，全团队10个人，仅仅是review全部人员的工作日志，本身就是一个耗时的事情，这个工作的效率比较低，较难取得明显效果。

他们在这个方向上需要一个有效的工具，能够方便的查看到团队成员的时间花费情况，而谷歌日程能够比较方便的支撑这个需求。团队成员每人在谷歌日程上建立了一个work日程，并且把这个work日程共享给团队内其他人，那些与自己工作相关的，以及负责优化工作的同事，就可以看到日程的细节。在优化时间的这个阶段，参与的同事只要在自己的谷歌日程上，记录下自己的工作内容，就可以实现记录工作，为后期优化分析提供数据的目的。

图N.2是一个谷歌日程的界面示例。可以看出日程分成了多个日程，同时部分团队成员的日程也共享了，用以分析优化。

图N.2 谷歌日程与共享示例

在整理工作时间片段的过程中，海洋公司通过谷歌日程便捷的review方式，把早会能达到的工作分享效果，从每天一次的频率变成了时时刻刻随时可以进行的状态。

用这种方法后，分析团队成员的时间占用合理性的工作，变得非常快捷。管理人员更聚焦在时间花费的分析工作上，很快就找到了团队中的几个瓶颈工作，进而快速推进这些瓶颈工作的改进工作。

并且通过这种分析工作，他们还重新安排了工作流程的设置，花费了少量的代价，就提高了工作的效率，使得团队获得了更高的产出能力。

而与此同时，对于团队成员个人来说，通过谷歌日程，同时建立“个人”和“Work”日程，就可以合并自己的工作和生活时间，团队的成员开始把个人的时间来当做资源进行合理的分配。理论上来说，一个人的时间(资源的一种)只有一份，每个人是必须合并工作和生活日程的，否则就会出现无法发现冲突的问题。通过这种统一视图来管理自己的时间，可以合理安排，避免冲突带来的手忙脚乱。

他们利用谷歌日程来安排时间以后，时间的利用率提高了很多。他们发现时间可以更多的来挖掘价值，甚至开始使用番茄工作法等方法，专注在自己一天重要的事情上。团队也因为这样的改变，带来了进步。

小结

海洋公司在通过谷歌工具改变工作方法的过程中发现，其实并不会有一层不变的工具，也不存在一个工具就能解决所有的问题。

对云创业初期的公司来说，采购昂贵的企业工具不见得是最开始需要去做的事情。用什么工具，由想要解决的问题来决定，选择工具时，先要想好，要解决什么问题，以及如何用这个工具去解决。这些都想清楚了，工具的选择才有方向，剩下的就是仔细去探索了，总能找到合适的。