充满血泪的项目收尾

　　众所周知，一个完整的软件项目生命周期在RUP(Rational Unified Process，统一软件开发过程)方法中可以分为：初始需求分析、业务建模、设计阶段、编码和测试、交付部署与收尾阶段等几个过程。在初始阶段项目发生风险损失是最小的，比如在这个阶段如果突然资金来源断了，以至于不能继续进行而不得不终止项目，那么这时候的损失只是需求分析阶段的投入。但随着项目进展风险对项目的损失逐渐变大，快到收尾阶段的时候如果发生重大风险将产生最大的项目损失，严重时可能会烂尾或收不到结算款，这对软件开发项目来说是最大的打击。

　　但让人非常遗憾的是,在软件开发项目中项目收尾过程和工作往往不被大家重视。有时是因为项目任务繁重，开发组为了按时完成任务正忙于埋头赶工，或一大堆的问题急需解决，有时是项目经理干脆就把该项工作给忽略了。因此，在谈到项目收尾时，可能大家都有一大段牢骚话要说，其中的血泪史更是数不胜数。例如，谁都可能经历过在项目"接近"结束的时候突然陷入困境的情况，以为已经干完了"该干的事情"，但客户却不断的提出新要求，结果拿起合同一看。天啊，不但在许多细节需求上丢三落四，而且还可能在重大需求上也存在着缺失，如果客户一定要一项一项地对合同的话，项目根本就不可能验收通过。

　　准确定义软件开发项目收尾

　　项目收尾根据PMI(美国项目管理协会)的概念，工作内容包括：项目范围重新确认和质量验收，就是说项目验收前重新审核工作成果，检验各项工作范围是否完成，或者完成到何种程度。如果是外部开发项目还有费用结算，例如对从项目开始到项目结束全过程所支付的全部费用进行核算，编制项目决算表的过程。最后，还有合同终结，例如整理并存档各种合同文件。

　　简单的说，软件开发收尾一般分为合同收尾和管理收尾两部分。合同收尾就是抓起合同，和客户(无论是内部客户还是外部客户)一项一项的核对，是否完成了合同所有的要求，是否可以把项目结束掉，也就是通常所说的项目验收。管理收尾是说把开发期间的所有项目文档整理和归档的过程，例如收集需求分析文档、编码文档、测试文档、会议记录，当然还有阶段性总结报告等。

　　(1)合同收尾

　　合同收尾就是了结开发合同并结清帐目，包括解决所有尚未了结的事项。合同收尾需要对整个项目开发过程进行系统地审查，找出合同上签订的事项是否已经完成任务。据经验分析，软件开发项目也象众多的工程项目收尾一样，合同收尾是最容易产生问题的时候。就象经常提到的80/20理论，花了计划的80%的时间以为完成了项目80%的工作，结果剩余的20%的收尾工作又要花80%的计划时间来完成。

　　因此，合同收尾往往是软件开发经理最为头痛的事情，理想的情况下既要使客户和用户对软件满意，又要使公司顺利地收到项目资金，造就一个"双赢"的局面。但实际中，软件开发项目先天就有很多不确定因素，比如软件功能需求人员在并不清楚项目的具体细节和难度的时候所许诺的事情根本就是一个泥潭，还有由于用户需求不明确造成的不断变更需求等。考试大编辑整理

　　(2)管理收尾

　　管理收尾是指对项目验收正式化而进行的项目资料的移交和归档。具体包括开发记录、功能需求对照表、测试记录、项目阶段性进度报告等。因此，管理收尾做得是否好对降低项目失败率有重大的意义，例如有什么地方可以改进的建议，这类问题进行分析总结得越多，资料就越丰富，就越能预防项目风险。同时，管理收尾也是收集、整理、保存项目记录最好的时机。当当项目快要完成的时候，项目成员手头都还保留有工作记录，收集起来是非常容易的。时间久了，有些项目成员可能去了其它项目组，有些可能离职了，到那时去收集可能就晚了，有些记录可能就永远也找不到了。

　　为什么项目收尾工作总是这么难?

　　一直以来有一个怪圈，项目似乎到达收尾阶段很容易，但真正要把尾给收好了，到达一个可以完善的阶段却总是面临一堆问题，拖了又拖。我们经常在软件开发项目中不止一次听到，许多项目在合同收尾的时候才出现了大的漏洞。

　　(1)没有明确项目收尾负责人

