软件项目的风险管理详解

软件项目的风险管理详解
我是一名计算机软件开发人员。

我精通多种编程语言。

我热爱这份工作，设计程序、编程、调bug、解决问题……这一切让我觉得很兴奋、很有成就感。

我愿意学新东西，解决一个又一个技术难题——这让我觉得自己是一个“有用的人”。

“我喜欢我的同伴们，他们是一群很棒的人，我们谈得来，技术上的事儿我们总能一起找到办法。

”
“但是项目是另外一回事儿，有时候真的让人很恼火，我们团队只有3个人，却干着6个人的活儿！”
“我们只有1台调试机，几个团队都要用，每天因为争用调试机打架。

”
“忙死了，还要带一帮新人干活，他们什么都不会，光添乱！他们要是早一点儿来我还有时间带他们，现在？算了，我还是加班自己来吧。

”
“早干嘛去了，这时候才说要改架构，我们开发都进行一半了！”
“这活儿真没法儿干，客户干嘛总是来指手画脚啊，打乱我们的计划了。

”
“我在公司接受了3个月的培训，现在正式加入这个项目了。

项目很大，任务很重，据说对公司的前途至关重要，我很兴奋。

前辈们很有经验，也很忙，我也想做点儿什么，但
是他们好像不太欢迎我加入，有点儿沮丧”。

如果你是一名软件开发者，上面的话是不是感觉很熟悉？每个人都有干劲儿，大家目标也一致，但是总是有这样那样的问题使我们无法专注于自己的“本职”工作。

问题，问题，那么多的问题！虽然说解决难题能带来成就感，但是相信我，当意料之外的问题组团出现的时候，它们带来的只能是混乱！更糟糕的是，火气、丧气、疲惫感也一起来凑热闹。

对于项目，尤其是大项目来讲，这可不是个好现象。

好吧，让我们静下来，想一想，那些问题在成为问题之前，我们真的一点儿都没预料过么？如果能预料的话，是否能够提前做些什么来避免，或者减轻问题的破坏力？退一步讲，最起码让人喘口气，问题别一起出现！要达到上述目的，用一个术语化的说法，就是进行“风险管理”。

通俗的说，风险就是“问题发生的可能性”。

所谓问题，就是之前我们提到的各种各样的不希望发生的“闹心事儿”。

风险管理的主要任务是：在问题发生之前，识别它、评估它、做对策，降低其发生的可能性和发生时的危害程度；然后，在对策的实施过程中，进行定期跟踪、再评估、调整对策，以确保问题是可控的，直到安全解决。

风险管理
综上所述，风险管理主要体现在下面几方面：
● 风险识别：找到可能发生问题的地方
● 风险评估：是哪类问题、发生的可能性、发生后的影响度以及危险等级
● 风险对策：什么时间、做哪些工作、能降低风险发生的可能性还是发生后的影响
● 风险跟踪：可能性的变化、影响度的变化、危险等级的变化、风险对策是否需要调整、是否引起新的风险等等风险管理是软件项目整个生命周期中的常规工作。

在项目策划、项目范围变更、项目计划变更、定期项目跟踪时，都要进行风险管理。

风险识别
在软件开发项目中，要识别风险，一个基本方法是“模拟法”——用现有的人员、技术、资源，在项目开始的时点上，审视现有流程上的每一个步骤，思考并预测将会遇到什么问题。

这项工作将使我们得到一份风险描述的列表。

对风险列表中的风险进行“合并同类项”处理，尤其是当一个项目涉及到多个团队、较多人，不同的团队和个人提出与他们相关的风险的时候，这种“合并同类项”的处理就显得尤为重要。

它可以保证资源的统一调配，最大限度复用，避免各自为政造成的浪费。

风险评估
对风险进行深入的评价，主要分析风险的种类、可能性和影响。

● 风险的种类
一般来讲，所有的风险都可以归结到软件项目的几个要素上去。

现在，我们首先来提取这些要素。

什么是项目？通俗的讲就是：在特定的时间内、特定的成本下、完成特定的工作，成果物要质量达标，令用户满意。

所以说，项目有下面几个关键的维度：
○ 进度：在什么时间完成
○ 成本：花费多少代价
○ 范围：做什么，做到什么程度
○ 质量：成果物的质量属性
○ 客户满意度：令客户满意
所谓风险的种类，在软件项目中，通常指上述维度的某一个。

当然，从市场及企业经营的级别来看，会有另外一套关于种类的定义标准，这里不做深入讨论。

● 可能性：这个风险演变成问题的可能性有多少
● 影响：这个风险演变成问题的话，其破坏力有多大
● 风险级别：根据风险演变成问题的可能性和影响度，形成各风险评级。

风险级别越高，越应该得到管理者的重视
下表列举了风险评级的方法(表1)：
首先，量化描述可能性及影响度，然后把风险放到矩阵中的相应位置上，最后根据风险所处的区域，判断是S、A、B、C的哪一个级别。

S级：影响大、发生的可能性大。

这样的风险必须进行处理，一定要制定对策降低风险或者规避风险。

