备考信息系统项目管理师，学习过程中整理的思维导图。便于知识的复习，同时也分享给大家共同学习。下面的文字为思维导图大纲，自身不太喜欢。可以直接下载后续的图片，观看思维导图更加清晰明了。
此处为思维导图下载链接：https://download.csdn.net/download/skykls/12111576

范围管理

范围管理概述

确保项目包含且只包含达到项目成功所必需完成的工作

所需工作

明确的项目边界，明确哪些在范围内，哪些工作不在范围内
对项目执行工作进行监控，确保所有该做的工作都做了，而且没有多做。杜绝额外工作
防止项目范围蔓延

范围蔓延：未对时间、成本和资源做相应调整，未经控制的产品或项目范围的扩大

范围

产品范围
- 产品或者服务所应包含的特性和功能
- 完成：以产品是否满足产品描述来判断
项目范围
- 为了能够交付产品所需做的工作
- 完成：以范围基准（项目范围说明书、wbs以及词典）衡量标准

重要性

项目范围来自于项目目标，完成项目工作范围是为了实现项目目标
项目范围管理以及控制的有效性，是衡量项目是否成功达到成功的一个必要标准
在项目中不断重申工作范围，是项目中实施控制管理的一个重要手段
项目范围管理可以详细、清楚地界定分工界面和责任
项目范围管理能确定项目边界，明确主要可交付成果，范围管理能提高对项目成本、进度和资源估算的准确性
项目范围管理影响到项目的成功，在实践中，范围蔓延是项目失败最常见的原因之一

管理过程

过程

规划范围管理

说明
- 对如何定义、确认和控制项目范围的过程进行描述
输入
- 项目管理计划
- 项目章程
- 事业环境因素
- 组织过程资产
输出
- 范围管理计划
  - 作用
    - 对团队如何管理项目范围提供指导
  - 内容
    - 如何制定项目范围说明书（定义范围）
    - 如何根据项目范围说明书创建WBS（创建WBS）
    - 如何维护和批准WBS
    - 如何确认和正式验收已完成的项目可交付成果（确认范围）
    - 如何对详细范围说明书的变更——与整体变更控制过程想关联（控制范围）
- 需求管理计划
  - 作用
    - 如何分析、记录和需求管理需求。是对项目的需求进行定义、确定。记载、核实管理和控制的行动指南
  - 内容
    - 如何规划、跟踪和报告各种需求活动
    - 需求管理需要使用的资源
    - 培训计划
    - 项目干系人参与需求管理的策略
    - 判断项目范围与需求不一致的准则和纠正规程
    - 需求跟踪结构
    - 配置管理活动
工具技术
- 专家判断
- 会议

收集需求

说明
- 为实现项目目标，明确并记录项目干系人的相关需求的过程
作用
- 为定义和管理项目范围奠定基础
需求分类
- 业务需求
  - 整个组织的高层级需求
- 干系人需求
  - 干系人或干系人群体的需求
- 解决方案需求
  - 为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征
  - 功能需求
    - 关于产品能开展的行为
      
      如：数据、流程
  - 非功能需求
    - 产品正常运行所需的环境条件或质量
      
      如：可靠性、安全性、性能等
- 过渡需求
  - 当前状态过渡到当前状态所需的临时能力
    
    如：数据转换和培训需求
- 项目需求
  - 项目要满足的行动、过程或其他条件
- 质量需求
  - 基本需求
  - 期望需求
  - 意外需求
输入
- 范围管理计划
- 需求管理计划
- 干系人管理计划
- 项目章程
- 干系人登记册
输出
- 需求文件
  - 描述各种单元的需求将如何满足于项目相关的业务需求
  - 内容
    - 业务需求
    - 干系人需求
    - 解决方案需求
    - 项目需求
    - 过渡需求
    - 与需求有关的假设条件、依赖关系和制约因素
- 需求跟踪矩阵
  - 特征
    - 正向跟踪
      - 检查需求文件中的每个需求是否都能在后续工作产品中找到对应点
    - 反向跟踪
      - 检查设计文档、产品构件、测试文档等工作成果是否都在需求文件中找到出处
  - 过程
    - 图
    - 从用户原始去求可向前追溯到需求文件，可区分受变更影响的需求，确保需求文件包括所有用户需求
    - 从需求文件回溯到相应的用户原始需求，确认每个需求的出处
    - 从需求文件追溯到产品元素，可知每个需求对应的产品元素，从而确保产品元素满足需求
    - 产品元素回溯到需求文件，使项目团队成员知道产品元素存在的原因
    - 需求文件直接的跟踪，便于更好的处理各需求之间的逻辑相关性，检查需求分解中可能出现的错误或遗漏
  - 内容
    - 业务需求、机会、目的和目标
    - 项目目标
    - 项目范围（WBS可交付成果）
    - 产品设计
    - 产品开发
    - 测试测量和测试场景
    - 高层级需求到详细需求
