前言风险管理(Risk Management,RiskM )的目的是在风险造成危害之前识别它们,有计划地消除或减弱风险。
风险管理过程域是SPP模型的重要组成部分。 本规范阐述了风险管理的规程,该规程的“目标”、“角色和职责”、“启动标准”、“输入”、“主要步骤”、“输出”、“完成标准”和“衡量标准”均有定义。
本规范适用于国内IT企业的软件开发项目。 建议用户根据业务目标、研发实力等情况,适当修改本规范,推广使用。
所有可能危害7.1介绍项目的因素都称为风险。 被描述为风险的事件最终可能发生,也可能不发生。 人们对风险的态度有两种。 一种是被动的态度,可以和“灭火模式”相媲美。 另一种是自主态度,可以与“防火模式”进行比较。 风险管理是一种“防火模式”,旨在“防止风险造成的真正危害”。
为了便于定量管理,为风险定义了三个参数。
风险的严重性:指风险对项目的危害程度。
风险的可能性:指风险发生的概率。
风险系数:风险的严重性与风险可能性的乘积。
参数
等级
值
描述
风险
严重性
很贵
5
例如,进度延误超过30%,费用超支超过30%。
比较贵
4
例如,进度落后20%~30%,或者费用超支20%~30%。
中等的
3
例如,进度延迟低于20%,或费用超支低于20%。
比较低
2
例如,进度延迟低于10%,或费用超支低于10%。
很低
1
例如,进度延迟低于5%,或费用超支低于5%。
表7-1风险严重程度
参数
r: #383838;">等级
值
描述
风险
可能性
很高
5
风险发生的几率为1.0 ~.8
比较高
4
风险发生的几率为0.8 ~.6
中等
3
风险发生的几率为0.6 ~.4
比较低
2
风险发生的几率为0.4 ~.2
很低
1
风险发生的几率为0.2 ~.0
表7-2 风险可能性等级
风险 系数 | 风险可能性 | |||||
很高 | 比较高 | 中等 | 比较低 | 很低 | ||
风险 严重性 | 很高 | 25 | 20 | 15 | 10 | 5 |
比较高 | 20 | 16 | 12 | 8 | 4 | |
中等 | 15 | 12 | 9 | 6 | 3 | |
比较低 | 10 | 8 | 6 | 4 | 2 | |
很低 | 5 | 4 | 3 | 2 | 1 | |
本表灰色部分的风险系数值为10~25,应当优先处理。 |
表7-3 风险系数等级
风险严重性的等级划分如表7-1所示,风险可能性的等级划分如表7-2所示,风险系数的等级划分如表3所示。
风险管理有4个主要活动:
◆风险识别:根据风险检查表,识别出本项目的风险。
◆风险分析:估计风险严重性、风险可能性、风险系数。
◆风险减缓:对于风险系数超过“容许值”的每一个风险,都应当采取减缓措施。
◆风险跟踪:跟踪风险减缓过程,记录风险的状态。
图7-1 风险管理示意图
在项目的生命周期内,上述4个活动将被循环执行,如图7-1所示。直到项目的所有风险都被识别与解决为止。
常用的风险检查表见 [SPP-TEMP-RISKM-CHECKLIST],使用者应根据实际情况进行适当的删减或补充。风险管理过程域产生的主要文档是《风险管理报告》,模板见 [SPP-TEMP-RISKM-REPORT]。
7.2 风险管理规程7.2.1 目的在项目的生命周期内,循环执行风险识别、风险分析、风险减缓和风险跟踪,直到项目的所有风险都被识别与解决为止。
7.2.2 角色与职责项目经理负责风险管理。
项目成员协助项目经理处理风险。
7.2.3 启动准则《项目计划》已经制定,项目研发已经开始。
7.2.4 输入《项目计划》
项目监控过程产生的文档如《项目监控数据表》、《项目偏差控制报告》和《项目进展报告》等
7.2.5 主要步骤[Step1] 风险识别项目经理根据“风险检查表”[SPP-TEMP-RISKM-CHECKLIST],定期(例如每周一次)识别本项目的风险。
[Step2] 风险分析项目经理评估每个风险的严重性、可能性和风险系数,并按照风险系数从高到低的顺序排列风险。
[Step3] 风险减缓对于风险系数超过“容许值”(建议为10)的每一个风险,项目经理应当给出风险减缓措施,并指定责任人。风险系数越高,越先处理。
[Step4] 风险跟踪项目经理跟踪风险减缓过程,直到风险已经解决为止。如果风险的性质发生变化,应当及时更新风险减缓措施
7.2.6 输出《风险管理报告》
7.2.7 结束准则所有风险都已经解决,相关信息已经记录到《风险管理报告》之中。
7.2.8 度量项目经理统计工作量。
7.3 实施建议对风险管理过程域产生的所有有价值的文档进行配置管理。
项目经理根据本项目的特征,确定风险识别的频度(通常为每周一次),适当修改“风险检查表”[SPP-TEMP-RISKM-CHECKLIST]。
选用合适的软件工具,尽量减少风险管理过程域的工作量。
项目监控和风险管理均由项目经理负责,建议同步执行。
附录一:《风险检查表》
商业风险 | |
风险类型 | 检查项 |
政治 法律 市场 | 政府或者其他机构对本项目的开发有限制吗? |
有不可预测的市场动荡吗? | |
有不利于我方的官司要打吗? | |
本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗? | |
竞争对手有不正当的竞争行为吗? | |
本产品销售后在使用过程中可能导致发生重大的损失或伤亡事故吗? | |
是否在开发很少有人真正需要却自以为很好的产品? | |
是否在开发可能亏本的产品? | |
客户 | 客户的需求是否含糊不清? |
客户是否反反复复地改动需求? | |
客户指定的需求和交付期限在客观上可行吗? | |
客户对产品的健壮性、可靠性、性能等质量因素有非常过分的要求吗? | |
客户的合作态度友善吗? | |
与客户签的合同公正吗?双方互利吗? | |
客户的信誉好吗?例如按客户的需求开发了产品,但是客户可能不购买。 | |
子承包商 供应商 | 与子承包商、供应商签订的合同公正吗?双方互利吗? |
子承包商、供应商的信誉好吗? | |
子承包商、供应商有可能倒闭吗? | |
子承包商、供应商能及时交付质量合格的产品(或部件)吗? | |
子承包商、供应商有能力做好售后服务吗? | |
管理风险 | |
风险类型 | 检查项 |
项目计划 | 对项目的规模、难度估计是否比较正确? |
人力资源(开发人员、管理人员)够用吗?合格吗? | |
项目所需的软件、硬件能按时到位吗? | |
项目的经费够用吗? | |
进度安排是否过于紧张?有合理的缓冲时间吗? | |
进度表中是否遗忘了一些重要的(必要的)任务? | |
进度安排是否考虑了关键路径? | |
是否可能出现某一项工作延误导致其他一连串的工作也被延误? | |
任务分配是否合理?(即把任务分配给合适的项目成员,充分发挥其才能) | |
是否为了节省钱,不采用(购买)成熟的软件模块,一切从零做起? | |
… | |
项目团队 | 项目成员团结吗?是否存在矛盾? |
是否绝大部分的项目成员对工作认真负责? | |
绝大部分的项目成员有工作热情吗? | |
团队之中有“害群之马”吗? | |
技术开发队伍中有临时工吗? | |
本项目开发过程中是否会有核心人员辞职、调动? | |
是否能保证“人员流动基本不会影响工作的连续性”? | |
项目经理是否忙于行政事务而无暇顾及项目的开发工作? | |
上级领导 行政部门 合作部门 | 本项目是否得到上级领导的重视? 上级领导是否随时会抽调本项目的资源用于其他“高优先级”的项目? |
上级领导是否过多地介入本项目的事务并且瞎指挥? | |
行政部门的办事效率是否比较底,以至于拖项目的后腿? | |
行政部门是否经常干一些无益于生产力的事情,以至于骚扰本项目? | |
机构是否能全面、公正地考核员工的工作业绩? | |
机构是否有较好的奖励和惩罚措施? | |
本项目的合作部门的态度积极吗?是否应付了事?或者做事与承诺的不一致? | |
技术风险 | |
风险类型 | 检查项 |
需求开发 需求管理 | 需求开发人员懂得如何获取用户需求吗?效率高吗? |
需求开发人员懂得项目所涉及的具体业务吗?能否理解用户的需求? | |
需求文档能够正确地、完备地表达用户需求吗? | |
需求开发人员能否与客户对有争议的需求达成共识? | |
需求开发人员能否获得客户对需求文档的承诺?以保证客户不随便变更需求? | |
综合技术 开发能力 包括设计 编程、测试等 | 开发人员是否有开发相似产品的经验? |
待开发的产品是否要与未曾证实的软硬件相连接? | |
对开发人员而言,本项目的技术难度高吗? | |
开发人员是否已经掌握了本项目的关键技术? | |
如果某项技术尚未实践过,开发人员能否在预定时间内掌握? | |
开发小组是否采用比较有效的分析、设计、编程、测试工具? | |
分析与设计工作是否过于简单、草率,从而让程序员边做边改? | |
开发小组采用统一的编程规范吗? | |
开发人员对测试工作重视吗?能保证测试的客观性吗? | |
项目有独立的测试人员吗?懂得如何进行高效率地测试吗? | |
是否对所有重要的工作成果进行了同行评审(正式评审或快速检查)? | |
开发人员懂得版本控制、变更控制吗?能够按照配置管理规范执行吗? | |
开发人员重视质量吗?是否会在进度延误时降低质量要求? |
附录二:《风险管理报告》
风险名称 | 风险识别人 | ||
风险编号 | 风险识别日期 | ||
风险描述 | |||
风险严重性 | 风险系数 | ||
风险可能性 | 风险处理人 | ||
风险减缓措施 | |||
跟踪记录 | (1)记录何人在何时做了什么事情 (2)记录当前风险状态(正在处理,已经解决,不作处理) |