延迟上班别发愁，远程办公抗疫情！

做者 | 黄东旭

本文经受权转载自PingCAP（ID：pingcap2015 ）

责编 | 胡巍巍

2020 年的春节注定是一个不平凡的春节，全国都在抗击新型冠状病毒肺炎。除了不出门，勤洗手，戴口罩之类的常规操做，咱们就在想，在这个大背景下，咱们还可以作哪些事情？

考虑到春节假期临近结束，返程的旅途中可能会加大传染的几率，延长隔离时间、远程在家办公也许是普通群众能给国家在这场战役中作的最大贡献。

然而在咱们国家，暂且不论别的行业，至少咱们所在的高科技行业尚未普及远程办公的文化，因此咱们在此将 PingCAP 实践了近五年的工程师远程办公经验介绍给你们。

本文将尽可能少描述理念，而更多的从实践方面讲述咱们的落地经验，以期在这样的一个特殊的时刻帮助更多的朋友和公司尽快行动起来，为国家为社会贡献一份咱们微薄的力量。

咱们已经经过实践证实，在这个时代，至少对于相似软件工程这样的主要以脑力和创意为主的工做，已经有足够的方法论和基础设施，让远程工做的效率不比传统模式差，有时候甚至能有更好的产出（相信已经有同窗想起了早上拥挤的交通对心情和思惟的反作用）。下面咱们聊聊一些具体落地的经验。

 

远程办公的管理哲学

 

远程办公在国外并非一件新鲜的事情。在硅谷，尤为是新一代的科技公司几乎都有远程工做的基因，这背后有不少缘由在这篇文章中就不展开了，若是感兴趣的朋友能够看看来自 37 Signals 的 David Heinemeier Hansson 的《Remote》一书。

对于咱们来讲，PingCAP 从公司创建之初就开始践行这个文化，主要出于这几点缘由：一方面包括我在内的几位联合创始人都是工程师出身，自己对于效率比较有追求，自由的工做形式可以提升咱们的工做效率，同时咱们痛恨低效形式主义；另外一方面，对于一个初创的公司来讲，咱们不但愿人才由于地域的限制而不能加入咱们。

一个很好的例子是咱们的首席架构师 siddontang，也是咱们招聘的第一位员工，由于家庭缘由不但愿来北京，过去的几年一直都在珠海的家里远程工做（这篇 blog 详细描述了他的亲身经历：https://github.com/siddontang/blog/blob/master/2016/my-remote-work.md）。

另一个很是重要的缘由是咱们的员工是全球分布，基于开源的开发模式，因此一开始就注入了远程工做的基因。

软件工程是一项以脑力为主要资源开展的工做，在现在高度发达的互联网技术支撑下，实际上是自然适合远程工做的，可是咱们为何大多数时候以为远程工做不如集中工做效率高？

除了远程带来的沟通协做障碍外，咱们认为其实最根本的差别仍是在管理哲学上，是倾向于传统监管的管理思惟仍是自驱的管理思惟，在 PingCAP，咱们在企业文化上一直倡导的是后者。

为此，咱们须要创建一个强大的愿景驱动力，并落实在咱们的各类细节中，同时尽量为同事们营造自由、开放、分享的工做氛围。

幸运的是，这也和咱们从事的开源领域的工做方向完美契合。举个例子，在 PingCAP 咱们历来不进行任何形式的打卡，每周五咱们都有例行可是议题不限的员工 TGIF 分享 ，任何一位同事都有机会站在台上分享本身的工做成果和心得，甚至咱们发给你们的周边产品都是在设计、选材上一遍一遍的精挑细选，且限量供应，以期让每个小伙伴感觉到温暖和尊重。

这一切的工做看似和咱们的远程办公没有直接关系，可是实际上让咱们一点一点地变成了一个脱离形式、高于形式而存在的强大的远程组织。

 

目标和计划管理

 

若是问一个问题，对于工程师团队来讲，何时须要沟通最多？我想是制定计划和目标的时候。

软件工程远程办公咱们首先要解决的是咱们要创建远程可操做的更加清晰、高效的目标和计划管理。

