进公司第一个项目经验总结 项目总结：1、 需求分析不充分，需求变更频繁，系统分析人员有时候对问题模棱两可，直接导致开发人员经常改动工作量增大，无疑给项目执行带来风险。2、 需求分析开发方面没有明确的掌握全局的负责协调沟通的主导人员，各自顾着忙自己手头任务。3、 项目质量监控把握力度有待提升，没有完善代码审查机制；程序写完不代表项目结束，只有很好的审查代码，修改程序不合理的地方，使开发人员改正长期以来可能养成的错误习惯，从而让含后的系统开发质量得到提升实现公司与开发人员双赢。我们目前都只是功能性测试黑盒测试，没有对程序代码进行白盒测试，给以后程序使用留下安全隐患。4、 项目沟通方面不是非常顺畅，系统分析人员与开发方面有时候因为理解不一造成最终功能偏差！造成这种原因很多，归根结底主要原因是沟通技巧问题造成。我的建议开发前使用系统Demo，开发结束使用BugList，这样可以有效减少因最终用户－需求分析人员－开发人员三方沟通造成的沟通成本增加。是在每一个BUG出现的地方，抓个图，如果有可能最好能把操作步骤抓过来。这样会省去修改人员的很多时间。Demo:用直观真实的Demo配以详实的需求说明代替抽像空洞的文字需求描述或ppt，这样带来的明显好处是，可以在项目开发启动前跟头脑中没有系统展现雏形的用户/领导进行演示沟通，在前期进行无数次的修改演示直到用户/领满意为止，将不必要的需求变更从开方转移到分析阶段，将它扼杀于摇篮之中，等需求敲定时，项目正式进入开发前再给开发人员演示讲解，明确最终系统功能及界面要求，而不是扔一推需求让开发人员跟据自己的主观意念去开发系统。BugList:用明确详细的BugList代替口述或纸质亦或Word文档的Bug描述；无论谁在想事或做事情时，总是不希望被人打断开发人员也不例外，BugList这种静巧巧的提示小助手可以保证开发人员的工作节奏！BugList可以很清楚地将Bug出轻重缓急让开发人员一目了然地知道孰轻孰重，而且Bug提交者也可以通过BugList查找Bug的修改状况。而且BugList还可以帮助项目经理很好的掌控项目进度及统计开发人员不同等级错误的Bug率;BugList可以让没有Bug描述经验的任何人将Bug描述得详细明确。规范方面：1、 缺少完善的开发规范体制，没有严格的强行执行策略。像变量及字段的前缀lng，lng是长整形long的前缀，确被整形integer使用。2、 数据库表设计，不应由开发人员设计！不同人可能数据库设计水平参差不齐，这样容易造成系统性能问题。3、 缺少完整详实的开发文档，可能造成人员离职带来的系统维护成本。最后建议： 公司没有明确的新技术敏感性，大部份系统还处于前几年的开发水平；开发人员无法将新技术融入系统，以让系统用户带来更好的用户体验。建议公司投入小部分人力研究适合我们系统开发的基于新技术的.net框架。好像作者遇到的问题都是软件工程里面提到需要注意的地方。由此看来不规范开发即使是在软件工程学科已兴起多年的现在来说，还是大量存在的。这实在是件不容乐观的事。一般这种情况好像都是发生在主业不是软件，却需要软件，又使用自己成立的软件部门进行开发的公司中。由于他们的主业不是软件开发，所以领导可能对软件工程并不是非常重视，所以才会出现这种情况吧。这篇项目总结中提到的这些问题，几乎每天都在重复发生着。要到什么时候才能连非专业开发部门也能注意过程控制呢？软件危机，真的还没有结束。。。