远程协作 8 个月后的总结：你需要避免的 4 个大坑

[miaozaiye]

写在程序员客栈 2.0 web 和 APP 都已完成的现在，给我们团队前面 8 个月的工作和观察经验做个小结。

从 15 年 1 月份我们远程协作团队组成到现在，这 8 个月我们发布了 4 个 web 大版本和不计其数的小修改； iOS 和 安卓分别发布了 8 个版本，从 1.0 到 2.0 ，其中 1.0 用了 2 个月的时间(包含春节）； 2.0 上线用了 2 个月的时间（包含从业务逻辑探讨，到最后 web, iOS & Android 端全部上线）。
中间小版本的迭代，基本是 2-3 周一次。

所有这些事情的完成，全部基于远程协作。
这么段时间的尝试，不能说多成功，但起码有了不少经验，踩过了不少坑，可以分享出来供大家参考。

所有经验适合于需要通过团队协作来完成产品的各位。

坑一：没找到正确的人，时间的浪费以月来计算

这也是最重要的问题。是我们一开始遇到的问题。现在看来，找人的时候，以下几点都需要考虑到：

• 有经验是前提条件，对于你要实现的产品，他有过类似开发经验， 80%的开发需求他已经了然于心，不仅能够实现想法，还能够基于自己的经验给出更优的建议；另外 20%他也知道去向谁求助。
• 很聪明，善于学习，是第二条。总有他没有做过的部分，但没关系，他会轻松告诉你，我去看下文档就会了。（目前我的亲身体会，我们开发团队童鞋们简直就是神笔马良，能想到，就能做到#_#)
• 同时，他还要有时间有兴趣，愿意来做你的项目。

以上三点，缺一不可。
这样的人肯定不便宜。是的，他们的正常薪水比平均水平高 50%-100%。
那么要不花少一点的钱，找个便宜点的新手？如果你准备好了接受需求往复确定的时间翻倍，开发的时间翻倍，测试之后再修改的时间翻倍。他走了之后别人因为代码难读懂不得不全部推翻重来。。。我也还是建议你不要做这个尝试了，因为最后你会发现：
成本并没有降低，也许更高，因为他薪水虽然是高手的一半，但时间却花了 2 倍不止；你还花了更长的时间，整个团队付出了更高的时间成本。得不偿失。

从去年 11 月份开始，这样的人我们花了 3 个月，才找到， 1 月底才组成我们自己的开发团队，然后开发速度飕飕的就上来了。

在做客栈的远程项目功能时，我们对所有申请签约的开发者，都像 8 个月前为自己找开发团队一样仔细筛选，然后再加上匹配算法，确保需求方的项目发布后，我们可以用 12 个小时，就为你对接到过去我们用了 3 个月才找到的优秀开发者。

如果去年 11 月我们就有了客栈的远程项目这个产品，我们的发展时间，可以再快 3 个月。

坑二：协作的顺序没安排好，将导致时间以周为单位被浪费

一个产品的简单顺序如下：

原型（一般需求明确的情况下，所有文档一周左右）->设计（根据页面而定，一般简单的产品 1-2 周），后端（根据功能需求而定，一般简单的产品 1-2 周）->前端开发（ 2-4 周）->测试->上线

对于我而言，每个版本，从原型到最后上线，都是在一个完整的时间段里面。作为创业小团队的产品负责人，同时还是测试负责人，意味着只有当产品上线了，这个版本的活才干完，然后才有精力开始计划下一个版本。

而这是之前效率低下的原因之一！在我们早期某个版本，需求，原型被同时传达给了设计和所有开发者。导致前端小伙伴足足等了一个多星期，才拿到可以开工的文档。我们的上线时间也因此延误了一周多。
实际上，当设计和前端交接完，你就应该请设计师开工准备下个版本的设计了-当然，这意味着你此时已经完成了下个版本的原型，准备好了和设计师探讨下个版本他需要做什么。

详细来说，一个更高效的流程应该是这样：

• 当你的前端开始开发 1.0 版本的时候，你已经在准备 1.1 的需求和原型
• 当你的前后端在进行联调的时候， 1.1 的设计已经开工
• 当 1.0 版本最终发布的时候， 1.1 的后端接口已经完成

这样，项目才会无缝运行下去，大家都能高效运转，每天都很精彩，尤其是 PM,每天都在精分:P 。

坑三：以为日子到了，事情就发生了？

远程协作，意味着大家没有面对面工作的机会，不会有这样的瞬间：他抬起头来，看到你，想起你这边的任务 deadline 快到了，于是快马加鞭一气呵成。

• 设计师会等产品原型确定；
• 后端会等产品逻辑，流程和文档确定；
• 前端会等静态设计，产品交互，流程文档，以及后端接口确定。

是的，每个环节都在等，而作为产品负责人的你，是拉动整个机器的引擎，是链条，是润滑剂。你不能等。

人只受眼前事物的影响，这是必然的心理状况。因此，作为远程项目的负责人，你可以学习 scrum 的方式，

• 每天和你的远程团队开一场虚拟立会。每天主动去提醒他，项目进展如何？要完成项目，还需要什么支持？什么到位了，什么没有到位？
• 每周有可交付任务，每周进行回顾总结，上周完成情况，本周计划如何。

我看到过有项目，负责人在项目建组的时候和大家打了个招呼，问了项目执行时间，然后就不再过问。前面一周组内都非常安静，没有人主动发言，待到预定的第一个 milestone,不出所料，全面延误。

坑四：以为对方随时都等着和你互动？别忘了你们有时差。

远程协作的团队，一般都有时差。

也许你在中国，他在美国，你睡觉时他正好上班；
也许你是全职，他是兼职，你下班了，他才开始上你的班。
即使你们都是全职，可你喜欢白天，他夜晚最有灵感，白天需要补眠。

这些问题都可能碰到，在最开始，就要商量好;做 milestone 的时候就要考虑到，所有需要沟通协作的点都要提前协商好时间（ Basecamp 的创始团队在他们非常有名的《 rework 》一书中建议，远程协作的团队确保每天 2-4 小时的共同工作时间是较好的。）

我们的经验小结

1. 高质量的人才是高效率完成项目的基础，选对了人，就是节省了时间和金钱。
2. 根据项目流程提前做好人员安排，严格遵守 原型-设计-后端-前端的顺序，是多方协作的基础。
3. 项目负责人要主动推动每个环节前进，而不是等待。
4. 提前协商好 milestone 和共同工作时间，能提升协作效率。

我相信远程协作是未来的趋势，也是远程的坚定实践者。
国外已经有非常值得学习的对象，创造了 Basecamp,Rails on Ruby 的 Basecamp 公司（前 37signal)是一个典范：他们的员工分布在两个大洲 8 个城市，他们同时享受着生活和工作的乐趣，他们不用等到退休以后才去做自己想做的事情。
希望有一天，我们也能实现这样的目标。

---

如果你是远程工作者，欢迎来和我聊聊，一起来探索这个目标。
我的邮箱: [email protected]

[mittya]

感谢分享

---

讲远程的那本书不是《 Remote 》？还没看过《 Rework 》不太确定

[miaozaiye]

@mittya remote 更专注在讲远程， rework 更有名：）

[JhOOOn]

技术够了，在尝试这个