从宏观层面说，在 PingCAP 咱们依赖的是 OKR 这个工具进行公司以及团队的目标管理，OKR 是硅谷以及国内的不少互联网公司愈来愈流行的目标管理工具。

通过探索，咱们认为 OKR 是一个比较适合远程工做团队的目标管理工具，由于 OKR 相比 KPI 来讲，首先更增强调由团队成员共同制定团队目标，这样带来的好处是易于让整个团队就目标和关键结果达成共识，始终保持团队的目标导向一致。

其次可以让团队成员更加明白作手头上的事情对于团队以及对于公司的意义，这一点对于远程团队尤其重要，极大的有利于促进部门与部门、人与人的协做，让团队更加具备总体性。

最后，OKR 还有一个很重要的特色：透明，在咱们的实践中，每一个团队均可以看到别的团队的 OKRs，你们在制定完各自团队的 OKR 后，还须要在公司级别宣布，确保你们都能了解。

从微观层面说，例如一个具体的项目计划制定和执行跟踪，也须要同样的透明。咱们的实践是项目的负责人为每个大的项目创建一个全局的项目「地图」。

力求作到即便是半路加入的同窗，看到这个地图后，就可以清楚的知道如今是什么状况，须要的资源的连接在哪，负责人是谁，风险点在哪。这个对于远程工程团队的管理者来讲更是相当重要。下面是一个例子：

某个项目事项追踪表

当咱们把咱们的目标和计划可以清晰、高效、透明的在整个公司内部制定、发布和管理起来，远程办公已经具有了初步的可操做性。

 

工欲善其事，必先利其器

 

既然咱们这里更多的是讨论实操，咱们接下来重点讲一讲软件工程远程办公环境咱们所使用的工具。

企业文化、目标管理咱们须要相对长时间的工做去逐渐创建，工具的引入则相对快速见效，也就是俗话说的，工欲善其事，必先利其器，使用良好的工具会让事情事半功倍。

PingCAP 的主要产品 TiDB 是一个开源的数据库，咱们研发的主要工做流都是构建在 Github 上面，彻底对社区公开。

因此咱们的工具链也是以 Github 为中心，串联其它的工具，下面是完整的工具列表（这些工具不少都有国内的替代工具，若是公司不像 PingCAP 这种员工全球分布的，能够根据实际需求选择）：

• GitHub：代码托管，公开的 RFC，社区 Issue 反馈，产品发布，Code Review 等。

• Zoom：在线会议。

• Slack：即时通信，机器人消息中枢。

• 微信、企业微信：即时通信（没错，咱们两个都用，但以企业微信为主）。

• 在线文档：文档协做，幻灯片，表格。

• 邮件，日历。

• Confluence：内部的文档，包括已成型的设计文档（如内部的 RFC 文档），Wiki 等。

• Jira：Bug 和 Milestone 跟踪。

• Trello：看板，记录一些重要客户和事件的备忘。

• Jenkins：持续集成，daily build。

这里经过一个小例子介绍一下咱们研发的工做流：

1. 假设咱们须要作一个新功能，从构思开始，可能第一个会使用的工具是在线文档，负责的同事会草拟一个文档，将大体的想法在其中描述，而后经过 Share 的功能，分享给相关的同事，大多数时候这些设计文档都会 share 到全部的工程师都会在的邮件组里，任何人均可以上去评论或者编辑。

2. 文档通过沟通讨论定稿以后（沟通环节我会在下面一节重点介绍），会同步到 Confluence 和 GitHub 中（若是能够公开的话，英文版会发到 GitHub 上）。

3. 接着该项目将被拆分红多个子项目，经过 JIRA 分配到具体的人，完成后直接提交到 GitHub 上，项目的该模块的 Reviewer（也包括 Maintainer）会参与 Code Review，收集到两个 LGTM（Looks good to me） 并经过各类持续集成工具的测试后，最终合并到主干。

修 Bug 的流程也相似，值得一提的是咱们开发了一个 bot，用于同步 GitHub 中来自社区的 Issue 到内部的 JIRA 中。

优秀工程师的创造力是无穷的，尤为在远程工做的背景下，咱们很是鼓励工程师经过自制工具来提高工做的效率。

