在项目开发的时候，个人觉得，对整个项目的管理而言，关键的有以下几点：

　　1.需求的控制

　　做过项目的程序员都懂，开发一个需求变动平凡的模块，绝对是一件让人崩溃的事!个人认为，想把项目漂亮的完成，需求的控制一定要做好，需求一变，就意味着需要花费更加多的资源来解决这问题，如此一来，原来的工作计划不但会延期，而且对于程序员来说，在心理上也是有很大的影响，毕竟，让你总是推翻自己写的代码，重新来过，任谁也有怨气。但是，在实际开发过程中，需求的变动对于任何一个项目而言，却又是不可避免的事。这个时候我们该如何来做才比较好?

　　2.资源的平均分配

　　在一个项目组里面，往往都有那么几个是技术非常扎实的人。这个时候，分配任务的，很多经理往往都是把好多好多关键的、复杂的、不容易解决的问题都交给他们来做，但是，这样真的好吗?假如说，person1负责了3个核心模块的编码工作，但是到后来发现3个模块存在先天畸形，也就是需求上有问题，亦或者是bug比较多，高居不下，这个情况下，可能person1计划的别的工作就要放下来，花很多时间来改bug和改需求变动，且这些工作又不能分配给别人来完成，这个时候，又会导致项目的延期。所以个人认为，项目资源的分配要因人而分，平均而分，充分的对成员的信任!

　　3.计划的制定

　　在项目开始，经理往往都要制定一个项目计划出来，但是项目计划的制定，很多时候都是在开发人员对需求似懂非懂，朦朦胧胧的情况下，漫不经心的一口答应下来的。我觉得这个是不妥的，就算是基本的增删改查，在和开发人员核对的时候，都要清洗的说清楚，不然这样的计划，宁可不要也罢!

　　4.版本(代码版本/发布版本)的控制

　　对于版本的控制，相信大家都不陌生，很多版本控制器(例如SVN)，都很很好的控制代码的版本，一个测试环境，一个上线环境;开发人员负责测试环境代码更新和bug修改问题。这些问题只要稍稍留心，都能很好的解决;但是，当项目上线的时候，客户在对项目的进行UTA测试，出了bug怎么办?我经历的几个项目中都是采取敏捷式开发，也就是即改即穿。这样固然很好，能较快的修改很大一部分bug，但是，这样一来，发布的版本有从何谈起?个人觉得，这方面我们应该学习一下日本人的开发模式，也就是项目上线的时候，发布第一个1.0版本的war包项目，让客户随意的测试，并把测试结果记录下来，在指定的日期将测试结果反馈到测试部，测试部在将bug发布到bug管理器，并制定相应的计划修改，完成后发布1.1版本，继续上述流程，最终达到2.0 的稳定版本。

　　PS：以上是小弟对项目管理的个人见解，因工作年限有限(2年+)，且不曾参与过管理工作，见识不多，望大虾们嘴下留情，多多给点好的意见。不胜感激!