第五章 范围管理
范围问题
产品范围表示你和你的团队正在构建的产品或服务的特性和功能。
项目范围是建立产品所需完成的全部工作。比如，项目计划和其他管理文档，使用产品的人看不到的，比如项目进度、规范、蓝图和预算。
范围蔓延是指导导致团队做额外工作的失控变更。
项目管理计划描述了你如何写出范围，确保范围是正确的，并保证范围不断得到更新。
范围管理的威力
- 团队无法启动项目
- 存在大量有错误的开始
- 赞助人和干系人难以预料 (开始谈的时候没有的需求，做完后他们居然会问为什么没有这个功能！！！)
- 总有大量变更
5个范围管理过程
- 收集需求，需求文档
- 定义范围，项目范围说明书
- 创建工作分解结构，工作分解结构 工作分解结构(Work breakdown Structure , WBS)将你的团队的工作组织为工作包(Work Packages)
- 控制范围，变更需求 范围变更失控时，需要整合变更控制
- 核实范围，接受的可交付结果
收集需求
属于计划过程组
输入
- 干系人登记表
- 项目章程
工具
与干系人讨论
- 访谈(Interviews),一对一，解释明确
- 专题小组讨论(Focus Groups ),一组人，能讨论出之前没想到的需求
- 辅助工作室(Facilitated Workshops),头脑风暴，合作定义需求
需求详解：提出需要->商业案例->需求文档
决策技术
- 一致同意(Unanimity)
- 多数同意(Majority)
- 少数服从多数(Plurality)
- 总裁制(Dictatorship)
群体创新技术(Group Creativity Techniques)
- 思维导图(Mind Maps)
- 德尔菲法(Delphi Technique),匿名问卷表
- KJ图
- 亲和图(Affinity Diagrams),一般用贴纸，方便移动归类改变分组
- 头脑风暴(Brainstrming)
- 名义群体法(Nominal Group Technique)
调查问卷
给使用产品的人，从其他角度看问题
产品原型
给干系人看，了解团队在想什么，找出新需求
有的组织把需求收集活动划分为项目需求(Project Requirements)和产品需求(Project Requirements),项目需求涉及到预算、期限、资源，产品需求关于产品的特性。
如果你有办法一旦建立需求就分别进行核实，就能知道你的需求是否是完备的。
输出
需求文档
- 功能需求(Functional requirements)，比如新特性、bug修正、新行为或不同的行为
- 非功能需求(Non-Functional requirements)，比如性能、可靠性、错误处理、易用性
定义项目范围
属于计划过程组
输入
- 需求文档
- 项目章程
- 组织过程资产
工具
更进一步的定义范围，写下你和你的团队在项目过程中要做的所有工作。
- 辅助工作室
- 产品分析
- 替代方案识别
- 专家判断
输出
项目范围说明书
- 项目目标
- 产品范围描述
- 产品排除
- 项目交付成果
- 产品验收标准
- 项目约束
- 项目假设
项目范围说明书指出你在项目中将要做以及不应该做的工作。
项目管理计划更新
与变更控制有关
创建工作分解结构
创建工作分解结构是范围管理知识领域中最重要的过程，因为你要在这里明确所要做的全部工作。
收集需求和定义范围过程的输出会成为创建工作分解结构过程的输入。
输入
- 组织过程资产(有表格和模板)
- 需求文档
- 项目范围说明书
分解工作 WBS
- 按可交付成果分解
- 按阶段分解
按阶段分解
- 项目管理
- 设计
- 构建
- 测试
按可交付成果分解
- 项目管理
- 美工作品
- 源代码
- 用户文档
工作包
工作包是团队用来组织完成项目所做工作的工作单元，是WBS的最低层次。
- 根据如何工作组织项目
- 确保团队有足够的工作包信息来完成任务
- 每个工作包必须简洁，以便组织
举例，美工和包装 -> 编写故事、构思角色、创建场景、美工作品包装到文件中、检查外包装、 取得CD用户手册和外包装印刷品
也就是说工作包的内容要求可以实施的最小工作量，可以精确到团队的每个人的每件事。
WBS词典
下面是一个WBS词典条目的内容
- 工作包ID和名称
- 工作说明书
- 负责组织
- 进度里程碑
- 质量需求
- 账户标识码
- 必要的资源和成本估算
注意
- WBS必须是图形化的，要显示所有的工作包
- WBS重点是列出所有的工具包，不需要给出依赖关系
- 信息不全的工作包也要写在里面
范围基线(Scope Baseline)
构成
- WBS词典
- 工作分解结构
- 项目范围说明书
只要做出变更，就需要让它得到批准，然后更新基线。
输出
- 工作分解结构
- 范围基线
- WBS词典
- 项目文档更新
区分变更控制
- 好的变更。很少的代价让产品更出色，很少发生 :(
- 不好的变更。
- 范围蔓延。一个变更导致另一个变更，依次变更下去。这样会耗费大量的资源在上面，拆了东墙补西墙，降低项目质量。
- 镀金。程序员想到方法能让一个特性更棒，就直接实现，没有跟任何人(项目经理、产品经理)谈论，你必须为你从未要求的特性付费(项目资源，开发时间，更多bug)。
控制范围过程
属于监控过程组
输入 、工具、输出
输入
- 项目管理计划
- 需求文档
- 追踪矩阵
- 工作绩效信息
- 组织过程资产
工具
- 差异分析
输出
- 工作绩效考核
- 对组织过程资产的更新
- 项目文档更新
- 对项目管理计划的更新
变更刨析
- 确实需要变更
- 创建一个变更需求
- 让变更得到批准
- 完成差异分析
- 重新计划工作
- 创建一个新基线
差异分析
收集的所做工作有关数据与范围基线进行比较，二者存在差别时，就是一个差异(variance)。
控制范围的目标是更新范围、计划、基线和WBS信息。
作为一个项目经理，管理的是团队完成的工作，而不是他们建立的产品。
只要对项目范围做出变更，它会影响到产品范围，反之亦然。
每一个范围变更都要经过控制范围过程。
确保团队交付了正确的产品
属于监控过程组
输入、工具、输出
输入
- 需求文档
- 追踪矩阵
- 可交付成果
- 项目管理计划
工具
- 检查
输出
- 接受的可交付成果
- 变更请求
- 项目文档更新
检查
干系人决定项目何时完成。
正式验收意味着你已经得到所有干系人的书面确认，证实你的可交付成果满足需求和项目管理计划。
每一个可交付成果都应当进行检查，包括所有项目管理文档，以及团队生产的所有产品。
不接受
进行变更控制
- 变更请求
- 项目文档更新
接受
交工
总结
范围管理贯穿的是计划过程租和监控过程租，强调了对项目过程中的任务的范围和变更的规范和流程。
在实际项目进行中，如何做好WBS词典、列出全部工作包、变更需求完整操作是最重要的。
做好范围管理能更有效的利用有限的资源和开发时间，做出符合实际需求的产品。
公司项目不是私有项目，镀金的事情尽量少做，对公司负责，合理炫技。
参考资料
- 《Head First PMP 第二版》
