啥也不说了，又没人看也得坚持下去~~~

5.2 规划范围管理

规划范围管理是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，在整个项目中对如何管理范围提供指南和方向。范围管理计划需要项目管理团队全员 参与。

5.2.1 范围管理计划

项目范围管理计划可能项目，在项目管理计划之中，也可能作为单独的一项。根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的。

范围管理计划是制订项目管理计划过程和其他范围管理过程的主要输入，要对将用于下列工作的管理过程作出规定。

• 如何制订项目范围说明书。
• 如何根绝范围说明书创建WBS。
• 如何维护和批准WBS。
• 如何确认和正式验收已完成的项目可交付成果。
• 如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。

5.2.2 需求管理计划

需求管理贯穿于整个过程,它的最基本的任务就是明确需求，并使项目团队和用户达成共识，即建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。

需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。

主要包含以下内容。

• （1）如何规划、跟踪和汇报各种需求活动。
• （2）需求管理需要使用的资源。
• （3）培训计划。
• （4）项目干系人参与需求管理的策略。
• （5）判断项目范围与需求不一致的准则和纠正规程。
• （6）需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求。
• （7）配置管理活动。

5.3 收集需求

5.3.1 需求的分类

• （1）业务需求：整个组织的高层级需求，例如：解决业务问题或者抓住业务机会，以及实施项目的原因。
• （2）干系人需求：是指干系人活干系人群体的需要。
• （3）解决方案需求
• （4）过渡需求：从当前状态过渡到将来状态所需的临时能力
• （5）项目需求：项目需要满足的行动、过程或其他条件。
• （6）质量要求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件和标准。QFD对质量需求进行了细分，分为基本需求、期望需求和意外需求。

5.3.2 收集需求的工具与技术

5.3.3 需求文件

收集需求过程的主要输出有需求文件和需求跟踪矩阵。需求文件描述各种单一的需求将如何满足与项目相关的业务需求。需求文件既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。其内容包括：

• 业务需求
• 干系人需求
• 解决方案需求
• 项目需求
• 过渡需求
• 与需求有关的假设条件、依赖关系和制约因素。

5.3.4 需求跟踪

1. 需求跟踪的内容

每个配置项的需求到其涉及的产品（构件）需求都要具有双向可跟踪性。所谓双向跟踪，包括正向跟踪和反向跟踪。正向跟踪是指检查需求文件中的每个需求是否能在后继工作产品（成果）中找到对应点；反向跟踪也称为逆向跟踪，是指检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。具体来说，需求跟踪涉及五中类型，如图，箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，即从需求建议到交付的全过程。

第五类联系链是需求文件之间的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏。

①　追溯到需求（客户需求——需求）

②　从需求追溯（需求——下游工作产品）

③　回溯到需求（下游工作产品——需求）

④　从需求回溯（需求——客户需求）

2. 需求跟踪矩阵

表示需求和其他产品元素之间的联系链的最普遍方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。

需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文件描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（例如，进行中、已取消、已推迟、新增加、已批准、已分配、已完成等）和状态日期。

5.4 定义范围

定义范围是制定项目和产品详细描述的过程，是明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确产品、服务或成果的边界。

5.4.1 定义范围的工具与技术

主要工具与技术有专家判断、产品分析、备选方案生成和引导式研究会。

5.4.2 项目范围说明书

1. 范围说明书的内容

• （1）产品范围描述。
• （2）验收标准。
• （3）可交付成果
• （4）项目的除外责任。
• （5）制约因素。
• （6）假设条件。

项目经理向干系人说明项目范围时，应以项目范围说明书为依据。

2. 范围说明书的作用

• （1）确定范围。
• （2）沟通基础。
• （3）规划和控制依据。
• （4）变更基础。
• （5）规划基础。

5.5 创建工作分解结构（WBS）

创建WBS是将项目可交付成果和项目分解成较小的、更易于管理的组件的过程。

5.5.1 WBS的层次

1. 里程碑

里程碑标志着某个可交付成果或者阶段的正式完成。

2. 工作包

由于工作包应便于完整地分派给不同的人或组织单元，所以要求明确各工作单元直接的界面。工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承建的责任。

8/80规则：工作包的大小应该至少需要8小时来完成，而总完成时间也不应该大于80小时或两周。

3. 控制账户

控制账户时一种管理控制点。既可以是工作包，也可以是比工作包更高层次上的一个要素，如果是后一种情况，一个控制账户中就包括若干个工作包，但是一个工作包仅属于一个控制账户。

4. 规划包

规划包是指在控制账户之下，工作内容一致但尚缺详细进度活动的WBS组成部分。规划包是在控制账户之下、工作包纸上的WBS要素。规划包是暂时用来做计划的，随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。

5. WBS词典

WBS词典描述WBS各组成部分的文件。WBS词典可能包括账户编码标识、工作描述、假设条件和制约因素、负责人或组织单元、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献协议信息等。

5.5.2 分解

分解是一种将项目可交付成果和项目工作分解成较小的、更易于管理的组件的技术。要将整个项目工作分解为工作包，通常需要开展以下活动：

• 识别和分析可交付成果及相关工作。
• 确定WBS的结构和编排方法。
• 自上而下逐层细化分解。
• 为WBS组件制定和分配标识编码。
• 核实可交付成果分解的程度是恰当的。

1. 分解的原则

