很久以前的项目开发失败经验总结

      最近这段时间我的思想老是给我出难题，我心里感觉老是感觉不踏实，所以一定要讲出来才能解我这颗烦恼的心，以下说的话并不是危我危言耸听，最主要对我们开发的现状提出一点疑问，这是我在开发当中身有体会，为什么开发这么久就是离项目的目标相差那么远？还有如何保证质量和进度？作为公司开发核心人员，负有其责，我谈谈自己的看法，如有不妥之处请指正。
1.JAVA技术选型：目前开发的系统，到底是用什么样的技术标准和体系，对于我们这样大的项目，有没有好的技术标准，虽然java体系是个好的开发架构体系，但是它的技术点太多，也太杂，今天这个体系，明天那个框架，难道只有在开发过程中才能体现出来用哪些好，一些技术点只能被某个人的想法左右，说用什么就什么，那我们离目标会越来越远的(我们不是很懂，在项目中间需要学习时间，这样会拖累我们的进度）。虽然我们目前还不是很熟悉java技术点，但是我们在考虑技术选行的时候一定要至少2位非常有经验的java系统架构设计师来论证(架构设计师肯定对这些技术体系或多或少的用过，以至于大家在探索和学习过程中减少时间和难度。好多稍大的公司一定要技术体系论证，考虑到进度、时间、学习难度和大家易掌握的程度折衷进行），不然在项目开发的时候，我们会很被动，在掌握的过程中 如果是对于一个有经验的系统架构设计师来说，这些东西在项目开始的时候必须要考虑的，而不是在项目中间才想到的，比如我的rmi这个远程调用技术，是在开发过程中才想到要用到的，当时为什么没有想到？还有发卡的Rich Client用Swing,AWT,还是applet,还是Webstart, 以后还有报表工具、web页面的web frame etc。
2.团队建设：对于大的项目开发，势必团队建设有它的标准，我最主要来谈下对技术方面的，首先项目启动的时候肯定有PM(项目经理），然后就是系统分析员（业务专家）、系统架构设计师（技术专家）、核心工程师、普通工程师和程序员，还有测试工程师等。对于我们公司的PM和系统分析员是一个人（也就是业务需求分析建模），系统架构设计师既然是技术专家，那就他对技术体系非常熟悉，非常有经验，不需要摸索，可以在技术上指导和引导工程师前进，但是对于一些新的技术可以探索，考虑项目组成员学习的时间和难度以及项目的进度，权衡它的利与弊，不需要盲目上一些新技术，这样就有风险（否则的话他有私心）。
3.人员补充：对于大的项目开发，如果要用java体系开发的话，一定要2个非常熟悉java技术和有经验的人。我们都是由其它的结构化语言转型而来的，而且要接受全新的OOP,未必所有的开发人员能转过来，这就在第1步技术选型的时候，有经验的java开发人员能充分发挥它的作用，不然的话会导致局面失控，由一人说了算。另一方面对于我们的技术提高也有好大的帮助，就是某些技术不需要花太多的精力去专研，只需要指导即可。这就是我第4个方面：培训里面会讲到的。所以宁愿多花点银子找些非常有JAVA开发经验的开发人员，甚至可以是JAVA系统架构设计师，也总比那些没有经验要培养的人强（最主要他们学了点东西就另谋高就了，非常不稳定），舍不得孩子套不住狼。
4.培训机制：我们公司的培训确实做的很差，外部培训就范围太大了，那是人力资源的一部分的事情，现在就讲内部培训遇到的问题,新来的员工抱怨没有机会学到新东西，老员工说学的东西都不是核心的，都是皮毛的，没有什么用，那么究竟怎么样的培训机制？什么样的人员结构调整，我觉的培训无非就是学东西，但是在什么样的环境下学东西最快，最好？答案就是在项目当中。架构设计因为他懂的核心怎么做就参与少点，可以关注全新的技术（ 要么他也是没有经验，纸上谈兵，没有任何实际意义；要么他自私不愿意把自己的技术公开出来，这样的人能配得上这个职位吗？再来说这对公司发展始终不好，公司的技术掌握在一个人的手上，能行吗？底下的员工师中成长不起来，公司怎么面临竞争？一个IT技术公司靠的是技术，怎么样才能成为一个梯队结构？这是比较关键的。）,核心的框架设计（如dao,hibernate,安全）可以由核心工程师参与一部分，核心模块（组件）可以由普通工程师参与一部分，这样螺旋式的递增下去，有阶梯有难度，他们更加愿意学,也看到自己的希望，看到自己的发展，也可以得到公司对自己的贡献价值认可。
5.职责明确：也就是分工明确和责任划分，项目前期，大家对自己的职责不明确，没有权利，大家也多一事不如少一事，也没有义务去管理。到头来惹得一身烧。关键一点的就是个明确责任和义务,这也是相当难控制和把握的。工程师做架构设计师的事肯定不妥，架构设计师做其他的事情也不妥等等这样的事情，就目前我司开发人员素质和技能水平来看，难免会出现交叉情况，但是怎么样解决可以爸问题点降低到最小
6.项目风险：对于这么大的项目，以后的升级、维护和培训，这些工具都不比window's DK,都是可是化的工具，假设写核心模块或者组件的工程师离职，那肯定需要花很长时间才能维护他的代码，这样造成维护成本和代价都很高，甚至在最后关头收不到回款导致失败。
我写这些东西可能有写不自信或者扰乱民心的想法在里面，但是以上问题确实是当前所遇到的问题。我主张的东西先忧后洗，不要像过去军事打仗一样，天天报喜不报忧。只有意识到自己有危机感，才有学习的压力和紧迫感，如果安逸现状，迟早被淘汰。在此申明一点,以上所写我没有针对对任何个人进行批判或者攻击，只是本着我在工作所遇到的一些问题和当中的几点体会写出来，这是站在我的角度想问题，但是你站在公司的角度肯定与我不一样的，希望能达到一个平衡点！

原文转自：http://www.ltesting.net