工具技术
- 访谈
  - 形式
    - 结构化
      - 事先准备好问题，有针对的进行
    - 非结构化
      - 列出粗略的想法，根据访谈具体情况发挥
- 焦点小组
- 引导式研讨会
- 群体创新技术
  - 头脑风暴
    - 原则
      - 庭外判决原则
      - 欢迎各抒已见，自由鸣放
      - 追求数量
      - 探索取长补短和改建办法
  - 名义小组技术
  - 德尔菲技术
    - 组织专家就某一主题达成一致意见
    - 特点
      - 匿名
      - 多轮次
    - 缺点
      - 过程复杂
      - 花费时间长
    - 步骤
      - 根据问题特点，邀请选择专家
      - 问题信息分别提交专家，请他们各抒已见形成书面材料
      - 主持人手机并综合专家意见，将意见综合后反馈给各专家，请他们分别发表意见
        
        分歧大，集中开会讨论；分歧不大，主持人分别与专家联系
      - 反复多次，形成专家组意见方案
  - 概念/思维导图
  - 亲和图
  - 多标准决策分析
- 群体决策技术
  - 一致同意
  - 大多数原则
  - 相对多数原则
  - 独裁
- 问卷调查
  - 缺点
    - 灵活性不足
    - 双方未见面，无法获得更多的隐形信息
    - 干系人可能不重视，得到的信息不全面
    - 回答数量比预期少
- 观察
  - 工作跟踪
- 原型法
- 标杆对照
- 系统交互图
- 文件分析

定义范围

说明
- 详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础
输入
- 范围管理计划
- 项目章程
- 需求文件
- 组织过程资产
输出
- 范围规范说明书
  - 内容
    
    助记：严、验、可、除、制、假
    - 产品范围描述
    - 验收标准
      - 定义可交付成果通过验收前必须满足的一系列条件，以及验收过程
    - 可交付成果
    - 项目的除外责任
      - 明确说明哪些内尔用不属于项目范围，有助于管理干系人的期望
    - 制约因素
    - 假设条件
      - 指定计划时，不需验证即可视为正确、真实或确定的因素
  - 作用（同适用于WBS）
    - 确定范围
    - 沟通基础
    - 规划和控制依据
    - 变更基础
      - 为评价变更请求或额外工作是否超出项目边界提供基准
    - 规划基础
- 项目文件更新
工具技术
- 转机判断
- 产品分析
- 备选方案生成
  
  通用的管理技术都可用于生产备选方案
  
  如：头脑风暴、横向思维、备选方案分析等
  - 备选方案分析
    - 对已识别的可选方案进行评估的技术
  - 横向思维
    - 又称戴勃诺理论、发散思维、水平思维。是指思维的广阔度，要求人们能全面的观察问题，从事物多种多样的联系和关系中去认识事物。不一定是有序的，同时也不能预测
- 引导式研讨会

创建工作分解结构（WBS）

说明
- 把整个项目工作分解为较小的、易于管理的组成部分，形成一个自上至下的分解结构
表现形式
- 树形结构
  - 特点
    - 层次清晰、直观性和结构性强
    - 不易修改，不适合大、复杂的项目
- 表格
  - 特点
    - 直观性差
    - 可以反映出项目所有的工作要素
输入
- 范围管理计划
- 项目范围说明书
- 需求文件
- 事业环境因素
- 组织过程资产
输出
- 范围基准
  - 已批准的项目范围说明书、WBS、WBS词典
  - 只有走正式变更程序，才能变更范围基准
  - 内容
    - 范围说明书
      - 项目范围
      - 主要可交付成果
      - 假设和制约的描述
    - WBS
      - 详细的范围说明书的进一步分解
      - 定义了整个项目的工作范围，不在WBS里的不属于项目范围，要增加，必须走变更
    - WBS词典
      - 工作单元的细节描述
