实际做项目非常重要
项目范围包扩做且只做所需的全部工作，两重含义：
- 产品范围
- 项目范围
产品范围决定项目范围，由产品需求书确定，项目范围服务于产品范围，由项目管理计划决定
（需求和范围的理解：比如产品说要实现一个功能，在你看来是一个需求，但是如果继续挖下去，你可以通过另一个方式实现产品想要的效果，所以说，产品提的应该是一个范围）
规划范围管理
为记录如何定义，确认和控制项目范围及产品范围，而创建范围管理计划的过程。
作用就是对如何管理范围提供指南和方向
（后面的项目xx管理，第一个过程都是规划xx管理，只提供指南和方向）
输出
范围管理计划
收集需求
为实现目标而确定、记录并管理相关方的需要和需求的过程，为定义范围奠定基础
需求：发起人、相关方、客户等已量化且书面记录的需要和期望
输入
项目文件
- 相关方登记册
-
商业文件
协议
工具与技术（记住每个工具的适用范围）
数据收集
头脑风暴
- 访谈，获取机密信息
- 焦点小组，互动式讨论
- 问卷调查，多样化，快速完成，地理分散，统计分析
- 标杆对照，内部或者外部，同行业或者不同行业，识别最佳实践，形成改进意见
数据分析
- 投票
- 一致同意，每个人都同意，德尔菲（专家，匿名，多轮，趋同，消除偏见）
- 大多数同意，超过50%
- 相对多数同意，相对多数
- 独裁型，一个人做决策
-
数据表现
亲和图
-
人际关系与团队技能
名义小组，（民意小组）
- 工作跟随和交谈，难以说清的，挖掘隐藏需求
- 引导，跨职能，跨部门，协调相关方差异
系统交互图
原型法
输出
需求文件
描述单一需求如何满足与项目相关的业务需求，只有明确的，可跟踪的，且主要相关方愿意任何的需求，才能作为基准需求跟踪矩阵
把产品需求从其来源连接到能满足需求的可交付成果的一种表格。确保每个需求都具有商业价值，提供了整个项目生命周期中跟踪需求的一种方法。
收集需求产生的需求文件和需求跟踪矩阵并不代表项目的真实范围
定义范围
输入
制定项目和产品详细描述的过程，从需求文件中选取最终的项目需求，然后制定出关于项目及其产品，服务或成果的详细描述。
项目章程
需求文件
工具与技术
备选方案分析
多标准决策分析
引导
产品分析
输出
项目范围说明书
对项目范围，主要可交付成果，假设条件和制约因素的描述，包括项目和产品范围。详细描述了项目的可交付成果，明确指出以下：
- 产品范围描述，逐步细化在项目章程和需求文件中所术的产品，服务和成果特征
- 可交付成果
- 验收标准
-
创建WBS
把项目可交付成果和项目工作分解成较小的，易于管理的组件的过程
作用： 组织并定义了项目的总范围（项目范围说明书只定义了范围，没有组织范围）
最底层是工作包，集中包括计划的工作，这个工作是指作为活动结果的工作产品和可交付成果，而不是活动本身
输入
范围说明书
工具与技术
分解
工作包
分解步骤
识别与分析
- 确定wbs结构和编排方法
- 自上而下逐层细化分解、
- 分批额标志编码
- 核实分解的程度是否恰当
形式：
控制账户
CA，是一个管理控制点，在该控制点上，把范围，预算，实际成本等加以整合，通过上移下移来控制粒度
确认范围
客户或发起人正式验收已完成的项目可交付成果的过程，通过验证每个可交付成果，提高最终验收的可能性
输入
核实的可交付成果
工具与技术
检查
输出
验收的可交付成果
必须符合：
若有收获，就点个赞吧
0 人点赞
