第八章 IT项目收尾管理实践.

Presentation on theme: "第八章 IT项目收尾管理实践."— Presentation transcript:

1 第八章 IT项目收尾管理实践

2 内 容 提 纲 8.1 IT项目收尾概述 8.2 IT项目收尾过程 8.3 IT项目收尾成功与失败因素 8.4 案例分析1---ERP项目验收，给自己一杆标尺（需求方角度） 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度） 8.6 案例分析3---教学管理信息系统进行项目总结 8.7 IT项目收尾总结 8.8 复习思考题

3 8.1 IT项目收尾概述 收尾过程组包含为完结所有项目管理过程组的所有活动，以正式结束项目或阶段或合同责任而实施的一组过程。当这一过程组完成时，就表明为完成某一项目或项目阶段所需的所有过程组的所有过程均已完成，并正式确认项目或项目阶段已经结束。

4 8.1 IT项目收尾概述 项目或阶段收尾时可能需要进行以下工作： 获得客户或发起人的验收； 进行项目后评价或阶段结束评价；
记录“裁剪”任何过程的影响； 记录经验教训； 对组织过程资产进行适当的更新； 将所有相关项目文件在项目管理信息系统（PMIS）中归档，以便作为历史数据使用； 结束采购工作。

5 8.1 IT项目收尾概述

6 8.1 IT项目收尾概述 ■ IT项目收尾： 结束采购包括合同完成和结算，包括解决任何悬而未决的事项。
将项目或项目阶段的可交付成果交付的过程，或者是取消项 目的过程。 对于IT项目来说，更为重要的是努力做到项目可以真正收尾。 对大多数IT项目来说，项目进入收尾也同时意味着进入维护性阶段。 结束采购包括合同完成和结算，包括解决任何悬而未决的事项。 结束项目包括审计、资料归档、总结、表彰和人员转移。

7 8.1 IT项目收尾概述 表1 项目收尾的过程和输出 知识领域 过程 输出 项目整体管理 结束项目 最终产品、服务或成果移交
表1 项目收尾的过程和输出 知识领域 过程 输出 项目整体管理 结束项目 最终产品、服务或成果移交 组织过程资产（更新） 项目采购管理 结束采购 结束的采购

8 8.1 IT项目收尾概述 ■ IT项目收尾前应该完成的任务： 客户正式接受这个项目 项目文档记录完整 产品的最后版本必须满足完整的条件
保留必要的项目文档 准备经验学习资料 转移必要的权限

9 8.1 IT项目收尾概述 ■ IT项目收尾完整而成功完成所需要的任务： 1、确认项目中的所有要求都已得到满足。 2、核实并书面记录项目或项目阶段满足了计划过程组中制定的完成或验收标准。 3、从客户处获得项目产品的正式的（法律）签署。 4、书面记录项目早期终止的原因。 5、做最终的支付并完成成本记录。 6、收集经验教训。 7、更新项目记录。 8、确保所有的项目管理过程都已完成。 9、基于经验教训，更新公司过程、程序和模板。 10、将团队成员获得的新技能加到人力资源记录中去。 11、实施采购审计。 12、制定收尾程序。 13、完成结束采购 和 结束项目 过程。 14、分析并书面记录项目的成功和效率。 15、建立并发布最终的项目绩效报告。 16、编制索引并存档项目记录。 17、衡量客户的满意度。 18、交付已完成的可交付成果给运营单位和维持单位。 19、释放资源。

10 8.1 IT项目收尾概述 ■ IT项目成功与失败的标准： 项目最后执行的结果只有两个状态： 评定项目成功与失败的标准主要看： 成功 失败
可交付成果如何 是否实现目标 是否达到项目业主的期望 客户关系保持良好

11 8.2 IT项目收尾过程 ■ 项目收尾： 项目收尾需要对项目验收正式化而进行的项目资料的移交和归档。具体包括开发记录、功能需求对照表、测试记录、项目阶段性进度报告等。

