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