如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

85510295 2020-01-03

12 月 9 日, TGO 鲲鹏会武汉分会成功组织了第一次小组活动。在此次小组活动中,Tower 联合创始人 & TGO 鲲鹏会武汉分会会员徐峥带来了《Tower 团队 72 个月远程协作实践》的精彩分享。

在分享过程中,徐峥分享了 Tower 的成长经历,以及 72 个月远程工作的成功实践经验。以下为徐峥现场分享内容,Enjoy:

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

今天,我给大家带来的分享主题是 Tower 团队 72 个月远程工作的成功实践。

因为我也是初来乍到,所以想先给大家介绍至今为止 Tower 团队的成长历史,这和我们的远程协作也有极大的关系。

实际上,彩程设计成立的时间还挺早的。彩程设计成立于 2008 年,公司 CEO 是沈学良,我们都叫他“老沈”。

最早我们开始创业时,我们主要做的是用户体验设计外包。那时,国内还很少公司有「用户体验」「UCD」「UX」等概念,所以我们最开始是抱着当时上市公司——亚信联创的大腿,帮他们做一些运营商业务系统的用户体验设计优化。

因为他们的系统都用了很长时间,所以系统已经变得非常难用。实际上,那时已经是 Web 时代了,但是他们很多软件仍然在使用 CS 架构。

当时,我们主要负责的是四川、辽宁、北京 10086 网上营业厅、客服系统、网管系统、亚信海外的一个计费系统等等。在整个设计过程中,我们团队累积了不少产品设计上的经验。

2011 年,随着移动互联网的兴起,我们团队也开始为一些移动 App 做一些设计外包,包括成都本地的咕咚运动、易到用车等等。

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

在做了几年用户体验设计外包后,我们逐渐开始想要打造一款属于自己的产品。于是,从 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 本身也是一个远程工作模式的团队,所以我们觉得是不是可以通过这样的方式,更好地打造产品。

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

第二个原因是,我们不想把时间浪费在通勤上

2008-2013 年,我们团队在一起差不多 4-5 年的时间。在这期间,我们团队更换过非常多的办公地点,这也是希望我们团队的小伙伴不要花太多的时间在路上。但是无论我们更换到哪一个地方办公,都会有将近一半的小伙伴每天平均花费 2 小时的时间在上下班通勤路上。

我们可以来计算一下,如果我们取平均值 1.5 个小时,每个成员一周在通勤的时间就是 7.5 个小时,扣除掉节假日和休假之类的时间,每年我们会有 300-400 个小时在路上。

我们觉得如果能把这个时间节省下来,那么大家可以用这个时间学习很多东西,或者做其他更有意义的事情。况且,当今城市交通状况越来越差,不管是乘坐公共交通工具还是开车,大城市的早高峰和晚高峰都让人心情沮丧。

第三个原因是,整个核心团队在一起工作 5 年左右的时间了,我们发现大家来到办公室,也是各自处理手头的事情

如果遇到需要沟通的时候,为了避免打扰别人,我们还会刻意的把讨论地点定在公司楼下,或者比较偏远的会议室。这也让我们考虑,是不是非要大家聚在一起才能做好 Tower。

于是,在 2013 年春节之后,我们就把团队“解散”了,开始远程办公。

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

远程工作的好处

不得不承认的是,远程工作确实会带来不少好处。

第一个好处,也是我认为最大的好处——个人生活质量会得到非常大的提升

在远程工作的前几年,我每天基本规律得像机器一样。每天早上 7:00 起床,然后走路去家对面的健身房游泳;8:30 开始工作,直到 12:00,接着吃午饭、睡午觉;14:00 继续开始工作,直到 19:00,之后再去家附近的一个社区图书馆看书;20:30 回家,最后洗漱睡觉。

每天早上,我从健身房回家的路上,看着早高峰行色匆忙的人,想着自己再也不用去挤公交地铁的时候,感觉自己幸福极了。

第二个好处是,可以让团队保持更加专注的状态

平时在办公室时,你可能常常会被周围说话、开会的声音打扰。同时,根据报告显示,当长时间在同一个环境工作时,你会因为自己的审美疲劳,导致自身注意力下降,让你影响到自身的工作效率。

因此,我们当年在提倡远程工作时,从来不是提倡在家办公,或者是旅行办公,而是不管你在哪个环境,只要是你能保持工作效率最高的地方就可以。

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

