编者按:本文来自程序员客栈的投稿。文章写在「程序员客栈」2.0 web和APP都已完成的现在,给他们团队前面8个月的工作和观察经验做个小结。
从2015年1月份我们远程协作团队组成到现在,这8个月我们发布了4个web大版本和不计其数的小修改;iOS和Android分别发布了8个版本,从1.0到2.0,其中1.0用了2个月的时间(包含春节);2.0上线用了2个月的时间(包含从业务逻辑探讨,到最后web, iOS & Android端全部上线)。中间小版本的迭代,基本是2-3周一次。
所有这些事情的完成,全部基于远程协作。
经过这么一段时间的尝试,不能说多成功,但起码有了不少经验,踩过了不少坑,可以分享出来供大家参考。所有经验适合于需要通过团队协作来完成产品的各位。
坑一:没找到正确的人,时间的浪费以月来计算
这也是最重要的问题。是我们一开始遇到的问题。现在看来,找人的时候,以下几点都需要考虑到:
以上三点,缺一不可。
这样的人肯定不便宜。是的,他们的正常薪水比平均水平高50%-100%。
那么要不花少一点的钱,找个便宜点的新手?
那意味着你将承受更大的成本:需求往复修改的时间翻倍,开发的时间翻倍,测试之后再修改的时间翻倍,他走了之后别人因为读不懂代码而导致产品不得不全部推翻重来……我还是建议你不要做这个尝试了,因为最后你会发现:成本并没有降低,也许更高,因为他薪水虽然是高手的一半,但他的用时却是高手的2倍;你还花了更长的时间让整个团队付出了更高的时间成本,得不偿失。
从去年11月份开始,这样的人我们花了3个月,才找到,1月底才组成我们自己的开发团队,然后开发速度飕飕的就上来了。
在做客栈的远程项目功能时,我们对所有申请签约的开发者,都像8个月前为自己找开发团队一样仔细筛选,然后再加上匹配算法,确保需求方的项目发布后,我们可以用12个小时,就为你对接到过去我们用了3个月才找到的优秀开发者。
如果去年11月我们就有了客栈的远程项目这个产品,我们的发展时间,可以再快3个月。
坑二:协作的顺序没安排好,将导致时间以周为单位被浪费
一个产品的简单顺序如下:
原型(一般需求明确的情况下,所有文档一周左右)->设计(根据页面而定,一般简单的产品1-2周)->后端(根据功能需求而定,一般简单的产品1-2周)->前端开发(2-4周)->测试->上线。
对于我而言,每个版本,从原型到最后上线,都是在一个完整的时间段里面。作为创业小团队的产品负责人,同时还是测试负责人,意味着只有当产品上线了,这个版本的活才干完,然后才有精力开始计划下一个版本。
但这恰恰是之前效率低下的原因之一!在我们早期某个版本,需求,原型被同时传达给了设计和所有开发者。导致前端小伙伴足足等了一个多星期,才拿到可以开工的文档。我们的上线时间也因此延误了一周多。
实际上,当设计和前端交接完,你就应该请设计师开工准备下个版本的设计了。当然,这意味着你此时已经完成了下个版本的原型,准备好了和设计师探讨下个版本他需要做什么。
详细来说,一个更高效的流程应该是这样:
产品开发协作流程.png
这样,项目才会无缝运行下去,大家都能高效运转。
坑三:以为日子到了?事情就发生了
远程协作,意味着大家没有面对面工作的机会,不会有这样的瞬间:他抬起头来,看到你,想起你这边的任务Deadline快到了,于是快马加鞭一气呵成。
是的,每个环节都在等,而作为产品负责人的你,是拉动整个机器的引擎,是链条,是润滑剂。你不能等。
人只受眼前事物的影响,这是必然的心理状况。因此,作为远程项目的负责人,你可以学习Scrum的方式:
我们的周会总结
我看到过有项目,负责人在项目建组的时候和大家打了个招呼,问了项目执行时间,然后就不再过问。前面一周组内都非常安静,没有人主动发言,待到预定的第一个Milestone,不出所料,全面延误。
坑四:以为对方随时都等着和你互动?别忘了你们有时差
远程协作的团队,一般都有时差。
也许你在中国,他在美国,你睡觉时他正好上班;
也许你是全职,他是兼职,你下班了,他才开始上你的班。
即使你们都是全职,可你喜欢白天,他夜晚最有灵感,白天需要补眠。
这些问题都可能碰到,所以做Milestone的时候就要考虑到,所有需要沟通协作的节点,都要提前协商好时间。
我们的经验小结
我相信远程协作是未来的趋势,也是远程的坚定实践者。国外已经有非常值得学习的对象,创造了Basecamp,Rails on Ruby的Basecamp公司(前37signal)是一个典范:他们的员工分布在两个大洲8个城市,他们同时享受着生活和工作的乐趣,他们不用等到退休以后才去做自己想做的事情。希望有一天,我们也能实现这样的目标。