关于远程工作的微观视角

2020 注定不会平凡。

自从年初的黑天鹅事件以来，大量的公司和个人不管愿不愿意，在开年之后都选择了远程开工。与之相伴，那些先行者也都纷纷撰文分享经验，朋友圈和微信群中远程办公也成了热门词汇。看过这些文章之后，想想我们也已经采用远程工作的方式好几年了，于是不能免俗，也想谈谈我个人的一些看法。

就目前所看的文章，大多可以归为工具介绍和企业文化两大类，我比较喜欢其中的两篇文章，分别来自于 PingCAP 和左耳朵耗子（他们的远程团队协作协议令人拍案叫绝！）。而我既不打算重复他人，也没打算去讲太宏大的话题，所以就这些年的微观实践谈谈个人的感受。

本文会从以下几个方面展开讨论，并且讨论的工作类型涉及软件开发，至于其他工种和行业由于没有涉足也就不冒充“砖家”了。

• 工程实践

• 交流沟通

• 团队关系

没有好的工程实践，远程工作将困难重重。

远程工作的内涵绝不是在一台安装了远程工具的机器上办公那么简单。从结果上来看，它仍然和在办公室里办公没有什么分别：组织一帮人完成一件事。只不过由于地理上的分散性，它会将一些原来在本地可以容忍的问题给放大了，进而造成问题。

设想一下，对于连基本版本控制都没有的公司（不要笑，这不在少数），它怎么可能组织有效地远程开发？要是在办公室里，还能通过开发人员相互之间互拷文件（高级一点的利用共享文件夹）来对付一下，可一旦出了办公室的门，其困难可想而知。

在我看来，不少好的软件开发工程实践具有天然的“地理无关性”（结对编程可能会有影响，但现在也有工具支持），比如每日立会、issue tracking、版本控制、自动化测试、持续集成等等。只注重工具而不关心具体实践，将适得其反，期望越大失望越大。

除了上面讲到的日常开发实践，另一类工程实践问题会因为远程工作而显得格外刺眼：安全。典型比如：开发服务器的安全和代码本身的安全。前者本质上跟产品服务器的管理没有太大差异，只是因为不少公司的开发服务器就是简单的本地一台机器，外面根本访问不了，一旦远程就傻眼了，但这个问题并不是本文要考虑的。至于代码安全，我之前曾在一篇代码管理的文章中有过说明，这里也就不再赘述。

关于工程实践的文章和书籍，外面已经有很多了，这里也不打算展开。只提醒两点：

• 实践采用非一日之功，一开始必然经历一个混乱的调整期（产出甚至可能下降），请调整心态制定合理预期和目标，坚持下去。

• 自艾自怜没有意义，不妨将此次事件视为一次 chaos 工程挑战，积极看待暴露出的问题，逐一分析原因进行调整。

远程工作，有效地交流和沟通至关重要。

为什么我特别喜欢左耳朵耗子他们的远程团队协作协议？因为它本质上跟网络通信协议就是一码事，只不过构成这个网络节点的是人而不是机器。虽然节点由机器换成了人，但问题却是相似的：

• 响应会有延时

• 节点可能失效

• 异步沟通为主

• ……

要是没有一个这样显式的协议约定，协作起来还真是麻烦。就我个人的经验有以下几条：

• 必须保证每日例会，它就像一个心跳，保证大家对事情和现状的了解在同一个水平面上。关于每日例会，可直接挪用 scrum 中的那三个问题：

• 昨天干了什么？

• 今天准备做什么？

• 阻碍进度的障碍在哪里？

• 人的时间成本都很高，不要开无效会议，可考虑的措施：

• 做足会前准备，比如提早将大纲或要讨论的内容提前发出。

• 只有相关人员参会。

• 会上尽量不跑题，比如：不要在每日例会上就一个问题进入讨论，只需了解情况，散会之后另外单独组织会议进行探讨。

• 设定沟通的优先级：哪些直接电话、哪些利用 im 工具即可、哪些采用邮件。同时，尽量在一次沟通上下文中把事情交代清楚，避免来回引用和翻查历史。

• 注意邮件书写和礼仪，请自行翻阅相关文章，外面有很多资料已经言及。当年在 SAP 时，也有专门培训过，可见其重要性。

• 自动化固然关键（如 ci 失败邮件），但也要有主动告知他人自己工作状态的习惯，比如你负责的 issue 当前状态需要及时更新。

• 有些工具做得非常好，比如，gitlab 可以在 commit log 中指定关联的 issue 号，并辅以相应的关键字（如 fix ）达到自动关闭的效果。

• 遵循约定成俗的习惯，节约大家的时间，比如：

• git commit log 的格式可以直接照搬 angular 社区的做法

• 引入代码分析工具强制要求，java 社区有很多，这里就不再重复

• 建立上下班机制，不要理所应当地把远程办公（尤其是那些在家办公的团队成员）当做随唤随到的免费劳力。

• 注：在我看来，在不在家办公更多的是一种仪式感，用以作为上班和下班的开关。

类似的经验可以总结很多，不管是定期会议总结还是项目复盘，将这些记录归类，能自动化的自动化，能改进的改进，坚持下去总会有效果。同时，这些要求除了可以帮助团队现有人员，对于新成员的快速融入也大有裨益。

远程团队不等于没有团队关系

远程团队跟同一办公室内的团队没有区别，都是由活生生的人组成的，因此同样要注意他们的情感或情绪，因为这些都会对协作产生影响：正面或负面。但由于很少见面，所以很难第一时间掌握团队成员的心理状态。同时，远程工作也容易产生孤独感，进而产生一些负面情绪，这一点也需要考虑在内。

面对这些，作为团队带头人，可以考虑采取的措施：

• 建立闲聊机制，不论是吹水群、开会前闲聊时光，或是线上聚会，需要提供一个这样的环境来模拟类似办公室的氛围。不能让人觉得上来只有工作，而且通过这种方式也有助于建立私人关系，这对于团队成员的心理健康也是有帮助的。

• 鼓励同一城市成员的定期聚会，可以提供必要的资金支持，本质上而言，这就是所谓的“士气基金”。

• 每年定期全员聚会，比如我朋友拆叔他们公司（odd-e）就有类似的举措，这种形式的聚会让人不再觉得合作的同事只是线上的一个“图标”、一个电话号码或一个邮件地址，而是活生生的人。对于加强团队的亲密感和凝聚力非常有益。

• 关注团队成员社交媒体上的发言，有助于了解他们当前的心理状况，如有必要可以在线上 one-on-one 。

• 注：这里可不是鼓励成为“窥私狂”哟！

• 鼓励团队成员参加本地社区，定期参与线下聚会。既有助于心理健康，还能锻炼能力，并且还客观上可以宣传公司，三全其美。类似的，如果有条件，也可以资助参加付费行业会议或培训，不能因为远程员工而区别对待。

• 注：有些公司担心鼓励员工参与社区活动或对员工进行投资会让他们流失掉，这种其实是一种短视的想法。（这里不展开讨论，否则又要加入 xxx 字了。）

对于全员都是远程的公司或团队来讲，应该很早就会关注远程团队的建设；而对于部分远程的公司来讲，核心点就是避免让远程员工觉得被区别对待或是二等公民。

总的思想很简单：远程团队也是人。

写在最后

归根结底，都是人的问题。

靠谱的人，即使面对困难也会主动挑战和解决，因此是否远程并不关键；不靠谱的人，即使在同一个屋檐下也会消极怠工，远程与否结果相同，区别在于多了一个借口。因此，尽量找到那些靠谱的人，将他们收罗于旗下。

往期推荐

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。