系统集成项目管理工程师第7章-案例分析.docx

第7章 项目范围管理7.1 范围定义 系统集成项目管理工程师教程 第23章-案例分析 23.2.1M公司原本是一家专注于企业信息化的公司，在电子政务如火如荼的时候，开始进军电子政务行业，在电子政务的市场中，接到的第一个项目是开发一套工商审批系统。由于电了政务保密要求，该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存着全部信息，其中包括部分机密信息；政务外网可以对公众开放，开放的信息必须御到授权。系统要求在这两个了网中的合法用户都可以访问到被授权的信息.访问的信息必须是一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。 张工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同，有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格爆布模型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。在项目交付时，虽然系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换，由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70%的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重写部分代码才通过驶收，由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也超出原计划的100%。【问题1】（5分）请不超过150字，对张工的行为进行点评?【问题2】（5分）请从项目范围管理的角度找出该项目实施过程中的主要管理问题？不超150字【问题3】（5分）请结合你本人实际项目经验，指出应如何避免类似问题?不超过150字【问题1】请对张工的行为进行点评？ 工作的优点：1、认识到电子政务建设与企业信息化建设的不同，考虑到了项目的独特性的特征； 2、针对业务需求中对内网、外网的互联互通的要求，针对性招聘了网络互联互通的技术人员； 3、满足了用户保密性的要求；工作的缺点：1、采用“瀑布模式”的项目生命周期，没有进行论证，武断；2、用户需求调研的不全面，忽视了系统页面的需求；并且，进行第二版修正时，没有针对页面的需求修改进行确认。 3、设计方案没有进行验证；表现层内耦合的业务逻辑，增加了修改的代价； 4、团队管理措施不力，成员产生挫折感； 【问题 2】请从项目范围管理的角度找出该项目实施过程中的主要管理问题。1、 没有建立规范的项目范围管理流程和制度。2、 范围定义和需求分析时，工作不细致，忽视了B/S架构下的页面需求3、 需求范围变更中，没有对页面变更进行“确认”，就修改代码【问题 3】 答题的思路和提纲，请将下列答题点细化1、 针对甲方的需求，制定实用的项目范围管理计划；2、 做好范围定义工作（详细列出方法）3、 做好需求分析工作（方法、过程、工作步骤）4、 重视范围确认（方法）5、 严格范围变更（变更流程）6、 建立完善的项目范围管理制度和规范的范围管理流程7.2 需求评审 系统集成项目管理工程师教程 第23章-案例分析 23.1.5答：1、软件需求是软件开发的最重要的一个输入，需求风险也常常是软件开发过程中最大的一个风险，降低需求风险的一个重要手段就是需求评审，但是需求评审是所有的评审活动中最难的一个，也是最容易被忽视的一个评审。2 以上的现象可以在很多项目中都可以看到。概括起来，在需求评审中常见的问题是： 需求报告很长，短时间内评审者根本就不能把需求报告读懂，想清楚； 没有作好前期准备工作，需求评审的效率很低； 需求评审的节奏无法控制； 找不到合格的评审员，与会的评审员无法提出深入的问题；3 问题所在：l 评审缺乏有效依据和规范，不能保证评审的覆盖率和有效性。l 产品经理没有把握好会议主题，评审变成了头脑风暴。l 目标性需求没有沟通好，后面的需求变成空中楼阁。l 缺乏评审的可操作依据，遗漏评审内容。l 没有作好前期准备工作，导致评审时间长，效率低。l 没有选择合适的评审人员，无法获得有价值的反馈。l 参加人员过多，容易陷入细枝末节的讨论，会议演变成一场人人自由的混战。 4 那么究竟如何做好需求评审呢？ 建议一：分层次评审 我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次： 目标性需求：定义了整个系统需要达到的目标； 功能性需求：定义了整个系统必须完成的任务； 操作性需求：定义了完成每个任务的具体的人机交互；目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。 建议二：正式评审与非正式评审结合正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。2种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这2种方式。 建议三：分阶段评审应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。 建议四：精心挑选评审员需求评审可能涉及的人员包括：需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。为了保证评审的质量和效率，需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。 建议五：对评审员进行培训在很多情况下，评审员是领域专家而不是进行评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行，同样对于主持评审的管理者也需要进行培训，以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率，避免发生案例一和案例二中出现的现象。对评审员的培训也可以区分为简单培训与详细培训2种。简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中的需要把握的基本原则，需要注意的常见问题说清楚。详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。需要注意的是被评审人员也要被培训。 建议六：充分利用需求评审检查单需求检查单是很好的评审工具，需求检查单可以分成2类：需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。检查单可以帮助评审员系统全面地发现需求中的问题，检查单也是随着工程财富的积累逐渐丰富和优化的。 建议七：建立标准的评审流程对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件，评审需要提交的资料，每次评审会议的人员职责分配，评审的具体步骤，评审通过的条件等等。通过评审流程执行可能会避免出现案例五之类的问题。 建议八：做好评审后的跟踪工作在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。 建议九：充分准备评审评审质量的好坏很大程度上取决于在评审会议前的准备活动。 常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。7.4 范围管理 2009下 阅读下列说明，针对项目的范围管理，回答问题1至问题3，将解答填入答题纸的对应栏内。【说明】 C公司是一家从事电子商务的外国公司，为了在中国开展业务，派出S主管和W翻译来中国寻找合适的系统集成商，试图在中国建设一套业务系统。S主管精通软件开发，但是不懂汉语，而W翻译对计算机相关技术知之甚少。W翻译通过中国朋友介绍，找到了从事系统集成的H公司。H公司指派杨工为该业务系统建设项目经理，与C公司进行交流。经过需求调研，杨工认为，C公司想要建设一个视频聊天网站，并据此完成了系统方案。在W的翻译下，S审阅并认可了H公司的系统方案。经过进一步的谈判，C公司和H公司签订了合同，并把该系统方案作为合同附件，作为将来项目验收的标准。合同签订后，杨工迅速组织人力投入系统开发。由于杨工系统集成经验丰富，开发过程进展顺利，对项目如期完工很有把握。系统开发期间，S主管和W翻译忙于在全国各地开拓市场，与H公司没有再进行接触。就在系统开发行将结束之际，S主管和W翻译来到H公司查看开发进度。当看到杨工演示的即将完工的业务系统时，S主管却表示，视频聊天只是系统的一个基本功能，系统的核心功能则是通过视频聊天实现网上交易的电子商务活动，要求H公司完善系统功能并如期交付。杨工拿出系统方案作为证据，据理力争。 W翻译承认此前他的工作有误，导致双方对项目范围的认识产生了偏差，并说服S主管将交付日期延后2个月。为了完成合同，杨工同意对系统功能进行扩充完善，并重新修订了系统方案。但是，此后C公司又多次提出范围变更要求。杨工发现，不断修订的系统方案已经严重偏离了原始方案，系统如期交付已经是不可能的任务了。【问题1】（6分） 请结合案例简要说明，详细的项目范围说明书应包含哪些内容，并指出C公司和H公司对哪些方面的理解出现了重大偏差。【问题2】（6分） 请指出S主管的要求是否恰当？为什么？并请结合本案例简要分析导致C公司多次提出范围变更的可能原因。【问题3】（3分） 作为项目管理者，杨工此时应关注的范围变更控制的要点有哪些？问题1详细的项目范围说明书应包含如下内容：1、项目的目标；2、产品（或服务）的范围描述；3、项目的可交付物；4、项目边界；5、产品验收标准；6、项目的约束条件；7、项目的假定。C和H在如下几个方面出现了严重偏差：1、项目的目标：H以为是实现视频聊天网站，而C期望是通过视频聊天实现网上交易的电子商务；2、项目的可交付物：同上；3、验收标准：H把未经确认的存在严重偏差的“系统方案”作为验收标准。问题2S主管的要求是恰当的。因为双方在需求（项目范围）理解上存在重大偏差，而H公司未把详细的项目范围说明书（需求分析说明书），提交给C公司（S主管）确认签字。导致C公司多次提出范围变更的可能原因：1、W翻译对计算机相关技术知之甚少