2014 年,我们曾经开源了一个叫 Simditor 的文本编辑器,它在 Github 上有 4.5k 的 stars,这也算是一个小有名气的开源项目。这个小东西就是我们团队里一个前端工程师,他自己跑到丽江待了两个月,独自开发的产物。

另外,我们在远程之后发现,超过 4 个人以上的会议时间会明显缩短,频次也会降低。

以前,你很容易不自觉地加入到一个会议,然后把会议变得比较冗长;当开始远程办公之后,因为人不在一起,大家说话的成本会变得非常高,所以在每次开电话会议之前,大家都会先在 Tower 上把想法写清楚后,再和大家做沟通,这也是在远程之后留下的好习惯。

第三个好处是,招人会比较方便

因为我们是一个小的创业团队,所以我们在薪资上肯定比不上大厂,那么我们怎么去吸引更多的人才加入呢?

远程就可以成为我们这种创业团队的吸引力。

同时,我相信敢于选择远程工作的小伙伴,大多数是都是技高人胆大的人,他们自身肯定也比较有实力的,所以他才敢选择一条比较困难的路。远程是在变相地帮助我们筛选候选人,这样招募进来的小伙伴普遍水平都比较高。

最后,因为是远程,所以我们完全可以招募全国的人才,而不仅仅是局限于武汉,或者成都。当你撒的网够大时,你的鱼才会变多。

以上这 3 点,是我认为远程工作带来的最大好处。

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

如何保证远程的工作质量和效率

接下来,可能就是大家最关心的一点,远程工作团队该如何保证质量和效率呢?

根据我们多年的实践结果来看,最核心的无非 2 点:

  • 招募对的人;
  • 不断优化团队业务流程。

###招募对的人

不知道大家有没有看过丹尼尔·平克的这本书:《驱动力》?

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

丹尼尔·平克在书中谈到,在创意工作领域,如果想要激发员工动力,唯一靠得住的办法就是鼓励他们从事自己热爱的、在乎的事情,“胡萝卜”加“大棒”在创业公司,对激励员工是无效的。

因此,对于我们的团队来说,如果想要远程办公,那么找到自驱力强、专精、对我们的事情是热爱的人,就是至关重要的事情。

在创业的不同阶段,我们招聘的办法各有不同。

2008 年,刚回到成都开始创业的时候,我们的当务之急就是扩充团队。

那时,我们的团队既没有名气,也没有钱,如果贸然做各种广告,或者去招聘网站上发招聘帖子,可想而知,效果是很差的。

因此,这时最好的办法就是从熟人下手

那时,彩程有一半的员工都是成都电子科技大学里“栋力无限”学生社团的成员,因为老沈(沈学良,彩程 CEO)是社团发起人。我们会在“栋力无限”学生社团里,找到想要出来实习和锻炼的学生。

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

上图中的小伙伴就是我们当时找的同学,他现在也是我们团队中的 CTO。

那时,他是成都电子科技大学大四正在休学的学生。在休学期间,他跑到香港大学旁听。希望通过更多的学习,了解到在未来漫长的人生中,他真正想要的是什么。

当你了解到他的经历时,你会发现他是一个独立思考能力很强的人,所以他现在也成为了我们的公司合伙人。同时,在两年前,他就把我“踢下”了 CTO 的位置。

这是我们在创业最开始阶段找人的一个办法,随着公司的逐渐壮大,我们开始在成都当地举办了一个叫做“UCD 书友会”的活动。

每个月固定的周末,我们会邀请一些朋友,以及公司的小伙伴,用一个下午的时间,与对设计和产品感兴趣的同行进行交流。这样的活动,不仅帮助我们扩大了成都本土的人脉资源,也让很多对当时还不那么火爆的「用户体验设计」感兴趣的人能够进入到我们的视线里。

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

在这期间,我们认识了现在做 Tower 交互设计师的小伙伴。当时,他是西南民族大学大四辍学的学生,曾经一个人骑车去过西藏,爱好是开卡丁车,现在他是四川省业余组冠军。

也是这样的人,让我们看到,当一个人非常热爱一件事时,他会非常投入地完成它。

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

上图就是他大四时的手稿,看了他的手绘原型设计图,我们就知道,他就是我们要找的小伙伴。

这是我们在第二阶段,也就是当你团队处于稍微成长的阶段时招聘的秘诀

在我们推出 Tower 之后,团队逐渐有了一些口碑。这时,我们才能收到一些来自全国各地的简历。

