远程办公绝非远程监控，究竟什么才是关键？

无论是全程视频在线的办公规定，还是例会、日报的双重汇报制度，都在保证居家工作气氛、团队信息同步的同时，向团队传递了一些带有怀疑和监督色彩的心理暗示信号，让团队士气莫名的消沉、研发效能不可避免的降低。更不用提，在远程办公的场景中，上述机制常常力有未逮，那些平时会“偷懒”的员工，现在还是会“偷懒”。 有鉴于此，在 2 月 13 日的「鲲鹏说」线上直播节目中， Eolinker CEO 刘昊臻为大家分享了一套“特别”的管理方法，让监督更少，自由更多，管理者的注意力更集中，团队的效能也更加高涨，快来看看他是怎么做的吧。 注：本文为「鲲鹏说」线上直播内容整理，不代表 TGO 鲲鹏会观点。

大家好，我是 Eolinker 的 CEO 刘昊臻。

今天，我为大家分享的主题是：「远程团队的时间管理和研发管理」。其实在之前的直播（TGO 「鲲鹏说」）里，各位老师也讲了很多与研发管理相关的内容。那么今天，我可能会讲得更细、更偏实操，比如“如何做好以 API 为核心的研发管理”、“远程团队如何做好时间管理”等。

其实从 2017 年 Eolinker 成立到现在，我们就面临着远程办公的问题。

原因之一是我们的客户来自于全国各地，但公司产品和研发部在广州。我们产品团队很难为了跟小型客户演示一个 SaaS 产品在全国各地飞来飞去。因此线上沟通是一个良好的替代方式。截止到今天，大概 95% 的 SaaS 客户都没有与我们在线下见过面（本地化部署除外）。

原因之二是公司的技术基因深种，研发人员占团队总人数 80% 以上。这意味着，团队 80% 的成员日常从事着高强度的脑力劳动。这样看来，到公司上班既需要支付通勤的时间成本，还要被嘈杂的办公环境扰乱思路。我们讨厌像菜市场一样嘈杂的开放办公环境，因此远程办公就成为了自然而然的选择。

所以，面对这次疫情来袭， Eolinker 顺水推舟地就开始了全员的远程办公。恰好，我们自己的产品就涉及到整个 API 生命周期的管理流程，包括从设计到开发、管理、协作、对接、测试、自动化测试等流程，对远程协作非常有帮助，让我们 3-5 天就可以完成一个新版本的迭代上线。

总结下来，要顺利、高效的完成远程办公场景下的时间管理与研发管理，我们第一个要探讨的问题，就是 「如何打造“高效且自由”的研发团队」。

一、打造高效且自由的研发团队

高效和自由，听起来比较矛盾。有些人只有被拘束时才会高效，自由起来就会比较懒散。所以我们应该考虑一下，如何将高效和自由融合在一起。

我做过很久的技术开发，做过 CTO，之前也是一个自由平面设计师，现在在公司内主要负责产品设计。做过的工作种类较多，但基本上都属于知识劳动。做知识劳动不是单纯地做复制粘贴，也不是说去 GitHub 上找一个开源代码拷贝下来，改改就能用了。

更多时候，知识劳动者是用智力去解决实际生产中遇到的比较困难的问题。对于许多传统企业出身，或是受传统企业管理经验熏陶较多的管理者来说，他们可能会用管理劳动密集型团队的方法，去管理互联网研发团队，提太多日常考核、KPI 等内容。这就会带来一个显著的缺点：团队积极性的降低。

所以很多公司会偶尔组织编程马拉松或是其他形式的 24 小时编程挑战，将团队成员的积极性给刺激起来。许多团队的效率和稳定性之所以会降低，其实是因为管理的规则和团队的属性不吻合。

除此之外，传统办公场景是基于监督机制的，这也会影响团队积极性。 OKR、KPI、日报、周报，所有这些规则，其核心目的就是为了监督员工。 为什么要监督呢？本质是怀疑，怀疑在没有监督的情况下，员工不会认真工作。被监督、被怀疑就已经让员工的工作体验非常差了，放在远程办公的场景下，问题会更大。远程办公是基于信任产生的工作形势，管理者不得不去信任员工，因为远程环境中的员工有太多方法瞒过管理者。

