软考高级-第5章 项目范围管理

软考高级 第5章 项目范围管理，从规划范围管理（范围管理计划、需求管理计划）、收集需求（需求的分类、收集需求的工具和技术、需求文件、需求跟踪）、定义范围（定义范围的工具和技术、项目范围说明书）、创建工作分解结构WBS（WBS的层次、分解、WBS的作用）、确认范围、控制范围（范围变更）方面来描述如何进行范围管理，对准备考软考或者从事项目管理的同学非常实用

第5章 项目范围管理

• 一、项目范围概述
  • 产品范围与项目范围
    • 产品范围是指产品或者服务所应该包含的功能
    • 项目范围是指为了能够交付产品，项目所必须做的工作
  • 范围管理的重要性
    • 范围蔓延是项目失败最常见的原因之一，范围管理影响到项目的成功
  • 范围管理的过程
    • 通过规划范围管理，收集需求，定义范围，创建WBS，确认范围和控制范围六个过程来实现
    • 规划范围管理
      • 编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程
      • 输入：项目管理计划、项目章程、事业环境因素、组织过程资产
      • 输出：范围管理计划、需求管理计划
      • 工具与技术：专家判断、会议
    • 收集需求
      • 为实现项目目标而确定、记录并管理干系人的需要和需求的过程
      • 输入：范围管理计划、需求管理计划、干系人管理计划、项目章程、干系人登记册
      • 输出：需求文件、需求跟踪矩阵
      • 工具与技术：访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析
    • 定义范围
      • 制定项目和产品详细描述的过程
      • 输入：范围管理计划、项目章程、需求文件、组织过程资产
      • 输出：项目范围说明书、项目文件更新
      • 工具与技术：专家判断、产品分析、备选方案生成、引导式研讨会
    • 创建WBS
      • 将项目可交付成果和项目工作分解为 较小的、更易于管理的组件的过程
      • 输入：范围管理计划、项目范围说明书、需求文件、事业环境因素、组织过程资产
      • 输出：范围基准、项目文件更新
      • 工具与技术：分解、专家判断
    • 规划过程组
    • 确认范围
      • 正式验收已完成的项目可交付成果的过程
      • 输入：项目管理计划、需求文件、需求跟踪矩阵、确认的可交付成果、工作绩效数据
      • 输出：验收的可交付成果、变更请求、工作绩效信息、项目文件更新
      • 工具与技术：检查（审查、产品评审、审计、走查、巡检）、群体决策技术
    • 控制范围
      • 监督项目和产品的范围状态，管理范围基准变更的过程
      • 输入：项目管理计划、需求文件、需求跟踪矩阵、工作绩效数据、组织过程资产
      • 输出：工作绩效信息、变更请求、项目管理计划更新、项目文件更新、组织过程资产更新
      • 工具与技术：偏差分析
    • 监控过程组
• 二、规划范围管理
  • 范围管理计划
    • 范围管理计划是制订项目管理计划过程和其他范围管理过程的主要输入，对以下工作的管理过程做出规定
    • 如何制定项目范围说明书
    • 如何根据范围说明书创建wbs
    • 如何维护和批准WBS
    • 如何确认和正式验收已完成的项目可交付成果
    • 如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联
  • 需求管理计划
    • 1、如何规划，跟踪和汇报各种需求活动
    • 2、需求管理需要使用的资源
    • 3、培训计划
    • 4、项目干系人参与需求管理的策略
    • 5、判断项目范围与需求不一致的准则和纠正规程
    • 6、需求跟踪结构，即哪些需求属性将列入跟踪矩阵，哪些需求跟踪信息应该被收集和整理等
    • 7、配置管理活动
    • 需求管理计划包括的内容
    • 需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求
    • 需求管理计划是对项目的需求进行定义、确定、记载、核实管理和控制的行动指南
