独立开发者如何避免“远程协作”的四大坑
题记：在「程序员客栈 」2.0 web 和 APP 均已完成之际，对我们团队过去 8 个月的工作和观察经验做一个小结。独立开发通常处于远程状态，作为远程开发者，你需要避免以下 4 个大坑。
从 2015 年 1 月份我们程序员客栈远程协作团队组建至今，这 8 个月里，我们发布了 4 个 web 大版本以及不计其数的小修改；iOS 和 Android 分别发布了 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 版本的后端接口已经完成。
如此，项目才能无缝推进，团队成员也能高效协作。
坑三：以为日子到了，事情就会自动完成
远程协作意味着团队成员没有面对面工作的机会，不会出现这样的场景：成员抬头看到你，便想起任务的截止日期临近，从而加快工作进度。
- 设计师会等待产品原型确定。
- 后端开发者会等待产品逻辑、流程和文档确定。
- 前端开发者会等待静态设计、产品交互、流程文档以及后端接口确定。
每个环节都在等待，而作为产品负责人的你，是推动整个项目前进的引擎、链条和润滑剂，不能被动等待。
人往往容易受到眼前事物的影响，这是正常的心理现象。因此，作为远程项目的负责人，可以借鉴 Scrum 的管理方式：
- 每日虚拟立会：每天与远程团队成员召开虚拟立会，主动了解项目进展情况，询问完成项目还需要哪些支持，以及哪些事项已经完成、哪些尚未完成。
- 每周交付与总结：每周设定可交付的任务，并进行回顾总结，包括上周的完成情况和本周的工作计划。
我曾见过这样的项目，负责人在项目组建时与成员简单沟通了项目执行时间后便不再过问。项目前期一周内组内十分安静，无人主动发言，到了预定的第一个里程碑，项目全面延误也就不足为奇了。
坑四：以为对方随时都等着和你互动，别忘了你们有时差
远程协作的团队通常存在时差问题。
- 也许你在中国，对方在美国，你睡觉时对方正好上班。
- 也许你是全职工作，对方是兼职，你下班时对方才开始为你的项目工作。
- 即使你们都是全职，但你习惯白天工作，对方夜晚灵感充沛，白天需要补觉。
这些情况都可能出现，因此在制定里程碑计划时，需要考虑到所有需要沟通协作的节点，并提前协商好时间。
我们的经验小结
- 选对人才：高质量的人才是高效率完成项目的基础，选对人就是节省时间和金钱。
- 合理安排流程：根据项目流程提前做好人员安排，严格遵循原型 - 设计 - 后端 - 前端的开发顺序，是多方协作的基础。
- 主动推动项目：项目负责人要主动推动每个环节前进，而不是被动等待。
- 提前协商时间：提前协商好里程碑和共同工作时间，能有效提升协作效率。
我坚信远程协作是未来的发展趋势，我也是远程协作的坚定实践者。国外有许多值得学习的范例，如创造了 Basecamp、Rails on Ruby 的 Basecamp 公司（前 37signal）。他们的员工分布在两个大洲的 8 个城市，既能享受生活，又能高效工作，无需等到退休后才去做自己想做的事情。希望有一天，我们也能实现这样的目标。