Tower 团队 48 个月远程实践

原文地址: https://tower.im/help/articles/73

这是古灵 2017 年 03 月 18 日在成都中生代技术大会上的分享

我们的历史

彩程设计是 2008 年在成都成立的，CEO 叫沈学良，大家叫他老沈。我 2008 年的时候还在成都电子科大读研究生，名义上虽然是在上学，但实际上从 2006 年开始就一直在跟老沈做事情了，所以 08 年老沈回成都创业的时候，我想反正年轻，而且创业是一件多么自由的事情啊，那就试试呗，谁知道这一试就一直试到了今天。

我们 08 年最开始做的事情是用户体验设计外包，那个时候国内还很少有公司知道「用户体验」或者「UCD」这样的概念。最开始我们做的比较多的，是帮一些电信运营商，像亚信联创去做他们业务系统的体验优化设计。传统的电信运营商公司的业务系统多半是跑了很多年的，在底层架构上非常稳定，但是因为那个时候大多数业务系统并不太关注用户的使用体验，这些产品的设计往往都是极其复杂的。所以从 08 年开始我们帮着这些基础服务运营商优化他们的系统，亚信当时的四川、辽宁、北京 10086 网上营业厅，还有客服系统、网管系统、亚信海外的一个计费系统，都是我们帮助他们重新设计的。在这个过程中我们自己团队也积累了很多产品上的经验，特别是怎么把复杂的东西简单化的思考方式，以及在前端技术方面积累了很多。

后来随着移动互联网的兴起，我们团队从 2010 年开始也为一些移动 APP 做设计外包，比较著名的有成都本地的咕咚运动，还有易到用车，这些 APP 的早期版本的设计都是我们和客户合作的结果。但是随着做外包的时间越来越久，我们发现如果继续做下去，会面临一些问题。

首先是整个行业会逐渐成熟起来，互联网企业会慢慢的掌握设计的技巧，并且因为随时都能了解用户实际使用的感受，所以互联网企业用自己的产品经理和设计师，从长远来看，一定会比外包给设计公司做设计更合适。其次，如果我们要把这艘小船往更开阔的海域行驶，只做设计外包的话肯定是不行的。所以我们团队从 2011 年开始，就试着做自己的产品。

在推出 Tower 之前，我们做过另外两款给团队使用的工具，Teamcola 和 Designboard。前者是一个用于记录每天工作时间的工具，在类似一个日历的界面上拖动，然后记录每天的工作内容，并且团队成员彼此可以共享。这个产品最初只是为了解决我们自己做设计外包的问题，就是我们的一些客户是按照工时付费的，我们要记录设计师每天的工作时间，好最后汇总成工单找用户结算，做了 Teamcola 以后，发现还挺好用，于是干脆就把它开放出来，试了试水。

另外一款叫做 Designboard 的产品，和 Teamcola 诞生的背景也很类似，也是我们自己在做外包的过程中，发现怎么交付设计稿，怎么围绕设计稿进行讨论这件事情可以交给工具来处理，于是我们自己打造了这么一个产品，它可以把设计图上传，组织自己的设计板，然后针对设计图进行评论。

这两款小试牛刀的产品让我们团队积累了做产品的原始经验，我们以前只是帮别人生孩子，现在终于开始学着自己生了。

到了 2012 年下半年，我们推出了 Tower 这款协作软件，这款产品上线第一天的注册用户数，就远远超过了 Teamcola 和 Designboard 的总和，我们也在随后一个月就拿到了红杉的 A 轮投资，于是几个创始人商量了一下，决定停止所有外包业务，转向浩瀚的企业市场领域。

除了从一个设计外包公司转型成了产品公司，2013 年开始远程办公也是我们团队的一个非常大胆的举动，后面我会介绍关于远程工作的原因和经验。先来看看，现在 4 年多时间过去了，我们团队从当时的 10 来个人，成长到现在将近 100 人，我们取得了哪些成果。

首先是 Tower 这个产品，现在是中国市场排名第一的协作软件，有超过 50 万的注册团队，带来了 700 万的注册用户，这些用户每天在 Tower 上产生大量的任务、讨论、文档和文件，如果把 Tower 比作写字楼的话，这应该是全国最大的一栋写字楼了。

