软件项目总结报告.docx

精品文档 精品文档 精品文档 精品文档 XXXXXXXXXXXXXXXXXXXXXXX 系统 项目总结报告 XXXXXXXXX 2017/7/27 项目概要信息 XXXXXXXXXXXXXXXXXXXXXXX 系统的技术团队由 11 人组成，其中项目经理 1 人， 需求分析师 1 人，UI 设计师 1 人，开发人员 6 人，测试人员 2 人。 本项目的前期工作从 2017 年 5 月 19 日开始，历时 16 个工作日，于 6 月 9 日完成需求分析等准备工作。开发阶段从 2017 年 6 月 12 日开始，历时 22 个工作日，于 7 月 10 日完成全部开发工作，进入外部业务人员验证测试阶段，目前，可使用XXXXXXXXXXXXXXXXXXXXXXX 的二级域名进行访问，详细信息如下： 用户资助申报地址：XXXXXXXXXXXXXXXXXXXXXXX 用户审核管理地址：XXXXXXXXXXXXXXXXXXXXXXX 本项目的开发过程有 5 个关键的里程碑，具体时间及内容如下： 2017 年 06 月 21 日：项目初次全新功能开发完成； 2017 年 06 月 29 日：项目初次内部功能测试、安全测试、性能测试完成； 2017 年 07 月 04 日：需求变更，准备进行二次开发； 2017 年 07 月 10 日：项目二次开发全部完成； 2017 年 07 月 11 日：项目二次内部测试完成，等待外部业务人员验证测试。 项目经验 因为是初次担任项目经理的角色，我最初找不到切入点，领导和同事在整个的过程中给了我很多的指导和建议。实际的项目管理工作使我对自己已学的理论知识有了更深刻的体会。所谓理论指导实践，实践验证理论，回想整个项目开发过程，至少可以总结了以下几点经验： 2.1 2.2 沟通讨论 信息交换要及时 沟通讨论是贯穿整个项目生命周期的活动，团队成员间信息交换是否及时，更是 项目成功的关键。虽然不同角色承担不同工作，但都是以达成项目目标为指导的，团队成员只有始终保持沟通讨论，保证接收到最新的、一致的项目需求信息，才能使得开发工作顺利进行，避免出现信息交换不及时而导致的返工。 对于沟通，结合实际来说，如果需求分析师不能将变更的需求信息及时传递给 UI 设计人员，就会导致不符合用户需求的设计，更会使开发人员写出无用的代码，这必然导致重设计、重编码，甚至会延误整体项目进度。 对于讨论，尤其是像我这样缺少经验的项目经理，不论是制定计划，还是工作量识别，都必须向有经验的同事请教，接受正确的建议，才能得到合理的安排。 2.3 项目范围 功能边界要清晰 项目经理以需求文档为依据，将项目范围及边界清晰罗列，是把控项目开发进度的先决条件。 对于 XXXXXXXXXXXX 系统来说，其功能并不复杂，且开发周期短，所以在确定项目范围并进行任务细化时，可精确到接口、页面。把一个大任务分解成一个个的小任务的好处是，可以帮助我们更加精确的估计出它们的工作量，并暴露出很多可能一时无法想到的工作量，也可以保证后续进行项目开发过程的状态跟踪，更加精确。 时间计划 人员分配要合理 以前总认为写计划比写代码容易的多，其实恰恰相反。一份合理的项目计划需要经过思考、沟通、权衡、询问、倾听的过程，要知道，用来分析解决问题需要花费的时间，远远大于单纯的写代码时间。 项目进度计划必须将分解出来的小任务，综合考虑时间、难易程度、人员能力， 估出工作量并进行合理分配。 代码开发 功能验证要同步 当日的开发任务结束后，作为项目经理应该对现有开发成果做验证，即对已完成的功能做验证，及时发现缺陷或其他问题，次日找对应的开发人员做修复。 因此，代码开发和功能验证的同步进行，既可以保证软件质量，同时也可以保证项目进度。当然，应该根据实际情况同步调整项目进度计划，预留处理缺陷的时间。 2.7 进度执行 问题修复要反馈 项目成员必须及时反馈当日任务完成情况，及前一天遗留缺陷的修复情况，才可以保证项目经理对整体进度的把控，准确跟踪项目状态。 2.9 需求变更 文档修改要记录 开发过程中的任何变更，都应做记录，作为项目成员之间沟通交流的依据，也可以避免重复修改，增加无谓的工作量。 项目教训 计划应当先于执行 项目计划必须要尽可能周全，并且在项目经理的可控范围内，可以根据实际情况 及时做调整，但一定要保证，具体工作的开展是在计划范围内，因为没有计划直接执行会直接导致项目进度不可控，状态无法跟踪。 沟通应当注意技巧 高效沟通是项目成功的决定因素。因缺乏高效的沟通技巧。对内，在与开发人员进行需求沟通、代码实现方式设计等方面沟通时，并不能快速准确表达自己意图；对外，在与业务人员协商问题时，会不自觉的使用技术术语等业务人员不易理解的词汇， 导致双方无法在较短时间内达成一致意见。希望自己以后有更多的