12 8.2 IT项目收尾过程 ■ 结束采购： 结束采购就是了结开发合同并结清帐目，包括解决所有尚未了结的事项。结束采购需要对整个项目开发过程进行系统地审查，找出合同上签订的事项是否已经完成任务。

13 8.2 IT项目收尾过程 ■ IT项目文件整理： ------这个阶段的主要工作有： 鉴别未完成的工作和工序
核对所有任务和活动的相关记录是否准确、齐备 确认所有与项目收尾相关的资料是否完整 检查项目管理计划中的工作是否实际完成 完成资料的整理工作，为项目的最终移交做准备

14 8.2 IT项目收尾过程 ■ IT项目结束过程： ------当项目接近生命期末期时，项目资源开始转向其他活动或项目，项目经理和项目团队成员所面临的工作也开始转向项目收尾活动： 制定项目结束计划 完成收尾工作 项目最后评审 项目结束总结 IT项目结束的主要类型： 正常完成项目 未全部完成项目 失败项目 Begin with the end

15 8.2 IT项目收尾过程 ■ IT项目验收： 项目结束或者项目阶段结束时，项目团队将其成果交付给使用者之前，项目接收方会同项目团队、项目监理等有关方面对项目的工作成果进行审查，核查项目计划规定范围内的各项工作或活动是否已经完成，应交付的成果是否令人满意。若审查合格，项目成果由项目接收方及时接收并转入使用。

16 8.2 IT项目收尾过程 ■ IT项目验收意义： 项目的验收标志着项目的结束（或阶段性结束）。
若项目顺利地通过验收，项目的当事人就可以终止各自的义务和责任，从而获得相应的权益。同时，项目团队可以总结经验，接收新的项目任务。 项目验收是保证合同任务完成，提高质量水平的最后关口。 通过项目验收，整理档案资料，可为项目最终交付成果的正常使用提供全面系统的技术文档和资料。

17 8.2 IT项目收尾过程 ■项目验收收尾与移交 ： 项目验收收尾的意义。 项目验收标准和依据 项目验收范围 项目结项与移交

18 8.3 IT项目收尾成功与失败因素 ■促进IT项目收尾成功的一些因素： 专人负责、强调计划 收尾阶段需求变更的灵活处理
强调并建立管理收尾的制度化 公司领导大力支持,为顺利收尾保驾护航

19 8.3 IT项目收尾成功与失败因素 ■导致IT项目收尾混乱的一些因素： 没有明确项目收尾负责人 没有制定规范的管理收尾制度
开发计划安排前松后紧

20 IT项目收尾总结 1、项目收尾就是到了胜负关键的时刻，一不小心就有可能前功尽弃、满盘皆输。 2、每个项目的收尾都在为下一个项目的成功做准备。 3、收尾过程出现的问题，90%都是因为前面过程的问题处理不当导致的结果。 学会学习

21 IT项目收尾总结 学习有很多种方法，最深刻的是从实践中学习，在项目结束的时候一定要做出总结，形式上项目总结一定要用书面方式。 只需写三种：
在这个项目中我做对了什么？ 在这个项目中我哪些地方做得不够好？ 在以后的项目我需要做哪些改进？

22 IT项目收尾总结 项目收尾是项目经理经常不重视的过程。 1、把项目文档整理一下归档，对于项目的延续性是有很重要的意义的。 2、项目经理把项目经验归纳归档起来，又会对别的项目经理、对公司的项目管理文化作出了不少的贡献。

23 8.4 案例分析1---ERP项目验收，给自己一杆标尺（需求方角度）
8.4.1 背景说明 项目该何时验收 项目该验收什么 小结

24 8.4.1 背景说明 公司规模越来越大，从最初的一个人担当技术支持，也逐渐发展到五个人了，IT部门也顺理成章的被独立出来。小章因为技术出色，办事又有条理，便被任命为IT主管。小章上任后，总经理下放的第一件任务便是企业信息化进程要排上议事日程，为了让公司内部的工作更加的条理化，在管理上更上一个台阶，上ERP被排在了第一件。

