软件项目管理==风险计划

软件项目管理 风险计划

请列举出几个软件项目中的风险现象

• 从人员方面
• 从软件生命周期各阶段方面
• 从软件项目管理进度方面
• 成本管理方面
• 掌握现有技术和工具方面

风险现象

1. 软件行业人员流动率很高
2. 项目经理或技术骨干的辞职
3. 雇佣了技术能力不强的开发人员
4. 使用了不熟悉的开发工具

软件项目中的风险

1. 不断变换的需求
2. 人员流动
3. 技术失败
4. 政策变化

软件项目风险计划

1. 风险基本概念
2. 风险管理过程
3. 风险管理计划
4. 案例分析
5. 课程实践

风险

• 不确定的事件或情况，一旦出现会对项目目标产生积极或消极影响
• 我们常常所指的风险：一旦出现会对项目目标产生消极影响的不确定事件或情况

风险的描述

原因+后果

没有经验的员工导致低生产率

将下面 原因 和结果进行匹配

A 员工经验

B 缺乏高层领导的承诺

C 新技术

D 用户需求不确定

后果

i 测试比计划用的时间长

ii 活动结果和时间超出预期

iii 项目规模增加

iv 为获得计划更改的同意使时间推迟

可能答案：

A i和ii，由于员工缺乏经验，导致编码中出现错误，需要更多时间测试。有经验的员工可以发更多时间 实施开发

B iv 如果上层不对项目做一个坚定的承诺，他们在执行的时候不会有紧迫感

C ii 新技术需要时间学习和适应

D iii 需求不确定 ，可能增加新内容

风险特点（性质）

• 风险存在的客观性和普遍性
• 某一具体风险发生的偶然性和大量风险发生的必然性
• 风险的可变性
• 风险的多样性和多层性
• 风险的不利性

风险的可变性是指在一定条件下风险可以转化，风险的可变性包括：

1. 风险量的变化
2. 某些风险在一定空间和时间范围内被消除
3. 新的风险产生

项目风险的三要素

1. 一个事件
2. 事件发生的概率
3. 事件的影响

风险图示

风险类型

1. 预测角度

   1. 已知风险
   2. 可预测风险
   3. 不可预测风险

2. 范围角度

   1. 商业风险、管理风险、人员风险、技术风险、开发环境风险、客户风险、过程风险、产品规模风险等

   已知风险：通过仔细评估项目计划，开发项目的商业和技术环境以及其他可靠的信息来源之后可以发现的哪些风险

   不现实的交付日期，没有需求或软件范围的文档，恶劣的开发环境

   可预测的风险：从过去项目经验中可推测出来的风险（如人员调整，与客户无法沟通，由于需要进行维护而使得开发人员精力分散

   不可预测的风险：可能，也会真的出现，但很难事先识别出来

   项目管理这只能对已知和可预测风险进行规划，不可预测的风险只能靠企业能力承担

   风险的三个属性是( )。

   A.风险发生的时间、地点、负责人

   B.风险事件、时间、影响

   C.风险事件、概率、影响

   D.风险数量、风险影响程度、概率

风险管理的四个过程

风险识别

风险识别是视图通过系统化的确定对项目计划的威胁，识别已知和可预测的风险

风险识别方法

• 德尔菲方法
• 头脑风暴法
• 情景分析法
• 利用风险条目检查表

• 你以前是否曾与这个客户合作过？
• 该客户是否很清楚需要什么，他能否花时间把需求写出来
• 该客户是否同意花时间召开正式的需求收集会议，以确定项目范围？
• 该客户是否愿意参加复审工作
• 待开发的软件是否需要使用新的或未经证实的硬件接口？
• 是否有足够的人员可用

利用风险条目检查表

• 利用检查表作为风险识别的工具
• 根据列表中的条目识别风险
• 集中识别常见的类型中的已知和可预测的风险

IT项目常常存在一些共同的风险源

风险识别的结果