想明白这些关键，让我们再回归到“如何高效地进行远程办公”这个问题，其核心有三点，我们可以用“玩游戏”来类比，便于理解：

• 稳定的工作环境

首先要有稳定的工作环境，这个在线下可以解决，但是远程办公就很难，这也是许多人觉得远程办公效率低下的重要原因。就像一台高配的游戏电脑，是玩好游戏的基础。

如果工作环境太差，在身边有太多干扰项，办公的效率就很难提高。所以我们必须要把办公环境弄好，即使在家也应该保存干净整洁的办公桌，把手机等无关内容调至静音，放一些轻松的纯音乐帮助自己冷静地快速进入工作状态。

• 清晰的工作目标

有了环境，还得知道要做什么。有一个清晰的工作目标，就像游戏中告诉你打败 BOSS 所需的等级和装备要求，有了目标才有追求的动力。

在线下办公会有周围同事和上司监督你，告诉你需要做什么，在一个群体意识浓厚的地方是很容易推动人一起完成某件事的。但是在远程环境下则没有这些监督，因此我们需要通过工具来进行自我管理，实现类似的效果。

• 经常获取有价值的反馈

有价值的反馈就像游戏 BOSS 掉落的装备和通关评分，能够激励团队以饱满的热情继续前进。

线下也比较容易实现这一点，毕竟做得好和不好可以直接从里面上司评价中感受到。远程办公情况下则需要借助工具来实现，比如做了一件事情就需要有反馈，否则就会很无聊。

大家常说远程办公效率低，主要是因为以上三点在线下场景内很容易完成，在线场景就需要特殊的管理技巧或者额外的工具来完成。

刚才说到我们的目标是打造高效且自由的研发团队，接下来我们就来聊聊自由。

自由其实是以高效为前提的，员工可以获得自由，但起码要先完成工作吧？我在公司和研发团队讲：“只要能够按时按量地完成工作，并且不破坏公司的文化氛围（比如不回消息、懒散等），你可以躺在床上工作，甚至可以裸体蹲在马桶上工作，反正我们不会强制要求你打开摄像头。只要能够顺利完成工作目标，怎么工作只是员工的个人隐私。“

这样实践下来，我们的研发团队一开始就拥有了开放的文化氛围，当团队目标制定的足够清晰时，我们甚至不需要固定的早晚会。当然了，这一切的前提是信息足够透明，当团队信息不够透明时，我们也会召开临时会议，及时同步信息。

二、尽量少，但够用的工具

说完了管理理念，我们来说说远程工具，这也是大家比较关心的。

我发现很多公司选用了大量的工具，其实工具越多，学习成本就越高。团队会把更多的时间花在工具学习上，而不是通过工具解决问题上。

所以在通讯工具方面，我们常用就只有企业微信和 QQ，因为我们的客户也是用这两种；在研发管理上面，与代码相关，我们就用 Gitlab；与 API、测试相关的就全部使用自己的产品（Eolinker），还有其他的一些研发相关的工具，但也都是尽量统一。

以下是我们通过 Eolinker 实现的 API 全生命周期管理流程：

至于其他的工具，比如共享文件、日程管理、办公套件等，我们自己搭了一个私有云盘（群晖 NAS），硬盘插个网线就可以用了，上面什么协同办公套件（支持多人同时编辑文档）、日程管理等等的东西都有，大不了在上面自己部署一套 docker 爱装啥装啥，它本质上是个容量大些的 Linux 服务器。私有云盘方便团队远程访问办公资源，里面存放有客户的资料、团队的代码、项目更新文档等所有的信息。

经过长期的实践，我发现只要把工具用好，其实几个工具就够用了。

三、打造“全功能”团队

除了工具的选用之外，努力去打造“全功能”的团队是最重要的。

