第7章项目范围管理（1）

软考中项/系统集成项目管理工程师/第7章项目范围管理（1），确保项目做且只做所需的全部工作，以成功完成项目的各个过程。

第7章 项目范围管理 （1）

• 概念
  • 含义
    • 确保项目做且只做所需的全部工作，以成功完成项目的各个过程
  • 关注的焦点
    • 什么是包括在项目之内的，什么是不包括在项目之内的，即为项目工作明确划定边界
  • 项目范围是项目其他各方面管理的基础。
  • 确认项目范围的作用（重要性）
    • 清楚了项目的工作具体范围和具体工作内容，为提高成本、时间和资源估算的准确性提供了基础。
    • 项目范围既然是确定要完成哪些具体的工作，项目范围基准是确定项目进度测量和控制的基准。
    • 项目范围的确定就是确定了项目的具体工作任务，有助于清楚的责任划分和任务分配。
  • 比较
    • 产品范围
      • 表示产品、服务或结果的特性和功能（需求分析、技术方面）
        • 是否完成以产品要求作为衡量标准
    • 项目范围
      • 为了完成具有规定特征和功能的产品、服务或结果，而必须完成的项目工作（管理方面）
        • 是否完成以项目管理计划、项目范围说明书、WBS、以及WBS字典作为衡量标准
  • 6个过程
    • 1||| 编制范围管理计划过程
      • 对如何定义、确认和控制项目范围的过程进行描述
    • 2||| 收集需求
      • 为实现项目目标，明确并记录项目干系人的相关需求的过程
    • 3||| 定义范围
      • 详细描述产品范围和项目范围，编制范围说明书，作为以后项目决策的基础
    • 4||| 创建工作分解结构（WBS）
      • 把整个项目工作分解为较小的、易于管理的组成部分，形成一个自上而下的分解结构
    • 计划
    • 5||| 确认范围
      • 正式验收已完成的可交付成果
    • 6||| 范围控制
      • 监督项目和产品的范围状态、管理范围基准变更
    • 监控
