第13章 软件项目结束

第13章软件项目结束13.1合同结束项目终止的条件项目计划中确定的可交付成果已经出现，项目的目标已经成功实现项目已经不具备实用价值项目由于各种原因而导致无限期拖长项目出现了环境的变化，它负面影响项目的未来项目所有者的战略发生了变化项目无竞争力，难以生存甲方合同结束----验收过程验收清单制定验收清单评审验收计划制定验收计划执行验收报告验收报告确认需求资料验收报告合同文本验收问题处理计划甲方合同结束----合同终止过程合同有关文档归档合同终止通知项目执行总结合同项目执行总结乙方合同结束在合同终止过程中，乙方(供方)应该配合需方的工作，包括项目的验收、双方认可签字、总结项目的经验教训、获取合同的最后款项、开具相应的发票、获取需方的合同终止的通知、将合同相关文件归档的过程。13.2项目结束成功与失败的标准可交付成果如何是否实现目标是否达到项目业主的期望软件项目关闭前应该完成的任务客户正式接受这个项目。项目记录完整。产品的最后版本必须满足完整的条件。保留必要的项目文档。准备经验学习资料。转移必要的权限。结束过程----结束计划项目计划的一部分与客户一同评审项目结束计划细化并实施项目结束计划结束过程----项目收尾工作内容范围确认项目接收前，重新审核工作成果，检验项目的各项工作范围是否完成，或者完成何种程度，最后，双方确认签字。质量验收质量验收是控制项目最终质量的重要手段，依据质量计划和相关的质量标准进行验收，对不合格的不予接收。费用决算当所有的工作成果都通过验收后，乙方向甲方提交最终产品的过程。结束过程----项目收尾工作内容合同终结费用决算是指从项目开始到项目结束全过程所支付的全部费用进行核算，并编制项目决算表的过程，财务人员负责支付合同余款。资料验收收尾阶段需要花时间来汇集项目的文件，检查项目过程中的所有文件是否齐全，然后进行归档以供将来使用，为企业提供了一个项目准确的历史。结束过程----最后评审是否实现项目目标是否遵循项目进度是否在预算成本内完成项目项目进度过程中出现的突发问题以及解决措施是否合适，问题是否得到解决对特殊成绩的讨论和认识回顾客户和上层经理人员的评论从该项目的实践中可以得到哪些经验和教训项目总结项目总结是一个把实际运行情况与项目计划不断比较以提炼经验教训的过程。通过项目质量计划和总结，项目过程中的经验和教训将得到完整的记录和升华，成为“组织财富”。总结成功的经验和失败的教训，为以后的项目人员更好的工作提供一个极好的资源和依据。对软件项目过程文件进行总结，将项目中的有用信息进行总结分类，放入信息库。项目总结良好气氛下的充分交流。讨论需求及变更需求时，需求人员与客户及用户应该尽量采取协作的态度，良好的工作氛围也会提高工作效率。确定需求基线的过程也就是与用户交流的过程。需求人员认真听取用户的要求，进行分析和整理。专职人员负责需求变更管理。专职的需求人员和由此组成的需求变更执行小组是项目稳定、进度良好的保证。专职人员应该具有专业的需求分析技巧技能，针对用户的变更需求，可以给用户说明利弊，可以按紧迫程度为开发人员提供工作重点。项目总结明确合同约束，限制需求变更。需求在软件项目中的地位已经越来越重要，需求变更给软件开发带来的影响也是有目共睹的，甚至可能因为质量低下的需求或者频繁无控制的需求变更而导致项目的失败。让客户明白需求变更给项目带来的工期、成本等各方面的影响，在互相理解的基础上增加合同条款，比如明确说明客户可以提出需求变更的期限，超过期限的需求变更的具体处理细则。良好的软件结构适应需求变更。优秀的软件体系结构可以快速应对不同情况的需求变更，这样就可以适当降低需求的基线（当然是在成本影响的允许范围内），从而来提高客户的满意度。13.3项目管理的建议项目管理的常见问题1）缺乏项目管理系统培训。在软件企业中，以前几乎没有专门招收项目管理专业的人员来担任项目经理，被任命的项目经理主要是因为他们能够在技术上独当一面，而管理方面特别是项目管理方面的知识比较缺乏。2）项目计划意识问题。项目经理对总体计划、阶段计划的作用认识不足，因此制定总体计划时比较随意，不少事情没有仔细考虑；阶段计划因工作忙等理由经常拖延，造成计划与控制管理脱节，无法进行有效的进度控制管理。