一些企业受限于历史原因，可能会同时具备产品、研发、测试等部门，架构分的比较散。Eolinker 倾向于全功能小团队作战，即使是比较大的产品也会把团队人数尽量控制在刚好够用。

因为人多的团队和人少的团队的侧重点是不同的：人多的时候会考虑怎么找更多事去填满人力，人少的时候会考虑如何选重要的事情来充分利用时间。灵活的小团队可以承担更灵活的任务安排。

而要打造这样的灵活的全功能团队，关键分为四点：

• 团队成员适当的身兼多职，以便激发积极性

在我们的研发团队中，成员全部都要兼职去做技术客服。只有如此，才能充分了解客户需求，更好地开发代码。

很多技术人其实不太善长沟通，跟电脑打交道太多了，语言能力就有点退化，大家都很宅，觉得解决了技术问题就是解决了客户需求，但实际客户是不是这样想的，他不知道也不敢开口问。最终导致团队内的沟通也很成问题。

通过偶尔的合适的身兼多职的形式，能帮助不擅长沟通的工种锻炼自己的语言能力，不仅提高内部团队沟通效率，对个人的生活也是有帮助的，不会那么压抑。但前提是不能影响本职工作。

• 高度信息透明，减少沟通成本

我认为信息透明包括三个等级：明白自己在做什么、明白别人在做什么、明白自己的工作如何对别人产生帮助。

明确了这三点之后，员工既能明白自己的工作内容，也能知晓该与哪些同事请教工作，还能明了自己的工作价值。

其中第三点尤为重要，这是解决工作矛盾、解决工作动力的很好的途径。

• 提高自动化程度

提高自动化程度需要一定的前期成本，但百利无一害。既能减少重复劳动导致的工作积极性降低，也能减少人工出错的几率。

• 能看 / 写文档的不说话：减少沟通成本，方便回顾历史

我们认为如果一件事情需要讲清楚，通过文档是效率最高的方式。

首先是人的思维逻辑是发散式的，而语言是线性的。让不善言谈的人把发散的思维通过语言表达出来，本身就很困难。

其次是零散的文本（即时通讯记录）以及口头表达（语音）并不适合回溯，绝大部分人根本想不起来上周写的便签是什么意思，也无法在录音里快速查找内容。

文档解决了以上所有的问题，文档不容易有歧义、方便回溯、方便分享、方便查找。

四、远程协作如何协调工作与生活的时间

远程办公的最大难点在于工作环境和工作时间的不统一，因此没办法再使用劳动密集型企业的管理方式。取而代之的，我认为提高团队效能的办法是：目标和价值驱动。

你需要让团队成员了解他的工作目标是什么，在什么时间需要完成，以及达成目标的收益，他自己就会安排时间去完成。

依然以游戏为例：明晚 12 点（时间）需要开个副本打 BOSS（目标），赢了有顶级装备并且在全服有小喇叭公告你的名字（收益）。玩家会自己根据实际情况安排玩的时间。

执行目标和价值驱动有 3 点最重要：目标是什么（target）？完成任务要用多少时间（time）？收益是什么（reward）？

比如团队管理者对团队成员说：这个版本需要明天上线，发布之后就会有客户使用并且愿意付费。这个目标清晰、收益明显的事情会促使团队内的人努力完成工作。

有些人会觉得这样的管理方式会让成员懒散，但为什么部分员工一旦远程办公就会懒散，而其他的不会？

为了理解这种现象，在此可以举个例子；成绩好的学生总是越学越好，因为他们知道学好的价值（父母的奖励，同学的羡慕，老师的夸奖等），并且这个价值可以激发他们的动力。成绩差的总是越学越差，因为学习好对他们来说价值就是考个好分数，而好的分数无法激发他们的动力。

类比企业内的人才激励，有人做过研究：金钱激励往往在一开始有效，但是效用会随着时间急剧下降。后期人才往往更注重个人价值的实现。简单地说就是做起来开心有成就感。

