V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
欢迎通过 V2EX 的 创造者 节点寻找创业伙伴。
推荐书目
Founders at Work 简体中文译本
Founders at Work
全世界的各种创业签证
StartUp Britain
Start-Up Chile
miaozaiye
V2EX  ›  创造者

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

  •  
  •   miaozaiye · 2015-09-22 20:20:55 +08:00 · 3367 次点击
    这是一个创建于 3352 天前的主题,其中的信息可能已经有所发展或是发生改变。

    写在程序员客栈 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 周)->测试->上线

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

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

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

    产品开发协作流程.png

    • 当你的前端开始开发 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]

    3 条回复    2015-12-20 22:19:47 +08:00
    mittya
        1
    mittya  
       2015-09-22 21:05:45 +08:00
    感谢分享

    ---

    讲远程的那本书不是《 Remote 》?还没看过《 Rework 》不太确定
    miaozaiye
        2
    miaozaiye  
    OP
       2015-09-22 21:14:10 +08:00 via iPhone
    @mittya remote 更专注在讲远程, rework 更有名:)
    JhOOOn
        3
    JhOOOn  
       2015-12-20 22:19:47 +08:00
    技术够了,在尝试这个
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5639 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 03:34 · PVG 11:34 · LAX 19:34 · JFK 22:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.