项目管理（PMP）项目范围管理

范围包括：

产品范围：某项产品，服务或成果所具有的特性和功能

项目范围：为交付具有规定特性与功能的产品，服务或者成果而必须完成的工作

在交付产品项目中，项目范围包括产品范围

	预测型	迭代型/增量型	适应性（敏捷）
定义范围的时间	项目开始	每次迭代开始	随时
确认范围的时间	项目或者阶段结束	每次迭代结束	随时反馈
范围控制文件	范围基准	版本配置文件	产品待办事项列表
发起人/客户参与	里程碑	周期性	持续性

范围管理发展的趋势和新兴实践

必须要注重和商业分析专业人士的合作，以便：

确定问题并识别商业需要；识别并推荐能够满足这些需要的可行解决方案；收集，记录并管理相关方需求，以满足商业和项目目标；推动项目集或者项目的产品，服务或最终成果的成功应用。

项目经理和商业分析师应该是伙伴式合作关系，如果项目经理和商业分析师能够理解彼此促进项目目标实现过程中的角色和职责，项目成功的可能性就更大。

裁剪时需要考虑的因素

知识和需求管理：组织是否能够拥有正式或者非正式的知识和需求管理体系？为了在未来项目中使用需求，项目经理应该建立哪些指南？

确认和控制：组织是否拥有正式或者非正式的与确认和控制相关的政策，程序，指南？

开发方法：组织是否能够采用敏捷方法管理项目，开发方法属于迭代型还是增量型？是否采用预测型方法？混合型方法是否有效？

需求的稳定性：项目是否存在需求不稳当的领域，是否有必要采用精益，敏捷或者其他适应型技术来处理不稳定的需求，直至需求稳定且明确定义？

治理：组织是否拥有正式或者非正式的审计和治理政策，程序和指南？

规划范围管理

需求管理计划和范围管理计划对比：

需求管理计划	范围管理计划
规划，跟踪和报告需求	制定详细的范围说明书
配置管理活动	创建WBS和WBS词典
确定需求的优先级排序	创建责任分配矩阵
确定产品测量指标	正式验收可交付成果
跟踪矩阵的跟踪结构	处理对项目范围的变更

范围管理计划主要解决以下问题：

范围说明书的定义，以及WBS和WBS词典的格式，流程；

范围基准的生成和审批程序；

范围变更管理的规则和程序；

可交付成果的验收标准和流程；

收集需求

需求：指根据特定协议或者其他强制性规范，产品，服务或者成果必须具备的条件或者能力。具有多样性，复杂性，隐蔽性，差异性，变化性，矛盾性的特点。

收集需求的常用工具

头脑风暴：团队成员集思广益，畅所欲言，相互启发，会因为参会人员知识所限。

访谈：访谈有经验的项目参与者，发起人，其他高管以及主题专家，有助于识别和定义可交付的产品的特征和功能。

焦点小组：召集项目相关方和主题专家，了解他们对所讨论的产品，服务或者成果的期望度，由一位受过训练的主持人引导大家进行互动式讨论，聚焦在产品的某一个方面。

问卷调查：适用于受众多样化，需要快速完成调查，受访者位置分散，适合开展统计分析。

标杆对照：将实际或者计划的做法与其他可比组织的做法进行比较，方便识别最佳实践，形成改进意见。

联合应用程序开发或设计（JAD）：客户被邀请和开发一起，通过一系列的探讨收集需求和改进软件开发过程，客户持续参与，有助于客户了解项目，和团队更深入的理解需求。

质量功能展开（QFD）：

第一步：产品规划矩阵，把用户需求转化为设计要求。

第二步：零件规则矩阵，把设计要求转化为零件特征。

第三步：工艺规划矩阵，把零件特性转化为工艺要求。

第四步：工艺/质量规划矩阵，把工艺要求转化为生产要求。

数据表现

亲和图（KJ法，川喜田二郎）和思维导图。

需求决策

投票：一致同意原则，大多数同意原则，相对多数同意原则。

独裁：必要时可高效决策。