我们作为管理者也应该在此时反思，除了提钱，能否通过管理方式来提高员工的成就感。这样的方式才是长久之计，也是对于企业经营者性价比最高的方式。

但是只要是远程办公，即使是通过目标和价值驱动，偶尔也会导致信息不透明的问题出现。 当团队效率出现下降趋势的时候，我会问成员几个问题：

• 第 1 个问题：你当前在做的工作预计会花费多少时间？

通过此问题我能得到第一个反馈：他觉得自己需要多久完成工作。然后我会根据自己对该成员能力的评估，对该时长进行调整。

• 第 2 个问题：你的工作这么多，哪一项更重要？为什么？产出是什么？

其实这个问题很多人没有想明白。所以这里给大家介绍一个思维方法。

大家可以将每天的工作任务分成 4 个部分：

1、重要且紧急的； 2、重要不紧急的； 3、紧急不重要的； 4、不重要也不紧急的。

如果每天都这样拆分下自己的任务，工作的优先级也就明确了。

关于“产出”，很多人的理解可能不对。在团队协作中，产出最重要的特征是能够被团队复用。

我以前经常问测试团队，做某个功能的测试为什么这么久？测试团队给我的回答是，花一小时了解产品需求，花一小时看文档，花几小时写测试脚本，花几小时调试脚本，最后脚本终于可以跑起来了，花了 5 分钟测完得到报告。

那么从我的角度来看什么是工作的产出呢，其实只有最后 5 分钟得到的测试报告是产出。因为只有这才能够被其他成员使用。至于自己写的测试脚本，如果代码或者 API 内容改变之后还得重写，那这只能算成本而不是产出。

我们不能把做了的事情当作是有用的事情，工作中真正有用的事情其实不多。所以我会跟团队提倡宁愿在动手前先花一半的时间找到聪明的办法，这才有助于长期的工作。

• 第 3 个问题：近期你是否有其他个人安排，可能会导致工作效率降低？

远程办公状态下，每个员工的时间都是碎片化的，就像是一张披萨被分成许多大小不一的碎片，即使在办公室也不能保证一个人一直在做目标工作。远程办公管理的另外一个重点是将成员的时间拼凑起来，把每个人的时间碎片拼成一个团队完整的工作时间段，协调整合团队成员的工作内容和时间，保证高效协作。

以上三个问题都得到答案后，我会召集一个会议，既是为了向其他团队成员同步信息，也是为了统一调整大家的时间和工作安排。

五、聊聊 API 研发管理中的效率损耗

聊完时间管理方面的内容，接下来聊聊 API 研发管理。

通过对我们的客户进行调研，我们发现了一个有趣的现象：许多公司的研发团队用在沟通、测试和 API 管理等事项的时间，和花在写代码上的时间差不多。这让人不禁好奇，在前后端分离、微服务架构的环境和大趋势下，研发团队每天究竟在做什么？

答案是前端、后端、测试等都在围绕 API 接口进行协作，后端人员将需求点变成 API，前端人员使用 API 获取数据和服务，测试人员通过测试 API 来测试后端逻辑，等等。

此时的研发流程如图所示，是一个围绕 API 进行的线性流程：

我们还发现在处理这些与 API 相关的研发工作时，很多问题会接连不断的出现，从而极大的影响研发团队效率：

• API 文档不清晰而不知道怎么对接和测试，需要反复和后端沟通？
• 遇到历史遗留的 API，没有文档只能看代码？
• 前端和测试需要等待 API 开发完成才能继续进行工作？
• API 变更了不及时通知相关人员跟进？改动了哪里也不清楚？
• API 文档和测试是两套系统，来回切换并且无法同步数据？
• API 测试用例无法复用，API 一改就需要重新测试，导致测试时间不足，测试范围不够？
• API 自动化测试需要写脚本，学习成本、时间成本、维护成本高？
• ……

有这么多的问题，效率当然会大受影响。在此我们先回顾一下上文提到的效率三要素：

1. 稳定的工作环境
2. 清晰的工作目标
3. 及时的价值反馈