25 8.4.1 背景说明 在经历选型、实施、验收之后，小章松了口气，以为非常圆满的完成了上任后第一件最漂亮的工作。但事实却恰恰相反，内部的一些办事流程依然是老样子，一些比小章资格要老的员工更是我行我素。ERP只是成了服务器以及各个客户端电脑中的一个摆设。项目的验收报告也签了，和ERP厂商双方都盖了章了，按理说应该项目很圆满才对，为什么造成了这样的局面呢？这里且不说在实施上出了什么问题，最后的验收工作很明显也没有做到位，没有给自己一个明确的验收标准，自然实施结束后没有对应的标准进行参照，结果是软件安装完了，可以成功运行，就算是合格验收了。

26 8.4.1 背景说明 项目验收绝对就是企业内部的事。在验收过程中，项目算是成功上线，和软件提供商签订验收报告之前，绝对要进行很好的评估，严格参照曾建立好的验收标准，也就是说项目验收，要给自己一杆标尺，有了标尺的参照，验收工作自然更加完美。

27 8.4.2 项目该何时验收 1、制定一个合理验收的时间标准 ERP针对企业来说是一项非常大的项目，所以基本上很少企业内部能在ERP项目的各个流程上有十足的经验。

28 8.4.2 项目该何时验收 1、制定一个合理验收的时间标准 等软件安装工作完成后，一般运行一、两个星期后有些实施顾问便会要求项目验收，如果这时验收的话，是肯定看不到项目效果的，即使觉得项目验收不合格，往往也说不出所以然，在这种朦胧的状态签订了报告后，便预示着项目结束，后续的便剩下服务的商谈，而实际的验收效果则看不到。

29 8.4.2 项目该何时验收 2、如何设置合理验收的时间标准 首先： ERP系统至少需要运行一个月后才可以验收，毕竟一个月才能是一个小的系统周期，如果小的周期都没有跑顺，就更别说一年这样的大周期了。

30 8.4.2 项目该何时验收 2、如何设置合理验收的时间标准 其次： 根据模块的多少，系统涉及部门人员的多少，在验收时间上还需要更多考量，如果能做到系统平稳运行两个月，财务模块报表无差错，再做验收则更好。

31 8.4.2 项目该何时验收 2、如何设置合理验收的时间标准 再则： 对于有二次开发模块的项目验收，一定要将标准模块与二次开发项目的验收进行分开。因为二次开发的为全新的模块，同普通软件一样，也应有个“公测”除Bug阶段，应该在平稳运行三至四个月后再做验收，

32 8.4.3 项目该验收什么 1、项目验收内容 2、项目验收标准 3、给自己项目验收一把标尺

33 8.4.3 项目该验收什么 1、项目验收内容 A、项目文档： 实质内容：项目实施过程中的会议记录等等（会议记录往往包含着实施顾问对整个项目的指导性建议以及本企业内部在实施过程中所遇到的问题，问题的解决进度等等。 ）

34 8.4.3 项目该验收什么 1、项目验收内容 A、项目文档： 实质意义：小点说，可以从这些文档中管窥整个项目的实施过程，大点说，可以为企业后续的信息化进程提供更多的参照，避免犯重复的错误，少走弯路。

35 8.4.3 项目该验收什么 1、项目验收内容 B、执行情况： 问题说明：很多企业上ERP到最后，变成了财务部门信息化，其他部门的系统都成了一个花架子。

36 8.4.3 项目该验收什么 1、项目验收内容 B、执行情况： 问题原因：因为财务的报表相对来说比较容易突现出其工作情况，其他部门可能仍旧采用老旧的办公方式。

37 8.4.3 项目该验收什么 1、项目验收内容 B、执行情况： 问题症结：信息化本身的重要意义就在于通过软件的标准化进一步规范企业的作业流程，一方面提高作业效率，另一方面提升企业员工的总体管理水平。

38 8.4.3 项目该验收什么 1、项目验收内容 C、二次项目开发的附属物： 实质内容：项目开发的整个框架、软件架构模型，其中也包括数据库结构，特别是核心配置表间的一些关系以及源代码。

