疫情封城之下，看区块链公司的分布式办公最佳实践
2020 年初，本该喜迎新春佳节的华夏大地上被突如其来的疫情所席卷。为了有效控制疫情进一步扩散，各地政府都下达了红头文件，对人口流动进行严格限制。受其影响，部分公司至今为止都无法正常复工；而对于那些已经返程的员工们来说，脸上的口罩、心中的担忧都在或多或少地影响着他们的工作效率。
正因如此，远程办公这一概念又一次进入了大众的视野。各类视频会议软件开始加班加点对服务器进行扩容，各个单位和组织也都在为了保障远程工作而积极进行着员工教育和动员。
事实上，相比于其他行业，远程办公早已在区块链行业广为普及，绝大部分区块链创业公司在创立之初就实行了分布式办公这一制度，由于行业属性，公司员工大多分布于全球各地，通过远程协同办公推动业务发展。
那么分布式办公在区块链行业为何如此流行，又有什么实战经验可供分享呢？作为就职于美国区块链公司 Algorand 的开发从业者 ，在此我就为大家深入介绍一下区块链公司分布式办公实践中所面临的问题和解决办法。
区块链公司的分布式办公现状
Algorand 由 MIT 教授、图灵奖得主 Silvio Micali 教授创办，其提出的同名共识算法 Algorand 首次将密码学融入到了共识机制中，实现了区块链技术在性能和安全性上的突破，在学术和产业界都引起了广泛的关注和讨论。目前 Algorand 已将该技术产品化为区块链平台，并已经和全球多家公司达成合作，联合开发基于区块链的创新金融应用。
那么为什么选择分布式办公？
区块链技术是一项强调去中心化的技术，它的使用者和应用场景分布在全球各地。也正因为如此，区块链技术的创造者也需要能覆盖到全球每一个角落。只有深入各地市场，了解企业和用户的需求，才能实现区块链这一技术的大规模应用。而这正是 Algorand 和大多数区块链公司选择分布式办公的主要原因。
选择分布式办公机制的另一个原因，则是希望能获取来自全球各地的人才资源。与传统科技企业一样，区块链公司也面临着人才招聘这一问题。但与传统企业只能在有实体公司的城市招聘不同，采用分布式办公的区块链公司们能够实现从全球各地招揽人才。以 Algorand 为例，我的同事有来自麻省理工和哈佛大学的高材生，也有帅气的欧洲小哥，就连 Silvio Micali 教授本人也能经常在一些线上会议中碰到。人才之间的交流和碰撞，才是推动技术发展的不竭动力，而分布式办公正是为这一过程提供了最佳土壤。
但分布式办公也有需要克服的困难。
首先是效率问题，由于物理上的距离以及缺少形式上的监督，工作很大程度依赖于员工的自觉性；另一方面，远程沟通所导致的信息不对称、工作进展迟缓甚至内耗问题都是高效办公的绊脚石。如何驱动员工充分发挥个人价值，上级如何指导员工工作，整个团队如何实现既定目标，这些问题的解决方法都会和与办公室环境下有所不同。
而对于跨越时区的全球分布式办公来说，时差也是一个问题。当我们在办公室工作，需要同事协助时，只需扭头张嘴或是走几步，当下就能获得需要的帮助；但在分布式办公情况下，能帮助你的同事很有可能还在睡梦中，而你也不得不暂时停下手头的工作等你亲爱的同事起床。
想要解决这些问题，就需要团队采用相应的管理协作办法、并借助一些工具。接下来就介绍一下我们团队在分布式办公方面的有效实践。
如何实现全球分布式办公？
首先是团队整体的任务管理制度。
OKR（Objectives and Key Results）制度相信大家都不陌生，它在 Google 和 Facebook 等公司都有广泛实践。OKR 制度强调以结果和交付为导向，要求各部门及其员工设定各自的广义目标，并制定包含可以切实实现和量化成果的里程碑。
OKR 并不简单的和 KPI 一样只是计算绩效和决定工资的工具，它更重要的功能是指明方向，让团队所有人都有清晰的目标。同时，好的制度也需要好的执行，使用 OKR 制度要求领导者能够保持透明和灵活，需要员工对工作有足够的积极性。所以这方面的具体实践还是需要各个团队针对自身情况而做出调整。
Algorand 团队算是 OKR 制度的坚定执行者。以 Algorand Foundation 团队为例，2020 年的目标（Objective）被定位了生态建设，对应的交付成果则是合作企业的数量，开发者和开发团队的数量，社区的人数等等。所有的交付成果都有可以量化的指标，并且被赋予不同的优先级；根据优先级给每一个交付指标加一个参数，再将所有的指标乘以优先参数以后想加求和，就可以得到一个 1 到 100 分的 OKR 指数。跟踪这个指数的变化，团队就可以清楚地了解到目前公司整体的现状和进展。
接下来会对团队整体的 OKR 进行细化。
对于每个小团队来说，团队领导会根据公司的整体 OKR 和自己团队的职能，划分出自己的团队的子目标，并同样设定一些可以量化的交付成果。再到个人，每个人都会根据自己所属团队的 OKR 再细化出自己的 OKR。在周会和月会上，团队会对当前的 OKR 指标进行回顾和总结，并对接下来的工作进行调整。
这里详细说一下开发任务管理。
从瀑布式开发（Waterfall Model）到敏捷开发（Agile Development），实际上所有的开发流程也都有自身的优缺点，并没有所谓的新旧之分。敏捷开发中的最火的算是 SCRUM 了。SCRUM 的思想是通过使用 2-4 周的 Sprint 周期来划分里程碑，并不断迭代开发产品。
SCRUM 开发流程
我们从项目开始就采用了 SCRUM 流程来管理开发，并在这过程逐渐积累了不少经验。团队开发的大致流程为：
需求制定：由产品经理主导，制定产品开发需求，写出需求文档（PRD），里程碑时间节点（Milestonr）和版本发布的时间表（Release Schedule），并由团队和领导进行评审。
Sprint 开始前：举行会议，团队讨论决定该 Sprint 的需求列表，产品经理提供 PRD，开发负责人对需求进行工时评估，并细化成开发任务，再由各工程师认领开发任务。
Sprint 进行中：开发进行中团队随时同步进程，产品经理或项目经理需要对 Sprint 的进程进行检测，并及时上报隐患。
Sprint 结束后：举行总结会议，对 Sprint 的结果和过程进行总结，该表扬的表扬，该批评的批评；之后开始准备进行下一个 Sprint。
产品发布：根据预先制定的里程碑时间节点举行产品发布，需要项目经理预先整理出产品发布流程和事项检查表，保证发布顺利进行；并且在发布完成后，团队还需要 Stand-By 一段时间，以应对产品发布后可能出现的突发情况。
以 Algorand 钱包的开发为例，整个开发计划被划分为了三个里程碑节点，分别实现基本的转账功能，多钱包管理功能和 ASA（Algorand Standard Asset）的收发功能。每个里程碑又使用了 3 到 4 个 Sprint 迭代实现，每个 Sprint 为时两周。每个里程碑节点过半时，团队会提前开会进行需求冻结，确定哪些需求必须在该里程碑实现，哪些可以先放弃，保证产品上线。
以上这个过程看似复杂，但实际上非常富有逻辑性。在完成该产品的过程中，涉及的所有的协作，都是通过文档和视频会议完成的。事实上，根据工程师们的反馈，远程协作不仅没有造成阻碍，反而提升了效率：想象你在开发钱包时需要 SDK 团队的支持，而恰好该团队与你有 12 个小时的时差，这时你大可选择在 github 上开一个 issue 并 @ 他们，然后洗洗睡觉；第二天早上起来你就会发现该 issue 已经被 close，而你也可以继续进行你的钱包开发。在你睡觉的时间，项目都依然向前进展，这也算是分布式办公都有的优势。
除此以外还有非常重要的一点，那就是团队沟通。
沟通不仅是一门艺术，还是一项技术活，这在分布式办公的团队中更是如此。Algorand 在团队沟通这方面也制定了一些原则性的制度，其中着重强调了基于文字的异步沟通这一沟通方式。
所谓基于文字的异步沟通，实质上就是指通过 Email 或者 IM 来发送文字进行沟通，又或者是通过书写一份文档来描述问题或是汇报结果。采用这种沟通方式，并不仅仅是由于时差的存在所以不得已而为之，更是因为它有着自己独特的优势。
人在进行实时的沟通时需要同时进行逻辑思考和组织语言，这本身是一个比较复杂的过程；而在异步沟通的过程中，我们将会有更宽松的环境和更多的时间来让我们深入思考所想要表达的事情；使用文字来进行描述也能让逻辑更加清晰，使读的人能更快的明白问题所在。除此以外，异步沟通还能防止你的工作流被随意打断。相信很多开发者在写代码时，最怕被人打扰，等你应付完他人再回头看屏幕，很可能会发现你已经不知道自己在写什么了。
除了异步沟通，沟通前做好充分准备、理清事情优先级、规定限定时间内回复，这些原则也都能有效帮助克服分布式办公的沟通问题。
以上就是一些我们在工作中沉淀下来的原则和方法，希望能对还在犹豫是否要启用分布式办公的团队能够提供给一些借鉴。
分布式办公工具
除此以外，工欲善其事，必先利其器，合适好用的工具也能帮我们更好地执行以上策略。
首先在最基础的沟通方面，我们使用了三种沟通工具，分别是邮件、Slack 和 Google Meet。
邮件就是用来进行上述异步文字沟通的主要工具了。我们使用了 Google 的 G Suite，它不仅提供了方便可靠的邮件服务，同时还附带了日历功能，让团队成员间能够随时了解对方的时间。需要开会时只需要打开大家所有人的日历，然后找到一个空缺即可快速完成会议预约并发送邀请给所有人。
Slack 被用来作为即时通讯工具使用。Slack 中如何建立频道（Channels）是一个需要注意的地方。一般来说我们会在两种情况下建立频道。首先一个小团队会需要有一个内部频道来进行日常沟通；该频道可以按照需求设定为私密频道。其次，对于每一个正在执行的项目会建立一个频道，邀请所有相关人员加入；该频道内用来讨论该项目相关事项和分享所有相关资料和信息，同样可设为私密。
视频会议软件有很多，不过既然已经选择了 Google 全家桶，其中自带的 Google Meet 自然成为了我们的首选。Google Meet 完全基于网页，不需要另外下载软件，并且功能也足够强大而且可以免费使用。美中不足的是目前还没有美颜功能，需要下载第三方软件实现。
文档工具方面，我们同时使用了 Google 文档和 Quip 两个工具。Google 文档主要用来保存一些需要对外发送的文件和内容，大多以 PDF 形式存在并存在云盘上，使用 Google Drive 进行权限管理，从而保证大家都能找到自己需要的东西。Quip 主要用来进行团队内部的协作和沟通使用。Quip 支持使用 Markdown 语法来书写文档，习惯之后将会大大提高书写和排版效率；同时 Quip 中还有许多很好用的插件，比如看板、日历、倒计时等，可以用来丰富文档，实现更多的需求。
使用 GitHub 管理开源项目
我们的项目为开源项目，所以代码管理就直接使用了众所周知的 Git 和 GitHub。使用 GitHub 同样需要注意一些开发流程上的事项，比如在实现一个新的 Feature 时，需要拉出一个新的分支进行实现，在实现之后再合入 Develop 分支，并进行测试，然后在版本发布时才合入 Master 分支完成发布。这个流程相信对于老程序员来说已经是熟门熟路，但对于新入行的程序员们来说，还是需要写一个清晰的文档给其作为参考。
使用 Quip 管理开发任务和项目进度
在开发任务管理方面，我们并没有使用 Jira 这种过重的项目管理软件，而是直接使用了 Quip 和 GitHub 自带的工具来实现。Quip 本身自带看板插件，可以实现类似 Jira 的 Backlog 和 Sprint 功能；同时 GitHub 的 issue 本身也是一个很好的需求池工具。工具的选择原则是灵活和够用，如果强行要求团队去适应 Jira 的风格的话，可能反而会适得其反，降低效率。
使用 Travis-CI 进行自动化部署和测试
软件项目的自动化测试工具近几年也逐渐成为主流，DevOps （运维工程师）这个工种也逐渐走俏，这方面的工具也有很多的选项可供选择。不论是选择付费的 Travis CI 还是 Jenkins，又或者是直接自行搭服务器写脚本实现，具体的选择都应该由负责运维的工程师来主导团队讨论决定，保证大家都能舒服是第一原则。最近 GitHub 也新推出了 Acitons 功能，我们虽然目前在使用 Travis CI，不过最近也正在调研是否可以通过直接使用 Actions 来降低成本和提升效率。
最后想要提醒一句：工具不在于多，够用就好，强行让团队学习使用过多的工具反而是门负担，学习和利用好现有工具一定是第一要义。
结语
远程办公是一门大学问，以上讨论和列举的只是其中的一部分而已。在真正的日常办公和生活中，远程办公的我们还需要处理许多细节问题，比如如何缴纳社保和个人所得税，如何扩大社交，如何找对象等等。这些问题都很少有参考答案可供借鉴，而往往需要各位从自身情况出发去寻找针对性的解决方案。所以随时保持独立思考和果断执行，这才是作为一个远程工作者的不二法门。
作者简介：朱海潮，Algorand 基金会的 Associate Director，主要负责开发者社区和生态系统的建设。海潮曾在 Nervos 项目任数字货币研究员和产品经理职务，并在微软和日本东京大学等研究机构担任研究员。
Summer Miao，Algorand 基金会中国区市场经理，主要负责中国及东南亚市场策略、活动、媒体及社区管理。
☞“华为搜索”正海外内测；苹果5亿美元和解“降速门”；Firefox隐藏HTTPS | 极客头条☞微盟耗时 145 个小时弥补删库，血亏 1.5 亿元！☞0.052秒打开100GB数据？这个Python开源库这样做数据分析
☞两成开发者月薪超 1.7 万、算法工程师最紧缺！| 中国开发者年度报告
☞Libra为何而生？Facebook为何要给 Libra创建Move语言？Calibra技术负责人给出了回答