ZYBB项目总结(二)

从项目开始到现在有差不多2个半月了,原来计划1个半月全部完成的.现在才做了估计有一半多刚刚,后期还有好多东西要做的.

 这个项目做到现在感觉是失败的.整个项目感觉乱乱的.做到现在了,才开始说要培训delphi,太奶奶的太离谱了.从需求,到设计,到代码,到项目管理无一例外.究其原因最主要的还是人的原因,最重要的还是项目管理的问题,开始低估了一些问题,一切想的太简单了,感觉因为大家的责任心都不强了,从上到下,上的不抓下边的就好不到哪去.一个项目的成功关键在于这个项目的管理和技术,就这个项目来说管理上应用到别的项目应该没有问题,但因为技术上的问题(一帮java程序员,在做delphi的程序)导致管理的效果不明显,而且管理没有解决技术上存在的缺陷.

上周一个做导数据的gm走了,总工也说要走了(这个项目开始就是他在带着做),现有的几个也都心不在焉了,现在整个团队没有了凝聚力,从sz回来结果发现有2个实习的研究生进来了,还做报表,不敢想象以后是什么样子.上周又加了一个java程序员,哈哈.现在唯一欣慰的是同样在上周招了一个有经验的delph,i程序员.估计能在技术上提供不小的帮助.

其实还是原来的人都懒,没有人肯钻研delphi的东西,就现在用的这些东西,其实1个月完全可以搞的挺好的,如果项目组没有一个人对它(delphi)特别的熟悉,而又不想引进熟悉的人员,最好的办法是安排厉害的一个人,把用的东西全部搞懂,对项目组的其他人提供技术支持.而这个人也是项目成败的关键.其实原来有这么个人的,但作用发挥的不到,而导致现在这样.

而且项目中存在这样一个问题,是下级找上级的人解决问题,让下级的人负责某块的东西,这本身就是个错误,如果下级不够积极或下级自以为是或上级不负责任,就会有问题了,我觉的应该把责任的权力交给上级,而不是给下级,让上级去检查下级和督促下级和帮助下级.现在管理上是这样做的,但技术上这个人没有起到相应的作用.

而且这次的需求的流程也和以往不同,先根据自己做过的相关项目的行业知识,整理出自己的需求,其实这个没有问题,很多产品都是自己先整理需求,然后开发.但我觉的问题出在需求还没有经过客户的完全认可,就开始设计编码,说要等东西出来了,再去给客户演示,提需求.这样对客户是好的,但对于软件开发商就不好了,因为如果有特殊的需求让你改变了项目的整体的设计,那可就惨了.到时候只会增加一些代码的熟练度.其实demo原型完全可以做成和实际系统演示的一样.我觉的应该尽早的排2个人去谈需求.而且一些模块的开发还可以进行.

最主要的是现在人心散了,就什么也不好做了.而且这个项目应用的客户那么广,估计会给以后的使用,推广,升级,修改,维护带来很多的问题.

下次写写测试的问题.