39 8.4.3 项目该验收什么 1、项目验收内容 C、二次项目开发的附属物： 问题描述：同标准版程序不一样的是，二次开发项目的后续维护会更麻烦，特别是软件提供商那边发生人事变动后，经过几年，当时的开发人员离职后，程序再有什么问题，解决起来估计就非常麻烦。

40 8.4.3 项目该验收什么 1、项目验收内容 C、二次项目开发的附属物： 问题解决：这些相关资料要保存好，以便在后续使用过程中出现问题时，企业内部的IT部门员工可以从这些文档中寻找相关信息，对解决问题有很大作用。

41 8.4.3 项目该验收什么 1、项目验收内容 C、系统性能： 实质内容：基本的性能要满足要求，比如在多用户并发操作，以及大批量数据运行的过程中，系统是否有严重的性能瓶颈等等。

42 8.4.3 项目该验收什么 1、项目验收内容 C、系统性能： 问题解决：在公司的IT部门内，通过和一线的系统操作员工进行沟通，进而了解系统的性能方面的问题。 对这些汇总的问题登记备份，为下次的系统需求做参考。

43 8.4.4 小结 1、项目验收的困难 A、项目验收无统一的标准； B、项目文档验收无统一的标准； C、项目文档验收的困难（因为系统本身的功能、性能等方面导致容易弱化这方面的重要性。）

44 8.4.4 小结 2、项目验收的意义 A、验收ERP的功能、性能、系统动作情 况。 B、验收项目实施过程中的经验，为后续的信息化工作打下基础。

45 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.1 背景说明 分析说明 小结

46 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.1 背景说明 一个很小的项目，做得比较顺利，提前完成并上线。这个小项目是附属于前期公司给该客户做的一个大项目而形成的。总共用了2个月的开发时间，现在上线已经三个月了，客户就卡住一个小问题，说此问题查清后再验收。

47 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.1 背景说明 根源：开发期间有段代码有些小问题，没有解决彻底，大多数情况下此问题是不会出现的，只有在特殊的操作下才会出现，原来基本上是一月出现一次，客户方也一直无法找到规律，总是不能重现此Bug。每次发生这个问题我们的开发人员都积极协助查了多次，一直没能彻底查清（这种偶发性的问题是非常难查的）。

48 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.1 背景说明 问题：之前一直和客户沟通，讲明这个问题属于一般性问题，不会对系统造成任何大的影响，此问题应该放在维护期解决。但客户方老总一直咬定这个问题查清后再验收。不明白为什么这么小的合同额，客户为什么这么较真，而且对于其他问题我们处理都是非常及时的，现在整个合同除了这个问题外，客户也真的找不到其他任何问题了。

49 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.1 背景说明 反馈：我们之前为客户做的大项目早已经验收，和对方主管验收老总交流过一次，他也主要讲了这个大项目存在的问题，而对我们这个小项目的评价是比较稳定。

50 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）

51 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.2 分析说明 项目性质：主要的工作前期“大项目”已经完成，该项目是附属的任务。

52 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.2 分析说明 原因分析： 1、双方的因素； 2、软件提供方的因素； 3、客户的因素；

53 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.2 分析说明 原因分析： 1、双方的因素；（验收无依据） A：在双方签合同时，没有规定验收标准是什么、什么时候验收、验收步骤和流程是什么，以及售后服务的范围是什么等问题。 B：合同写得很清楚，但由于“人情稿与合同”的缘故，双方都没按照合同来执行。

54 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.2 分析说明 原因分析： 1、双方的因素；（验收无依据） 经验总结： 要想让客户方验收,首先要明白其内在的真正意图:做好售后服务的承诺,让客户方放心.或者合同中对验收标准有明确的规定,可以以此为依据,让客户方验收。

55 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.2 分析说明 原因分析： 2、软件提供方的因素； A：项目合同及阶段验收标准有可能不明确，或阶段验收未实施好，与客户沟通不到位，未就售后服务需求与客户达成一致。 B：本项目与大项目有附属关系，客户有将大项目不满的情绪带到本项目中。如果客户故意为难项目经理，说明两者的关系处理得太差。项目经理是要负一定得责任的。