除了上面提到的 Issue 机器人，咱们的 Chaos 测试（最近已经开源, https://github.com/pingcap/chaos-mesh），CI/CD，甚至包括社交网络上简单的动态舆情监测，都有自动化的工具在作。

还有小伙伴们经过自动化的手段优化本身工做中的一些流程，举几个好玩的例子：disksing 同窗使用 App Script 自动生成本身的周报（http://disksing.com/review-recorder/）；

siddontang 同窗本身写了个小工具 github-cli（https://github.com/siddontang/github-cli）来高效的追踪关注的 Github 项目的动态；

我用 Python 写了一个小脚本，每日收集 Trello 上指定 Board 内的卡片的更新，并给我汇总发邮件……

这样的例子数不胜数，有时候真是很佩服你们想象力和动手能力，咱们很是坚决地鼓励你们作这些事情。

咱们的 IFTTT 机器人在收集说起 TiDB、PingCAP 的推文

由咱们的 bot 同步的 Github Issue

天天下班以前自动生成的当天动态报告

每周周会以前自动生成的 Weekly Report

提早根据模版生成出来的我的周报

提醒你们准备周报的企业微信机器人

SRE 机器人自动 Merge PR 并 Cherry-pick 到 Release 分支

介绍了这么多好玩的东西，其实我想表达的是：对于远程工做来讲，能交给机器作的，尽可能不要人来作，自动化是相当重要的。

尤为对于线上的协做来讲，多一我的的参与就意味着多一份沟通成本。我对于工程师团队选择开发相关的效率工具，有几个建议：

1. 选择有开放 API 的工具，方便写 bot，造成协同效应。

2. 切忌讳过多过杂，选择几个好用的，将其用透。

3. 使用 Slack 之类的 IM 做为各类工具的 Message Hub，尽量作到在一个地方就能一目了然事情的状态。

另外就像上面提到的，因为咱们也有一些海外的同事、客户以及海外社区沟通的需求，因此主要选用的工具基本都是国际上比较通用的，若是大家公司的业务都在国内的话，这些工具基本均可以找到国内的或者私有部署的替代方案，例如 ONES，Tower，Gitlab 等。

 

对远程友好的沟通和协做机制

 

若是说上面聊的工具只是基础的话，那么远程工做最大的挑战就是沟通了。对于一个成熟的团队来讲良好的沟通必定是必不可少的，甚至沟通的品质决定了作事情的品质。

并非说由于远程工做由于条件约束，就少沟通甚至不沟通了，相反的，在这种环境下咱们的沟通可能会更多更细致，只是形式并不只仅限于面对面的会议这种形式而已。

在聊咱们的沟通实践以前，我想先聊聊沟通的意义，首先我认为沟通最重要的意义在于：信息拉平。

对于一个远程的团队来讲，用大白话来讲也就是：你们须要互相都知道本身该干吗，团队正在干吗以及该干吗。

这件事情在不少公司是经过大大小小的会议，或者甚至吼一嗓子完成的。可是在一个远程的团队中，沟通这件事情须要作得更加的透明。

即便是远程，大部分时候会议仍然是最高效的信息拉平方式，相似 Zoom 这样的视频会议工具已经提供了很好的平台，并且智能手机和移动互联网的普及也让会议的参与变得更加的便捷。

这里多提一句，PingCAP 是 Zoom 的重度用户（也是企业客户），Zoom 的用户体验真的很是棒，咱们即便是全公司级别的会议，也都是经过 Zoom 完成的（昨天刚得知一个使人振奋的消息，也给 Zoom 作个友情广告，目前国内用户访问 zoom.com.cn 能够免费不限时长使用，直到疫情获得有效控制之日）。

在 PingCAP 从形式上来讲，由于会议基本都会有远程的同窗参与，因此默认都是线上会议。

从内容上来讲，大概有两种会议，一种是例会，一种是具体业务的沟通会。相信和别的公司也没什么不同，我这里聊聊咱们以为比较好的一些实践：

在 PingCAP 各个团队（包括虚拟团队）大大小小必定都会有例会，一般以周为单位，有些比较重要且紧急的项目会以天为单位，会议的时间和长度也不必定。周会是一个很好的机会能让团队成员互相了解你们在干吗，对于 Manager 也能很好的知道方向有没有歪，进度是否正常。

