【信管师-资料总结篇】三、范围管理

项目范围管理

• 1、项目的范围基准：经过批准的项目范围说明书、WBS 和 WBS 词典。
• 2、判断项目范围是否完成，要以范围基准来衡量。产品范围是否完成，则根据产品是否满足了产品描述来判断。
• 3、范围管理计划是制订项目管理计划过程和其他范围管理过程的主要输入，包含如下内容 ：
  （1）如何制订项目范围说明书。
  （2）如何根据范围说明书创建 WBS。
  （3）如何维护和批准 WBS。
  （4）如何确认和正式验收已完成的项目可交付成果。
  （5）如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。
• 4、项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的。
• 5、需求管理贯穿于整个过程，它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基 线。另外，还要建立需求跟踪能力联系链确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
• 6、需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。主要包括以下内容：
  （1）如何规划、跟踪和汇报各种需求活动。
  （2）需求管理需要使用的资源。
  （3）培训计划 。
  （4）项目干系人参与需求管理的策略。
  （5）判断项目范围与需求不一致的准则和纠正规程 。
  （6）需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求 。
  （7）配置管理活动。
• 7、需求的分类：
  （1）业务需求
  （2）干系人需求
  （3）过渡需求
  （4）质量需求，QFD 对质量需求进行了细分，分 为基本需求、期望需求和意外需求。
• 8、收集需求的工具与技术主要有：访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、 观察、原型法、标杆对照、系统交互图、文件分析等。
• -9、焦点小組：将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。 由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比一对一的访谈更加热烈。焦点小组是一种 群体访谈而非一对–访谈，可以有 6〜10 个被访谈者参加。针对访谈者提出的问题，被访谈者之间开展互动式讨 论，以求得到更有价值的意见。
• -10、引导式研讨会：通过邀请主要的跨职能干系人一起参加会议。引导式研讨会对产品需求进行集中讨论与定义。 研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于 建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。该技术的另一个好处是，能够比单项会议更 快地发现和解决问题。
• -11、群体创新技木是指可以组织一些群体活动来识别项目和产品需求，群体创新技术包括头脑风暴法、名义小组 技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。
  （1）头脑风暴：各抒己见
  （2）名义小组技术：通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是 头脑风暴法的深化应用，是更加结构化的头脑风暴法
  （3）德尔菲技术：可以防止个人的观点被不正确的放大
  （4）概念/思维导图：是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与 差异，从而引导出新的创意。
  （5）亲和图又称为 KJ 法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图 解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方 法。亲和图的核心是头脑风暴法，是根据结果去找原因。
  （6）多标准决策分析是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准， 从而对众多方案进行评估和排序的一种技术。
