- 1. 范围管理大纲
- 1.1 规划范围管理
- 1.1.1 输出
- 1.1.1.1 范围管理计划
- 1.1.1.2 需求管理计划
- 1.2 收集需求
- 1.2.1 输出
- 1.2.1.1 需求文件
- 1.2.1.2 需求跟踪矩阵
- 1.2.2 工具
- 1.2.2.1 数据收集
- 1.2.2.1.1 头脑风暴
- 1.2.2.1.2 访谈
- 1.2.2.1.3 焦点小组
- 1.2.2.1.4 问卷调查
- 1.2.2.1.4 标杆对照
- 1.2.2.2 数据分析
- 1.2.2.2.1 用例图
- 1.2.2.3 决策
- 1.2.2.3.1 投票
- 1.2.2.4 数据表现
- 1.2.2.4.1 亲和图
- 1.2.2.4.2 思维导图
- 1.2.2.6 人际关系和团队技能
- 1.2.2.6.1 名义小组
- 1.2.2.6.2 观察/交谈
- 1.2.2.6.3 引导
- 1.2.2.7 系统交互图
- 1.2.2.8 原型法
- 1.3 定义范围
- 1.3.1 输出
- 1.3.1.1 范围说明书
- 1.3.2 工具
- 1.3.2.1 数据分析
- 1.3.2.2 决策
- 1.3.2.3 产品分析
- 1.4 创建WBS
- 1.4.1 输出
- 1.4.1.1 范围基准
- 1.4.2 工具
- 1.4.1 分解
- 1.5 确认范围
- 1.5.1 工具
- 1.5.1.1 检查
- 1.6 控制范围
- 2. 课堂习题
- 3. 脑图
范围是地基,是整个项目的地基
范围蔓延:出现变更、客户提出需求 质量镀金:超出客户的预期(多做事情会更多风险)
这些事情出现之后,责任可能在我的身上
计划指导后续流程 定义范围很大,需要创建WBS细化 确认范围由客户验收 控制范围,防止镀金
过渡需求可以理解为一次性需求
需求需要遵循SMART原则
用于跟踪需求,从哪里来?从哪里去 确保有商业价值
例如: 有价值,能做,可行
头脑风暴:
头脑风暴: 激发各自的创意,数量越多,质量就越多
访谈防止用户撒谎。可以另外一种方式提问题,比如,能不能提个建议更加好?
焦点小组:一个专业的技术团队对一个专业的领域做技术探讨;
问卷调查作为辅助,不太重要
找差别,做对比
IT管理可以找建筑管理做对标,因为是局部做对比,不是全局,比如团队管理。 同组织内有竞争关系,所以不要在组织内对标 跨行业对标是最好的,而且其它行业愿意教你
是系统的一系列动作
一致同意 要有该领域的专家参与
也称为加权矩阵
头脑风暴的深入,小组讨论之后汇总到大组
JAD会议就是驻场开发
用户故事
给他指令,他给你反馈,这是一次交互
把做出来的成品给自愿者使用,提出反馈
用户故事地图:
用例、系统交互、用户故事、故事板:按电梯案例
上面的都是收集需求
一个人的能力是可以项目拆解,并不是把所有的功能完成
SV叫进度偏差,SV=+100比计划完成了多100 ,如果减100则代表少100
1.3 不是父子关系,
注意:WBS注重的是名词,而不是动作。
项目层级不要超过3层,如果项目太大,则分成子项目,由各个项目经理去管。
先检查质量,在签字确认范围
如果客户提出减少钱,那么可以削减范围。保质量,舍范围
控制范围和确认范围的区别:
所有跟需求有关的文件如下:
答案: D:计划是定义如何? B:确认需求,没有B则选A 答案:DA(题干问什么答什么)
答案:DD
答案:C(时间紧急是一点,但是达成一致才是重点,尽量用引导)、D(不需要遵循统一,如第一层分4个,第二层分5个)