另一点，分享一些关于会议的实践：

1. 对于相似例会这种偏信息拉平的会议，Manager 最好不要直接在这类会议上作决策。由于不少信息多是刚接收到立刻作决策不必定是通过深入的思考，另外一方面信息可能不全面，还须要进一步的跨团队沟通。

2. 善用 Calendar。我建议研发团队内部将 Calendar 能够别人可见（这点上财务，商务，高管团队须要酌情考虑），经过订阅和你相关的同事的 Calendar 是一个也是一个很好的信息拉平渠道。

3. 会议前发 Agenda，会议后造成 Meeting notes 发给参会的人，并记录在 Wiki 中。

4. 尽可能少开大会长会。Amazon 的「两个 Pizza 原则」也一样适应于开会（这点提及来简单，其实作起来很困难，尤为在跨团队协做上，咱们也在努力）。

这里说几个咱们亲身经历的坑。由于远程的关系，在 PingCAP 咱们一直以来要求尽量的使用文档进行沟通，咱们确实在早期很严格的践行了，可是那个时候咱们重度依赖在线文档。

因而陷入了一个问题：协同功能很棒， 可是索引功能很弱。因而不少时候就出现了，可能记录某件事情的文档找不到了，或者有多个文档（不少甚至只是讨论稿）在描述同一个事情。

为了解决这个问题，咱们后来引入了 Confluence，用作团队 Wiki，主要起到信息索引和搜索的功能，咱们很是依赖 Confluence，而且玩出了不少花样，这里我只举几个最佳实践的例子：

1. 给每一个团队建立团队的 Page（相似前面提到的「地图」的概念）索引一切和这个团队相关的内容，让新人可以一目了然。例以下面是来自 TiKV 团队的例子：

2. 团队周报和我的周报，每一个团队的周报会一层层的汇总和概括，在每周的高管例会前发出。全部的周报都在 Confluence 里被索引。

3. Logbook，这个是咱们比较有意思的东西，对于一些带有探索性质的工做，例如一些小实验，性能测试，一些特殊场景的优化等等。咱们也会详细的记录下来，造成一个个实验 logbook，这些 logbooks 能够经过关键字被 Confluence 的检索到，一是做为将来实现或者输出成文章的素材，二是防止未来作重复的工做。

在内部协做全面引入 Confluence 后，咱们的文档信息碎片的问题获得了比较大的缓解，惟一美中不足的是 Confluence 的移动端作得实在不尽如人意，但愿 Atlassian 团队将来能改进。 

另外一个坑来自于 IM 工具的选择。这个可能也不是坑，更多的是因为微信平台自己不是为了办公场景设计的带来的问题。

因为咱们多数的国内客户都倾向于使用微信做为沟通的渠道，做为一个 toB 企业，咱们必须去适应这个现实（好比我手机上有几千个微信群），这个问题致使了咱们 IM 沟通的碎片化，而远程工做的环境会进一步放大这个问题。

可能同一件事情，有些同窗看着微信，有些同窗看着 Slack，这就致使了消息不对称。再者微信是一个封闭系统，没有 Open API，很难经过技术的手段同步到一个平台。

另外一个问题是，微信这种用法，工做和生活很难分开，有时候很使人苦恼。这个问题经过引入企业微信获得了必定的缓解，可是由于企业微信又是一个新的 IM，也是一个封闭系统，信息碎片化的问题和海外同事使用习惯上的问题仍然存在。在这个方面，咱们仍然在探索。

 

远程办公环境下的自我管理

 

远程办公还有一个很重要的方面是我的的心理建设和自我管理。这点因人而异，其实不少人不太适合长期 work from home，例如我远程工做的时候必定要从家走出来，去个咖啡厅或者 WeWork 之类的地方才能进入工做状态，可是咱们的首席架构师就能够五年如一日将他家的书房当成办公室。

人无疑是最重要的一环，不过在这篇文章中，我并不想展开太多，有机会再详细聊聊，这篇文章我但愿尽可能关注比较普适的方法。

