以文会友,聊一聊参与和管理软件开发外包的经验吧

  • d
    downey
    本人以前的一份工作,参加一个离岸开发的项目组,为网络设备做开发。总部在国外,与硬件无关的软件部分由国内的开发团队来做。项目做下来,没有太多问题。软件也升了几个大版本。现在来看,需求既明确又基本稳定,的确是一个很大的有利条件。因为开发针对的是相关设备的国际协议规范,打印成册后需要两只手才能拿起来。

    后来在另一个公司,为自助终端做开发。由于不是公司主营方向,又不想直接用别人的产品,于是开始时想交由外面的人来做。结果早早散场,后来是为公司招人来做,自己也投入进去,才算完了这桩事。

    总结上面这次管理外包的失败,觉得有几个比较大的因素:
    一、对方在实践中不能配合原型开发、快速迭代的要求,结果无论进度还是质量都难以掌控。
    二、不能有效地联络对方的实际开发人员,带来很多无谓的损耗。

    以上抛砖引玉,大家在这方面有什么经验呢。



    最后,近日手头有几个手机APP开发、微信开发的活儿,有兴趣了解更多的同学请说一声。
  • 华莱士
    这个问题我不认为能在帖子里谈清楚
  • b
    banditcat
    微博上画一幅4格营销漫画收费10万,互联网真的泡沫了么
  • h
    hermoss
    什么样的app活儿?
    9年从业经验其中4年猴狗双修,现在银行讨生活。

    求lz赏口饭吃
  • y
    ygd
    ls是做核心的还是外围系统的?
  • l
    leafss
    除了我之外有人进来之前在标题里看到包茎了么
  • d
    downey
    用什么方式聊,比较好。您来定吧。愿洗耳恭听。
  • d
    downey
    您客气了。希望有机会相互学习。我PM你了,请查看。
  • d
    deadpuppet
    想考个pmp,结果没钱,艹…
  • c
    cfan8
    研究生码农一枚,大大小小项目做过不少,想买alienware没钱,求楼主pm~
  • l
    lwwnet
    铜球微信开发的活
  • d
    downey
    已PM。神船也还不错。
  • d
    downey
    已PM。有想法请尽管交流。
  • 总是注册不成功
    对app有兴趣,只会玩猴。
  • d
    downey
    本人邮箱[email protected]
    只要有兴趣,都可以来交流。
    猴玩得好,就很好。狗可以放到后期。
  • h
    hermoss
    手机银行算啥?
  • d
    downey
    回复你的邮件后,觉得可以补充一句,不妨把它看作有社区功能的较简单的电子商城。可能有现成的技术或框架可以用得上。

    [本帖最后由 downey 于 2015-1-17 00:39 编辑]
  • x
    xubangnew
    第一个项目怎么也失败了…读第一段时候完全没读出这层意思来…哭了…
  • d
    downey
    没太明白您的意思。“第一个项目”指本人做网络设备的那个么?
  • y
    ygd
    属于前端吧?哥们哪个公司的?国内网银这一块就这么几家,是不是同事,哈哈

    本帖最后由 ygd 于 2015-1-17 01:11 通过手机版编辑
  • y
    ygd
    属于前端吧?哥们哪个公司的?国内网银这一块就这么几家,是不是同事,哈哈

    本帖最后由 ygd 于 2015-1-17 10:51 通过手机版编辑
  • h
    hermoss
    anz,嘿嘿
  • f
    floyd23
    甲方也来关注下
  • S
    SYNTH16
    你还不如开个群
  • y
    ygd
    你是银行的?那相当不错,我们属于乙方,别提多苦逼了……
  • d
    downey
    澳新?久仰!
    对于后台, Drupal 也许是一个选择。
  • h
    hermoss
    恩。。。现在是跟vendor一起做项目。澳洲这边不太一样vendor也挺强势的。因为ba文档写得很规范的,一切根据签合同时的specs来,改动都牵扯很多各种加钱。

    之前银行只做ba,开发相当于整体外包了。现在开发还是vendor主导,我也就是夹在中间混口饭吃而已。
  • f
    floyd23
    有没有对供应商相关的管理文档可以参考啊,国内的这方面太不规范了
  • h
    hermoss
    对供应商的管理文档?不确定这是指的什么。

    如果是详细的需求文档,我可能不太方便提供。

    这边的流程是在开始动手之前,甲方乙方的ba会坐在一起把方案的方方面面全部讨论到并归档做成一个一个的user story并有wire frames支撑。

    双方达成完全共识以后开始实际开发。

    乙方负责完成所有文档上的需求并提供warrenty。除此之外的任何改动都需要重新论证当然这个过程的开销是甲方承担。所以这个框架下甲方其实会更加尽责因为一个改动带来的可能就是几万刀的开销。因为不管乙方怎么付员工工资他们报给甲方的人工都是150刀起一个工时。你感受一下10个人开一天会甲方的支出。。。

    对乙方的约束最直接的就是详尽的不能更详尽的需求文档。一个按钮的功能最好都要写清楚,会有什么异常的情况,错误处理怎么做都要写清楚。如果这个做不到,甲方可能就会觉得乙方什么东西都小题大作一个小改动都这么麻烦。乙方会觉得甲方想要什么他们自己都没搞清楚我们怎么做?别做了又被打回来还是大事小事都找甲方一再确认。这样效率当然高不了。

    所以窃以为,最终这种合作的效率其实取决于售前,也就是BA阶段以及实际开发中甲乙双方接口人的专业程度和默契程度
  • f
    floyd23
    看你说这个模式非常高阶啊,对BA的素质要求相当高。
    在国内的金融业应该都没有达到这种成熟度的,还有很长一段路要走啊。。
  • 飞鸟相与还
    29楼是靠谱的模式。反正我是见过使用敏捷开发的并成功企业应用。
    如果事先沟通不畅,开发人员进入后就各种扯皮
  • 求摸摸小手
    能否PM一个联系方式?小学生想跟着大牛们学习一下~!
  • d
    downey
    不知上面那些大牛有没有给您信息,敝人Loser,已PM。