多标准决策分析（MCDA）：把多个因素按照权重配置，分别打分，按照总分进行评估和排序。

需求跟踪矩阵

把产品需求从其来源连接到能满足的可交付成果的一种表格，提供了在整个项目生命周期中跟总需求的一种方法，有助于确保需求中被批准的每一项需求在项目结束时都能交付。还为管理产品范围变更提供了框架。

敏捷场景下的需求管理

卡诺模型（狩野模型）：狩野纪昭将产品属性分为五类：魅力属性；期望属性；无差异属性；必备属性；反向属性；

当我们的资源和时间有限时，优先提升必备属性，其次是期望属性，如果我们有能力，再去提供魅力属性，拉开与竞品的差距；无差异属性不必刻意追求；尽量避免提供反向属性；

精益画布：精益画布是从商业模式画布中发展而来的，包括九个部分：

最小可发布版本（MMR）：用MVP（最小可行性产品）验证用户的"购买意愿"，并不代表客户见了产品就会真的购买。

MMR的原则如下：

最简特性清单；最小特性颗粒；最少特性组合；

莫斯科法则（MoSCoW）：

必须有的特性（Must Have）如果没有，产品不可行；

应该有的特性（Should Have）非常重要但不是必须的特性，可以想其他方法替代和暂时不提供；

可以有的特性（Could Have）有了更好，没有也行，只有在时间允许，资源富裕的情况下，企业才会考虑；

不该有的特性（Would not Have）不关键，不必要，且不该在这个版本里考虑的特性；

产品待办事项列表（Product Backlog）：

详略适当；经过估算；涌现的；按优先级排序；

分解和细化产品待办事项列表中的条目，如果有同样重要的活动，团队应该用最短作业优先的方式=延期满足的代价/这项活动的历时估算。

用户故事：表达用户需求的固定语法，作为一个《角色》，我想要《活动》，以便于《商业价值》，用户故事卡片和用户故事地图。

定义范围

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

项目范围说明书

包含一下内容：

产品范围描述；验收标准；可交付成果；项目的除外责任；制约因素；假设条件；项目范围说明书是对项目章程的细化和具体化。

创建WBS

是把可交付成果和项目工作分解为较小的，更易管理的组件的过程。

WBS元素

包含

可交付成果：是团队为完成某一过程，阶段或者项目必须产出的任何独特并核实的产品，成果或者服务能力。

子项目：是整个项目的一部分，能够被独立的作为项目来管理，可由一个专业团队或分包组织负责。

控制账户：是一个管理控制点，在控制点上，把范围，预算，实际成本和进度加以整合，并与挣值进行比较，以测量绩效。

工作包：WBS最低层次的组件，通常表达为可交付成果，工作包可以对相关活动进行归类，以便对工作进度进度进行估算，开展监督与控制。

规划包：是最低层次组件，位于控制账户下，工作范围是已知的，但是包含活动的预期和预算是未知的。

任务：通常是活动的组成部分，不属于WBS组件，由某一个团队成员负责。

WBS元素的下次层分解必须100%的表示上一层元素，不能有重复或者遗漏。

WBS账户编码

可以通过账户编码与组织分解结构，资金分解结构，风险分解结构建立关联，形成项目核心控制系统，是项目管理信息系统的基础。

WBS的形式

 

责任分配矩阵

WBS词典

WBS词典是针对WBS中的每一个工作包，详细描述可交付成果，验收标准，进度，成本等信息的表格。

WBS的价值：基准的来源；计划的基础；工作的展现；控制的依据；团队的指南；

确认范围

确认范围是获得项目发起人或客户对项目可交付成果正式验收的过程

控制范围

主要作用是在整个项目期间保持对范围基准的维护，并确保所有变更请求，纠正措施或预防措施都通过实施整体变更控制程序进行处理。

范围蔓延：是指未经控制的产品或项目范围的扩大（未对时间，成本，资源做出相应的调整），狭义是指：未经正常的范围变更控制程序而出现的产品或者项目范围的扩大；广义是指项目管对在定义工作范围之外主动增加的额外工作，但没有经过范围控制程序。统称为范围蔓延。