编号 |
风险名称 |
内容 |
发生概率 |
损失 (人周) |
危险度(周) |
1 |
计划编制风险 |
计划不切实际; 计划基于特定小组成员,一个关键任务的延迟导致其他相关任务的连锁反应 |
50% |
10 |
5 |
2 |
组织和管理风险 |
缺乏强有力、有凝聚力的领导;计划性太差,无法达到预期速度; 管理方面英雄主义,忽略客观确切的状态报告 |
5% |
5 |
2.5 |
3 |
开发环境风险 |
开发环境的搭建与现有的环境冲突; |
5% |
1 |
0.5 |
4 |
最终用户风险 |
最终用户对最后交付的产品不满意,要求重新设计和重做 |
5% |
1 |
0.5 |
5 |
客户风险 |
客户没有参与规划、原型和规格的审核,导致需求不稳定,以及长时间的变更; 性能不完善; |
5% |
1 |
0.5 |
6 |
需求风险 |
需求定义不加:不清晰、不准确 |
10% |
5 |
5 |
7 |
产品风险 |
发生错误几率高的模块,需要多次测试; 严格要求产品的兼容性; 开发额外不需要的功能浪费了时间; |
30% |
10 |
3 |
8 |
人员风险 |
成员不能有效的在一起工作; 成员之间的冲突导致沟通不畅; 任务的分配和人员的技能不匹配; 人员怠工导致工作遗漏、质量底下 |
60% |
20 |
12 |
9 |
设计和实现的风险 |
设计过于复杂,导致也写不必要的工作,影响工作效率; 使用不熟悉的方法导致需要外的培训时间; 分别开发的模块无法有效集成,需要重新设计和实现
|
50% |
20 |
10 |
统计表明,项目80%成本用于解决20%的问题
风险管理重点关注20%重要的部分
根据风险的危险度确定风险的重要性,忽略其他部分。
据上分析出重要的部分为:
编号 |
危险度 |
8 |
12 |
9 |
10 |
1 |
5 |
6 |
5 |
针对每一个重要的风险,制定一个处理该风险的计划
风险由于谁引起
表现形式是什么
可能什么时候发生
为什么发生
如何避免
发生后措施
编号 |
控制方法 |
8 |
培养人员技术,每人指定psp0表格,以达到分配的结果 |
9 |
项目开始前,每个成员阅读相关书籍,学习相关技术,总结相关经验 |
1 |
估算要科学,利用工具,解决历史数据 |
6 |
调研多类、多组、多个用户 |
原文:http://www.cnblogs.com/zhaixing/p/4469929.html