工作环境无法靠工具解决，但是我们可以通过工具解决上述第 2、3 两点问题。解决的关键在于：文档驱动模式和测试驱动模式。

文档驱动模式

是指在相关人员开发之前先把工作相关的文档写好，放到研发工作中就是：明确功能需求、入参出参定义、异常情况处理等内容。

如果不通过文档驱动，团队沟通的过程一定是混乱的，因为口头语言其实是一种不严谨的表达方式，大脑的思维是一种网状思维，在对话发生时，对话者常常会联想到其他方面；但文档是一种线性思维，从上往下写，从左往右看，方便记忆、传输、存储。

文档驱动解决了效率三要素提到的设定“清晰的工作目标”的问题。如果没有明确的文档，参与沟通的双方经常会混淆需求，导致研发过程走歪路、绕远路。

目前我们公司内部就通过 Eolinker 自动更新文档状态，前端、后端通过文档沟通，研发进程完全由文档驱动：

1. API 文档写好自动通知相关成员审核；
2. API 文档审核完成后通知后端成员开发；
3. API 开发时，前端人员在 API 文档基础上编写 mock API，获取虚拟数据来对接页面；
4. API 开发时，测试人员在 API 文档基础上编写测试用例；
5. 当 API 开发完成，后端成员可以直接一键运行测试人员写好的测试用例并得到测试报告，如果有异常直接 debug；
6. API 出现异常时，直接在 API 文档上发表评论并通知相关人员；
7. API 变更时自动通知相关成员修改前端或者测试用例；
8. API 变更之后可以看到历史版本对比，也可以回滚 API 文档版本。

以上研发流程还会继续进行，值得注意的是，API 文档对测试团队来说也非常重要。测试团队可以通过 API 文档提前参与 API 设计的审核，了解需求，并且在其他成员开发过程中直接基于 API 文档构建测试用例，实现“测试的左移（前移）”，以免测试时间不足。

测试驱动开发

是指在开发前先将测试方案 / 用例写好，只开发能够顺利通过测试的功能，如果测试不通过则持续进行改进。

测试驱动解决了效率三要素提到的“及时的价值反馈”的问题。如果不通过测试驱动，不仅测试的效率很低，开发人员也无法及时获取测试反馈。

测试驱动的结果就是团队的沟通更加充分，每个人的工作进度不会轻易被其他人阻塞。

比如当 API 文档写好时，测试人员就基于 API 文档写测试用例，不需要考虑 API 是否开发完成。当前后端开发完成后，可以自行使用写好的测试用例进行测试，这可以帮助我们节省非常多的测试、沟通与协作成本。

当这两种模式完全建立并开始运行后，我们的研发流程是这样的：

整个研发流程由串行的 N 步流程简化为并行的三步流程，没有任何一位研发人员的时间是被浪费的，这就很好地解决了远程办公团队时间的协调问题。

六、总结

第一，传统办公场景是基于监督的，基于不信任和怀疑。我们不能说它不行或不好，的确很多人会在日常办公中习惯性摸鱼，但在远程环境下就没有办法监督了，这个时候我们只能选择去信任团队。这时，我们不能用体力劳动的规则去评判远程团队。让团队更加高效、更加自由才是管理者应该追求的。

第二，高效是自由的前提。只要能够按时按量完成工作目标，怎么工作只是员工的隐私问题；

第三，与其规定劳动者的劳动时间，不如做好目标驱动。我会经常与我的团队一起分析：要实现需求，哪种方式成本更低？用户体验更好？用全员参与的方式刺激团队的积极性。

第四，研发团队花费在沟通、测试和管理 API 接口的时间和用在项目开发上的时间是差不多的。那么进行 API 的管理和自动化测试，就可以减少大量成本。

第五，根据我们的实践经验，文档驱动和测试驱动两种开发模式十分有益于远程团队效能提升。

我们的内容到这里就结束了，感谢大家的一路陪伴，也感谢「鲲鹏说」这个节目，希望我们能在 TGO 鲲鹏会再次相遇。