56 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.2 分析说明 原因分析： 2、软件提供方的因素； 经验总结： 1、就项目验收标准，确定哪些主要工作完成即可通过验收，根据合同及相关文件，平时认真做好项目的阶段及里程碑验收，并让客户签字，减少最终验收风险。 2、就项目验收步骤和方法与客户达成共识，前期在项目合同及阶段验收等文件中，与用户达成一致，明确验收标准、时间、双方责任等事项。

57 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.2 分析说明 原因分析： 2、软件提供方的因素； 经验总结： 3、就项目已经完成的程度让用户确认。例如出具系统试运行报告，请客户签字确认。 4、向客户提出明确的服务承诺，是客户没有后顾之忧。

58 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.2 分析说明 原因分析： 2、软件提供方的因素； 经验总结： 5、和客户展开深入的交流，明确客户为什么不愿意验收，动之以情，晓之以理，说明本项目与大项目的区别和联系，并达成售后服务事宜。 6、向公司反映大项目实施情况和用户问题，如果有可能，组织大项目售后调查与评估，及时解决存在的问题。

59 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.2 分析说明 原因分析： 3、客户方的因素； 项目合同及阶段验收标准有可能不明确，或阶段验收未实施好，与客户沟通不到位，未就售后服务需求与客户达成一致。客户存在某种程度的抵触情绪，双方缺乏信任，客户对项目质量信心不足，怕承担责任，因此不愿签字。

60 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.2 分析说明 原因分析： 3、客户方的因素； 经验总结： 一、项目的变更管理可能做得不好，变更未以书面的形式提出申请。 二、虽然有好的变更流程，但客户负责人没有在变更申请上签字。因为客户方害怕出现问题担责任。 三、客户对项目质量如何心里没底，尤其出现了bug，而项目负责人没有及时沟通和解决这个问题，客户当然会拖延时间来进行测试和试用。

61 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.2 分析说明 原因分析： 3、客户方的因素； 经验总结： 客户没底的原因： 一是可能因为合同里没有售后服务的承诺，客户担心签字付款后，系统出问题就没人管；而是对未解决的问题，那个bug，项目方没有承诺解决的时间；二是项目经理和客户方验收老总沟通不够，客户对项目没有信心，不能放心签字。

62 8.5 案例分析2---项目验收迟迟通不过（IT软件提供方角度）
8.5.3 小结 项目经理应该重视与关键项目干系人的沟通，注重跟客户相处的技巧，努力促成双方的良好合作氛围。

63 8.6 案例分析3---教学管理信息系统进行项目总结
8.6.1 项目总体信息 项目评审记录 实际与计划差异分析 项目管理评估总结和建议 质量保证的评估总结和建议 技术开发的评估和建议

64 8.6 案例分析3---教学管理信息系统进行项目总结
8.6.1 项目总体信息 包括项目总时间、总成本、总人力、总规模等信息。 项目总时间：45天，比计划多3天； 项目总成本：￥ ； 项目总人力：5人； 项目总规模：157.80人天；

65 8.6 案例分析3---教学管理信息系统进行项目总结
8.6.1 项目总体信息 规模比例图如图所示：

66 8.6 案例分析3---教学管理信息系统进行项目总结
8.6.2 项目评审记录 总评审次数：23。 其中： 项目计划评审：1； 设计评审：2； 质量评审：2； 定期评审：8； 阶段评审：8； 事件评审：2。

67 8.6 案例分析3---教学管理信息系统进行项目总结
8.6.3实际与计划的差异分析 项目总时间差异表

68 8.6 案例分析3---教学管理信息系统进行项目总结
8.6.3 实际与计划的差异分析 项目总规模差异表

69 8.6 案例分析3---教学管理信息系统进行项目总结
8.6.3实际与计划的差异分析 项目总成本差异表

70 8.6 案例分析3---教学管理信息系统进行项目总结
8.6.3实际与计划的差异分析 结论：从项目时间、规模、成本差异表看，尽管略有差异，但基本上控制在范围以内。