• 三、收集需求
  • 收集需求是为实现项目目标确定，记录并管理干系人的需要和需求的过程，其作用是为定义和管理项目范围（包括产品范围）奠定基础。收集需求旨在定义和管理客户期望。
  • 需求的分类
    • 业务需求：整个组织的高层级需要
    • 干系人需求：是指干系人或干系人群体的需要
    • 解决方案需求：是为满足业务需求和干系人需求，产品 服务或成果必须具备的特性 功能和特征
    • 过渡需求：从当前状态过渡到将来状态所需的临时能力
    • 项目需求：项目需要满足的行为 过程或其他条件
    • 质量需求：用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准
  • 收集需求的工具和技术
    • 访谈
      • 访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答
      • 通常采取一对一的形式，也可以有多个被访谈者和（或）多个访谈者共同参与
      • 访谈有经验的项目参与者、干系人或主题专家
      • 干系人经常较忙，难以安排时间
      • 面谈时信息量大，记录较为困难
      • 沟通需要很多技巧，以及足够的领域知识等
      • 访谈会遇到的问题
    • 焦点小组
      • 焦点小组将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度
      • 焦点小组由一位受过训练的主持人引导大家进行互动式讨论
    • 引导式研讨会
      • 通过邀请主要的跨职能干系人一起参加会议，引导式研讨会对产品需求进行集中讨论与定义
      • 研讨会是快速定义跨职能需求和协调干系人差异的重要技术
      • 还可以使用质量功能展开引导式研讨会
      • 该技术的好处是，能够比单项会议更快地发现和解决问题
      • 质量功能展开研讨会的步骤
        • 将用户的多种需求（例如，可靠性、可用性、安全性等）及其相对重要性列为矩阵表的第一列
        • 将产品可能的多种特性（例如，功能列表）列为矩阵表的第一行
        • 由相关专家集体讨论每种特性与每种需求之间的关联性，即每种特性能满足每种需求的程度，并记录在矩阵表相应的空格中
        • 按列加权汇总，即可看出哪种产品特性最能满足用户需求
    • 群体创新技术
      • 头脑风暴
      • 名义小组技术
      • 德尔菲技术
        • 德尔菲技术是一种组织专家就某一主题达成一致意见的一种信息收集技术
        • 步骤如下：
          • 根据问题的特点，选择和邀请做过相关研究或相关经验的专家
          • 将与问题有关的信息分别提供给专家，请他们各自独立发表自己的意见，并写成书面材料
          • 主持人收集并综合专家们的意见后，将综合意见反馈给各位专家，请他们再次发表意见
          • 如此反复多次，最后形成代表专家组意见的方案
        • 优点
          • 能充分发挥各位专家的作用，集思广益，准确性高
          • 能将各位专家意见的分歧点表达出来，取各家之长，避各家之短
        • 缺点
          • 过程比较复杂，花费时间较长
      • 概念/思维导图
      • 亲和图
        • 是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，求得统一认识，利于解决的一种方法
        • 亲和图的核心是头脑风暴，是根据结果去找原因
      • 多标准决策分析
        • 是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术
    • 群体决策技术
      • 就是为达成某种期望结果而对多个未来行动方案进行评估
      • 群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序
    • 问卷调查
    • 观察
      • 是指直接观察个人在各自的环境中如何开展工作和实施流程
      • 也称为工作跟踪
    • 原型法
    • 标杆对照
    • 系统交互图
    • 文件分析
  • 需求文件
    • 需求文件收集需求过程的主要输出有需求文件和需求跟踪矩阵。
    • 需求文件描述各种单一的需求将如何满足与项目相关的业务需求
    • 需求文件包括：
      • 业务需求：包括可跟踪的业务目标和项目目标、执行组织的业务规则、组织的指导原则
      • 干系人需求，包括对组织其他领域的影响、对执行组织内部或外部团体的影响、干系人对沟通和报告的需求
      • 解决方案需求，包括功能和非功能需求、技术和标准合规性需求、支持和培训的需求、质量需求和报告需求。
      • 项目需求，包括服务水平、绩效、安全和合规性等以及验收标准
      • 过度需求
      • 与需求有关的假设条件、依赖关系和制约因素
  • 需求跟踪
    • 需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪
    • 需求跟踪的内容
      • 每个配置项的需求到涉及的产品（或构件）需求都要具有双向可跟踪性
      • 需求跟踪涉及五种类型
      • 图中箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，即从需求建议到交付的全过程
      • 图中左半部分，从用户原始需求可向前追溯到需求文件，这样可以区分项目过程中或项目结束后由于变更收到影响的需求。也是用例和功能需求之间的跟踪情况
      • 图中右半部分，由于在项目实施过程中，产品需求转变为设计和测试等实现元素，所以
      • 第四类联系链是从产品元素回溯到需求文件，使项目团队成员知道每个产品元素存在的原因
      • 第五类联系链是需求文件之间的跟踪，这种跟踪便于更好地处理各种需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏
    • 需求跟踪矩阵
      • 需求矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格
      • 需求矩阵内容包括
        • 业务需求、机会、目的和目标
        • 项目目标
        • 项目范围（WBS可交付成果）
        • 产品设计
        • 产品开发
        • 测试策略和测试场景
        • 高层级需求到详细需求
      • 需求跟踪矩阵中记录的典型属性包括：唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态、和状态日期
• 四、定义范围
  • 定义范围是制订项目和产品详细描述的过程，其主要作用时明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确产品、服务或成果的边界。
  • 定义范围的工具和技术
    • 产品分析
      • 针对产品提问并回答，形成对将要开发的产品的涌入、特征和其他方面的描述
      • 产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析
      • 价值工程与价值分析两种活动都是对商品的价值、功能与成本进一步做思考与探索，以小组活动方式集思广益
      • 价值工程是在产品开发设计阶段进行的价值与成本革新活动
    • 备选方案生成
      • 备选方案分析
      • 横向思维
  • 项目范围说明书
    • 范围说明书的内容
      • 产品范围描述
      • 验收标准
      • 可交付成果
      • 项目的除外责任
      • 制约因素
      • 假设条件
    • 范围说明书的作用
      • 确定范围
      • 沟通基础
      • 规划和控制发展
      • 变更基础
      • 规划基础