在远程环境下，须要工做者可以克服孤独感，而且因为没有同事在身边，须要比较强大的自律精神克服倦怠感。

在这点上，我推荐使用一些我的时间管理工具，例如番茄钟，日历等工具。可是和公司选用工具同样，切忌贪多，选择一个用透最好。

另外在生活中也保持一个规律的做息习惯也会颇有帮助，这点在上面引用的 siddontang 那篇博客（https://github.com/siddontang/blog/blob/master/2016/my-remote-work.md）中有很好的阐述。

另一点比较重要的是，不少工程师多是一个比较内向的性格，遇到困难的时候，尤为是在远程的环境下，容易钻牛角尖。

这种状况下，必定切记要主动的求助和沟通，甚至可能须要比面对面的环境下更加频繁的沟通。

对于管理者来讲，要作到这点，须要将任务拆解得足够细，在前期沟通须要反复确认是否和远程工做的同窗达成一致，这个环节须要很是的重视。

 

Online and Offline（线上与线下）

 

PingCAP 并非一个完全的每一个人都远程办公的公司，咱们仍然在各个大城市有咱们的办公室（北京、上海、广州、深圳、成都、杭州、硅谷）。就像上一节说的，远程工做看起来很美，可是可能也并不适合每个人。

人是社会化动物，不少时候咱们仍然须要从线上走到线下，和同事一块儿吃顿饭，聊个天。

由于这点，咱们的解法是：PingCAP 使用远程的工做方式和文化，可是仍然保留着各地的办公室，因此咱们有一个不成文的惯例，当每一个城市的员工超过 4 我的的时候，就能够找个办公室了。

在各地 Office 的运营上，也是比较有 PingCAP 的特点的。不少传统公司的各地子公司一般是定位特殊的办事处，例如销售，测试，研发等。

可是因为咱们的远程办公文化，咱们各地的 Office 其实更像是一个虚拟的组织，也就是说可能同一个团队的同窗会隶属于不一样的 Office，或者反过来，每个分公司均可能会有不一样职能、不一样团队的同窗。

这样是有好处的：

1. 做为一个 toB 公司，咱们国内的客户也主要分布在几个主要城市，在客户当地有分公司能更方便的开展客户支持和市场活动。

2. 在同一个城市的办公室内有不一样部门的同事，有助与构建更多样化且健康的文化，也能更顺畅的进行跨团队合做。

办公室的 Manager 更偏向于当地办公室具体事务和活动的管理和组织，另外每一个 Office 都会有一个行政来处理平常的事务。因此，一般咱们的 Team building 会有几种：

1. 当地 Office 本身会有 TB 的经费，能够本身组织活动。

2. 每当团队出差到同一个地方的时候，组织团队的 TB（固然，咱们大多数是程序员，基本就是吃吃吃）。

这里提到了出差，顺便介绍一下，咱们建议远程研发团队的 Managers 大概一个月须要尽可能和团队的大多数成员 Face to Face 的见一次面，这些行程一般能够和客户拜访安排在一块儿。线下的沟通可让线上的交流更加顺畅。

 

总结

 

总得来讲，远程办公并不是十全十美，像咱们这样的科技公司具有自然的文化和规制土壤，但仍然有不少地方有继续改进的空间，欢迎你们给咱们多提建议。

很高兴在国内远程办公文化还没有普及之时，可以用这么长的篇幅为你们分享一点落地经验。在这个特殊时期，咱们在家不动的同时劳动创造价值，也算是为社会作了点微小的贡献 。

做者简介：黄东旭 PingCAP 联合创始人兼 CTO，资深基础软件工程师，架构师，曾就任于微软亚洲研究院，网易有道及豌豆荚，。擅长分布式系统以及数据库开发，在分布式存储领域有丰富的经验和独到的看法。狂热的开源爱好者以及开源软件做者，表明做品分布式 Redis 缓存方案 Codis，以及分布式关系型数据库 TiDB。2015 年创业，成立 PingCAP，在 PingCAP 的主要工做是从零开始设计并研发开源 NewSQL 数据库 TiDB, 目前 GitHub 上该项目累积 star 数超过 22000+，成为本领域全球顶级的开源项目。