年终项目总结 第一篇：关于项目管理

       

           这是我第一次作为一个大团队的负责人来进行三代产品的开发。产品终于交付生产了。本来说要好好地做一个项目总结的，但是似乎没有时间做这种表面的功夫了。这是第一次涉及了这么多人员来进行的产品开发，总的来说，积累了很多很好的经验，也吃了不少的教训。

1. 要有一个最高的指挥官，可以拍板所有的事情（不需要亲自拍板所有的事情），要监控整个开发过程，能够有目的地、有序有效地分配人力资源、物理资源等。否则各个组会出现各自为战，只一味关注自己的事情，乱作一团的情况，出了问题也相互推搪。组内的事情较易管理，因为组长能把握组内的全盘，控制到位，基本不会有什么拖沓的，但是牵涉的不同组的人员多，简单的问题就不那么简单了，因此才需要项目管理。

2. 丰富和提高测试手段，如这次增加了CPU、内存监控、任务管理器等协助测试工具，以后希望增加更多的测试，如白盒测试，另外可发展更多的手段，有效地诊断问题发生在哪个层面或者模块，软件架构的设计必须把这个考虑在内，并且在发现必要修改软件架构时要尽早地调整。

3. 对关键问题的测试，如系统稳定性、运行效率、速度、内存使用等要尽早开始监控并贯穿整个项目的开发过程。在这次的开发中，发生一些严重问题难以定位，就是因为疏忽了这一点，特别是一些难以重现的问题，花了很大精力去找在哪个版本出现的。因而这次的开发我也强烈地要求每个开发人员要严格地编写程序更新和修改日志，所有人对同一份日志进行更新，在哪个时间节点上出现的问题都能一目了然。

4. 监控和提高代码质量，如内存泄露、死机等严重问题往往出在了代码质量不够上，因为编写时求快操心，或思考不够全面，又或者是开发人员本身的编码基础不好造成的。因此建立一个代码质量监控或者白盒测试的举措显得相当重要。

5. 对于那些问题出现在哪个部分，或功能应该在哪个模块实现，这些划分界线模糊的问题要优先重点进行会议讨论对策。否则这种问题必然会拖项目的进度，因为这种情况，A组会寄希望于B组去先找到问题的症结再去改，谁也不认为要优先搞这个，因为明显是组内的问题会更想优先去解决。

6. 开发的节奏的控制，要雷厉风行，不可以先松后紧。否则到了项目要交付时无尽的加班和巨大的压力会严重打击开发人员的激情和效率。

7. 参与开发的人员一定要事先做过产品熟悉的培训。并且培养其在完成代码后要先测试后而后再发布到测试组测试。如开发人员A完成的功能自测试过后，由另一个开发人员B检查过(必须熟悉产品)和测试过，这样可以减少很多简单的Bug无谓地去到测试组转一圈。

8. 开发小组人员不能进行过于实行固板的分工方法，要根据项目的具体情况进行作调整，灵活分配。对于一个团队来讲，分配好任务就一成不变了，等着其按时完成，效果会很不好。