　　我曾经经历过的两个项目，在收尾的时候都设置了项目收尾主管来专门负责收尾，项目收尾之难，可见一斑。因为收尾工作的复杂和千头万绪，收尾如果没有指定专人负责，就不能及时的把项目文档整理、验收、归档等。而且没有专人结合合同条款拟定收尾计划也就不能保证能全面的解决了合同的要求。总而言之，如果对项目收尾工作不重视，就会因为合同只差少许事情没有做好而不能验收通过，使到结算款收不到，这对软件开发来说可是一件大事情。

　　(2)开发计划安排前松后紧

　　无数个项目我们在早期显得"有条不紊"， 前期时间安排宽裕，成员可以花大量时间不紧不慢地讨论、写文档，而且许多管理收尾的工作如文档应该提前做好而事实上没有做好，到了后期时间紧张时才发现没有时间再做文档资料整理了。由于后期时间紧张，结果为了赶工除了不断加班还被迫删减一些东西，或许采用"临时"方案造成虎头蛇尾，也许删减是可行的，但"临时"方案几乎必然导致更大的人力浪费和混乱。造成这种问题就是因为前期安排不紧凑，过度乐观的假设，低估工作量，使到项目收尾时经常发生丢三落四的事情。

　　(3)没有制定规范的管理收尾制度

　　项目收尾是个琐碎、重复的工作，所以必须要制定规范的收尾制度。项目收尾制度必须是严密无情的，这样才能确保该收上来的信息、数据、文档等能及时的收上来。管理收尾是项目经理经常忽略的过程，实际上如果在合同清理时找不到相关文档，还是一样要找项目经理的茬。因此，项目收尾规范化是很关键的，这也是日后系统运行维护的需要，不能总是依靠项目组成员的自觉性来保证。所以，从制度上保证不丢失重要的资料，保证管理收尾的各项活动不得拖延到项目完成之后非常有必要。

　　成功项目收尾的步骤

　　项目负责人在项目快结束的时候，除了要做好合同收尾的一项一项对照检查外，还需要重点关注以下的几个收尾细节，为日后项目验收打下坚实的基础。否则会悔之莫及。

　　(1)专人负责、强调计划

　　搞软件开发的人都知道项目开始和收尾是最难干的，尤其是项目收尾。纷繁复杂是个擦屁股的辛苦活，加上临近结束人心浮动, 和客户的关系也因为牵涉到最后的结算，扯皮事儿特别多，矛盾日渐突出。在这种情况下，项目经理的重视和对收尾工作的强力支持就显得异常重要了，因此收尾必须指定专人负责。此人直接对项目经理负责，再辅以熟悉项目情况的人员，组成一个精干的移交、验收、资料归档小组，进行验收和归档为主的收尾工作。

　　同时，收尾要特别强调计划。可由负责收尾的人根据实际情况结合合同条款拟定计划，为保证计划的执行，最好要有一个例会制度，各方定期审查进度，及时解决存在的问题。总之，充分准备就是要有水到渠成的感觉，所有的问题都要在验收前解决掉，真正到验收时只是个形式，签字就行了。因此，一定要重视并做好项目收尾工作，千万不要把它当作可有可无的事情。

　　(2)收尾阶段需求变更的处理方法

　　当项目要收尾了，用户需求还在变怎么办呢?如果任由用户需求老是在变，项目验收就会遥遥无期。因此，要主动取得用户的理解，对其不甚合理的地方作出解释，争取谈判和开发上的主动性。不能一味的答应用户无理的需求，否则很有可能会陷入反复变更的泥潭而不得脱身，可以尽量与用户沟通争取把某些功能将放在下一个版本中去实现。

　　(3)公司领导大力支持,为顺利收尾保驾护航

　　软件项目收尾是一项复杂的工作，项目经理是其中的关键人物。成功的软件项目收尾应当是验收通过、资金顺利回收、客户关系保持良好的。因此收尾成功要求项目经理机智地协调收尾工作中的人物的关系，但因为项目开发活动只是整个生态范围环境中的一部分，许多对项目的影响因素不是为项目经理所控制的。因此，在收尾工作如客户款项收取、合同结束会谈、客户关系出现危机等许多场合下需要开发方公司高层领导的支持和参与，在一个公司领导很重视的环境下，收尾工作会是更为出色和顺利。

　　(4)强调并建立管理收尾的制度化

　　最后一点,是应该建立制度化的管理收尾。一般建议管理收尾事先列一个项目记录存档清单，在项目每一个阶段那些工作记录需要收集、整理和保存，由谁提供，什么时候提供，文档记录格式和要求等。并告知相关项目成员，除了完成项目工作以外，向项目经理及时提供准确的工作记录也是一项非常重要的工作。只有做到这一点，才能为项目收尾真正画上一个圆满的句号。