可是,你仍然很难直接从简历上对候选人进行判断,因此我们确定了两点作为我们招募合适小伙伴的核心原则,这也是 Trello 的创始人 Joel Spolsky 在他的《面试指南》一文中所提到的:聪明,又能及时完成工作。

其实这是两个特别简单的原则,我们只需要在 Tower 上给应聘者一些具体的任务让他去执行,通过观察他在完成任务过程中的速度和质量,以及看应聘者在完成这件事的过程中,他对 Tower 产生哪些思考,然后简单地判断他是否是我们现阶段所需要的人才。

举一个最近我们才招募到的一名设计师的例子,当时我们给他的任务是,让他重新设计 Tower 的任务详情页。

这位设计师,不仅很快就把作品交了上来,而且还交了一份 18 页的 Report:

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

他根据自己以前使用 Tower 的经验,以及身边一些朋友的可用性测试,做出了一份完整的 Tower 任务详情页重构的方案。通过这样的方式,你可以感受到,他具备我们目标成员的所有基本素质。

或许,我们不能说所有时候都能招到这种很好的小伙伴,但是很坦率地讲,我们公司的成员都能在团队中发挥出最大的价值。

因此,我认为我们应该像《奈飞文化手册》中谈到的那样,如果想要在公司做最核心的事情,那么公司人才密度一定要高。

我们人生中最宝贵的年华几乎有一半的时间都在工作,那么我们希望能和卓越的人共事,一起做出卓越的产品。对于彩程来说,这比我们能把公司做到多大规模更加重要。

不断优化协作流程

找到对的人只是第一步,第二步就需要我们提高远程团队的协作效率。因此,我们持续不断地优化我们打造产品的流程。

目前,我们打造 Tower (产品)的主要流程总结起来有 6 个步骤:反馈收集、需求梳理、方案设计、迭代开发、功能测试、功能发布。

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

因为 Tower 是一款围绕用户去做的产品,所以我们一切都是以用户为起点,用户会通过各种各样的渠道向我们反馈在使用过程中所遇到的问题。而这些问题首先汇总到我们的客服团队,客服团队会尝试帮助用户,解决他们当前所遇到的问题。

当客服解决不了时,我们就会把问题分为两种类型,一种是用户遇到 Bug,另一种是用户向我们提出一个潜在的新需求。

对于两种不同类型的声音,客服都会在不同的项目里创建任务,然后交给产品部门的同事处理。

对于 Bug 类的任务,工程团队会快速修复上线;而对于新需求,产品经理会经过一些判断来决定是否实现。如果确定需要实现,产品经理会写下完整的问题背景、解决方案和实现方式,然后放到需求池里,等待工程团队开发。

工程团队会以一个固定的周期进行迭代开发。在开始迭代之前,工程师会从需求池里,按照优先级评估每个任务的规模 ,并且创建对应的迭代任务,直到迭代周期的资源被分配完毕。

功能迭代开发结束后,产品负责人会进行测试;在测试通过后,团队会安排上线计划,有些功能我们会开放给部分用户内测,有些功能会直接全量发布。

每个工程迭代周期结束后,我们会开会总结这次迭代遇到的问题和改进的方法。

新功能推送到用户手中,又开始新的循环:收集反馈、整理需求、设计方案、迭代开发、测试上线,周而复始。

对应上述流程,我们团队会用到以下几个核心项目:

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

「VOICE 2019」项目中,主要是用来收集用户新需求。从这个项目名称可以看出,我们每年都会为当年的用户反馈建立一个新的项目,每年都是一次全新的开始。

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

客服在创建用户反馈时,需要将用户问题背景了解清楚,比如用户的团队规模、对应的使用平台、反馈所属的功能模块等等,并建立好对应的任务。

Tower 的客服比较特殊,因为 Tower 的客服基本上都是我们的工程师,他们每周会有一天的时间轮岗专门做客服,所以他们对自己的产品比较了解,对用户的需求也比较了解。

接下来,产品经理每天会花固定的时间查看「VOICE 2019」里用户的反馈,区分哪些不做、哪些要做,哪些要深入了解场景后再做决定。

产品经理对用户需求了解清楚以后,会在「What’s Next」项目里创建具体的需求任务,设定任务优先级,并进行方案设计。

整个「What’s Next」项目有几个阶段:原始需求、设计中、待估点、迭代中、已发布。

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