• 实现过程
  • 步骤（一） 编制范围管理计划
    • 含义
      • 是项目或项目集管理计划的组成部分，描述了如何定义、制定、监督、控制和确认项目范围
    • 作用
      • 有助于降低项目范围蔓延的风险
    • 编制范围管理计划和细化项目范围始于对下列信息的分析
      • 项目章程中的信息
      • 项目管理计划中已批准的子计划
    • 特点
      • 根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的
      • 一个范围管理计划可以包括在项目管理计划中，或者是项目管理计划的一个分计划
      • 是制定项目管理计划过程和其他范围管理过程的主要依据
    • ITO
      • 输入 Input
        • （1） 项目管理计划
          • 依据项目管理计划中已批准的子计划来创建范围管理计划
        • （2） 项目章程
          • 项目章程提供了高层级的项目描述和产品特征。产品特征出自项目工作说明书。
        • （3） 事业环境因素
          • 包括组织文化、基础设施、人事管理制度、市场条件
        • （4） 组织过程资产
          • 包括政策和程序以及历史信息和经验教训知识库
      • 工具与技术 Tool&Technology
        • a. 专家判断
        • b. 会议
      • Output 输出
        • 1||| 范围管理计划（乙方）
          • 是项目或项目集管理计划的组成部分，描述如何定义、制定、监督、控制和确认
          • 根据项目需要，范围管理计划可以是正式的或非正式的，非常详细的或高度概括的
          • 内容（管理过程）
            • 1||| 制定详细范围说明书
            • 2||| 根据详细项目范围说明书创建WBS
            • 3||| 维护和批准工作分解结构WBS
            • 4||| 正式验收已完成的项目可交付成果
            • 5||| 处理对详细项目范围说明书或WBS的变更。该工作与实施整体变更控制过程直接相联。
        • 2||| 需求管理计划（甲方）
          • 含义
            • 描述了如何分析、记录和管理需求，以及阶段与阶段间的关系对管理需求的影响。
          • 项目经理为项目选择最有效的阶段间关系，并将它记录在需求管理计划中。
          • 内容
            • （1） 如何规划、跟踪和报告各种需求活动
            • （2） 配置管理活动
            • （3） 需求优先级排序过程
            • （4） 产品测量指标及使用这些指标的理由
            • （5） 用来反映哪些需求属性将列入跟踪矩阵的跟踪结构
            • （6） 收集需求过程
            • 以阶段关系为基础
  • 步骤（二） 收集需求
    • 含义
      • 是为实现项目目标而确定、记录并管理干系人的需要和需求的过程
    • 作用
      • 为定义和管理项目范围（包括产品范围）奠定基础
    • ITO
      • 输入 Input
        • （1） 范围管理计划
        • （2） 需求管理计划
        • （3） 干系人管理计划
        • （4） 干系人登记册
        • 注意：无 [干系人清单]
        • （5） 项目章程
        • 注意：无 [事业环境因素、组织过程资产]
      • 工具与技术 Tool&Technology口诀：元芳因关文文洗新表绝交
        • （1） 访谈
          • 通过与干系人直接交谈来获取信息的正式或非正式的方法，一对一或一对多，可用于获取机密信息
            • 最基本的手段，直接
        • （2） 焦点小组
          • 召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。群体访谈，加入了专家和主持人
            • 主持人、分小组、分主题讨论
        • （3） 引导式研讨会
          • 集中主要干系人，集中讨论定义产品需求，强调跨职能和协调干系人差异，比单项会议更早发现问题，更快解决问题。
            • 跨职能，产品需求、更快
            • 联合应用设计/开发（JAD）、质量功能展开（QFD)
        • （4） 群体创新技术
          • 组织一些群体活动来识别项目和产品需求
            • 头脑风暴法
              • 一种用来产生和收集对项目需求与产品需求的多种创意的技术。 不包含投票和排序，但常与包含该环节的其他群体创新技术一起使用
            • 名义小组技术
              • 用于促进头脑风暴的技术，通过投票排列最有用的创意，以便进一步开展头脑风暴或优先排序。
            • 德尔菲技术
            • 概念/思维导图
              • 把从头脑风暴中获得的创意整合成一张图的技术，以反映创意之间的共性与差异，激发新创意。
            • 亲和图
              • 用来对大量创意进行分组的技术，以便进一步审查和分析
            • 多标准决策分析
              • 借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术
        • （5） 群体决策技术
          • 为达到某种期望结果，对多个未来行动方案进行评估的过程。 本技术用于生成产品需求，并对产品需求进行归类和优先级排序
            • 1||| 一致同意
              • 每个人都同意某个行动方案
            • 2||| 大多数原则 [超过50%]
              • 参与决策小组的人数定为奇数，防止因平局无法达成决策
            • 3||| 相对多数原则
              • 通常在候选项超过两个时使用
            • 4||| 独裁
              • 一个人为群体做出决策
        • 在收集需求过程中，二者可联合使用
        • （6） 问卷调查
          • 通过设计一系列书面问题，向众多受访者快速收集信息
            • 适用情况：受众多样化、需要快速完成调查，受访者地理位置分散、适合开展统计分析，
        • （7） 观察
          • 也称“工作跟踪”直接观察个人在各自环境中如何开展工作和实施流程
            • 适用情况：产品使用者难以或不愿清晰说明他们的需求
        • （8） 原型法
          • 在实际制造预期产品之前，先造出该产品的实用模型，并据此征求对需求的早期反馈。
            • 渐进明细/反复循环
        • （9） 标杆对照
          • 将实际和计划的做法与其他可比组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。
            • 所采用的可比组织可以是内部或外部的。
        • （10） 系统交互图
          • 是范围模型的一个例子。是对产品范围的可视化描绘，显示业务系统及其与人和其他系统之间的交互方式。显示了业务系统的输入、输入提供者、输出、输出接收者
            • 显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者
        • （11） 文件分析
          • 通过分析现有文档，识别与需求相关的信息，来挖掘需求。
            • 可供分析的文档：商业计划、营销文献、协议、建议邀请书、现行流程、逻辑数据模型、业务规则库、应用软件文档、业务流程或接口文档、用例、其它需求文档等
      • Output 输出
        • （1） 需求文件
          • 要求
            • 需求文件的格式多种多样，既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等详细文件
          • 内容 口诀：干姐也想过制嫁衣
            • （1） 业务需求
            • （2） 干系人需求
            • （3） 解决方案需求
            • （4） 项目需求
            • （5） 过渡需求
            • （6） 与需求相关的假设条件、依赖关系和制约因素
        • （2） 需求跟踪矩阵
          • 含义
            • 把产品需求从其来源连接到能满足需求的可交付成果的一种表格
          • 作用
            • 把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值
            • 提供了在整个项目生命周期中跟踪需求的一种方法
            • 有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付
            • 为管理产品范围变更提供了框架
          • 内容
            • 1||| 业务需求、目标、机会和目的
            • 2||| 项目目标
            • 3||| 项目范围（WBS可交付成果）
            • 4||| 产品设计
            • 5||| 产品开发
            • 6||| 测试策略和测试场景
            • 7||| 高层级需求到详细需求
          • 典型属性
            • 1||| 唯一标识
            • 2||| 需求的文字描述
            • 3||| 收录该需求的理由
            • 4||| 所有者
            • 5||| 来源
            • 6||| 优先级别
            • 7||| 版本
            • 8||| 当前状态
            • 9||| 状态日期
          • 补充属性
            • 稳定性
            • 复杂性
            • 验收标准
  • 步骤（三） 定义范围
    • 含义
      • 制定项目和产品详细描述的过程
    • 主要作用
      • 明确所收集的需求哪些将包含在项目范围内、哪些将排除在项目范围之外，从而明确项目、服务或输出的边界
      • 可以增加项目时间、成本和资源估算的准确度，定义项目控制的依据，明确相关责任人在项目中的责任，明确项目的范围、合理性和目标，以及主要可交付成果
    • 项目边界
      • 应该做的工作和不需要进行的工作分界线。 定义范围最重要的任务就是详细定义项目的项目边界。项目的范围边界一定是闭合的。
    • ITO
      • 输入 Input
        • （1） 范围管理计划
        • （2） 项目章程
        • （3） 需求文件
        • （4） 组织过程资产
      • 工具与技术 Tool&Technology
        • （1） 产品分析
          • 旨在弄清产品范围，并把对产品的要求转化成项目的要求
          • 包括产品分解、系统分析、需求分析、系统工程、价值工程、价值分析
        • （2） 专家判断
          • 常用来分析制定范围说明书所需的信息，专业判断和专业知识可用来处理各种技术细节
        • （3） 备选方案生成
          • 用来制定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法
          • 可用于生成备选方案的技术有：头脑风暴、横向思维、备选方案分析
        • （4） 引导式研讨会
          • 具有不同期望和专业知识的关键人物参与研讨会，有助于就项目目标和项目限制达成跨职能的共识
          • 快速定义跨职能需求和协调干系人差异的重要技术
      • Output 输出
        • 1||| 项目范围说明书
          • 定义
            • 对项目范围、主要可交付成果、假设条件和制约因素的描述
          • 项目范围说明书描述要做和不要做的工作的详细描述，决定着项目管理团队控制整个项目的有效程度 对项目范围进行管理，又可以决定项目团队能否很好的规划、管理和控制项目的执行
          • 内容 口诀：球边放牧可约架
            • （1） 项目目标
              • 包括衡量项目成功的可量化标准。没有量化的目标通常隐含着较高的风险
            • （2） 产品范围描述
              • 描述了项目承诺交付的产品、服务和结果的特征。在早期比较粗略，在后期随着产品特征逐步细化会更加详细
            • （3） 项目需求
              • 描述了项目承诺交付物要满足合同、标准、规范或其它强制性文件所必须具备的条件和能力
            • （4） 项目边界
              • 严格的定义了项目内容可包括什么和不可不包括什么，以防有的项目干系人假定某些产品或服务是项目的一部分
            • （5） 项目可交付成果
              • 在某一过程、阶段或项目完成式，产出的任何独特并可核实的产品、成果或服务 包括：各种辅助成果，如项目管理报告和文件
            • （6） 项目制约因素
              • 项目范围说明书的约束条件比项目章程中列出的约束条件更多，而且更加详尽。
              • 制约因素的信息可以列入项目范围说明书，也可以独立成册。
              • 包括内容：例如，客户或执行组织事先确定的预算、强制性日期、进度里程碑
            • （7） 假设条件
              • 假设条件的信息可以列入项目范围说明书，也可以独立成册。
              • 与范围相关的假设条件，以及当这些假设不成立时对项目造成影响 作为计划过程的一部分，项目团队要经常识别、记录和确认创设条件的有效性
        • 2||| 项目文件更新
    • 其它
      • 收集需求过程中识别出的所有需求未必都包含在项目中，需要多次反复开展定义范围过程。
      • 根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制项目范围说明书。在项目规划过程中，随着对项目信息的更多了解，应该更加详细具体地定义和描述项目范围。还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。需要多次反复开展定义过程。在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再针对每一次迭代明确详细范围。
    • 项目章程与项目范围说明书
      • 联系
        • 二者内容存在一定程度的重叠
      • 区别
        • 二者内容详细程度完全不同
          • 项目章程包括高层级的信息
          • 项目范围说明书则是对项目范围的详细描述。项目范围需要在项目过程中渐进明细。