3）管理意识问题。部分项目经理不能从总体上把握整个项目，而是埋头于具体的技术工作，造成项目组成员之间忙的忙、闲的闲、计划不周、任务不均、资源浪费。有些项目经理没有很好的管理方法，安排不好工作只好自己做，使项目任务无法有效、合理地分配给相关成员，以达到“负载均衡”。项目管理的常见问题4）沟通意识问题。在项目中一些重要信息没有进行充分和有效的沟通。在制定计划、意见反馈、情况通报、技术问题或成果等方面与相关人员的沟通不足，造成各做各事，重复劳动，甚至造成不必要的损失。5）风险管理意识问题。有些项目经理没有充分意识到风险管理的重要性，对计划书中风险管理的章节简单应付了事，随便列出几个风险，随便地写一些简单的对策，对于后面的风险防范起不到什么指导作用。6）项目干系人问题。在范围识别阶段，项目组对客户的整体组织结构、有关人员及其关系、工作职责等没有足够了解，以至于无法得到完整需求或最终经权威用户代表确认的需求。项目管理的常见问题7）项目团队内分工协作问题。项目团队内部有时责任分工不够清晰，造成工作互相推诱、责任互相推卸的现象。有时各项目成员只顾完成自己那部分任务，不愿意与他人协作。这些现象都将造成项目组内部资源的损耗，从而影响项目进展。项目管理的经验和建议1）平衡关系。需求、资源、工期、质量四个要素之间的平衡关系问题。需求定义了“做什么”，定义了系统的范围与规模，资源决定了项目的投人（人、财、物），工期定义了项目的交付日期，质量定义了做出的系统好到什么程度，这四个要素之间是有制约平衡关系的。2）高效原则。在需求、资源、工期、质量四个要素中，很多的项目决策者是将进度放在首位的，现在市场的竞争越来越激烈，软件开发越来越追求开发效率，大家从技术、工具、管理上寻求更多更好的解决之道。项目管理的经验和建议3）分解原则。“化繁为简，各个击破”是自古以来解决复杂问题的不二法门，对于软件项目来讲，可以将大的项目划分成几个小项目来做，将周期长的项目划分成几个明确的阶段。项目管理的经验和建议4）实时控制原则。在一家大型的软件公司中，有一位很有个性的项目经理，该项目经理很少谈起什么管理理论，也未见其有什么明显的管理措施，但是他连续做成多个规模很大的软件项目，而且应用效果很好。大家一直很奇怪他为什么能做的如此成功，经过仔细观察，终于发现他的管理可以用“紧盯”二字来概括，即每天他都要仔细检查项目组每个成员的工作，从软件演示到内部的处理逻辑、数据结构等，一丝不苟，如果有问题，改不完是不能去休息的。正是在他这种简单的措施下，支撑他完成了很多大的项目，当然他也是相当的辛苦。我们并非要推崇这种做法，这种措施也有他的问题，但是，这种实践却说明了一个很朴实的道理：如果你没有更好的办法，就要辛苦一点，实时控制项目的进展，要将项目的进展情况完全的实时的置于你的控制之下。项目管理的经验和建议5）分类管理原则。由于项目具有很多的特殊性，对于不同的软件项目其项目目标差别很大，项目规模不同，应用领域不同，采用的技术路线差别也很大，因而，针对每个项目的不同特点，不同的组织应该针对自己的特点实施相应的策略，其管理的方法、管理的侧重点应该是不同的。需要“因材施教”、“对症下药”。对于小项目不能像管理大项目那样去做，对于产品开发类的项目，也不可能像管理系统集成类的项目那样去做，项目经理需要根据项目的特点，制订不同的项目管理的方针政策。项目管理的经验和建议6）简单有效原则。项目经理在进行项目管理的过程中，不要花哨的功能，不要让多余的功能以花哨的面貌出现在项目中。往往会得到开发人员这样的抱怨：“太麻烦了，浪费时间，没有用处”，这是很普遥的一种现象。当然这样的抱怨要从两个方面来分析，一方面开发人员本身可能存在不理解，或者逆反，心理的情况，另一方面，项目经理也要反思：我所采取的管理措施是否简单有效？搞管理不是搞学术研究，没有完美的管理，只有有效的管理，不要确定不合理的目标。而项目经理往往试图堵住所有的漏洞，解决所有的问题，恰恰是这种理想，会使项目的管理陷人一个误区，作茧自缚，最后无法实施有效的管理，导致项目的失败。项目管理的经验和建议7）规模控制原则。该原则是和上面提到的其他原则相配合使用的，即要控制项目组的规模，不要人数太多，人数多了，进行沟通的渠道就多了，管理的复杂度就高了，对项目经理的要求也就高了。可以以少数资深人员开始项目。在徽软的MSF中，有一个很明确的原则就是要控制项目组的人数不要超过10人，当然这不是绝对的，也和项目经理的水平有很大关系。但是人员“贵精而不贵多”，这是一个基本的原则，这和我们上面提到的高效原则、分解原则是相辅相成的。13.4