另外，我们从 2015 年开始打造的另外一款人力资源类软件「知人」，去年下半年正式发布，这款产品相比 Tower，面对的业务场景更加复杂，为了能够做到自动计算工资，我们做了考勤、请假、公出、加班等出勤类产品的功能，还做了和工作流产品类似的审批流功能，还做了电子合同签署功能，更不用说基础的人事、社保公积金、期权功能，以及对接的滴滴打车、企业微信、摩卡招聘等等第三方服务。

从产品的复杂程度上来讲，知人是一款远超 Tower 的产品，从推广到市场的结果来看，知人也是目前市面上产品形态最完备的人力资源 SaaS 产品，能够支撑从几十人的公司到几千人的公司的人力资源日常事务。而这个结果，也是整个团队在远程工作的模式下做到的。

为什么要远程工作

有三个驱动我们远程工作的原因，一是产品原因，二是不愿意再花时间在一些麻烦事上，三是最重要的一点，就是因为彼此信任。

2013 年我们决定要开始远程工作，当时最大的一个初衷是想要通过这种方式，把产品打造得更好。这么说挺奇怪的，为什么不是大家聚在一起没日没夜的加班，而是干脆要分开来做事情呢？这是因为 Tower 这款产品本身的特点决定的，我们在 2012 年的时候冒出来了一个大胆的想法，就是如果一款协作类型的产品，能够完全支持一个远程团队的日常协作的话，那么它对于那些天天聚在一起的团队来说应该更不在话下了。

种瓜得瓜，后来的事实证明，虽然我们没法证明 Tower 对所有类型的团队都适用，但是它确实是对于远程工作者最为友好的工具，我们是最早支持 Email 回复、微信公众号、视频会议的协作工具。

另外我们选择远程，是因为创业那么多年，我们换过好几个办公场所，每次换个地方就要折腾网络、桌椅、吃饭等各种麻烦的问题，更别提花在路上奔波的时间。我们在 2013 年初租的最后一个办公场地快要到期的时候，突然发现要是继续待下去，大家都觉得有些审美疲劳，但是如果要想找新的地方，又会是一件劳心劳力的事情，加之我们团队最为欣赏和喜欢的一只外国团队 37signals 也是远程办公的模式，所以我们就开始琢磨这事儿的可行性了。

最后，前面跟大家啰嗦了半天公司的发展历程，因为我们从 2008 年到 2013 年，核心团队都在一起工作，5 年时间让彼此变得非常默契与信任，我们知道各自的长处和短板，核心团队在一起走了那么长的时间也没有人选择离开，说明大家的长远目标是高度一致的，加之当时的主要核心成员都在同一个城市，也觉得随时可以找个地方聚在一起，所以就更加觉得远程这个事情没什么可担心的了。

于是 2013 年春节后，我们就各自解散回家了。哦，我没有回家，而是买了张机票飞到英国去待了 3 个月，彻底远程了。

远程工作的好处

那么，这么多年的远程工作，给我们带来的好处是什么呢？我们团队的远程工作应该划分为前三年和 2016 年这两段来看。

从 2013 年到 2015 年这三年，我们团队的人数增长是缓慢的，因为协作类型的产品相对来说并不复杂，我们也不想用搭建销售团队的方式来获取收入，因此总是想保持小规模的状态来打造产品。这个时候远程工作带给我们最大的好处主要有两点。

首先不得不承认的是，远程工作会让个人的生活质量得到极大的提升，我在远程工作的前几年，基本上每天的生活可以规律得像机器一样。每天早上 7 点左右起床，走路 5 分钟去家对面的健身房游泳一个钟头，然后回家吃早餐，8点半左右开始工作，中午 12 点在家做午饭，然后小睡一觉到下午 2 点左右开始继续工作，工作到晚上 7 点，走路 10 分钟去家附近的一个社区图书馆看书到 8 点半，或者在家看部电影，结束以后处理工作到晚上 11 点，上床睡觉。

每天早上从健身房回家的路上，看到匆忙上班的人群，想着自己再也不用去挤公交地铁的时候，幸福极了。

其次就是工作上的，「专注」是远程办公能够获得的极大的好处。如果是一帮人聚在一起，难免时不时会被打扰，周围的环境也容易把你的注意力吸引走。远程以后，团队在怎么提高效率方面做了很多努力和尝试，这些努力里面就包括怎么样让每个成员都能更加专注的完成任务。远程所提倡的并不是「在家工作」，更不是「旅行办公」，而是「在任何你认为自己效率最高的地方工作」，所以我们有很多成员会去自己喜欢的咖啡店，或者干脆跑到偏远的小镇上去工作。

