首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    2015年信息系统项目管理师真题_信息系统项目管理师题目

    项目范围管理一般上午考察3分,需求是龙头,是做项目管理的基础。没有需求就不能确定项目的范围,没有范围,项目就无从谈起,此部分在下午案例分析的几率也是比较大的。 上午历年考试的重点在范围定义的概念,产品范围和项目范围以及各自的衡量标准。详细范围说明书的内容,WBS的表现形式,分解的方法,原则,工作包的定义作用,范围确认,范围基准,范围蔓延,范围变更等知识点上。输入输出和工具与技术直接考察的并不算多。 本章在下午案例分析的命题思路主要表现为:给出某项目在范围管理方面的案例场景描述,要求指出该案例场景中存在哪些问题并说明相关原因,要求给出解决这些问题的补救措施。

    04

    PMP 第5章错题总结

    1.工作分解结构是项目团队与相关方之间沟通的有效工具之一 2.控制账户是工作分解结构某个层次上的要素,以便与工作包一一对应 3.项目范围说明书包括产品范围、产品验收标准、项目可交付成果、项目除外责任,以及项目制约因素及假设条件的描述 4.范围变更会修改已确定的范围 5.工作分解结构的每一项都被分配了唯一的标识符:账户编码 6.规划范围管理过程是描述将如何定义、确认和控制项目范围 7.产品分析又叫产品分解,属于定义范围的工具 8.创建工作分解结构过程的结果是团队意见统一 9.WBS的基础是产品需求和项目需求 10.质量控制和确认范围往往同时进行 11.确认范围重点关注可交付成果的验收 12.控制账户>规划包>工作包 13.大多数同意是获得群里中超过50%人员的支持,就能做出决策的技术 14.审查项目章程之后,项目经理接着进行收集需求,后续再定义范围,输出项目范围说明书,范围规划后进行进度的规划 15.联合应用开发(JAD)适用于软件行业,用于改进软件开发过程 16.工作绩效信息属于控制范围过程的输出 17.原型法体现了渐进明细的理念 18.在工作分解结构自上而下的细分中,将导致估算准确度增加 19.用来衡量产品范围完成情况的文件是产品需求文件 20.工作分解结构中的工作是指作为活动结果的工作产品或可交付成果 21.质量功能展开QFD从收集客户需求(又称客户声音)开始,然后客观地对这些需要进行分类和排序,并为实现这些需要而设定目标 22.可交付成果必须具备的特性、功能和特征属于解决方案需求 23.引导与主题研讨会结合使用,可用于快速定义跨职能需求并协调相关方的需求差异 24.项目章程的可交付成果颗粒度太大 25.项目管理计划包括:范围基准、进度基准、成本基准 26.范围基准包括:范围说明书、WBS、WBS词典 27.WBS的用途:组织和定义项目的所有范围 28.管理质量-->过程QA 29.控制质量-->结果QC 30.范围蔓延是未经批准的 31.当相关方不愿或不能说明他们的需求时,用观察法收集需求

    01

    5 范围蔓延和镀金,90%的项目死于这两大杀手!人人都是项目经理系列(第5/13篇)

    游戏开发中,绝大多数都是使用的瀑布型,这也是我们这个系列主要介绍的方式。 “范(围)进(度)成(本)”是一个项目的重点,而需求则直是项目管理的重中之重,它是进度、成本的大前提。项目经理需要负责确保这些需求在项目管理计划中都有所安排,并且在预算内按时完成,同时尽可能的创造利润和价值。 在游戏开发领域也是一样,你本来做着《王者荣耀》,突然吃鸡火了,项目做一半去做吃鸡模式,自走棋火了,又去做自走棋,捡树枝火了,又去做捡树枝,范围的变更会导致进度和成本遥遥无期。所以防止范围失控是项目经理首要的责任目标。 所以最后,总结一下:项目范围管理包括 做且只做 所需的全部工作。 2 收集需求 收集需求的原始定义:为实现目标而确定、记录并管理相关方的需要和需求的过程。它为定义产品范围和项目范围奠定基础。 不过在细说收集需求之前,还要先提一个过程,叫做规划范围管理计划。这个是什么意思呢?还记得我们上一个章节里有一个过程叫做规划项目管理,其中的输入就来自于各个子的管理计划的输出。 范围管理计划里面没有定义实际的范围,它是一个流程性的文件,主要描述项目是如何定义、制定、监督、控制和确认项目范围的。 举个例子,在游戏开发中,需求一般是由策划负责的。主策划出具了一份需求规范,里面有写到,需求可以由项目里的任何人提出,然后由主策划评定是否有价值,通过后纳入需求池,然后指定具体的策划出具详细的策划案,最后对已经完成策划案的功能进行版本排期开发。 这就是一份最简单的范围管理计划了。但实际项目里,需求增加会更复杂一些,它可能还需要设计需求的优先级评定,指标测量等等,但是无论如何,范围管理计划里面是一定没有实际范围的,它只是流程性或者管理性的文件。 再反过来说需求,需求的概念是根据特定协议或其他强制性规范,产品、服务或成果必须具备的条件或能力。他包括,发起人、客户和其他相关方的 已量化 且 书面记录 的需要和期望。 你是开发,如果有策划拿着手机过来跟你说,你把这个士兵的颜色调成跟它们这个一样的红色。你可以呸他脸上。策划和程序沟通交流,最基本的礼仪就是文档。士兵ID是多少,颜色的色值是多少,有没有和主策划、PM报备过,有没有评估过实现难度,主程又知不知道。当然如果你们关系比较好,他说下午请你喝个奶茶,你调个效果给他看下,倒是可以考虑下。 需求的收集有很多种方式,这里罗列一下: 这里简单说一个我觉得有意思的地方,工作指导和工作跟随。 女朋友要换新电脑,叫你给方案。你说,CPU应该选I9,显卡应该选2080,内存应该要32GX4(确定是给女朋友配还是给自己?),这叫做指导,能够讲清楚,说明白的。但是淘宝下单,全部到了之后怎么组装?你远程视频教了两个小时,结果女朋友把硅胶涂到CPU的针脚面上了。你吓得赶紧过来,10分钟把主机组装好,为了让女朋友看的清楚,又拆掉装了两遍。然后女朋友在你手把手的方式下,自己把电脑装好了(虽然不知道为什么要插那,但是插上好像就对了)。这种方式叫做工作跟随。有些事情你要描述很困难,但是要实操一下就好。 收集需求的最终输出就是需求文件,很多流程管理里叫做用户故事Story。只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要相关方愿意认可的需求,才能作为基准。 大概有如下分类: 比如:

    04
    领券