A级：影响度在中等程度以上，发生的可能性比较大，或者影响度虽然小，但是发生可能性很高。

这样的风险也应该进行处理，制定相应的对策来降低或者规避风险。

B级：影响大，但是发生概率很低。

这样的风险不应该消耗太多的管理成本，不必专门制定对策，只需做定期跟踪。

C级：影响小且发生概率低。

这样的风险可以暂时不纳入管理体系。

需要注意的是，不同的领域、不同的项目，对风险的影响度和发生可能性的量化标准是不一样的。

对风险的容忍度，也就是SABC的判定标准也是不一样的。

例如：同样是“发生几率为万分之一的‘死机’”这样的风险。

在某些日用消费品中，是完全可以接受的，可以列为C级风险，不予关注。

但是在航天项目中，则是绝对不能容忍的，必须以S级来处理。

所以说，任何一个项目都需要为自己量身定做风险判断基准。

甚至需要在项目外、组织级进行定义。

在组织级定义
项目风险判断基准的好处是：同一个组织内，为风险制定统一的量化标准，则不同项目的风险之间具有可比性，为管理和决策提供依据。

因为风险评估对后期的决策有很重要的影响，所以，为慎重起见，有些评估会经与相关人员一起进行几轮的讨论，才能最后确定下来。

风险对策
根据风险评估中得出的风险级别，优先处理S、A级别的风险，并为每一个风险制定专门的对策。

在制定风险对策的时候，我们会发现，风险是可以“转移”的。

不同的风险，根据对策的不同可能在属性上有所转移，可能对原有的风险造成影响，也可能会带来新的风险。

下表是对一个风险的识别、评估和对策(表2):
上述对策会降低原有的风险，但是同时会增加一个新的风险，如下(表3)所示：
上述对策就是一个典型的用“成本”换“日程”的例子。

如果对策获得认可，就会对开发计划等其他方面造成影响，所有受到影响的部分，在分析影响范围的时候，也要再次回顾已经识别的风险是否会因为这个变化而变化。

在为风险制定对策的时候，需要掌握一个原则：控制风
险水平、分散重大风险。

每一个风险都是一个不确定因素，是定时炸弹，尽量不要把太多的炸弹尤其是大炸弹集中在一个阶段解决。

分散处理的话，万一问题爆发，控制起来也相对容易一些。

多数情况下风险的对策都不是唯一的，虽然对策本身可能也会带来风险，但是要尽量均衡的考虑对策本身对项目的影响。

尽量让项目总的风险水平处于平稳，避免过大的波峰。

如图1所示，文章开头所述的一团糟的情况，可能就是对风险没有事先的管理和干预，导致集中爆发或者风险过高，从而给项目整体带来不良的影响。

更糟糕的是，打一场没有准备的仗，我们输掉战争的同时也输掉了士气和信心。

如果有事先的管理和干预，项目的风险将会被控制在一个相对稳定的水平，管理起来会容易很多，如图表2所示。

即使最后问题还是发生了，但是最起码之前大家对此有预期，知道会发生什么，对团队情绪方面的影响也会小很多。

(图1、2)
风险跟踪
我们为项目识别了风险，评估了风险的级别，为重要风险制定了对策，在这些工作之后，还需要对风险进行跟踪。

一般在项目进行周报、月报的时候，要同时进行风险的跟踪和报告。

对风险的跟踪主要集中在以下几个方面：
● 对策跟踪：对策是否按照计划实施了，实施过程中是否有新的风险出现
● 可能性：随着时间的推移或对策的实施，这个风险演变成问题的可能性有什么变化
● 影响：随着时间的推移或对策的实施，这个风险演变成问题的话，问题的破坏力有多大
● 级别：随着可能性和影响的变化，级别也会随之变化
● 风险状态：如果风险级别已经变得很低，不需要再继续处理的话，则关闭这个风险，以后不再跟踪
● 调整风险对策：判断是否需要调整对策方案，如何调整——调整的过程又涉及到新的风险识别活动
在进行风险跟踪的时候，需要注意的是：并非所有的变化都是我们的对策在起作用，有时候可能是市场变化，也可能是客户要求的变化，或者是其他外部环境的变化，让原本的可能性及影响度发生变化。

管理好风险，把项目做出节奏感
风险管理是项目管理的重要组成部分。

作为软件开发的技术人员，通常我们是相信技术的力量的，我们享受解决问题所带来的成就感。

对于企业或者组织来讲，团队成员的这种成就感是最“物美价廉”的激励，它能
够让项目成功的同时，让每个人都很快乐，让队伍快速成长。

做好风险管理，能够让所有的团队成员清楚的看到，我们在什么时候会面临什么样的挑战，为了以合理的代价达成目的，我们需要在哪些时候、做些什么。

这就好像有一个看不见的敌人，在我们的路上设置了一个又一个地雷，不怀好意的等着看我们被炸得鸡飞狗跳、气急败坏。

哪知我们早有准备，虽然紧张但却兴奋地一个一个干掉它！我们跳跃着、踩着既定的节奏，到达了目的地！我们甚至可以轻松的回过头说，虽然有点儿麻烦，但只是小case。

中国。