2014 年我们曾经开源过的一个文本编辑器 Simditor，就是一个前端工程师跑到丽江去，独自开发了 2 个多月的产物。

远程工作后，我们超过 4 个人参与的会议数量明显减少，以前聚在一起的时候，不管是随便找个同伴，还是同伴可能自己无意识的加入，都会让会议变得很冗长。远程以后因为人不在一起，「说话」的成本变高，导致说话之前做的准备工作就会相对充足，比如会在 Tower 上形成具体的文字，或者能够忽略的不重要的事情，就直接被忽略掉了。这是远程带来的好处。

后来到了 2015 年以后，我们开始转做知人，这个产品如前所述，比 Tower 复杂很多，因此我们开始扩张团队，包括工程师，这个时候，远程的工作性质能从三个方面帮助我们招募到自己喜欢的人才。

首先，在薪资肯定比不过 BAT 的前提下，远程可以加持我们这种创业团队的吸引力，让候选人至少能够时不时的惦记你一下。

其次，那些敢于选择远程工作的成员，一般都是艺高人胆大的，普通的工程师可能更愿意找一个能上班的地方，让自己可以融入到群体里面，但是作为创业者，我们更希望的是招募那些更独立的，不畏惧「与众不同」的伙伴，所以远程也能变相帮助我们筛选候选人，这样招募进来的小伙伴普遍水平都比较高。

最后，因为是远程，所以可以完全的跨地区全国招募，网子撒的大，鱼儿才会多。

如何保证工作质量和效率

找到对的人

毋庸置疑，找人是创业公司的重中之重，在创业的不同时期，找到优秀的小伙伴都有不同的方法和渠道。

在 2008 年刚回成都开始创业的时候，我们还叫「成都彩程数字科技有限公司」，一个所谓的科技公司，但是能写代码的只有我一个人，所以当务之急就是赶紧扩充团队。我们没有足够的资金和成本去打招聘广告，而且可预见的是这个阶段就算打广告也不可能有什么好效果，这个时候最好的办法就是从身边的熟人「下手」。彩程当时一半的员工都曾经是电子科大一个叫做「栋力无限」的学生社团的成员，老沈甚至还是这个社团的发起人，所以当时我们很快找到「栋力无限」的小同学，请他推荐一些愿意出来实习锻炼的学生给我们。

现在我们团队里的前端技术负责人就是在那个时候加入彩程的。当时这位小伙子才读大四，而且自己曾经休学一年，跑到香港大学去游荡了一年以后才回来的。就像我在前面说的，有这样经历的小伙子一般来说，思想都非常独立，也不害怕去走一条看似风险重重的路，结果也证明了这一点，他现在同样是公司的合伙人，我们产品里所有交互上比较复杂的组件，都是由他带领完成的。

随着公司渐渐发展，在 2010 年左右曾有一段时间，我们在成都本地举办过一个叫做「UCD书友会」的活动，每个月固定的一个周末，邀请一些朋友，以及我们公司的小伙伴，用一个下午的时间，跟一些对设计和产品感兴趣的同行进行交流。这样的活动帮助我们扩大了成都本土的人脉资源，也让很多对当时还不那么火爆的「用户体验设计」感兴趣的人能够进入到我们的视线里。这期间我们认识了后来做 Tower 的交互设计师，那个时候他也只是一个西南民族学院的大四辍学小孩，曾经一个人骑车去过西藏，现在的兴趣爱好是开卡丁车，据说现在已经是四川省卡丁车前三强了。当时看到他手绘的原型设计图我们就知道，这就是我们要找的小伙伴。

让这样的小伙伴加入团队的好处是，他们周围基本上会有一些和他们同样出色的朋友。比如我们的前端技术负责人，带来了另外一个后来的合伙人，我们现在的数据专家，而那位做 Tower 的交互设计师则推荐了一位优秀的视觉设计师，我们在 Tower 里看到的那些漂亮的原画，都出自这位伙伴之手。

后来公司做的产品有了一些口碑之后，我们逐渐能收到一些全国各地的简历了，这个时候我们就需要提炼出对于团队来说，怎么才能从这些简历中找到优秀人才的方法了。

简单地说，我们在整个面试和笔试流程中，对人的考察的核心因素有两点，第一是他是不是足够聪明，第二是他对于我们在做的事情的认同感。