• 五、创建工作分解结构WBS
  • 创建WBS是将项目可交付成果和项目工作分解成较小的、更易于管理的组建的过程，其主要作用是对所要交付的内容提供一个结构化的视图。
  • WBS的层次
    • 里程碑：里程碑标志着某个可交付成果或者阶段的正式完成
    • 工作包
      • 是位于WBS每条分支最底层的可交付成果或项目工作组成部分
      • 建议工作包的大小应该至少需要8小时来完成，而总完成时间也不应该大于80小时
    • 控制账户
      • 是WBS某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素
      • 控制账户是一种管理控制点，在该控制点上，将范围、预算（资源计划）、实际成本和进度加以整合，并将他们与挣值进行比较，以测量绩效
    • 规划包
      • 是指在控制账户之下，工作内容已知但尚缺详细进度活动的WBS组成部分
      • 规划包是在控制账户之下、工作包之上的WBS要素
    • WBS词典
      • 账户编码
    • 特点
      • 每层中的所有要素之和是下一层的工作之和
      • 每个工作要素应该具体指派一个层次，而不应该指派给多个层次
      • WBS需要投入工作的范围描述，这样才能使所有人对要完成的工作有全面的了解
  • 分解
    • 创建WBS过程的工具与技术主要有分解和专家判断
    • 分解是一种将项目可交付成果和项目工作分解成较小的、更易于管理的组建的技术
    • 开展的活动
      • 识别和分析可交付成果及相关工作
      • 确定WBS的结构和编排方法
      • 自上而逐层细化分解
      • 为WBS组建制定和分配标识编码
      • 核实可交付成果分解的程度是恰当的
    • 分解的原则
      • 功能或者技术原则：对于不同阶段，需要不同的人员，要考虑将不同人员的工作分开
      • 组织结构
      • 系统或子系统：总系统划分为几个主要的子系统，然后对每个子系统再进行分解
    • 工作过程
    • 注意事项
      • WBS必须是面向可交付成果的
      • WBS必须符合项目的范围
      • WBS的底层应该支持计划和控制
      • WBS中的元素必须有人负责
      • WBS的指导
      • WBS应包括项目管理工作，也要包括分包出去的工作
      • WBS的编制需要所有项目干系人的参与，需要项目团队成员的参与
      • WBS完成后仍可以变更修改
  • WBS的作用
    • 明确和准确说明项目范围，项目团队成员能够清楚理解任务的性质和需要努力的方向
    • 清楚地定义项目的边界
    • 为各独立单元分派人员
    • 针对独立单元进行时间、成本和资源需求量的估算，提高估算的准确性
    • 为计划、预算、进度安排和费用控制奠定共同基础
    • 将项目工作和项目的财务账目联系起来
    • 确定工作内容和工作顺序
    • 有助于防止需求蔓延
• 六、确认范围
  • 确认范围是正式验收项目已完成的可交付成果的过程
  • 确认范围的步骤
    • 确定需要进行范围确认的时间
    • 识别范围确认需要哪些投入
    • 确定范围正式被接受的标准和要素
    • 确定范围确认会议的组织步骤
    • 组织范围确认会议
  • 需要检查的问题
    • 可交付成果是否是正确的、可确认的
    • 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件
    • 是否有明确的质量标准
    • 审核和承诺是否有清晰的表达
    • 项目范围是否覆盖了需要完成的产品或服务进行的所有活动，有没有遗漏或错误
    • 项目范围的风险是否太高，管理层是否能够降低可预见的风险发生时对项目的冲击
  • 干系人关注点
    • 管理层所关注的是项目的进度、资金和资源的影响，这些因素是否超过了组织承受的范围，是否在投入产出上具有合理性
    • 客户主要关心的是产品的范围，关心项目的可交付成功是否足够完成产品或服务
    • 项目管理人员主要关注可交付成果是否足够和必须完成，时间、资金和资源是否足够，潜在风险和预备解决方法
    • 项目团队成员主要关心项目范围中自己参与的元素和负责的元素
• 七、控制范围
  • 范围变更的原因
    • 政府政策的问题
    • 项目范围的计划编制不周密详细，有一定的错误或遗漏
    • 市场上出现了或是设计人员提出了新技术、新方案
    • 项目执行组织本身发生变化
    • 客户对项目、项目产品或服务的要求发生变化
  • 范围变更控制的工作
    • 影响导致范围变更的因素，并尽量使这些因素向有利的方面发展
    • 判断范围变更是否已经发生
    • 范围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理