- 项目文件更新
工具技术
- 分解
  - 总述
    - 工作包
      - WBS最底层的，可对其成本和进度进行可靠估算、控制
    - 滚动式计划
      - 近期工作要分解到详细工作包，以便安排、合适。远期的可以放一个规划包，随着渐进明细不断细化
    - 分解级别
      - 不同的可交付成果可以有补鞥呢的分解级别。分解颗粒度的8/80法则：工作包最小不小于8小时，最大不超过80小时
    - 全员参与
      - 所有（主要）项目干系人和项目团队成员共同参与
  - 原则
    - 功能或者技术原则
    - 组织结构
    - 系统或者子系统
  - 创建过程
  - 注意事项
    - WBS必须是面向可交付成果的
    - WBS必须符合项目的范围
    - WBS的底层应该支持计划和管控
    - WBS汇总的元素必须有人负责，而且只有一个人负责
      
      独立责任原则
    - WBS的指导
      
      一个工作单元之鞥呢丛书某个上层单元，避免交叉从属
    - WBS应包括项目管理工作
    - WBS的编制需要所有（主要）项目干系人的参与
    - WBS并非是议程不变的
      
      滚动分解原则
  - 核实分解的正确性
- 专家判断
作用
- 明确和准确说明项目范围，项目成员清楚理解任务的性质和需要努力的方向
- 明确的定义项目的边界
- 为各独立单元分配人员，规定人员职责，可以确定完成项目所需要的技术和人力资源
- 针对独立单元，进行时间成本和资源需求量的估算，提高估算的准确性
- 为计划，预算、进度安排和费用控制奠定共同基础，确定项目精度和控制的基准
- 将项目工作和项目财务账目联系起来
- 确定工作内容和工作顺序，将项目分解成具体的工作任务，就可以按照工作的任务逻辑顺序来实施项目
- 有助于防止蔓延

确认范围

说明
- 正式验收已完成的可交付成果
概述
- 确认范围步骤
  - 确定需要进行范围确认的世界
  - 识别范围确认需要哪些投入
  - 确定范围正式被接受的标准和要素
  - 确定范围确认会议的组织步骤
  - 组织范围确认会议
- 确认需要检查的问题
  - 可交付成果是否是确定的、可确认的
  - 每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件
  - 是否有明确的质量标准
  - 审核和承诺是否有清晰的表达
  - 项目范围是否覆盖了需要完成的产品或服务进行的所有活动
  - 项目范围的风险是否太高
- 两区别
  - 与控制质量的区别
    - 确认范围：强调可交付成果客户或发起人的接收。质量控制：强调可交付成果的正确性，并符合为其制定的具体质量要求
    - 质量控制：确认范围前进行，也可同时进行；确认范围：阶段末尾进行
    - 质量控制：内部检查，执行组织的相应质量部门实施；确认范围：外部干系人（客户或发起人）对项目可交付成果进行验收
  - 与项目收尾的区别
    - 确认范围：强调核实与接受可交付成果（目的：验收）；项目收尾：强调结束项目或阶段所要做的流程性工作（目的：结束和收尾）
    - 确认范围：强调验收项目可交付成果（验收：成果）；项目收尾：强调验收产品（移交工作、归档、总结经验）
输入
- 项目管理计划
- 需求文件
- 需求跟踪矩阵
- 确认的可交付成果
- 工作绩效数据
输出
- 验收的可交付成果
- 变更请求
- 工作绩效信息
- 项目文件更新
工具技术
- 检查
  
  审查、产品评审、审计、走查、巡检。包括测量、测试、检验等活动，判断结果是否符合要求和期望。
- 群体决策技术

控制范围

说明
- 监督项目和产品的范围状态、管理范围基准变更
范围变更原因
- 政府政策原因
- 范围的计划编制不周密详细，有一定的错误或遗漏
- 市场货设计人员提出了新技术、新手段或新方案
- 项目执行组织本身发生变化
- 客户对项目、项目产品或服务的要求发生变化
- 范围蔓延：未经控制的产品或范围的扩大
范围变更控制
- 影响导致范围变更的因素，并尽量使这些因素向有利的方面发展
- 判断范围变更是否已经发生
- 范围变更时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理
输入
- 项目管理计划
- 需求文件
- 需求跟踪矩阵
- 工作绩效数据
- 组织过程资产
输出
- 工作绩效信息
- 变更请求
- 项目管理计划更新
- 项目文件更新
- 组织过程资产更新
工具技术
- 偏差分析