找回密码
 立即注册

QQ登录

只需一步,快速开始

xaep

葡萄城公司职员

60

主题

67

帖子

1087

积分

葡萄城公司职员

积分
1087

活字格认证

xaep
葡萄城公司职员   /  发表于:2009-12-11 14:54  /   查看:5381  /  回复:0
Post by "WantSong", 2006-11-03, 13:14
-----------------------------------------------------

我们在救火沉思录--关于项目最后阶段的思考中讨论谁谁的责任,谁谁的问题,不如先把项目的火苗都找出来,然后找对策。列出问题,分析问题,再解决问题。项目不限于GrapeCity的,只要是自己参与的听说的都可以。或许项目在商业层面上并没有失败,但从软件工程角度的确失败了(如进度拖延、成本大大增加等)。偶先抛块砖,以前参与的比较典型的三个项目。
1. 一个书店ERP项目。一个民营书店成立研发部想自己整一套书店ERP产品。所以除了老板当需求提供者外,我们还找了一个业务专家。工作已部分是做在线销售部分(B/S),一部分是做企业管理(C/S),做了一年时间。
遇到的最大问题是项目经理缺乏产品管理经验。按理需求是自己提的,应该相对稳定,但是我们的目标是卖到新华书店,所以在流程的考虑上异常周到,有时感觉就是在定义行业标准,而公司的实力远远不够。比如,订单、销售单、出库单和发货单都被定义为不同的实体,这样在跟踪时异常复杂。
有些需求是不合理的,但却是现实的。在图书销售领域中,往往采用代销的方式,下游分销商可以压上游供应商的货款。如实现虚拟库存:相关供应商的货即使卖完了,如果他的业务人员来浏览我们的系统,会看到虚拟的库存。诸如此类的“特色”为开发带来巨大的麻烦。
其次,当时只有项目经理有OOAD的经验,其余的人(包括我)并不能很好的支持经理。我们严格遵循了不和陌生人说话、依赖倒转等设计原则,使用了MVC和 POJO,设计看起来很完美,但是开发的时候不是这样。比如我们记录一本图书的表就多达17张,还不包括字典数据(开本、出版社等)。
选择了错误的生产工具和方式。在C/S结构中,我们使用Java做应用后台,用C++做前台客户端(这是2000年初Borland公司主推的一种开发方式)。这样的搭配对成员要求太高,我们始终难以壮大队伍。
2. 一个在线产品管理(HP的AspenPlus)。这个项目由于商业原因,从项目启动就开始救火,异常痛苦。HP将这个项目给了两家,一家是做需求设计,另一家做开发(就是我们),结果那家做需求的啥都没做(商业原因),尽管官司赢了,但是项目还是要按期交付。我们只好边做需求边做设计边做开发,有些时候连着24小时工作(工作24小时,睡一觉,再工作24小时)。
我想这样的项目绝对应该杜绝。
3. 一个在线汽车零配件销售。 截至目前,这是我见过最乱的项目。我们的工作是从Coding开始,截止到单元测试。
计划20个人月,2个月开发完成的项目最后发展到了近80个人月,历时6个月。我们一共调查了三百多个问题,其中有七十多个bug,四十个左右无须对应,其余的都是式样变更。也就是说半年,14万行代码,200多个式样变更。甚至一次当完成某个模块的单元测试后准备发布时,客户修改了主要的业务表结构,但是并不延迟发布时间。
这个项目最大的问题是无计划性、需求和设计非常差,比AspenPlus的边设计边开发都差些。
其次,客户只提供了详细设计,并且是分期给我们,我们根本无法反溯到需求,没有调动开发团队的“主观能动性”。
当然失败的原因很多,上面只列出了自己认为比较重要的因素。希望大家借鉴,思考思考。

Reply by "WantSong", 2006-11-03, 13:45
-----------------------------------------------------

对策
需求分析时贪大贪全,没有拒绝不合理要求。
对于ERP系统,项目之所以会出现需求总分析不完的原因之一是领导层没有成本的概念。应该严格划分产品边界,定义哪些现在做,哪些将来做,哪些不做。一个产品不可能全部是亮点。
对不合理要求要说不。就拿虚拟库存来说,我们不仅仅要假造报表,还要假造订单、销售及发票等数据,并定义很多规则(是造假真实些)相当于开发了两套。
组建设计/开发团队和完美主义
当项目使用新技术时(比如OO),应该划出培训期。对于工程来说,没有最好,没有最坏,只有适合不适合。软件是工程。我们需要在优雅的设计和开发之间寻找一个平衡。
流行的/最新的不一定是适合的
显然经过时间的考验,Borland主推的这套方式没有被大家所接受。我们成了吃螃蟹的,或者换句话说投资者的钱都变成了员工的学费。
因为商业原因导致工期紧。
对公司来说似乎很完美,期短钱多见效益。但是公司为此付出的代价是员工的离职(走的都是有经验的老员工,顶上来的都是实习的);员工为此付出的是身体。如果在正常轨道发展的公司,这种项目应该杜绝的。
需求和设计是软件项目的重中之中。
即使仅从Coding开始开发团队也要尽可能多的向上游环节伸展,即理解需求、了解项目背景,否则将会非常被动。我们需要提高自己的分析设计能力,能够参与到项目的前期更好。

0 个回复

您需要登录后才可以回帖 登录 | 立即注册
返回顶部