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