风险	类别	概率	影响	RMMM
规模估算可能非常低	PS	60%	2
复用程度低于计划	PS	30%	3
最终用户抵制该系统	BU	40%	3
支付期限将被紧缩	BU	50%	2
资金将会流失	CU	40%	1
用户将改变需求	PS	80%	2
技术达不到预期的效果	TE	30%	1
缺少对工具的培训	DE	80%	1
人员缺乏经验	ST	30%	2

从项目、技术、人员、管理等方面列举出软件项目存在哪些风险

• 预算削减打乱项目计划；

• 项目计划由于压力而放弃，导致开发混乱，低效；

• 低效的项目组结构降低生产率；

• 由于前期乏力，项目长时间搁置；

• 解雇和削减开支导致项目小组能力下降；

• 非技术的第三方工作比预期延长（预算批准、设备采购批准……）

技术

• 分别开发的模块无法有效集成，需要重新设计或者重做；
• 采用不熟悉的方法，导致额外的培训时间，并重犯以前的错误；
• 产品采用低级语言来实现，导致生产率比预期低；
• 一些必要的功能无法是用现有的代码和库实现，开发人员必需使用新的库或者自行开发所需要的功能；
• 代码和库质量低下，导致需要额外的测试，错误修正或重做；

人员

• 开发人员和管理层关系不佳导致决策缓慢，影响全局；
• 项目组乘员没有全身心投入项目，进而无法达到需要的产品性能水平；
• 某些人需要更多时间适应不熟悉的软件工具和环境；
• 项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率；
• 由于项目组成员的冲突，导致沟通不畅，设计欠佳，接口错误和额外的重复工作；
• 关键人员只能兼职参与；
• 人员工作的进展比预期的慢；
• 技术人员怠工导致工作遗漏或质量低下，工作需要重做；

管理

• 管理层审查/决策的周期比预期时间长；
• 管理层做出了打击项目积极性的决定；
• 管理层强调英雄主义，而忽略客观确切的状态报告，降低发现和改正问题的能力；
• 仅由管理层或市场人员来进行技术决策，导致计划进度延长；

风险评估

对风险事件发生概率的评估，对项目风险影响的评估。给出项目风险排序

分析

• 风险发生的概率
• 风险对项目的危害
• 风险影响（风险暴露度）风险值=R=P*I

确定优先次序

• 按风险值排序
• 确定最需要关注的TOP风险

风险评估

• 如何定量化的评价风险的影响是一个难题
• 简单地评分方法
• 将可能性和影响给出1-10之间的分值–定量评估
• 将可能性和影响分为高中低级别—定性评估

定量确定风险值

1. 风险的可能性：危险发生的概率
2. 对项目的影响程度
3. 风险的重要性：
   1. 风险暴露量
   2. Risk exposure=risk likelihood*risk impact
   3. risk impact一般以金额为单位，而likelihood以概率为单位
   4. 风险暴露度或风险值（RE）=潜在危害*风险发生可能性
   5. 理想情况下：潜在危害，用钱的价值计算，比如：一场洪水将会引起50万英镑损失
   6. 风险发生的可能性取值0-1之间比如0.01 RE=0.5*0.01=5000
   7. 采用金额为单位，计算复杂，值比较大，不便于排序
   8. 将可能性与危害给出1到10之间的分值—定量评估

序号	起因	可能性	危害	风险值或暴露度
R1	由于前期乏力，项目长时间搁置	5	6	30
R2	代码和库质量低下，导致需要额外的测试，错误修正或重做	9	7	63
R3	某些人需要更多时间适应不熟悉的软件工具和环境	10	5	50
R4	人员工作的进展比预期的慢	9	4	36
R5	项目组乘员没有全身心投入项目，进而无法达到需要的产品性能水平	9	8	72
R6	解雇和削减开支导致项目小组能力下降	3	6	18
R7	由于项目组成员的冲突，导致沟通不畅，设计欠佳，接口错误和额外的重复工作	4	5	20
R8	开发人员和管理层关系不佳导致决策缓慢，影响全局	6	4	24
R9	项目计划由于压力而放弃，导致开发混乱，低效	4	8	32
R10	分别开发的模块无法有效集成，需要重新设计或者重做	7	6	42

