从事IT行业的工作已经6年多了，从当初的测试人员和码奴，到开发小组管理者，再到现在的项目经理（笔者成长比较慢⊙﹏⊙b汗），期间经历了N多项目也发生了N多的事。下面便说说笔者带过一个项目的总结，希望对各位能有些启发。
那是在2009年2月到2009年7月本人作为一个500强的日企做协力员工时的一个项目，做番号管理业务系统，项目的主要工作就把以前N个工厂书面化的番号管理改造成WEB管理系统，项目成员有6个人。
本着培养本社员工的思想，项目团队有如下成员组成：
项目成员A：一个刚从日本回来的经验者，业务和系统框架完全不熟悉。
项目成员B：一个工作2年的本社员，做个几个项目但是人浮躁，有超多不良记录。
项目成员C：一个工作1年的本社员，做了1年的配置管理和移送管理，没有开发经验。
项目成员D：刚毕业的本科生。
在项目前期要件分析时虽然是大家一起开会理解要件，但是由于时间紧要件分析理解文挡是由我和A一起做的。别人则去学习我们做成要件分析理解文挡。之后便开始做设计书，在review设计书时，我发现组员竟然还不理解自己负责那块到底要做什么，为什么要这么做，
我只好一个一个的说明，为了赶上进度，大家连续1周多加班到12点。
总结1：为了避免再出现这种情况，在前期要件时一定要确认，所有人对自己的那一块是不是已经掌握了，并且用开会的形式让每个人讲自己负责的那一部分。
因为全球经济危机爆发，公司提倡快速开发，即只做一本设计书，基本设计和详细设计的结合体，由于组员大部分是新人，设计书偏重于代码级的详细设计。在我们把设计书交给日方确认时，回信说负者后期维护系统的人员看不懂。因为后期维护系统人员都是业务出身，并没有过编码经历，为了使里程碑不延期，决定在项目结束后抽出2周时间（无偿，都是眼泪呀），根据现有的式样书再做一份偏重业务的式样书。
总结2：设计书作成前，定下设计书格式和写法，不只同日方项目开发负责确认，还要同后期维护人员确认设计书的写法。
项目组大部分是新人，所以我承担了核心业务的设计和编码，同时还要负责管理，再做代码check时只把C和D代码做了检查，对于A和B只是抽出部分检查，在测试时B的Bug远远多于其他人，因为B以前有过不良记录，所以只给他安排以前做个相似的机能，并把之前的设计书，代码给B参考，但B还是出了最多的问题。
总结3：尽力检查所有人的成果物（对于有不良记录人的成果物，必须全部检查）。但是，如果是大型项目没有时间来检查所有的成果物，只能层层检查，重点检查有不良记录的人。
以上是我的项目总结（之类的）
和大家分享这个项目管理中的小故事，希望能对大家有所帮助。