|
17#
楼主 |
发表于 2008-8-15 09:37:24
|
只看该作者
|
原帖由 jane 于 2008-8-14 21:19 发表
好像这个问题在我们公司也比较多,好在我们有个售后维护部,可以缓解下源源不断反馈回来的BUG。
看到你的描述,以及不少专家的高见。问题和解决方案差不多都明了。在这里我还是想谈谈我的陋见。
上面你描述需求这一 ...
需求在以前的项目中,是个大问题,老变.这次因为我在需求上卡的比较严,所以变更不大.而且设计初衷就是先做个东西出来,我只要主干需求就行,其他的能推后的都推后了.
可能我有点没说清楚,我们设计的变更不是由需求变更引起的.比如这个项目我们是要做一个网络硬盘集成到以前的产品中.项目时间有限,所以设计的时候就准备采用开源的FTP协议.但是设计的时间很短,只能找一个比较牛的开发来设计,设计的重点放在与原来系统的结合以及计费等方面,详细设计只是列出我们需要在FTP协议上扩展些什么功能.但是,在设计完成的时候,连采用哪个开源代码都不知道.所以,在编码的时候,我们要边分析代码边做,这里就容易出现一些技术瓶颈(而这些受代码框架引起的问题,我们在设计的时候完全没法知道,因为那时都不晓得将来用哪个代码).或者,发现一些逻辑有问题,这个应该跟评审有关,主要大家就是参加评审也因为各有各手头要紧的事,不是很投入,只想快点搞完回去搞自己的事.这个方面我应该去加强,不过不知道有什么办法能让他们能真正投入进来呢?
团队凝聚力绝对没问题,这个可能是我唯一有信心的地方:) |
|