Tetrate.io 是一家北美的企业级 Service Mesh 服务商, 提供基于 Istio, Envoy, SkyWalking 的企业级 Service Mesh 产品: Tetrate Service Bridge.Tetrate.io 创立之初就是以分布式团队, 在家办公为工作模式, 所有成员都不在统一办公地点工作. 目前, 公司团队分布于北美, 欧洲, 中国, 东南亚等多个国家. 本文是对 TVP 吴晟老师的直播演讲整理, 分享在分布式工作模式下, 如何保证高效沟通.「TVP 思享」专栏, 凝结大咖思考, 汇聚专家分享, 收获全新思想, 欢迎长期关注.
一, 分布式工作的背景和难点
1. Tetrate 成立背景
我们公司是在前年成立, 下图所列是最早期的所有的技术团队成员, 涵盖了全球绝大部分的时区, 包括日本, 中国, 印度等.
随着团队人数越来越多, 其中有一些同事, 并不总是固定在一个时区. 例如有的同事有段时间在北美, 其他的时间在日本, 包括我自己每年也会有大量的出差, 会频繁切换自己的时区.
这样可以带来一个好处, 除了大家能够保持一致的协作模式外, 也可以有更多的私人时间, 这是我们公司的经历背景.
其实现在有非常多有名的上市公司, 都在以远程协作的方式来工作, 基本上成了一个西方新进的技术公司一种标准模式. 因为它可以把更多地方的人联合起来, 而且这样的公司会有一个特点, 它们更多使用了开源作为背景.
如果大家熟悉开源或者了解过开源社区的状态的话, 会发现开源协作即使是在同一个时区, 因为大家还有其他的工作, 能抽出的时间不一样, 它也是一个极度分散的时间. 有人是早上有时间, 有人是晚上, 或者有人最近在其他的国家, 这是全球化协作的难点.
2. 分布式工作的挑战
(1)沟通难度
不管是在国内还是在不同的时区, 都有可能面临到一个最大的问题: 无法进行面对面的沟通. 没有办法到别人的桌子前拍拍人家, 然后跟他说这个问题, 你帮我解答一下. 或者我有这个事情想跟你来讨论, 然后马上会进行一个快速的高频次的沟通.
(2)作息时间
在我们公司这是一个必然, 会出现有人在休假, 有人在工作, 有人在不同的时间点有假期. 比如美国的圣诞节和中国的春节, 显然它不在一个时间点上.
另外每个人的工作时间, 工作习惯是不一样的. 有很多技术人员是夜猫子, 喜欢晚上工作, 并不喜欢一大早起床, 但有些人会有非常严格的作息时间, 可能会起得很早, 比如说五六点起床, 他就去锻炼身体, 跑步, 然后回来再工作.
(3)进度追踪
这可能是所有的分布式管理的领导都非常想解决的问题, 他觉得没有办法看到员工, 那也不知道员工在干什么, 那工作的进度怎么保障? 以及谁对工作更用心, 谁的产出更好. 这是很多领导想知道的一个事情.
二, 如何在线协作
1. 利用 SaaS 服务
对于在线协作, 有大量的在线的文档, 会议的工具来帮助大家去解决远程沟通的问题.
但即使有如此多的工具, 依然没有解决大家的心理问题, 在线协作还是让人感觉到非常别扭. 首先就是让人感觉到它并不顺畅. 好像在远程的过程中, 会让人觉得效率很低.
但有这么多的西方的公司, 它们并不是由于疫情而开启在线协作, 而是在正常的状态下进行, 保持日常的分布式的工作的模式, 公司的整体效益并没有受到损失.
所以到底什么东西的缺失, 让我们觉得在线协作模式很别扭, 效率不高呢? 在绝大多数公司远程协作的过程中, 缺少的东西叫时间协同.
因为不管是任何人, 他如果在家办公, 最希望的肯定是想兼顾家里的生活. 不管是家里的老人, 孩子, 还是自己单身的生活状态. 想给自己做一顿饭, 想现在去看一会电影, 或者今天有点生病, 他想多睡一会......
不管怎样, 首先就是需要透明的时间管理, 透明的时间管理和现在的 996(所谓的加班文化)之间是有巨大的隔阂的. 现在国内很多 IT 公司领导可能更多的认为, 工作的时间越长, 得到的收获就越高.
但如果大家关注一个特定的技术领域, 或者关注一个非常明确的开源的方向, 会发现绝大部分的技术社区或开源项目都是由国外的公司在引领, 而那些人其实并没有去付诸中国所谓的高效的 996 的这种工作模式. 首先要做到的是把工作时间安排透明化. 比如我今天不想上班, 想要陪伴家人孩子, 那么可以不去上班, 但要让所有人都知道这一情况.
在另外的时间我可能会告诉其他团队成员, 这周末我准备上班, 因为我这周只上了 4 天班. 我会把自己的 Calendar 进行调整, 这周改成休周二或周日, 而周六是工作日, 大家有时间可以来找我. 如果有事你想建立一个会议的话, 也可以以这种透明的方式, 包括团队成员要出差, 哪些时间是无法应答的, 也需要第一时间告诉大家.
下图是我们公司去年 10 月份的截图, 在下图中, 你会看到不同的人, 用不同的颜色, 标识自己不同的状态. 那么其他人就会知道在这些时间内是不能联系他的, 因为他在休假联系了也没有价值.
2. 合理进行远程会议
在远程会议的过程中, 我们公司内部会有一些原则, 在这里给大家做一些分享:
(1)避免全员会议
前段时间刚开始远程工作的时候, 很多人发帖子和朋友圈抱怨公司开晨会. 每天早上开晨会, 让大家早早起来, 这本来就是效率很低的事情, 至少浪费了所有人一个小时的时间.
其实也并没有聊任何有价值的问题, 其实只有极少数公司才会有早晨的例会, 或者说能坚持下来做有意义的例会的公司是不多的. 既然在面对面的时候, 都无法发挥效率, 那么所谓的在线会议, 包括有的公司上班, 下班的打卡制度, 实际上严重的违背了远程办公的高效性, 让每个人变得更灵活这样的原则.
(2)会议提前 48 小时预约, 紧急会议仅限于必要时
在远程会议里面大家都会觉得开一个远程会议的成本很低, 因为随时可以联系其他人开会, 而这样的会议一旦被传承了, 形成一种文化, 那么就会发现每一个人都在不停的开会, 而根本就没有时间静下来去做自己该做的事情.
而又因为是远程, 容易造成相互间的不信任. 不能看见, 所以被邀请会议的人不能像在公司当面一样, 拒绝跟自己无关的会议. 更多的时候, 可能会被没有远程工作经验的人理解成: 他现在肯定没有在干活, 所以他不想跟我开会.
所以会议的预约制决定了会议能够保证正常进行, 受邀人一定能够按时的参加, 除了个别的紧急的会议. 当然这样的会议更多时候会遵守第 1 条, 只会邀请必要人员, 不会全员, 不会浪费绝大多数人时间.
(3)在会议前发送背景介绍和议题文档
这反映了大家文档工作的能力. 我知道在中国很多的工程师文化里, 对文档是非常排斥的, 特别不愿意写文章. 实际上全球的工程师们都是一样的, 都愿意去实现它, 并不愿意去写文档.
而多数远程办公的公司文化都有开源的经历, 开源需要文档. 全球在招收远程工作的职位时, 一般同时会写着需要这个人有开源或者远程的工作经验. 因为在这样的过程中, 你才能懂得文档的重要性, 才能懂得用文字表达, 会比语言, 开会更高效更准确.
(4)会议的时间不能超过 30 分钟
绝大部分的议题能在 30 分钟内结束. 如果是一个长篇大论的争论性质的讨论, 那这个会议其实可以在前期通过邮件, 文档的在线审议来决定. 而不需要占用所有的在线评议人, 参与人的时间, 聚在这进行无休止的争论和讨论. 会议本身最大的目的是做出决议, 避免有漏掉的一些情况以及同步信息.
(5)可能关系人采用邮件通知讨论结论
有些会议有人会缺席或不到场, 那在这过程中, 只需要把结论形成文档. 就好像我们平时在公司有人发会议纪要一样, 远程工作会议纪要, 对于那些没有与会的人是非常重要的. 他们需要知道结论, 但不用像会议纪要那样去描述所谓的讨论的细节. 因为对于其他最弱相关的人来说, 他要的更多只是一个结论.
3. 形成 Gossip 文化增强团队凝聚力
Gossip 文化是远程公司一个非常大的特点, 几乎所有的公司都会有, 包括在 Google 内部, 也会有 Gossip 的文化. 一般一周只有一次会. 当然可能像我们公司是不同时区的话, 可能会有两次, 我们是会有北京时间的早晨和北京时间的晚上, 因为这样两个时间可以协同全球的不同时区, 大家选择自己合适的时间来参加会议.
Gossip 的内容更多的是闲聊, 是除了技术问题之外的问题, 比如说这两周大家会问我, 中国的疫情情况, 中国政府到底是怎么样去应对的? 你了解到什么信息? 需不需要我们帮助你什么?
或者有一个同事出去玩了, 他会分享玩了什么东西, 觉得哪个地方不错, 大家有机会可以去玩. 当然也会有和公司相关的, 比如公司的合同进展状况, 客户关系的进展. 最大的差别是, 它都是非常粗线条的东西, 并不要去讨论细节, 方案, 目标, 更多的是分享给大家, 公司其他的团队成员在做什么? 把自己的信息共享给大家, 因为这种全面的公开信息, 可以让大家更容易为团队寻求支持.
三, 管理模式和沟通方式
在远程工作的时候, 技术手段反而是最容易被解决的. 不管是所谓的 Git, 还是在线的会议系统, 视频聊天系统, 文档协作自动化的流程, 这些都是工程师非常擅长的东西, 无非是敲代码和软件应用. 但是管理是分布式团队最大的挑战, 分布式管理需要要靠很多的细节去支撑.
1. 问题追踪
对于问题追踪, 我相信很多公司都有看板这样的东西, 并不稀奇. 但细节可能是远程工作和现场工作最大的一个区别. 因为在现场的话, 很多时候领导看到看板没有动, 他可以站起来去询问这个事情做得怎么样?
那么在远程工作的时候, 他不可能不停找人问, 成本是非常高的, 而且对于领导或 team leader 来说, 它会浪费了大量的时间. 所以在远程工作的时候, 就要求问题要更细致, 最好是分阶段的, 而所有的问题都应该被管理出来.
比如说它是一个简单的 issue, 可能要做三四步. 那么这三四步很有可能是 3~4 个 issue 不停的在操作, 这样的话你的工作进度对于领导来说是非常容易被发现的.
并且当你去报告被阻塞的时候, 是可以很明确的知道哪一个非常细的任务阻塞了, 其他人可以快速的去解决掉这个问题, 而不会是说一个大任务阻塞了, 但你实际上这事情根本就说不清.
另外就是在整个过程中间, 它需要有 Owner 和 Reviewer, 这在国内是非常少见的, 我们需要结对编程. 所谓的结对编程, 并不是说一个人编程, 真的有另外一个人在旁边坐着看. 而是两个人工作在相同的领域, 他们工作在相同的技术方向上, 能够理解对方在干什么, 对于细节都能理解.
那这两个人可以交叉互审, 同时也变相达到了交叉考核进度. 因为他自己在做这个方向, 能够非常准确的评估出对方的工作量, 相互之间可以形成一个很好的团队. 而上面只需要一个相对比较大的人物去考核, 去负责就可以. 所以问题的细化和责任到人, 这是在管理时和平时在做任务追踪时, 非常大的区别. 一个是非常粗犷的管理, 一个是大力度细化的管理.
2. 状态同步
我们公司会用文字的形式代替在国内的每一天的视频例会, 描述的内容其实对员工来说是一种鞭策. 你需要写出内容, 而你昨天的内容就在这上面放着, 当你天天写一样的内容, 或者进展非常慢, 这是非常容易被看见, 并不在乎于它是文字形式还是口述.
而对于视频会议, 因为十几个人不停在说, 对于听的人根本无从判断昨天这个人到底说了什么? 所以会议除了在视频上看见人以外, 其他并没有什么太大的好处. 而且因为每个人的工作结构不一样, 有人可能到晚上这个活才能干完. 那么你下午去问他的进展的时候, 其实他并没有办法给你回复, 每次都跟你说的是这个事情正在做, 这也变成了没有意义的.
同时 Standup 和刚才前面的 issue 管理是要呼应的, 因为前面的 issue 是非常的细的, 所以在 Slack standup 的 channel 里, 大家会发现细节的进展都可以被反馈出来. 最大的核心就是 Block, 因为任务被拆细后, 可以更离散地活动, 那么肯定会在特定的时候, 受到一些阻碍.
比如说任务协调不合理, 或者有一些设计出现了问题, 或者有一些技术障碍需要被排除, 以及有一些不可预知的错误, 需要大量的时间, 这都有可能.
Block 是你向团队申请援助的最大的帮助, 因为每个团队都有不同职级不同能力的技术人员. 不管是开源, 还是公司内部都一样. 那么你的 block 被报告出来, 有助于上面更好地对你进行帮助, 而你能够把 Block 说清楚, 更多地证明了你对这件事情的了解是非常透彻的, 你能分析出它的 Block 在哪个地方.
很多人都会告诉 leader, 我快做完了. 这是国内最容易上报的一个事情. 但实际上可能三天都做不完. 这就是我们的工程师们没有把自己的任务分析清楚, 可能需要两三周才能完成的功能, 没有做到任何的拆解.
3. 以开源的模式公开工作内容
公开工作内容, 在技术团队之间, 这和很多大型公司现在推广的所谓的 inner source, 就是对内开源的公开信息, 其实是有很大的关系的.
要防止员工不干活, 最好的方法就是把他工作的内容公开出来. 提交了多少代码, 做了多少次提交, 向哪些库提交过代码, 向哪些库提交过 issue 的讨论, 每次工作的讨论重心有多少? 有多少 review 的细节......
在这样的过程中, 就能看到其他人的工作状态, 这种公开透明的方式, 是对管理最大的支撑. 没有这些, 管理就无从说起. 因为在管理都讲一个事情, 就是对事不对人. 一定不能按你个人的某个感觉, 比如我感觉这个人好像没有好好干活, 这是非常不科学的事情. 但如果他的提交量, 参与度显著达不到平均水平, 那我就知道在这过程中, 他可能是真的没有好好的干活.
4. 邮件沟通准则
(1) 每封邮件只包含一个主题, 以免遗漏
邮件在发送的时候, 一定要避免长篇大论, 包含几十个主题, 寻求不同的人说明不同的事情, 这样的邮件很容易中间被遗漏. 因为有人读了前三个, 觉得跟自己没关系, 可能这篇邮件就跳了.
(2) 使用 [topic] 明确邮件内容领域.
就是你在公司内部哪个项目或哪个技术方向, 一定要通过邮件的名称来明确自己是在哪个领域, 方便大家快速检索.
(3)必须使用回复全部
所有的邮件系统除了涉及公司机密外, 一定要尽可能的使用回复全部, 避免有人漏掉了上下文的信息, 而不是使用直接回复给发件人. 因为大家也需要同步你在讨论过程中间的一些观点.
(4) 领导接受异步回复
如周末或非工作时间发出的邮件, 需要等到工作时间才会回复, 这是对领导的一个要求.
(5) 只有紧急问题才使用即时通讯软件(Slack)
一定是已经紧急到必须他出面来解决的时候, 才会使用即时软件. 在国外的公司可能更多的是 Slack, 那么国内可能会是微信.
但想告诉大家的是, 在国外即使是 Slack, 所有的工程师都可以选择在休息时间并不进行回复的. 所以这也回到前面, 需要结对编程的目的, 每一个技术细节都是有另外一个人在备档的, 两个人同时不在的情况是很少发生的.
(6)在休假期间设置自动回复
当你不能在规定的时间内, 大家预期的时间内回复, 比如你有个人的事务要处理, 或者你有一些特殊的情况, 比如在休假或者出差. 不管是因公还是因私, 或者你在进行时区的切换, 你都需要用自动回复的方式来告诉大家, 以免大家产生误会, 就觉得好像我问你的事情没有得到一个合理的回复.
5. 即时通讯软件 (Slack) 准则
其实在国外, Slack 会比类似于微信这样的工具更加流行.
(1) 使用 Thread 进行上下文讨论
Slack 会有典型的上下文, 可以针对一个点反复的进行讨论, 而不像微信会一下就刷没了, 对这次讨论的上下文没有非常明确的联系. 这就是为什么微信更适合于点对点的聊天, 绝大多数的国内通讯工具更适合于点对点, 或者说闲聊, 并不适合作为工程工具来进行使用.
(2)不使用 @here/@channel
就相当于在微信群或者 QQ 群里 @所有人一样, 如果所有人都干这个事情, 那最后的结果就是没有人关心谁 @我.
(3) 对于留言信息, 尽量提供明确的上下文, 甚至示例和步骤(原则上应使用 email 代替)
即使是 Slack 也和邮件需要遵守同样的原则, 需要提供明确的上下文, 不能说就写两句话, 别人看完后都没明白你在说什么.
你需要大家在没有你详细解释的情况下, 读这段文字就知道你要说什么. 那这需要大家对跟自己有衔接的工作细节, 有一定的了解, 你要花时间去了解别人.
(4) 即使使用 Slack 也要接受异步回复模式
同样 Slack 和邮件一样, 要能够支持异步回复, 公司也会有明确的指导告诉大家说, 如果你这段时间不想进行即时聊天, 那请打开勿扰, 原则上是允许员工每天抽出一到两个小时.
如果你是这样性格的人, 可以抽出一个到两个小时的时间, 集中去进行 Slack 上的问题和邮件的回复, 而在其他的时间内保持你自己的专注力.
这个是因人而异的, 有人可以做到非常快的上下文切换, 比如说在 3~4 个讨论中间, 他的脑子可以换得非常的快. 而另外一些人是需要非常大量的准备时间, 但可以非常深入的去讨论某个问题, 或者做某一个技术上的 coding 这样的动作. 所以大家可以根据自己的情况来决定. 同样的, 管理者要能够接受这样的一种讨论方式.
6. 开发准则
(1)面向设计文档
这可能又是工程师们最不喜欢的.
(2)面向 API 和协议
尽可能让 API 和协议文档化. 对于网络接口和需要调用的类, 一旦定义出来, 不允许被随便改动.
(3)在原型状态即提交 pull request, 并标识 WIP
因为我们有结对编程的一个策略, 所以 pull request 是要尽早的提出来, 这样别人才能看到你的 pull request 的内容, 并在早期指出一些你可能犯的原则性的错误. 因为所有的工程师都有状态不好的时候, 或者对某些技术领域不熟悉, 从而犯一些非常低级的错误.
如果 pull request 真的会 break 某些协议或者设计, 那你应该在 pull request 刚刚发起的时候, 就在第一时间通知所有可能会受到影响的团队和个人, 或者让他们尽早的看到 pull request 以及针对 pull request 预先做针对性的一个调整.
在所有以开源项目为背景的公司中有一个非常重要的文化: 所有的功能在提交代码的时候, 都需要通过全自动的端到端测试. 会有大量的测试, 而这些测试实际上是由工程师自己来完成. 比如你提供 REST 接口, 那么你在做的时候, 就应该有相应的测试程序去调用 REST 接口, 并测试 REST 接口是不是能够真实的完成数据的写入, 更新, 以及相应的一些行为特点. 才能保证系统在每一次交付的时候, 不用频繁去沟通, 为什么系统运行不了这样最常见的问题.
四, 分布式工作的核心要点
1. 异步工作核心
异步工作的核心原理, 并不是让团队连得更紧, 而是为了让个体工作效率的最大化. 在这过程中, 发挥个人的主观能动性才是工作的核心. 现在绝大部分的中国公司都是因为疫情被迫进行异步工作, 他们希望把在线下的那一套东西移到线上的, 而实际上反而成为了降低工作效率的一种方式.
因为传统的管理是基于人没有主动性, 那企业把员工拴在公司, 完成工作. 而不是依靠额外的考核制度, 追踪能力, 去反向证明你是不是有足够的工作效率和工作积极性, 以及自我约束的一个能力.
2. 团队工作原则
如下图所示, 右侧的几个原则, 是我们公司指导文件的一角:
如果你正在做的工作, 不是一个非常敏感或者优先级很高的工作, 而别人做的东西正在被卡住了, 做不下去了. 那你现在最应该做的事情, 就是去帮人家解决 Block 的问题, 而不是继续做你的工作.
如果你自己现在正在做一个非常高效的积极的工作, 你脱不开身, 那你应该去找被阻碍的那个人解一下, 到底是什么东西阻碍到他了, 有没有办法能够绕过去? 实在绕不过去了, 再去考虑是他的优先级高, 还是你的优先级高.
如果即使在这之后, 你依然发现你的工作还是优先级更高, 那这时就出现了结对编程时的最后的解决方案, 你去找跟你结对编程的那个人, 因为他和你的技术领域是类似的, 很有可能帮助被 Block 的人快速或暂时过滤掉阻碍的问题. 所以这是一个非常有顺序的流程. 大家需要了解的是, 在这个流程里面可能会帮你自己把事情做得更顺畅一些.
3. 远程办公对公司的影响
远程办公对公司的影响其实也是远程办公的要求.
(1) 需要具备远程工作经验的员工
现在绝大多数人被迫远程办公, 实际上他们中的大多数并不知道如何正确远程办公.
(2)对员工个人素质, 自驱能力, 时间规划能力, 专注力要求更高
在办公室, 因为领导就住在你背后, 所以你不可能瞌睡. 而在家里手机就摆在旁边, 你可以去随时去打游戏, 或者看电影.
那么你怎么保证每天的工作效率以及每天工作的输出, 这对个人是非常高的一个要求.
(3)需要远程办公管理经验的管理者
对于管理者也是如此, 怎样去协调不同工作习惯的员工, 怎样保证他们的工作效率, 怎样去协助他们, 做好协调, 这是非常重要的.
(4) 办公成本降低
因为大家都在家里, 用自己的网络, 自己的屋子, 那么实际上对于公司来说, 降低了非常多的成本. 以及每天加班的打车费, 餐补, 所有的这些东西, 公司都省掉了. 可能唯一成本的就是公司的几台物理服务器变成了云服务器, 以前的架设的一些服务, 变成了购买云厂商的或者第三方的 SaaS 服务.
(5) 差旅
比如像我们这样的公司, 每年会有一次到两次全球飞行的成本, 需要去连接更多这样的团队, 去提供一些短期的面对面沟通.
最后分享给大家, 不要认为所有的工作只要是远程就是最高效的. 即使对一个非常有经验的远程工作的团队来说, 依然需要时不时的去面对面沟通.
这既是一个人性的问题, 成员之间需要社交活动. 另外当面的讨论, 对于涉及这种不需要实践, 更多的是需要经验以及规划能力上的问题时, 面对面会比远程工作来得更好.
五, Q&A
Q: 在开发过程中, 如果缺少专业的测试工程师, 需要自己来承担不大不小的 bug 的问题, 这个事情怎么处理?
A: 像我们这样的公司都没有测试工程师这样的一个职务, 也没有测试组这么样一个团队.
实际上在这样一个过程中间, 工程师要向自己的代码负责. 为什么我刚才说端到端的测试会非常重要, 这个是保证你在交付的过程中间不会出现大大小小的 bug.
Q: 未来 3~5 年, 远程办公会不会成为一个主流形式?
A: 从我的理解来说, 短时间内应该不会, 至少在中国不会. 因为中国的大多数管理者还没有准备好适应这样的制度和文化. 可能相对于技术人员, 技术平台来说, 管理能力是最大的障碍.
讲师简介
吴晟, 腾讯云最具价值专家(TVP),Tetrate.io Founding engineer. 开源技术和开源社区爱好者, Apache 和 CNCF 基金会多个开源项目核心团队成员. Apache SkyWalking 创始人, VP 和 PMC 成员; Apache 孵化器 PMC 成员; Apache ShardingSphere(incubating) 联合创始人, PMC 成员; Apache Zipkin(incubating) 贡献者和孵化器导师. CNCF KubeCon + CloudNativeCon 2019 Program Committee 成员; CNCF OpenTracing 标准化委员会成员. 关注和推进云计算, 服务化, 云原生和服务网格技术的技术发展. 并积极为中国开源项目提供帮助.
关注云加社区公众号, 回复 "TVP 直播课", 即可获取老师演讲 PPT~
来源: https://www.qcloud.com/developer/article/1602654