那些评估通过的用户反馈会首先放在原始需求中,产品经理会预估一个优先级,然后针对高优先级的需求设计方案。我们对前期产品方案的设计要求比较仔细,一般每一个需求都会形成一篇固定的方案文档:

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

比如要更新在线编辑器,我们可以从目录看出,产品经理会写清楚用户使用场景、产品在各个终端下的方案、工程团队预计的资源投入,以及产出的目标。因为这份文档是后续团队讨论的基础,所以我们希望产品经理写得尽可能详尽一些。

产品经理完成方案设计后,会把这个任务放到待估点阶段,等待下一次迭代启动的时候进行评估。

我们的工程团队以前每 3 周处理一次迭代,现在已经改为每 6 周一次迭代了。

在每个迭代启动之前,我们会用一周的时间对上个迭代周期进行总结和全量发布,然后讨论下个迭代需要做的任务。在迭代启动会上,产品经理会和工程师会按照优先级,共同 Review「What’s Next」项目的「待估点」清单里的需求:

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

产品经理会讲解需求背景和设计方案,工程师会在这个过程中反复追问用户的需求场景,问清楚潜在的坑,然后进行任务估点。

接下来,工程团队会在迭代项目「福克斯 RS」里进行协作。项目名称是一赛车的型号,而「福克斯」代表了专注,「RS」代表了速度,我们希望工程师在迭代周期里,用最快的速度,专注于自己的需求的交付。

这个项目我们首先分成了四个阶段:待处理、执行中、测试中、已完成:

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

在工程迭代过程中,我们会每天开视频会议,确定是否有新的「待处理」清单里的任务可以挪到「执行中」;已经完成的任务,挪动到「测试中」阶段,交给产品经理进行测试。

在迭代周期里,我们会要求工程师尽快地将功能推进至「可以品尝」的阶段,达到这个阶段后,负责人会把任务卡片从「执行中」清单里拖动到「测试中」阶段里,并且把产品功能部署到内测服务器上,供不同的团队内测。

在内测阶段,我们会使用灰度机制实现。早期,我们会用一些独立的服务器来搭建内测环境。使用这种方式最大的问题是,它和实际的生产环境是隔离的,因为这种独立的服务器上没有正式的数据。因此,团队内的同事往往只是走过场一样的在里面去「玩玩」就结束了测试,这并不是我们预期的目的,所以我们改进了内测的方式。

我们有一台和生产环境数据库直联的 Web 服务器,这台 Web 服务器会部署内测分支。我们会在后台给我们自己的团队增加一个内测的 Cookie 标志位,这样 Nginx 在收到每个 HTTP 请求时,就会根据这个标志位判断是否把请求转发到特定的内测服务器上。

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

当产品经理和团队其他成员在真实环境里测试了产品功能,并觉得产品功能没有问题之后,我们会发布给部分用户进行测试。

实际上,这个地方也会存在一定风险——因为 Tower 已经有几千个付费用户,当某些功能改动比较大时,我们很难确定直接开放给用户会引起什么后果,所以我们会把功能放在一个叫做「实验室」的栏目里,开放给用户申请试用:

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

通过这样的方式,首先我们可以判断出哪些功能需求是用户比较渴望的,如果申请人数寥寥无几,那就说明需求源头有问题,也就不必浪费时间继续下去;其次,申请的用户一般都是对这些功能非常渴望的,这些用户愿意容忍功能在发布初期的一些缺陷,也乐于在试用过程中给予我们更多的反馈。如果我们围绕这些用户的需求进行改进,那么后续的成功率会更高。

基本上,我们会用以上两种方式进行发布,以此保证我们的小团队不会跑偏。

同时,在迭代三周结束后,我们会用一周的时间来做迭代复盘,发布这个迭代对应的功能。

关于迭代的复盘,我们会在 Tower 的知识库里写一篇对应的文档来统计这个迭代周期团队的输出效率,类似这样:

如何攻克异地协作难题?看 Tower 的 72 个月远程工作实践

根据这个迭代周期每个成员的负荷,以及最终实际可以发布的任务对应的点数,我们可以计算出每个成员在这个迭代周期里的输出效率。输出效率比较低的成员,我们可以在回顾周单独与他分析遇到的问题和改进方案,我们希望每一次迭代结束后,团队的输出效率都能有所提升。

以上就是我们团队打造 Tower 的几个主要流程。

团队虽小,但是流程仍在不停地优化,只有这样才能保证我们在远程工作时的工作效率。

相关推荐