如何攻克异地协作难题？看 Tower 的 72 个月远程工作实践
在分享过程中，徐峥分享了 Tower 的成长经历，以及 72 个月远程工作的成功实践经验。以下为徐峥现场分享内容，Enjoy：
今天，我给大家带来的分享主题是 Tower 团队 72 个月远程工作的成功实践。
因为我也是初来乍到，所以想先给大家介绍至今为止 Tower 团队的成长历史，这和我们的远程协作也有极大的关系。
实际上，彩程设计成立的时间还挺早的。彩程设计成立于 2008 年，公司 CEO 是沈学良，我们都叫他“老沈”。
最早我们开始创业时，我们主要做的是用户体验设计外包。那时，国内还很少公司有「用户体验」「UCD」「UX」等概念，所以我们最开始是抱着当时上市公司——亚信联创的大腿，帮他们做一些运营商业务系统的用户体验设计优化。
因为他们的系统都用了很长时间，所以系统已经变得非常难用。实际上，那时已经是 Web 时代了，但是他们很多软件仍然在使用 CS 架构。
当时，我们主要负责的是四川、辽宁、北京 10086 网上营业厅、客服系统、网管系统、亚信海外的一个计费系统等等。在整个设计过程中，我们团队累积了不少产品设计上的经验。
2011 年，随着移动互联网的兴起，我们团队也开始为一些移动 App 做一些设计外包，包括成都本地的咕咚运动、易到用车等等。
在做了几年用户体验设计外包后，我们逐渐开始想要打造一款属于自己的产品。于是，从 2011 年开始，我们团队开始尝试做了两个比较小的产品，一个叫 TeamCola，另一个叫 DesignBoard。
实际上，这两个产品都是根据我们团队的需求做出来的。
TeamCola 是一款用于记录工时的产品；DesignBoard 是一款可以让用户对 PSD 设计图进行沟通、评论的产品。
在两款产品发布之后，我们在互联网上累积了第一波口碑，也收获了一批粉丝用户，让大家了解到原来成都有一个彩程设计，他们打造了一些好用的小工具。
2012 年左右，我们开始思考是否能做一款更通用的工具。
于是，我们就开始在内部进行了一番讨论。因为当时国内没有简单、轻量级的团队协作工具，同时我们自己团队内容做项目和任务协作是通过 Basecamp 工具，所以我们就想是不是应该把 Basecamp 工具引入国内，做一个国内版的项目协作产品呢？
说干就干，2012 年下半年，我们推出了 Tower 的第一个版本。
Tower 发布以后，它的成绩是出乎我们意料之外的，因为它在上线的第一天，注册用户数量就已经远远超过了 TeamCola 和 DesignBoard 的用户数总和。随后，我们在一个月之内就拿到了红杉的 A 轮投资。
后来，我们几个合伙人就商量了一下，是不是要把自己的精力 All in 去做 Tower。最后，我们思前想后，决定停止所有外包业务，转向 ToB SaaS 领域。
至今为止，Tower 已经拥有了 80 万的注册团队和 1000 万的注册用户，在 Alexa 上长期排名国内第一名。
这些结果都是我们整个团队在远程工作的模式下完成的，接下来我将和大家分享一些这几年远程工作的思考。
2013 年，我们开始决定远程工作。
当时，我们的初衷是希望能更好地打造 Tower 这款产品。或许听起来会比较奇怪，想要打造一款好的产品，为什么不是聚在一起加班，反而是远程协作呢？
第一个原因是，我们有一个大胆的设想——如果 Tower 可以完全支持一个远程团队的日常协作，那么它对于那些天天在一起的团队来说更是绰绰有余。
同时，因为我们是基于 37signals 的 Basecamp 做的，而 37signals 本身也是一个远程工作模式的团队，所以我们觉得是不是可以通过这样的方式，更好地打造产品。
第二个原因是，我们不想把时间浪费在通勤上。
2008-2013 年，我们团队在一起差不多 4-5 年的时间。在这期间，我们团队更换过非常多的办公地点，这也是希望我们团队的小伙伴不要花太多的时间在路上。但是无论我们更换到哪一个地方办公，都会有将近一半的小伙伴每天平均花费 2 小时的时间在上下班通勤路上。
我们可以来计算一下，如果我们取平均值 1.5 个小时，每个成员一周在通勤的时间就是 7.5 个小时，扣除掉节假日和休假之类的时间，每年我们会有 300-400 个小时在路上。
我们觉得如果能把这个时间节省下来，那么大家可以用这个时间学习很多东西，或者做其他更有意义的事情。况且，当今城市交通状况越来越差，不管是乘坐公共交通工具还是开车，大城市的早高峰和晚高峰都让人心情沮丧。
第三个原因是，整个核心团队在一起工作 5 年左右的时间了，我们发现大家来到办公室，也是各自处理手头的事情。
如果遇到需要沟通的时候，为了避免打扰别人，我们还会刻意的把讨论地点定在公司楼下，或者比较偏远的会议室。这也让我们考虑，是不是非要大家聚在一起才能做好 Tower。
于是，在 2013 年春节之后，我们就把团队“解散”了，开始远程办公。
不得不承认的是，远程工作确实会带来不少好处。
第一个好处，也是我认为最大的好处——个人生活质量会得到非常大的提升。
在远程工作的前几年，我每天基本规律得像机器一样。每天早上 7：00 起床，然后走路去家对面的健身房游泳；8：30 开始工作，直到 12：00，接着吃午饭、睡午觉；14：00 继续开始工作，直到 19：00，之后再去家附近的一个社区图书馆看书；20：30 回家，最后洗漱睡觉。
每天早上，我从健身房回家的路上，看着早高峰行色匆忙的人，想着自己再也不用去挤公交地铁的时候，感觉自己幸福极了。
第二个好处是，可以让团队保持更加专注的状态。
平时在办公室时，你可能常常会被周围说话、开会的声音打扰。同时，根据报告显示，当长时间在同一个环境工作时，你会因为自己的审美疲劳，导致自身注意力下降，让你影响到自身的工作效率。
因此，我们当年在提倡远程工作时，从来不是提倡在家办公，或者是旅行办公，而是不管你在哪个环境，只要是你能保持工作效率最高的地方就可以。
2014 年，我们曾经开源了一个叫 Simditor 的文本编辑器，它在 Github 上有 4.5k 的 stars，这也算是一个小有名气的开源项目。这个小东西就是我们团队里一个前端工程师，他自己跑到丽江待了两个月，独自开发的产物。
另外，我们在远程之后发现，超过 4 个人以上的会议时间会明显缩短，频次也会降低。
以前，你很容易不自觉地加入到一个会议，然后把会议变得比较冗长；当开始远程办公之后，因为人不在一起，大家说话的成本会变得非常高，所以在每次开电话会议之前，大家都会先在 Tower 上把想法写清楚后，再和大家做沟通，这也是在远程之后留下的好习惯。
第三个好处是，招人会比较方便。
因为我们是一个小的创业团队，所以我们在薪资上肯定比不上大厂，那么我们怎么去吸引更多的人才加入呢？
远程就可以成为我们这种创业团队的吸引力。
同时，我相信敢于选择远程工作的小伙伴，大多数是都是技高人胆大的人，他们自身肯定也比较有实力的，所以他才敢选择一条比较困难的路。远程是在变相地帮助我们筛选候选人，这样招募进来的小伙伴普遍水平都比较高。
最后，因为是远程，所以我们完全可以招募全国的人才，而不仅仅是局限于武汉，或者成都。当你撒的网够大时，你的鱼才会变多。
以上这 3 点，是我认为远程工作带来的最大好处。
接下来，可能就是大家最关心的一点，远程工作团队该如何保证质量和效率呢？
根据我们多年的实践结果来看，最核心的无非 2 点：
招募对的人；
不断优化团队业务流程。
不知道大家有没有看过丹尼尔·平克的这本书：《驱动力》？
丹尼尔·平克在书中谈到，在创意工作领域，如果想要激发员工动力，唯一靠得住的办法就是鼓励他们从事自己热爱的、在乎的事情，“胡萝卜”加“大棒”在创业公司，对激励员工是无效的。
因此，对于我们的团队来说，如果想要远程办公，那么找到自驱力强、专精、对我们的事情是热爱的人，就是至关重要的事情。
在创业的不同阶段，我们招聘的办法各有不同。
2008 年，刚回到成都开始创业的时候，我们的当务之急就是扩充团队。
那时，我们的团队既没有名气，也没有钱，如果贸然做各种广告，或者去招聘网站上发招聘帖子，可想而知，效果是很差的。
因此，这时最好的办法就是从熟人下手。
那时，彩程有一半的员工都是成都电子科技大学里“栋力无限”学生社团的成员，因为老沈（沈学良，彩程 CEO）是社团发起人。我们会在“栋力无限”学生社团里，找到想要出来实习和锻炼的学生。
上图中的小伙伴就是我们当时找的同学，他现在也是我们团队中的 CTO。
那时，他是成都电子科技大学大四正在休学的学生。在休学期间，他跑到香港大学旁听。希望通过更多的学习，了解到在未来漫长的人生中，他真正想要的是什么。
当你了解到他的经历时，你会发现他是一个独立思考能力很强的人，所以他现在也成为了我们的公司合伙人。同时，在两年前，他就把我“踢下”了 CTO 的位置。
这是我们在创业最开始阶段找人的一个办法，随着公司的逐渐壮大，我们开始在成都当地举办了一个叫做“UCD 书友会”的活动。
每个月固定的周末，我们会邀请一些朋友，以及公司的小伙伴，用一个下午的时间，与对设计和产品感兴趣的同行进行交流。这样的活动，不仅帮助我们扩大了成都本土的人脉资源，也让很多对当时还不那么火爆的「用户体验设计」感兴趣的人能够进入到我们的视线里。
在这期间，我们认识了现在做 Tower 交互设计师的小伙伴。当时，他是西南民族大学大四辍学的学生，曾经一个人骑车去过西藏，爱好是开卡丁车，现在他是四川省业余组冠军。
也是这样的人，让我们看到，当一个人非常热爱一件事时，他会非常投入地完成它。
上图就是他大四时的手稿，看了他的手绘原型设计图，我们就知道，他就是我们要找的小伙伴。
这是我们在第二阶段，也就是当你团队处于稍微成长的阶段时招聘的秘诀。
在我们推出 Tower 之后，团队逐渐有了一些口碑。这时，我们才能收到一些来自全国各地的简历。
可是，你仍然很难直接从简历上对候选人进行判断，因此我们确定了两点作为我们招募合适小伙伴的核心原则，这也是 Trello 的创始人 Joel Spolsky 在他的《面试指南》一文中所提到的：聪明，又能及时完成工作。
其实这是两个特别简单的原则，我们只需要在 Tower 上给应聘者一些具体的任务让他去执行，通过观察他在完成任务过程中的速度和质量，以及看应聘者在完成这件事的过程中，他对 Tower 产生哪些思考，然后简单地判断他是否是我们现阶段所需要的人才。
举一个最近我们才招募到的一名设计师的例子，当时我们给他的任务是，让他重新设计 Tower 的任务详情页。
这位设计师，不仅很快就把作品交了上来，而且还交了一份 18 页的 Report：
他根据自己以前使用 Tower 的经验，以及身边一些朋友的可用性测试，做出了一份完整的 Tower 任务详情页重构的方案。通过这样的方式，你可以感受到，他具备我们目标成员的所有基本素质。
或许，我们不能说所有时候都能招到这种很好的小伙伴，但是很坦率地讲，我们公司的成员都能在团队中发挥出最大的价值。
因此，我认为我们应该像《奈飞文化手册》中谈到的那样，如果想要在公司做最核心的事情，那么公司人才密度一定要高。
我们人生中最宝贵的年华几乎有一半的时间都在工作，那么我们希望能和卓越的人共事，一起做出卓越的产品。对于彩程来说，这比我们能把公司做到多大规模更加重要。
找到对的人只是第一步，第二步就需要我们提高远程团队的协作效率。因此，我们持续不断地优化我们打造产品的流程。
目前，我们打造 Tower （产品）的主要流程总结起来有 6 个步骤：反馈收集、需求梳理、方案设计、迭代开发、功能测试、功能发布。
因为 Tower 是一款围绕用户去做的产品，所以我们一切都是以用户为起点，用户会通过各种各样的渠道向我们反馈在使用过程中所遇到的问题。而这些问题首先汇总到我们的客服团队，客服团队会尝试帮助用户，解决他们当前所遇到的问题。
当客服解决不了时，我们就会把问题分为两种类型，一种是用户遇到 Bug，另一种是用户向我们提出一个潜在的新需求。
对于两种不同类型的声音，客服都会在不同的项目里创建任务，然后交给产品部门的同事处理。
对于 Bug 类的任务，工程团队会快速修复上线；而对于新需求，产品经理会经过一些判断来决定是否实现。如果确定需要实现，产品经理会写下完整的问题背景、解决方案和实现方式，然后放到需求池里，等待工程团队开发。
工程团队会以一个固定的周期进行迭代开发。在开始迭代之前，工程师会从需求池里，按照优先级评估每个任务的规模 ，并且创建对应的迭代任务，直到迭代周期的资源被分配完毕。
功能迭代开发结束后，产品负责人会进行测试；在测试通过后，团队会安排上线计划，有些功能我们会开放给部分用户内测，有些功能会直接全量发布。
每个工程迭代周期结束后，我们会开会总结这次迭代遇到的问题和改进的方法。
新功能推送到用户手中，又开始新的循环：收集反馈、整理需求、设计方案、迭代开发、测试上线，周而复始。
对应上述流程，我们团队会用到以下几个核心项目：
「VOICE 2019」项目中，主要是用来收集用户新需求。从这个项目名称可以看出，我们每年都会为当年的用户反馈建立一个新的项目，每年都是一次全新的开始。
客服在创建用户反馈时，需要将用户问题背景了解清楚，比如用户的团队规模、对应的使用平台、反馈所属的功能模块等等，并建立好对应的任务。
Tower 的客服比较特殊，因为 Tower 的客服基本上都是我们的工程师，他们每周会有一天的时间轮岗专门做客服，所以他们对自己的产品比较了解，对用户的需求也比较了解。
接下来，产品经理每天会花固定的时间查看「VOICE 2019」里用户的反馈，区分哪些不做、哪些要做，哪些要深入了解场景后再做决定。
产品经理对用户需求了解清楚以后，会在「What's Next」项目里创建具体的需求任务，设定任务优先级，并进行方案设计。
整个「What's Next」项目有几个阶段：原始需求、设计中、待估点、迭代中、已发布。
那些评估通过的用户反馈会首先放在原始需求中，产品经理会预估一个优先级，然后针对高优先级的需求设计方案。我们对前期产品方案的设计要求比较仔细，一般每一个需求都会形成一篇固定的方案文档：
比如要更新在线编辑器，我们可以从目录看出，产品经理会写清楚用户使用场景、产品在各个终端下的方案、工程团队预计的资源投入，以及产出的目标。因为这份文档是后续团队讨论的基础，所以我们希望产品经理写得尽可能详尽一些。
产品经理完成方案设计后，会把这个任务放到待估点阶段，等待下一次迭代启动的时候进行评估。
我们的工程团队以前每 3 周处理一次迭代，现在已经改为每 6 周一次迭代了。
在每个迭代启动之前，我们会用一周的时间对上个迭代周期进行总结和全量发布，然后讨论下个迭代需要做的任务。在迭代启动会上，产品经理会和工程师会按照优先级，共同 Review「What's Next」项目的「待估点」清单里的需求：
产品经理会讲解需求背景和设计方案，工程师会在这个过程中反复追问用户的需求场景，问清楚潜在的坑，然后进行任务估点。
接下来，工程团队会在迭代项目「福克斯 RS」里进行协作。项目名称是一赛车的型号，而「福克斯」代表了专注，「RS」代表了速度，我们希望工程师在迭代周期里，用最快的速度，专注于自己的需求的交付。
这个项目我们首先分成了四个阶段：待处理、执行中、测试中、已完成：
在工程迭代过程中，我们会每天开视频会议，确定是否有新的「待处理」清单里的任务可以挪到「执行中」；已经完成的任务，挪动到「测试中」阶段，交给产品经理进行测试。
在迭代周期里，我们会要求工程师尽快地将功能推进至「可以品尝」的阶段，达到这个阶段后，负责人会把任务卡片从「执行中」清单里拖动到「测试中」阶段里，并且把产品功能部署到内测服务器上，供不同的团队内测。
在内测阶段，我们会使用灰度机制实现。早期，我们会用一些独立的服务器来搭建内测环境。使用这种方式最大的问题是，它和实际的生产环境是隔离的，因为这种独立的服务器上没有正式的数据。因此，团队内的同事往往只是走过场一样的在里面去「玩玩」就结束了测试，这并不是我们预期的目的，所以我们改进了内测的方式。
我们有一台和生产环境数据库直联的 Web 服务器，这台 Web 服务器会部署内测分支。我们会在后台给我们自己的团队增加一个内测的 Cookie 标志位，这样 Nginx 在收到每个 HTTP 请求时，就会根据这个标志位判断是否把请求转发到特定的内测服务器上。
当产品经理和团队其他成员在真实环境里测试了产品功能，并觉得产品功能没有问题之后，我们会发布给部分用户进行测试。
实际上，这个地方也会存在一定风险——因为 Tower 已经有几千个付费用户，当某些功能改动比较大时，我们很难确定直接开放给用户会引起什么后果，所以我们会把功能放在一个叫做「实验室」的栏目里，开放给用户申请试用：
通过这样的方式，首先我们可以判断出哪些功能需求是用户比较渴望的，如果申请人数寥寥无几，那就说明需求源头有问题，也就不必浪费时间继续下去；其次，申请的用户一般都是对这些功能非常渴望的，这些用户愿意容忍功能在发布初期的一些缺陷，也乐于在试用过程中给予我们更多的反馈。如果我们围绕这些用户的需求进行改进，那么后续的成功率会更高。
基本上，我们会用以上两种方式进行发布，以此保证我们的小团队不会跑偏。
同时，在迭代三周结束后，我们会用一周的时间来做迭代复盘，发布这个迭代对应的功能。
关于迭代的复盘，我们会在 Tower 的知识库里写一篇对应的文档来统计这个迭代周期团队的输出效率，类似这样：
根据这个迭代周期每个成员的负荷，以及最终实际可以发布的任务对应的点数，我们可以计算出每个成员在这个迭代周期里的输出效率。输出效率比较低的成员，我们可以在回顾周单独与他分析遇到的问题和改进方案，我们希望每一次迭代结束后，团队的输出效率都能有所提升。
以上就是我们团队打造 Tower 的几个主要流程。
团队虽小，但是流程仍在不停地优化，只有这样才能保证我们在远程工作时的工作效率。
大搜车技术 VP 沈淦 | AfterShip CTO 洪小军
马蜂窝 CTO 张矗 | 知道创宇 CTO & COO 杨冀龙
UCloud CEO 季昕华 | Charter CTO 黄勇
喜马拉雅 CTO 陆栋栋 | 有赞 CTO 崔玉松
（点击文字查看文章内容）