posts - 24,  comments - 68,  trackbacks - 0

    偶然看了网友 BirdGu 的一篇文章( http://blog.csdn.net/BirdGu/archive/2006/04/25/677369.aspx ),文中分析了一个失败的外包项目里面的风险问题。非常感谢 BirdGu 能拿出这么宝贵的经验和大家分享并提出了自己得见解,我自己在这方面也思考了很多,就该文中提出的问题,我自己也假设了一些情况,谈谈自己想法。

 

     第一个就是需求,作者也认为该项目的需求做的不好,如果再深究下去,不好的原因是什么呢?我自己的看法,该项目需求没做好的原因可能有以下几个原因中的一个或者几个

1.    用户自己都不知道需求是什么,传达给日方公司的需求也就是不明确的。

2.    用户虽然知道需求,但是日方的设计人员没有理解,或者一知半解,也就写不出合格的需求说明书。

3.    日方的设计人员对需求也很明白,但是写出来的文档中方开发者不能很好理解,而他自己却觉得自己表达的很清楚了。

   如果是第一个或者第二个原因,那该项目的失败就不仅仅是沟通上的问题了,起码日方的公司要负大部分责任。原因很简单,能把一个自己都不明确的需求发给别人来做,本身就存在问题,更别想得到符合需求的产品了。而现实中这种情况确实存在,怎么办?首先,日方公司要对这个问题加强认识并改进,改进的办法可以有很多,最根本的就是从管理制度上去解决,对需求是否完备要有相应的审核制度,并且纳入质量管理体系,形成管理制度同时又要严格执行。或许这不够敏捷,但是敏捷并不仅仅追求速度,而是在追求速度的同时保证质量的,也就是又快又好。后面我将阐述我对敏捷的认识。

    至于第三个原因,完全是一种理解上的差异造成的,作者也有所提到,要解决这个问题,需要不断的反馈,我完全同意。但是反馈什么呢?仅仅是告诉对方哪个地方不明白么?我想这种情况下,中方公司可以理直气壮的指出该需求说明中的不足,并提出希望增加相关的内容,这也给日方一个信息,就是告诉他们我们开发者希望看到的需求是什么样的。同时,中方的开发人员也应该加强理解日本文化,商业习惯,业务这方面的意识,经常有这样的情况,一个需求,即使非常明确,我们也常常按照自己的理解想当然的来做,结果作出来的东西,根本不符合对方的要求。如何做呢?我想最基本的要理解日本的会计规则,日语也叫簿记,企业系统无非就是人财物的流动,而这里面最核心的就是财,也就是钱的流动,理解了这个,对很多项目都有帮助。其次,日本人非常重视法律,很多新颁布的法令对业务系统和流程都有影响,这方面也是一个重要方面,例如马上要实行的 SOX 法,就让很多日本企业修改他们的业务系统以应对该法令。

    第二个,作者提到了 BSE 的职责问题。我也想谈谈自己的看法。 BSE 是做什么的?是一个重要的沟通窗口。那么这个窗口摆在日本还是中国就值得好好考虑了,我觉得把 BSE 安排在国内更好一些。理由很简单,离现场最近,最符合敏捷原则,最有利于发现问题,并及时进行沟通。 BSE 没有履行好自己的职责,这个原因也是需要深究的,使能力不足还是职责不明确。 BSE 的能力除了技术之外,更多的是对业务的理解,对开发过程的把握,发现问题,及时沟通及时解决。另外,日本人定义的 SE 和我们理解有所不同,他们要求的更多,更广泛,有时间我会另外写一篇文章介绍的。

    第三个,开发过程运用了迭代开发,并交付了一个阿尔法版,却没有发现其中对需求理解偏差的问题。这里面的问题就是中日双方对什么是软件原型的理解存在了误差,画面仅仅说明了针对用户的接口,并不能证明对需求理解的正确性,画面后面的各种各样的处理才是关键,那个日本上司的抱怨,其实只能怨他们自己。同时,中方的开发人员也没有作出一个合格的阿尔法版,也有一定的责任。阿尔法版里面应该用假数据体现出后台处理的过程,然后日方来判断该过程是不是正确。如何体现呢?我想应该有简单扼要的说明文档,所谓简单扼要就是多用图,少用文字。

    第四个,开发管理我认为也存在问题。这个问题是日方的。也就是日方对中方这边的开发没有进行良好的管理和监督,这个不是沟通和 BSE 能够解决的,而是由该公司的管理制度决定的。不仅日本的外包存在这个问题,日本国内的开发也有这个问题,项目包给合作公司后就不管不问了,结果一交付,什么问题都来了。

 

    最后说一下我对敏捷的理解。看了 Object Primer 后,我最大的收获就是对敏捷理解更加深入了。我现在的理解就是,敏捷就是用最简单最有效的办法,最快的解决问题,说白了就是不用拘泥于什么是敏捷不敏捷,也不用拘泥于什么形式,只要实用有效就好。谈敏捷的书里面列出的一些最佳实践,固然不错,但是真正的操作起来,不能生搬硬套,需要根据我们的实际情况设计出符合自己的敏捷方法,有时候即使不十分敏捷只要有效也不失为一个好办法。

 

     以上是我的理解,欢迎大家拍转!

posted on 2006-05-26 20:41 KnowNothing 阅读(1262) 评论(2)  编辑  收藏

FeedBack:
# re: 分析网友BirdGu的一个案例
2006-05-26 23:05 | 吴某人-不断地学习
老兄好久没有更新啊。。

程序员的26种能力继续写啊。。



  回复  更多评论
  
# re: 分析网友BirdGu的一个案例
2006-05-27 20:42 | KnowNothing
@吴某人-不断地学习
嗯,放心吧,努力中  回复  更多评论
  

只有注册用户登录后才能发表评论。


网站导航:
 
<2006年5月>
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

反省,反省。。。

常用链接

留言簿(22)

随笔档案(24)

文章分类

文章档案(3)

收藏夹(25)

AOP

Design and Architecture(O/R,Business Layer,View)

Good Blog

Good book download address

Good Java Website

Info

OpenSource

Project Management

SE Job

SOA and Web services

SOLUTION

Spring

TEMP

Test

Tools

Unicode

Web FrameWork

XML&Java

关于权限设计的探讨

工作流

最新随笔

搜索

  •  

最新评论

阅读排行榜

评论排行榜