我是一名项目经理，在过去的四个月里，我把一个项目带崩了(上线后频出问题，用户无法使用)。

　　项目和团队背景

　　1、该项目是一个二次开发项目。

　　2、系统是需要和国家系统对接，有三条主流程。

　　3、需求频繁变化，由于系统需要对接国家系统，需求方对需求也不甚了解。曾在5月份一个月内需求变更超过8次，都是主流程变更。

　　4、项目大小按照最初需求估算，约在100人天左右。

　　5、项目两条主流程无法测试，依赖于外部U盾，但开发过程中并没有U盾。

　　6、客户现场使用U盾调试和开发时间约为20天左右。

　　7、我当时同时负责大大小小4个项目，没有进入开发，仅管控进度。

　　8、团队成员共3名，其中两名是当时开发基础版本的项目成员，他们对此项目较为熟悉。

　　9、项目推进过程中，需要多次去现场调试测试，由团队中的两名工程师共同前去。

　　下面是我对该项目所做的反思：

　　一、除了监控进度，还要管理质量

　　1、进度和开发速度固然重要，但以质量换速度不可取。

　　2、如果开发时间和质量冲突，优先保质量，毕竟你埋下的坑，总是要坑你自己的。

　　3、再困难的情况下，也要保证基本测试。

　　4、时间极其不允许的情况下，也要保证主线功能顺利执行。

　　二、　既要给予信任，也要保持警惕

　　1、不论什么原因，都要关注到项目成员的状态。;

　　2、给予信任没错，但也要适当保持警惕，他们多少会因为经验问题疏忽遗漏一些问题。

　　3、给予信任，也要给予帮助，不以时间为理由推脱你应该对他们进行的指点和帮助。毕竟现在剩下来一分钟，以后要花一个小时去弥补。

　　三、若无法全局掌控，就指派专人负责

　　1、手里捏着管理的权利，却没有做到管理的事情。是我在这个项目里最大的问题。

　　2、授权!授权!授权!如果自己无法亲力亲为投入项目管理工作，就授权给团队某个成员管理权限，让他代替你去做管理工作。

　　3、管理一人，总比管理多个人轻松，也更有效。

　　四、要控制需求，更要控制流程

　　1、不做设计，不进开发

　　2、以管理工具指导开发进行，开发过程中所有变更、反馈做记录

　　3、控制需求变更，拒绝不合理的需求

　　4、需求变更规范化操作，统一变更，而不是直接压给开发

　　我怎么填坑的。

　　项目上线，问题频出，用户不满。花了8天时间来处理这个问题。幸亏项目不大，我一个人也能够挽回。

　　1、和开发主流程的同事详细熟悉了所有需求要点。

　　2、基于我对项目需求的熟悉，我花了三天把所有主流程的所有代码分析完毕，做出了我认为应该的修改，并实施部署到生产环境测试。

　　3、每天花超过12个小时来进行code review 和修改，几乎每天code review + 修改到凌晨2点多。

　　4、每次上班时间的修改让开发同事坐在旁边和我一起进行，我进行修改，开发同事在一旁监督。确保我不出错。

　　5、优化功能点，把我发现的提示问题，和优化点都同步修改进代码中，确保用户体验不要太糟，以期能挽回一些用户心态。

　　我所吸取的教训总结：

　　1、先设计，后开发。

　　2、管理权下放，项目中必须有人全身心负责。

　　3、无论什么情况都要进行code review。

　　4、压缩质量得到的进度保证不可取，开发周期不合理决不答应客户。否则坑了自己坑了同事，更坑了客户。

　　综上：项目失败，项目经理的能力只是一方面!做项目时，遇到棘手问题是件很正常的事，关键是我们用什么样的态度去对待，去解决。