71 8.6 案例分析3---教学管理信息系统进行项目总结
8.6.4 项目管理的评估总结和建议 1) 基本遵循企业的质量体系实施项目管理过程。 2) 由于大家对项目管理的认识不同，项目管理的磨合时间较长。 3) 建议：项目计划期间，管理、开发、质量保证三方应相互明确各自任务和 职责，以提高项目计划的准确性和透明度，为项目实施过程的相互协作打下基础。

72 8.6 案例分析3---教学管理信息系统进行项目总结
8.6.5 质量保证的评估总结和建议 1) 质量保证在项目中基本按计划进行，达到了预期的效果。 2) 系统测试阶段质量保证人员的参与，对产品的验错起到很好的作用。 3) 建议：以后的功能测试应增加质量保证人员。

73 8.6 案例分析3---教学管理信息系统进行项目总结
技术开发的评估总结和建议 1) 开发人员具有一定的敬业精神和实施能力。 2) 开发人员对项目计划的时间概念不强。 3) 建议：增强项目计划的时间观念。

74 8.7 IT项目收尾总结 1、项目收尾就是到了胜负关键的时刻，一不小心就有可能前功尽弃、满盘皆输。 2、每个项目的收尾都在为下一个项目的成功做准备。 3、收尾过程出现的问题，90%都是因为前面过程的问题处理不当导致的结果。 学会学习

75 8.7 IT项目收尾总结 学习有很多种方法，最深刻的是从实践中学习，在项目结束的时候一定要做出总结，形式上项目总结一定要用书面方式。
只需写三种： 在这个项目中我作对了什么？ 在这个项目中我哪些地方作得不够好？ 在以后的项目我需要做哪些改进？

76 8.7 IT项目收尾总结 管理收尾是项目经理经常忽略的过程。 1、把项目文档整理一下归档，对于项目的延续性是有很重要的意义的。 2、项目经理把项目经验归纳归档起来，又会对别的项目经理、对公司的项目管理文化作出了不少的贡献。

77 8.7 IT项目收尾总结 项目收尾其实并不只是收尾阶段要做的事情，它的根源会拉扯到项目的各个阶段。 项目经理的经验起着决定性的作用 抛开尊严与自信，多一点学习别人 的经验

78 8.7 IT项目收尾总结 有助于IT项目成功收尾的因素：

79 8.7 IT项目收尾总结 如何做到IT项目成功收尾： （1）通过正式验收。 （2）项目资金落实到位。 （3）项目总结认真。 （4）客户关系保持良好。

80 8.7 IT项目收尾总结 软件项目收尾是一项复杂的工作，项目经理是其中的关键人物，成功的软件项目收尾应当是通过验收的、资金落实到位的、总结认真的、客户关系保持良好的，是可持续发展的，收尾成功要求项目经理机智地协调收尾工作中的人物的关系，把握住有助于收尾成功的因素，即五个关键词“协调-交流-理解-支持-总结”。

81 8.8 复习思考题： 1、简述什么是IT项目收尾和对它的理解？ 2、简述IT项目收尾的内容？ 3、简述IT项目收尾中管理收尾所包含的内容？ 4、简要说明IT项目开发过程对合同收尾的影响？ 5、简述IT项目收尾过程中的项目验收 6、谈谈你对IT项目收尾制定规范的收尾管理制度的看法？ 7、简要说明导致IT项目收尾混乱的一些因素？ 8、简要说明促使IT项目收尾成功的一些因素？ 9、简述合同收尾过程中包含的内容有哪些？ 10、简述收尾阶段的变更需求如何处理？ （答案见word文档）

82 附相关文档模板： IT项目收尾阶段管理表格(14个DOC)： 用户部门新需求申报单 IT项目产品质量评审表 软件验收单 设备验收单
最终项目文件列表 IT项目验收单 项目成员述职报告模板 项目结束人员安排表 项目成员经验教训报告模板 设备回收交付表 项目团队内部经验总结模板 最终项目内部总结报告模板 最终项目用户移交报告模板