聪明的同伴有两个非常重要的判断标准，一是对产品的理解力，当你在跟一个聪明的小伙伴讨论产品需求的时候，他甚至能先于你想到很多潜藏的问题，以及这些问题的解决方案。第二是他的协作能力，他有没有在 Tower 上拆解自己的任务，能不能够用流畅的语言描述遇到的问题。

而小伙伴对我们团队和做的产品的认同感，是我们判断小伙伴是否合适的第二个标准。有些小伙伴是非常聪明的，但是在和他们合作的过程中，你却会觉得比较别扭。比如你跟他交流的时候，虽然他都知道产品的需求是什么，要做的改进是什么，但是就是投入不够，他会跟你抱怨说，产品的文档没有写好，有些代码写得很烂，但是自己却从不愿意主动去做改进。这其实本质上是对团队做的事情的认同感不够。如果认同感不够，那么这样的小伙伴在一起是走不长远的，他对于产品遇到的短期问题，也不会有足够的耐心。

我们并不能总是招到最好的成员，但是结果却一再证明，最后能真正在团队里发挥重大价值的，都是那些最好的 A Player。并且由于我们远程办公的特点，所以对于人的要求更是没法松懈，如果招募到一个资质平平的工程师，对于团队来说甚至是会带来极大的副作用，因为优秀的人对于那些不怎么优秀的人，总是没什么耐性的。

设计设计设计

招到对的人只是第一步，要提高远程团队的协作效率，尤其需要重视产品的前期设计，因为本来远程团队沟通成本是最高的，所以如果前期不围绕功能设计讨论透彻，开发了一段时间以后发现有问题，成本就太高了，这不是像大家坐在办公室里，随时一扭头就可以说，「诶，我怎么觉得这个地方有点问题」然后可以聚在一起解决掉的。

我们团队在开发一个功能点的时候，会要求产品经理至少写两份文档，一份叫做「思路笔记」，这份笔记主要是产品负责人个人对于功能点的思考，要解决的问题是什么，解决的思路是什么，有没有什么想得到的坑，怎么测试，上线以后用什么数据衡量功能是否成功。产品经理会把这份文档发给负责开发的工程师先看一阵子，然后大家会约定好一个时间进行远程视频会议，在视频会议上，每个人提出他们的问题，供产品经理参考。

接下来产品经理会去完成他的第二份文档，叫做「需求说明」，这份文档主要是明确具体的解决方案，根据需要，我们会去做一些具体的设计。如果功能比较简单，工程师根据现有的系统组件就能搭建出来，那么产品经理一般做一个草图即可，但是如果涉及的功能比较复杂，产品经理就需要在草图的基础上，寻求视觉设计师的帮助了。当这份需求说明文档完成后，我们会提前发给工程师再看一次，然后约时间再做一次视频会议。

这次视频会议因为有具体的设计图，所以工程师能更好的理解需求的意图，并且可以提出更具体的问题。像我前面说的，一旦试图省略掉前面的这些过程，那么必然会导致最后开发出来的产品功能考虑不完善，因为前面需要思索的时间，你偷懒了，那些自以为清楚的事情，往往根本就没有想清楚。所以最好的办法，就是用这些能够积累的的东西，把思想过滤出来。

设计这个事情随着做的产品越来越复杂，会变得越来越重要。在做像知人这样的产品的时候，有很多牵一发动全身的功能。比如就算是做一个简单的删除部门的功能，你都要考虑如果以前曾经在这个部门的员工重新入职，要怎么处理，于是重新入职的流程里就需要引入部门设置，然后你就会考虑除了部门以外，还有哪些属性是同样需要重置的，于是本来是在思考提供部门删除的功能，就会延伸为，先规范重新入职流程。问题一开始如果没有想清楚，很容易出现工程师吭哧吭哧做了半天，结果上线以后漏洞百出的情况。

所以，对于远程团队来说，产品迭代里的设计阶段会变得尤为重要，千万不要忽视它。

控制节奏

如果有游泳或者长跑习惯的朋友应该知道，在这些体育运动里，最重要的并不是瞬时的爆发力，而是始终如一的节奏。像长跑 10 公里，你如果能保持一个比较固定的速率的话，跑下来的时候人的感觉是很舒爽的。

我们在开发产品的时候，也需要做一些工作来保证产品的节奏感。主要是分组和迭代。

