今天是2月5日,春节假期结束后的第三天了。为了能够应对来势汹汹的疫情,众多互联网企业纷纷开启了远程办公模式。不知道各团队前两天的远程办公效果如何,我们 Worktile 管理层在大年初四就开始讨论远程办公的事情,并且将可能出现的问题都尽量提前想到并做了准备。从这两天实际执行的情况看,我所在的研发团队执行的还不错,基本没有受到什么明显的影响。因此我们希望将我们远程办公的一些思考、准备和实践分享给大家,共渡难关。
先简单介绍下,我是 Worktile 基础平台部的负责人,部门包括负责核心组件开发的平台组和负责线上及公司内部服务器管理的运维组。我们的运维团队一直都是一个分布式团队,成员包含北京和杭州,我本人之前也有几年跨国公司的工作经历,对远程工作并不陌生。接下来我想就以下几个方面聊一下我们 Worktile 研发团队是如何实施远程办公的。
首先,作为研发线的一名主管,我首先给自己明确了一条远程办公的原则——信任,并且首先是自上而下的信任。也就是说,远程办公首先要求管理者,无论是公司CEO还是普通的小组长,都要完全信任自己的团队成员是有责任、有担当,能够自觉的按时按质完成任务,能够主动沟通工作中的问题。只有基于这样的信任,远程办公才可能展开。否则,就会陷入到监视、控制、猜疑这种危险的状况中。所以,信任是远程办公的基础。
其次,任何一级的管理者都要以身作则。我们希望我们的团队成员能够像在办公室一样的工作,那么作为管理者就更要如此。比如我们Worktile明确了远程办公的在线时间,就会要确保我们的Manager在此期间沟通渠道必须是畅通的;我们要求了成员每天的例会,Manager就会要尽量参与这些例会(可能无需发言但是必须要参与);我们要求公司全体在此期间写日报并且明确了可见范围,Manager自己的日报是必须向团队成员开放的。
在明确了信任这个大前提下,我们就要非常小心的制定了远程办公的执行细则。之所以说“小心”,是因为我们清楚的认识到规则不是为了监视和约束,是为了最有效率的沟通与合作,为了尽可能减少远程沟通的成本。因此我们尽量将规则制定的少一些,简单一些。下面是Worktile的远程办公的规则:
比如,下图就是我昨天(2月4日)提交的工作日报,评审人是CTO,对我们部门的成员可见。
和业务线不同,研发部门需要用到更多的工具、软件、服务和资源。我们在明确了远程办公之后第一时间整理了研发团队日常可能用到的资源,逐一评估准备。如果你的团队现在已经遇到了一些远程办公资源访问的问题,可以依照我们的列表检查并逐一解决。
Worktile研发团队远程工作具体实践
每个团队的工作方式都不尽相同,因此在远程办公的时候遇到的问题和解决的办法都是不一样的。这里我只是想结合实际的情况来介绍一下我们Worktile研发团队是如何在远程办公的场景下完成工作的。
我们之前所有的会议安排都是通过Worktile日程同步的,通过Worktile日程不仅能安排会议时间、参会人以及参会人的反馈信息,还能查看当前团队所有的会议安排。而在远程办公的场景下,我们更加明确了“以Worktile日程安排为准”的原则,即任何的会议都要通过Worktile来组织,避免出现电话、微信等多个日程安排信息不同步的现象。
譬如下图就是我们部门本远程办公的日程安排,包括Sprint Plan、Daily Scrum、架构设计评审、管理层会议等。
下图是我们的Daily Scrum日程详情。和平日唯一的不同是,为了整个部门更好的沟通,在远程办公期间我们将另外一个组的成员也加入进来(这个组目前没有使用敏捷开发),将Daily Scrum扩展成每日工作例会。
远程办公主要的一个依赖工具就是视频会议。由于之前的工作原因,这种会议形式并不陌生。对于团队其它没有经历过这种会议的成员,我事先提出了一些特别的要求。
下图是我们今天上午10点的Daily Scrum会议。我们通过Zoom进行会议,Scrum Master共享自己的屏幕,通过Worktile Agile展示当前迭代的任务板,每个成员轮流打开发言。
而下图是昨天我们团队进行的架构设计和代码评审会。一样是通过Zoom进行的。会议组织者发起并共享屏幕,在会议中一些成员通过Remote Control的功能控制组织者的屏幕,提出设计上的问题和建议。
除了通过视频会议软件,我们还是用一些协作文档配合以及一些即时消息工具进行协作。譬如在我们2月份研发部门工作计划会上,就是用腾讯文档和微信群,大家在讨论的过程中一起完成计划表格的内容。
我们团队平日工作就是基于Worktile进行协同的,而且因为研发团队都是程序员组成的,因此即使此前在同一个工作区办公,大家也是优先通过Worktile上的在线功能交流。比如使用Worktile的即时消息对一些问题进行简单的讨论,在开发任务下面进行评论等等。
现在切换到远程办公的场景,其实工作的流程和方式变化不大。只不过是由在办公室发信息发评论变成了大家在家发消息发评论。
下图就是今天中午我们进行架构设计评审后,针对一些小问题在Worktile上的讨论。
下图是我们针对一个开发中的用户故事,通过评论进行产品细节的沟通。评论的好处是,沟通的过程和结果都可以在用户故事上保留,方便日后的查阅。
Worktile的代码一直是托管在Github上的,因此远程办公对于我们写代码、提交代码和做Code Review没有任何影响。唯一的影响可能是个别成员家里的网速不够给力。
而对于公司自己托管代码仓储的情况,比如搭建私有Gitlab仓储,则必须要提前由IT部门准备好外网访问权限,或者开通企业VPN。而如果像我们一样使用SaaS版本的仓储则完全不需要任何准备。
顺便说一句,我感觉这次的远程办公会让很多企业更明显的感觉到采用SaaS工具的重要性。
下图就是我们在Github上进行的Code Review。这样的方式我们之前就在使用,现在在远程办公的场景下也一样适用。
其实CI/CD和远程办公的关系并不是很大,但是如果我们研发部门已经建立好了完整的流水线,那么将会对远程办公帮助很大。我们知道,研发和运维的沟通和协作一直都是一个问题,而流水线的引入就是为了解决这个问题的。此前在一起工作,可能这个沟通的问题还没有那么明显的显现出来,但是现在研发团队、运维团队都是远程办公,如果有了这个稳定的流水线支持,一方面可以节省很多的沟通成本(研发提交代码直接部署),另一方面也自动化的保证了产品的质量(各条流水线集成的各种测试)。
下图就是Worktile自己的流水线执行信息。团队的所有成员都能够看到,并且在试行失败的时候会通过Worktile的消息通知整个团队。
虽然我们有自动化的流水线,但是由于线上环境的特殊性,我们还是会使用手动触发流水线的方式部署线上环境。由于团队特殊性,我们之前就已经通过Worktile 构建了线上部署申请平台和线上数据调查平台。
研发团队在需要部署的时候通过这个平台提出申请,运维人员批准后在对应时间操作。它的好处不仅仅是减少了频繁的沟通,而且让部署操作正规化、合规化,并且可追溯。
下图就是我们的线上部署申请单。
鉴于之前我提到的信任原则和最小化规则的原则,我们对于研发团队几乎没有给出个人工作生活的要求,譬如网上提到的开始工作前要在房门前假装刷卡,着工作装而非居家装等等。因为我们相信我们的同事能够很好的完成自己的工作,无论是在家还是在公司,是否穿着睡衣。
我们唯一的建议是尽量做到工作生活的分离,即工作的时候不要参与家庭活动,但是可以在休息期间、打水的时候简单的和家人互动沟通。
上面列举了我们Worktile研发团队这几天远程办公的内容和一些收获,也包括了我们之前做的一些准备。希望我们提到的内容能够帮助更多的研发团队平滑的实施远程工作。
再次说明,我认为远程办公最核心的是人,需要一个有责任心有自驱力的领导和团队。同时需要基于充分信任的这个大前提,不只是领导对员工的信任,也包括团队成员之间的信任,团队与团队之间的信任。
最后,合理灵活的利用各种工具是帮助我们高效协作的基础。不仅仅是在远程办公的时候,也是在不久的未来我们回到办公室之后。希望每个企业通过这次远程办公的实践机会,提高我们研发团队的执行力、凝聚力和效率。
作者简介:徐子岩,Worktile 首席架构师&研发总监,前微软高级项目经理、微软MVP,《实战Windows Azure》一书作者,十五年软件开发经历,包括企业级软件的架构设计、开发和测试。熟悉服务 端开发技术 C#、Node.js 以及相关的框架(ASP.NET、Express、Web Socket 等)和数据库(SQL Server、MongoDB),缓存和消息队列(Redis、 RabbitMQ)
Worktile官网: https://worktile.com/
本文作者:Worktile 首席架构师 徐子岩
文章首发于「Worktile官方博客」,转载请注明来源。