• -12、群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以 及对产品需求进行归类和优先排序。
• -13、标杆对照将实际或计划的做法与其他类似组织的做法(例如,流程、操作过程等）进行比较，以便识别最佳实 践，形成改进意见，并为绩效考核提供依据„标杆对照所采用的“类似组织”可以是内部组织，也可以是外部组 织。
• -14、系统交互图是对产品范围的可视化描述，显示系统（过程、设备、信息系统等）与参与者（用户、独立于本 系统之外的其他系统）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输 出接收者。
• -15、文件分析就是通过分析现有文档,识别与需求相关的信息来挖掘需求。可供分析的文档很多，包括商业计划、 营销文档、协议、招投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库、应用软件文档、用例文档、 其他需求文档、问题日志、政策、程序和法规文件等。
• 16、收集需求过程的主要输出有需求文件和需求跟踪矩阵。需求文件描述各种单一的需求将如何满足与项目相关 的业务需求。
• 17、需求文件的内容包括（但不限于）以下几个方面：
  （1）业务需求
  （2）干系人需求
  （3）解决方案需求
  （4）项目需求
  （5）过渡需求。
  （6）与需求有关的假设条件、依赖关系和制约因素。
• 18、需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求基线，保持项目计划与 需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可 交付物之间的依赖关系，跟踪基线中需求的状态。
• 19、可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟 踪，这些元素包括各种类型的需求、业务规则、系统组件，以及帮助文件等。可验证性是需求的最基本特性
• 20、每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性。所谓双向跟踪，包括正向跟踪和 反向跟踪，正向跟踪是指检查需求文件中的每个需求是否都能在后继工作产品（成果）中找到对应点；反向跟踪 也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。具体来说，需求跟踪涉及五种类型。如图：
  
• 21、从用户原始需求可向前追溯到需求文件，这样就能区分出项目过程中或项目结束后由于变更受到影响的需求，也确保了需求文件中包括所有用户需求。同样，可以从需求文件回溯到相应的用户原始需求，确认每个需求的出处。注意区分追溯和回溯。
• 22、由于在项目实施过程中，产品需求转变为设计和测试等实现元素，所以通过定义单个需求和特定的产品元素之间的联系链，可以从需求文件追溯到产品元素。这种联系链使项目团队成员知道每个需求对应的产品元素，从而确保产品元素满足每个需求。第四类联系链是从产品元素回溯到需求文件，使项目团队成员知道每个产品元素存在的原因。如果不能将设计元素或测试案例回溯到一个需求文件，就可能出现镀金行为。当然，如果某个孤立的产品元素表明了一个正当的功能，则说明需求文件漏掉了一项需求。
• 23、第五类联系链是需求文件之间的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。
• 24、表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。
• 25、应在需求跟踪矩阵中记录每个需求的相关属性这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（例如，进行中、已取消、已推迟、新增加、已批准、已分配、已完成等）和状态日期。
• 26、产品分析是一种有效的工具。通常，针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述。
• 27、项目范围说明书包括如下内容：
  （1）产品范围描述
  （2）验收标准
  （3）可交付成果
  （4）项目的除外责任
  （5）制约因素
  （6）假设条件。
• 28、里程碑标志着某个可交付成果或者阶段的正式完成。重要的检查点是里程碑、重要的里程碑是基线。
• 29、工作包是位于 WBS 每条分支最底层的可交付成果或项目工作组成部分，工作包的大小需要遵循 8/80 原则。
• 30、控制账户是一种管理控制点。是 WBS 某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素。如果是后一种情况，一个控制账户中就包括若干个工作包，但一个工作包仅属于一个控制账户。
• 31、规划包是指在控制账户之下，工作内容已知但尚缺详细进度活动的 WBS 组成部分。是在控制账户之下、工作包之上的 WBS 要素，是暂时用来做计划的。随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。
• 32、WBS 词典也称为 WBS 词汇表，它是描述 WBS 各组成部分的文件。
• 33、创建 WBS 过程的工具与技术主要有分解和专家判断，通常需要开展以下活动：
  （1）识别和分析可交付成果及相关工作。
  （2）确定 WBS 的结构和编排方法。
  （3）自上而下逐层细化分解。
  （4）为 WBS 组件制定和分配标识编码。
  （5）核实可交付成果分解的程度是恰当的。
• 34、分解的原则
  （1）功能或者技术原则。在创建 WBS 时，需要考虑将不同人员的工作分开。
  （2）组织结构。对于职能型的项目组织而言，WBS 也要适应项目的组织结构形式
  （3）系统或者子系统。总的系统划分为几个主要的子系统，然后对每个子系统再进行分解
• 35、在进行 WBS 分解时，可以有如下三种方式注意，如果说是第一层，也对：
  （1）将项目生命周期的各阶段作为分解的第二层
  （2）主要可交付成果作为分解的第二层
  （3）子项目作为分解的第二层
• 36、WBS 不是某个项目团队成员的责任,应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。
• 37、较常用的 WBS 表示形式主要有分级的树型结构（组织结构图式）和表格形式（列表式）。
• 38、树型结构图的 WBS 层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目很难表示出项目的全貌。用于中小型项目。表格形式的直观性比较差，但能够反映出项目所有的工作要素，用于大型项目。
• 39、在分解的过程中，应该注意以下 8 个方面。
  （1）WBS 必须是面向可交付成果的。项目的目标是提供产品或服务，仅仅是一连串特别的活动。
  （2）WBS 必须符合项目的范围。WBS 必须包括，也仅包括为了完成项目的可交付成果的活动
  （3）WBS 的底层应该支持计划和控制。WBS 是项目管理计划和项目范围之间的桥梁，WBS 的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。
  （4）WBS 中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与
  （5）WBS 的指导。作为指导而不是原则，WBS 应控制在 4〜6 层。当然，大项目可以超过 6 层。
  （6）WBS 应包括项目管理工作,也要包括分包出去的工作。
  （7）WBS 的编制需要所有（主要）项目干系人的参与，需要项目团队成员的参与。
  （8）WBS 并非是一成不变的„在完成了 WBS 之后的工作中,仍然有可能需要对 WBS 进行修改。
• 40、当一个项目的 WBS 分解完成后，项目干系人对完成的 WBS 应该给予确认，并对此达成共识。
• 41、确认范围的主要工具与技术是检查和群体决策技术。检査也称为审查、评审、审计、走查、巡检、测试等。
• 42、确认范围应该贯穿项目的始终，一般步骤如下
  （1）确定需要进行范围确认的时间。
  （2）识别范围确认需要哪些投入。
  （3）确定范围正式被接受的标准和要素。
  （4）确定范围确认会议的组织步骤。
  （5）组织范围确认会议。
• 43、确认范围与核实产品：核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或客户来验证，强调产品是否完整；确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。
• 44、确认范围与质量控制，确认范围与质量控制的不同之处在于：
  （1）确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准)。
  （2）质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段未进行。
  （3）质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。
• 45、确认范围与项目收尾，确认范围与项目收尾的不同之处在于：
  （1）虽然确认范围与项目收尾工作都在阶段未进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作。
  （2）确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。
• 46、需求工程：与需求相关的活动都叫做需求工程，分为 2 类：一类是需求开发、一类是需求管理。
• 47、需求开发主要包含：需求获取（捕获用户的需求）、需求分析（将需求信息进行分析、抽象描述、建立概念模型）、需求定义（编制《需求规格说明书》）、需求验证（对需求文档进行评审，确认需求。）在需求开发中，完成需求验证过程后将确定需求基线。
• 48、需求管理包含：制定需求管理计划（如何进行需求管理的）、求得对需求的理解（确保项目干系人对需求正确理解）、求得对需求的承诺（实现需求所需的活动人员之间达成一致和建立承诺）、管理需求变更（通过变更流程对需求进行管理，防止需求蔓延）、维护对需求的双向跟踪性（需求文档和产品之间的双向跟踪）、识别项目工作与需求之间的不一致性（识别项目计划和工作产品与需求之间的不一致之处）。