在做知人这款产品的时候，我们按照功能进行分组，比如电子合同这个具体的功能，就是两个工程师组成的一个小组，然后多个小组又会负责一个大的功能模块，比如电子合同，是属于人事模块下面的子功能，所以就会有好几个小组会被放在人事模块里面。属于人事模块的这些工程师一般不会做轮岗调整，因为他们做的越久，对人事业务就会越熟悉，也就越容易对产品功能做判断。但是人事模块里面的小组是会轮替的。比如做电子合同的两个工程师，一个季度以后会被调整去做组织架构，因为这些大的业务模块下的功能是彼此相通的，通过这种方式，工程师可以熟悉彼此所做的业务。

分好小组以后，我们会设置一个迭代周期，比如对于知人，就是两周一个迭代周期。我们的小组工程师会分为 A / B 两个 Team，在一个迭代周期里，如果 A 小组的工程师开发新功能的话，那么 B 小组的工程师就会负责处理 Bug。

在 Tower 里，我们会用两个项目把事情分开，一个项目我们叫做「战地」，这个项目会用看板的形式罗列所有待处理的需求，每个需求会关联到前面说的产品文档。

每个迭代周期开始的时候，开发新功能的工程师，按照需求的优先级认领任务，并把任务从需求池里拖动到「开发」清单里面。我们之所以用两周来做迭代，是因为一般来说，功能开发本身不会太久，因为需求一般都会拆分的比较细，但是开发完了以后，要上线去做测试，测试以后的改进时间也要预留进来，所以两周一次迭代是一个比较合适的长度。

在功能开发迭代之外的工程师，主要是处理另一个叫做「机械师」的项目里面的任务，里面主要是各种 Bug。当然，Bug 不会总是那么多，所以我们并不严格要求维护组的工程师在维护周期里只能做维护，我们希望产品功能能够尽快的推进，所以在维护期的工程师如果需要处理的 Bug 不多，他是会被要求提前去处理战地里的需求的。

如果把产品开发类比为体育运动的话，这种模式的训练强度明显是最高的。

善用工具

彩程设计从创建的第一天起，就在用各种提高我们工作效率和生产效率的工具。

对于远程团队来说，解决沟通是第一位的，我们用 Tower 解决工作计划的问题，在 Tower 里围绕项目、任务、文档和文件来沟通工作的计划，以及推进工作计划。但是也不可能把所有沟通都放在 Tower 上，所以我们团队平时还会重度使用企业微信这个 IM 产品。

对于 IM 工具的选择团队也是经过了很多尝试，从 Slack 还是 Beta 版本的时候，我们就开始尝试使用，到后来转到 Telegram，然后是钉钉，最后现在使用企业微信，对于工具的选择我们发现有两个重要的因素，一是工具要是所有人都能很快获得的。如果一直用 Slack，那么可能只是对工程团队友好，因为销售团队的同事不一定人人都会翻墙，而且产品的全英文也会导致有些同事使用起来产生障碍。所以如果是决定整个团队都长期使用的话，最好还是选择国内的产品。

其次是，这个工具要在产品设计上打动我们，让每个使用的成员觉得产品设计得很赞。而正是因为这个原因让我们最终选择企业微信，因为企业微信的设计更加简洁、舒服。

对于工程团队来说，最重要的几个工具是代码托管、集成测试、代码质量检查、持续发布和服务监控。我们曾经自己搭建过 gitlab 服务，3 年前的一次安全事故让我们明白其实自己搭建服务，并不比使用第三方靠谱平台安全，所以后来我们就把代码管理全部放到 github 了。

集成测试我们使用过 CircleCI 和 TravisCI，这两个工具都可以集成到 Github 里面，后者对前端组件的测试更加友好，前者在产品设计上我个人觉得优于后者，所以这两个平台都是很推荐大家使用的。

代码质量检查，我们使用一个叫做 CodeClimate 的服务，这个服务也是和 Github 的集成非常完美，在做 code review 的时候，可以直接在 Github 上看到一些代码质量的基本问题，工程师可以在 merge pull request 之前对提交的代码做基本的质量判断。

持续发布是我们自己写的一个定时发布工具，会在每天的三个固定的时间把 master 分支的代码发布到生产环境的服务器上面，这个定时发布工具在做代码发布的时候，会检查集成测试环境有没有跑过，只有当测试用例都跑过的情况下，才会做自动发布。如果发布失败，这个发布工具会给固定的一个微信公众号发告警通知，这样运维的同学就能去及时处理。

