项目总结

需求管理方面：鉴于项目实施过程中出现过开发人员错误理解需求的现象，后续做出以下调整：咨询调研需求尽量细化到细节，项目经理在项目正式进入开发前，组织咨询的当面给开发同事讲解一遍，一方面起到传达的作用，另一方面也给开发人员一个集中反馈提问的机会，尽量减少返工。

项目管理方面;鉴于项目实施过程中出现浏览器不兼容，未及时通知UAT用户介入测试，基础模块开发进度滞后等低级错误影响整个项目进度的情况，项目经理需要积累经验，提升自身识别风险的能力，在考虑整体功能实现的同时，需要从各个方面保证项目的质量，如健壮性，兼容性，实用性，美观性等方面多方位考虑；识别风险，规避风险，多考虑非功能性的东西来保证项目质量，功能性的东西通过代码检视来保证质量。

配置管理方面：文档方面，迭代一实施过程中走的先编码后设计的路线，事实证明是不合理的，迭代一不仅没有在规定时间内完成应有的功能，质量也不高，所谓磨刀不误砍柴工，先做好设计，包括总体设计，详细设计，接口设计，数据库设计，界面设计，而后编码，最后测试，不仅开发人员轻松，质量也有所提升，迭代二版本和迭代三版本按照此路线，有很好的成效。

开发测试方面：单从专业技能的角度来看，每位开发同事的编码能力我觉得是没有问题的，但是在测试阶段仍然会暴露很多问题，主要体现在业务场景涵盖的不全面，分支细节处理不到位，还有就是粗心大意导致的低级错误，鉴于这些，后续做出以下改进：一方面项目经理在传达需求时，需要给开发人员讲解清楚该需求的使用场景，清楚了这个，开发人员就能在心目中形成一个比较健壮的实现思路；另一方面，开发人员也需要不断提升自己的发散思维能力，能从业务场景中联想到后台可能存在的分支，这也是一个工程师成长的必经之路；第三就是，组内需要建立起交叉测试机制。开发人员A对于开发人员B编写功能相当于一个用户，可以更有效的发现不合理的地方。

上线投产方面：鉴于投产过程中出现过将测试阶段已经确认过的逻辑改错的现象和测试不充分就急忙封板的现象，后续需要做以下调整：新的优化需求下来时，先分析改动的设计范围，然后编写测试案例，最后动手编码，在代码封板前2天完成编码和自测，留够充分的时间测试和验证；对于没法在有效时间内完成编码的变更，可以移到后一个迭代版本上线，先保证版本的稳定性。

其他。。。。。