创建WBS时对工作的划分，可以参考一些现成的原则，这些原则包括：

（1）功能或者技术原则。在创建WBS时，需要考虑将不同人员的工作分开。

（2）组织结构。

（3）系统或者子系统。总的系统划分为几个主要的子系统，然后对每个子系统再进行分解。

在项目实践中，可以按照下列方式进行分解：

（1）项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层。

（2）主要可交付成果作为分解的第二层。

（3）整合可能由项目团队以外的组织来实施的各种组件（例如，外包工作），然后作为外包工作的一部分，卖方需编制响应的合同WBS。

2. 工作过程

WBS不是某个项目团队成员的责任，应该由全体项目团队成员、用户和项目干系人共同完成和一直确认。常用的WBS标识形式主要有分级的树型结构（组织结构图式）和表格形式（列表式）

• 树型结构的WBS层次清晰、直观性和结构性强，但不容易修改，对大的、复杂的项目很难标识出项目的全貌。
• 表格形式的直观性比较差，但能够反映出项目所有的工作要素。

3. 注意事项

WBS分解的过程中，应该注意以下8个方面。

• （1）WBS必须是面向可交付成果的。
• （2）WBS必须符合项目的范围。
• （3）WBS的底层应该支持计划和控制。
• （4）WBS中的元素必须有人负责，而且只有一个人负责，尽管实际上可能需要多个人参与。
• （5）WBS的指导，WBS应控制在4～6层。
• （6）WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。
• （7）WBS的编制需要所有（主要）项目干系人参与，需要项目团队成员的参与。
• （8）WBS并非是一成不变的。在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。

5.5.3 WBS的作用

WBS的目的和用途主要体现在以下8各方面。

• （1）明确和准确说明项目范围，项目团队成员能够清楚地理解人物的性质和需要努力的方向。
• （2）清楚的定义项目的边界，它提供了项目管理人员、项目产品或服务的用户、项目发起人、项目团队成员等其他项目干系人一直认可的项目需要做的工作和不需要做的工作。
• （3）为各独立单元分派人员，规定这些人员的职责，可以确定完成项目所需要的技术和人力资源。
• （4）针对独立单元，进行时间、成本和资源需求量的估算，提高估算的准确性。
• （5）为计划、预算、进度安排和费用控制奠定共通基础，确定项目进度和控制的基准。
• （6）将项目工作和项目的财务账目联系起来。
• （7）确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作任务的逻辑顺序来实施
• （8）有助于防止需求蔓延。

5.6 确认范围

确认范围是正式验收项目已完成的可交付成果的过程。确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。

5.6.1 确认范围概述

确认范围的主要工具与技术是检查和群体决策技术。检查也称为审查、评审、审计、走查、巡检、测试等，是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。

1. 确认范围的步骤

（1）确定要进行范围确认的时间。

（2）识别范围确认需要哪些投入。

（3）确定范围正式被接受的标准和要素。

（4）确定范围确认会议的组织步骤。

（5）组织范围确认会议。

2. 需要检查的问题

项目干系人进行范围确认时，一般需要检查以下6个方面的问题。

（1）可交付成果是否是确定的、可确认的。

（2）每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件.如 客户的书面认可等

（3）是否有明确的质量标准

（4）审核和承诺是否有清晰的表达。

（5）项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或者错误。

（6）项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击。

5.6.2 干系人关注点

管理层所关注的项目范围，是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。

客户主要关心的是产品的范围，关心项目的可交付成果是否足够完成产品或服务。

项目管理人员主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。

项目团队成员主要关心项目范围中自己参与的元素和负责的元素，通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作又有冲突的地方。

5.6.3 几个术语的比较

1. 确认范围与核实产品

核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或客户来验证，强调产品是否完成；

确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。

2. 确认范围与质量控制

两者的不同之处在于：

• 确认范围主要强调可交付成果获得客户或发起人接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）。
• 质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而控制质量并不一定在阶段末进行。
• 质量控制属于内部检查，由执行组织的响应质量部门实施；确认范围则是由外部干系人（客户或发起人）对项目可交付成果进行检查验收。

3. 确认范围与项目收尾

两者不同之处在于：

• 虽然确认范围与项目收尾工作都是在阶段末进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的结束项目（或阶段）所要做的流程性工作。
• 确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品

5.7 控制范围

控制范围是监督项目和产品的范围状态，管理范围基准变更的过程，其主要作用是在整个项目期间保持对范围基准的维护。在变更实际发生时，也要采取范围控制过程来管理这些变更。

1. 范围变更的原因

• 政府政策的问题。
• 项目范围的计划编制不周密详细，有一定的错误或遗漏。
• 市场上出现了或是设计人员提出了新技术、新手段或新方案。
• 项目执行组织本身发生变化。
• 客户对项目、项目产品或服务的要求发生变化。

未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应的调整）称为范围蔓延。在信息系统集成项目中，变更时不可避免的，控制范围过程依赖于范围变更控制系统，范围变更控制是对有关项目范围的变更实施控制，审批项目范围变更的一系列过程，包括书面文件、跟踪系统和授权变更所必须的批准级别。

2. 范围变更控制的工作

范围变更控制的主要工作如下：

（1）影响导致范围变更的因素，尽量使这些因素向有利的方面发展。

（2）判断范围变更是否已经发生。

（3）范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理。

第五章，吐血整理完毕！！！！