服务上线以后，我们会用各种工具来监控服务的质量，对于工程团队来说，首先就是各种报错的监控。我们使用 http://sentry.io 做程序运行错误的告警平台，这个 SaaS 产品允许设置一些 webhook 的回调地址，于是我们会根据告警的代码所属模块，自动在 Tower 的机械师项目里产生分配给对应工程师的任务，非常方便。

另外我们用 Newrelic 做性能监控，目前主要是对 Tower 的监控居多，像去年和钉钉的合作，有一阵子会从钉钉那边带来巨大的注册用户量，Newrelic 在分析到底是哪一层的服务出现了性能问题上是非常方便的。

我们还会用一个叫做 Mixpanel 的工具做用户行为的采集和分析，这主要是对产品经理的帮助更大，使用 Mixpanel 可以记录用户的行为轨迹，帮助产品经理对用户行为进行分析。

这些好的工具里的很多优秀的产品设计思想，正是我们自己打造自己产品时候的设计灵感的来源，深度使用好工具，能极大的提升整个团队的设计品味，这是除了提高团队工作效率之外的一个隐形的好处。

选择合适的技术

最后一点，也是一个很敏感的话题，虽然我们都知道「PHP 是世界上最好的语言」，但是我们团队还是选择了各种主流技术之外的一个冷门的技术栈，Ruby On Rails。

使用 Rails 的原因是，不仅仅是因为它是一个成熟度很高的框架，而且还因为这个框架背后的「价值观」。

一个互联网工程团队，一般都有两种属性，一种是技能属性，一种是产品属性，我们团队的工程师特别强调工程师的产品属性，而这种团队基因，注定了我们会选择 Ruby On Rails 作为当前的技术框架。我特别喜欢 Rails 的创始人 DHH 写的这篇文章：「The Rails Doctrine」。

Ruby 这门语言的出发点是为它的用户的「幸福」考量，而不是从纯粹的计算机科学的视角去发明的，这是 DHH 之所以会选择 Ruby 的初衷。Rails 框架继承了同样的价值观，相比于当前各种纷繁复杂的前后端分离框架，它在技术层面是否优劣，并不是它最重要的考虑因素，Rails 框架重点考虑的是，对于从 0 到 1 的 Web 产品开发，究竟什么样的框架能够让开发者尽快的输出产品功能，让用户去体验和使用，让用户在使用的过程中感到幸福。而 Rails 的天生的好处在于，同样作为一款产品，框架本身是为开发者的「幸福」考量的，这对于一个产品型团队来说，有助于工程师把所有注意力都放在「产品特性」本身上面。

让技术团队保持幸福感，把幸福感通过产品传递给用户，也是维持高效工作的一个基础。

远程工作适合什么样的团队

最后，可能大家会在心里开始默默评估远程工作是不是适合自己了。在我看来，你的团队如果特别小，或者特别久，这两者只要具备一条，那么你现在就可以考虑让团队远程工作了。

所谓特别小，一是团队规模小，二是做的事情小。在个人价值越来越凸显的今天，实际上我们的商业形式也会慢慢的转变，比如个人知识经济，那么可能两三个在一起就能做一些事情出来了，这种非常小的团队是很适合远程的，可以在全国，甚至全球范围内寻找志同道合、配合默契的伙伴。

另一种是核心团队在一起特别久的团队，像我们这样，公司的价值观已经形成，大家彼此呆久了也都足够信任（审美疲劳）了，做的事情也不会是一蹴而就，明天就收获成果的，那么也许可以试试远程。

不过我们也并不认为远程工作就是完美的，远程工作对于一些年轻的小伙伴来说，可能会造成巨大的孤独感，因为人毕竟是感情动物，需要交流，所以我们团队在招募工程师的时候，其实也会尽量在已有工程师的地区招募，这样我们每周五，会让同一个城市的工程师挑选自己喜欢的地方，大家带上电脑出门聚在一起工作。

另外，随着团队规模的扩张，我们也开始每年定期集中，比如 2016 年，整个工程团队一共集中过 3 次，大家在一起的时间总共差不多有 2 - 3 个月的样子，这样可以让新人更好的融入团队，也能集中在一起解决一些产品上重要的问题。

远程工作适合耐心的团队，适合愿意独自面对自己的团队，适合对目标有清醒认识的团队，适合单兵作战强悍的团队，如果你的团队是这样的，不妨一试。