风险排序

• 管理风险的策略有两条
  • 通过降低风险的概率和危害从而降低风险暴露量risk exposure
  • 建立意外计划
• 由于管理风险需要一定的成本，因而需要对风险进行排序人们通常用80%的钱解决20%的问题，重点关注前10个风险
• 基于给分的方法计算风险暴露量存在一些问题

风险评估的方法–定性风险评估

定性评估概率及后果：将可能性和影响分为高、中、低级别–定性评估

可能性等级	范围
高	发生概率超过 50%
显著	发生概率30-50%
中等	发生概率10-29%
低	发生概率小于 10%

影响等级	范围
高	超出预算 30%
显著	超出预算20 to 29%
中等	超出预算10 to 19%
低	超出预算低于10%

风险概率度量

• 高、中、低
• 极高、高、中、低、极地
• 不可能、不一定、可能和极可能
• 等等

风险影响度量

• 高、中、低
• 极高、高、中、低、极低
• 灾难、严重、轻微、可忽略
• 等等

风险概率及后果估计–矩阵图

P R I	Low	Medium	High
High	L	H	H
Medium	L	H	H
Low	L	M	M

风险评估有哪些任务？

风险识别–风险分析–风险评价

风险规划

针对风险分析的结果，为提高实现项目目标的机会，降低风险的负面影响而制定风险应对策略和应对措施的过程，即制定一定的行动和策略来对付，减少以至于消灭风险事件造成的影响

主要策略

1. 接受风险
   1. 有风险，但不采取措施：小风险，或者采取措施后投入的成本比风险发生的损失还多
2. 规避风险
   1. 规避风险是对可能发生的风险尽可能地规避，采取主动放弃或者拒绝使用导致风险的方案：例如放弃使用新技术
   2. 注意事项
      1. 对风险有足够的认识
      2. 当其他风险策略不理想的时候，可以考虑
      3. 可能产生另外的风险
      4. 不是所所有的情况都适用
3. 缓解和降低风险
   1. 采取措施，降低风险的发生可能性
   2. 识别出人员流失的可能性，高奖金
   3. 识别出开发数据库信息系统，数据格式和数据交换困难风险，采用支持通用数据库，采用标准SQL语句
   4. 识别出数据损坏风险，可以异地定期备份
4. 转移风险
   1. 转移风险是为了避免承担风险损失，有意识将损失或与损失有关的财务后果转嫁出去的方法
      1. 分包
      2. 开脱责任合同
      3. 保险

购买保险是( )类型的风险处理策略。

A.风险转移

B.风险规避

C.风险抑制

D.风险自担

例如，假设频繁的人员变动被识别为项目风险。基于以往历史和管理经验，估计频繁变动的概念为0.70（相当高），其影响预测为严重。

讨论缓解这个风险（让出现的概率低一点，让影响低一点），采用的措施：

引起人员变动的原因

• 恶劣的工作条件，报酬低，竞争激烈劳动力市场

讨论当人员离开后，如何保证工作的连续性

采取缓解风险的措施

• 与现有人员一起讨论人员变动的起因（恶劣的工作条件，报酬低，竞争激烈劳动力市场）
• 在项目开始之前，对我们能控制的人员变动起因，想办法减少
• 人员变动后，利用技术手段保证工作的连续性
• 每个人的开发胡哦哦东信息被广泛传播和交流
• 制定编制文档标准，并建立相应机制以确保能够及时创建文档
• 同等对待所有工作的评审
• 为每个关键技术人员制定一个后备人员

风险规划实例

人员的频繁流动是一项风险，基于过去的历史和管理经验，频繁流动可能性的估计值为70%，开发时间增加15%，总成本增加12%，为了缓解这一风险，项目经理是采取的策略

1. 与现有人员讨论人员流动的原因
2. 建立良好的项目组织和通信渠道。以使得大家能够了解每个有关的开发活动的信息
3. 制定文档标准并建立相应的机制，以保证翁当能够及时建立
4. 对所有工作组织细致的评审，使大多数人能够按计划进度完成自己的工作
5. 项目启动时，做好会出现人员流动的准备，采取一些技术以确保人员的一旦离开后，项目仍然能继续

风险管理应对计划

排序	输入	风险事件	可能性	影响	风险值	采取的措施
1	系统设计评审	没有足够的时间进行产品测试	70%	50%	35%	1.采取加班的方法2.修改计划去掉一些任务3.向客户商量延长一些时间
2	WBS	对需求的开发式系统标准没有合适的测试案例	20%	80%	16%	找专业的测试公司完成测试工作
3	需求和计划	采用新技术可能导致进度的延期	50%	30%	15%	1.培训开发人员2.找专家作指导3.采取边开发边学习的方法，要求他们必须在规定的时间内掌握技术

风险管理计划

• 风险应对计划（例如TOP清单）
• 岗位职责
• 风险追踪

风险控制

• 前10个风险列表，包括本周排序，上周排序，已上列表周数、风险、风险化解进展
• 中间检查
• 风险管理

在频繁人员变动的例子中，监测：团队成员的压力的普遍程度，团队的凝聚力，团队成员彼此关系与报酬等

风险监控

下面哪项不是风险管理的过程( )。

A. 风险评估

B. 风险识别

C. 风险规划

D. 风险收集

实施风险的管理过程有哪些，每个过程如何执行？

**第一步:识别风险。**您和您的团队发现、识别并描述可能影响项目或其结果的风险。您可以使用许多技术来发现项目风险。在此步骤中，您开始准备项目风险登记册。

**第二步:分析风险。**一旦确定了风险，你就要确定每种风险的可能性和后果。您可以理解风险的性质及其对项目目标和目标的影响。这些信息也被输入到您的项目风险登记册中。

**第三步:评估风险或给风险排序。**你通过确定风险大小来评估或排序风险，风险大小是可能性和后果的组合。你要决定风险是否可以接受，或者是否严重到需要治疗。这些风险排名也被添加到您的项目风险登记册中。

**第四步:应对风险。**这也被称为风险应对计划。在此步骤中，您将评估最高级别的风险，并制定计划来处理或修改这些风险，以达到可接受的风险水平。你怎样才能在增加机会的同时将消极风险的可能性降到最低呢?在此步骤中，您将创建风险缓解策略、预防计划和应急计划。并且您将最高等级或最严重的风险的风险处理措施添加到您的项目风险记录中。

**第五步:监控和检查风险。**这是您进行项目风险登记并使用它来监视、跟踪和审查风险的步骤。

评估进度计划的风险

• 使用PERT(program evaluation and Review Technique)评价不确定性的方法
• PERT与CPM同时出现，具有类似性
• 每个活动的持续时间的估计包括
  • 最可能实践m
  • 乐观时间a
  • 悲观时间b
  • 期待时间

• 通过期待持续实践可以用类似于CPM中前向路径方法计算项目结束日期
• 问题，此处获得日期是否为最早结束日期

练习

结果表达为“我们期待项目在…天完成”

活动标准偏差

达到目标的可能性

计算步骤

• 计算每个项目实践的标准偏差
• 计算具有目标期限的事件的值
• 将z值转换为概率
• 项目事件的标准偏差的计算方法与计算项目期待时间计算时采用的方法是类似的
• 两个标准偏差的和是两者的平方和再求平方根

请计算2，4，6事件的标准偏差

达到目标的可能性

• 计算z值

  

T：目标日期 te：期待时间 s：标准偏差

将z值转化为概率

达到目标的可能性

1. PERT的优点
2. 基于仿真的方法

实例

医疗信息商务平台：项目风险计划

风险管理的四个过程

风险管理计划