论文部分内容阅读
我是一名计算机软件开发人员。我精通多种编程语言。我热爱这份工作，设计程序、编程、调bug、解决问题……这一切让我觉得很兴奋、很有成就感。我愿意学新东西，解决一个又一个技术难题——这让我觉得自己是一个“有用的人”。
“我喜欢我的同伴们，他们是一群很棒的人，我们谈得来，技术上的事儿我们总能一起找到办法。”
“但是项目是另外一回事儿，有时候真的让人很恼火，我们团队只有3个人，却干着6个人的活儿！”
“我们只有1台调试机，几个团队都要用，每天因为争用调试机打架。”
“忙死了，还要带一帮新人干活，他们什么都不会，光添乱！他们要是早一点儿来我还有时间带他们，现在？算了，我还是加班自己来吧。”
“早干嘛去了，这时候才说要改架构，我们开发都进行一半了！”
“这活儿真没法儿干，客户干嘛总是来指手画脚啊，打乱我们的计划了。”
“我在公司接受了3个月的培训，现在正式加入这个项目了。项目很大，任务很重，据说对公司的前途至关重要，我很兴奋。前辈们很有经验，也很忙，我也想做点儿什么，但是他们好像不太欢迎我加入，有点儿沮丧”。
如果你是一名软件开发者（或任何需要团队合作的工作参与者），上面的话是不是感觉很熟悉？每个人都有干劲儿，大家目标也一致，但是总是有这样那样的问题使我们无法专注于自己的“本职”工作。
问题，问题，那么多的问题！虽然说解决难题能带来成就感，但是相信我，当意料之外的问题组团出现的时候，它们带来的只能是混乱！更糟糕的是，火气、丧气、疲惫感也一起来凑热闹。对于项目，尤其是大项目来讲，这可不是个好现象。
好吧，让我们静下来，想一想，那些问题在成为问题之前，我们真的一点儿都没预料过么？如果能预料的话，是否能够提前做些什么来避免，或者减轻问题的破坏力？退一步讲，最起码让人喘口气，问题别一起出现！要达到上述目的，用一个术语化的说法，就是进行“风险管理”。
通俗的说，风险就是“问题发生的可能性”。所谓问题，就是之前我们提到的各种各样的不希望发生的“闹心事儿”。
风险管理的主要任务是：在问题发生之前，识别它、评估它、做对策，降低其发生的可能性和发生时的危害程度；然后，在对策的实施过程中，进行定期跟踪、再评估、调整对策，以确保问题是可控的，直到安全解决。
风险管理
综上所述，风险管理主要体现在下面几方面：
● 风险识别：找到可能发生问题的地方
● 风险评估：是哪类问题、发生的可能性、发生后的影响度以及危险等级
● 风险对策：什么时间、做哪些工作、能降低风险发生的可能性还是发生后的影响
● 风险跟踪：可能性的变化、影响度的变化、危险等级的变化、风险对策是否需要调整、是否引起新的风险等等
风险管理是软件项目整个生命周期中的常规工作。在项目策划、项目范围变更、项目计划变更、定期项目跟踪时，都要进行风险管理。
风险识别
在软件开发项目中，要识别风险，一个基本方法是“模拟法”——用现有的人员、技术、资源（设备、能够得到的支持等），在项目开始的时点上，审视现有流程上的每一个步骤，思考并预测将会遇到什么问题。这项工作将使我们得到一份风险描述的列表。
对风险列表中的风险进行“合并同类项”处理，尤其是当一个项目涉及到多个团队、较多人，不同的团队和个人提出与他们相关的风险的时候，这种“合并同类项”的处理就显得尤为重要。它可以保证资源的统一调配，最大限度复用，避免各自为政造成的浪费。
风险评估
对风险进行深入的评价，主要分析风险的种类、可能性和影响。
● 风险的种类
一般来讲，所有的风险都可以归结到软件项目的几个要素上去。现在，我们首先来提取这些要素。
什么是项目？通俗的讲就是：在特定的时间内、特定的成本下、完成特定的工作，成果物要质量达标，令用户满意。所以说，项目有下面几个关键的维度：
○ 进度：在什么时间完成
○ 成本：花费多少代价
○ 范围：做什么，做到什么程度
○ 质量：成果物的质量属性（例如千行代码bug数、安全运行天数）
○ 客户满意度：令客户满意
所谓风险的种类，在软件项目中，通常指上述维度的某一个。当然，从市场及企业经营的级别来看，会有另外一套关于种类的定义标准，这里不做深入讨论。
● 可能性：这个风险演变成问题的可能性有多少
● 影响：这个风险演变成问题的话，其破坏力有多大
● 风险级别：根据风险演变成问题的可能性和影响度，形成各风险评级。风险级别越高，越应该得到管理者的重视
下表列举了风险评级的方法(表1)：
首先，量化描述可能性及影响度，然后把风险放到矩阵中的相应位置上，最后根据风险所处的区域，判断是S、A、B、C的哪一个级别。
S级：影响大、发生的可能性大。这样的风险必须进行处理，一定要制定对策降低风险或者规避风险。
A级：影响度在中等程度以上，发生的可能性比较大，或者影响度虽然小，但是发生可能性很高。这样的风险也应该进行处理，制定相应的对策来降低或者规避风险。
B级：影响大，但是发生概率很低。这样的风险不应该消耗太多的管理成本，不必专门制定对策，只需做定期跟踪。
C级：影响小且发生概率低。这样的风险可以暂时不纳入管理体系。
需要注意的是，不同的领域、不同的项目，对风险的影响度和发生可能性的量化标准是不一样的。对风险的容忍度，也就是SABC的判定标准也是不一样的。例如：同样是“发生几率为万分之一的‘死机’”这样的风险。在某些日用消费品中，是完全可以接受的，可以列为C级风险，不予关注。但是在航天项目中，则是绝对不能容忍的，必须以S级来处理。
所以说，任何一个项目都需要为自己量身定做风险判断基准。甚至需要在项目外、组织级进行定义。在组织级定义项目风险判断基准的好处是：同一个组织内，为风险制定统一的量化标准，则不同项目的风险之间具有可比性，为管理和决策提供依据。
因为风险评估对后期的决策有很重要的影响，所以，为慎重起见，有些评估会经与相关人员一起进行几轮的讨论，才能最后确定下来。
风险对策
根据风险评估中得出的风险级别，优先处理S、A级别的风险，并为每一个风险制定专门的对策。
在制定风险对策的时候，我们会发现，风险是可以“转移”的。不同的风险，根据对策的不同可能在属性上有所转移，可能对原有的风险造成影响，也可能会带来新的风险。
下表是对一个风险的识别、评估和对策(表2):
上述对策会降低原有的风险，但是同时会增加一个新的风险，如下(表3)所示：
上述对策就是一个典型的用“成本”换“日程”的例子。如果对策获得认可，就会对开发计划等其他方面造成影响，所有受到影响的部分，在分析影响范围的时候，也要再次回顾已经识别的风险是否会因为这个变化而变化。
在为风险制定对策的时候，需要掌握一个原则：控制风险水平、分散重大风险。
每一个风险都是一个不确定因素，是定时炸弹，尽量不要把太多的炸弹尤其是大炸弹集中在一个阶段解决。分散处理的话，万一问题爆发，控制起来也相对容易一些。
多数情况下风险的对策都不是唯一的，虽然对策本身可能也会带来风险，但是要尽量均衡的考虑对策本身对项目的影响。尽量让项目总的风险水平处于平稳，避免过大的波峰。
如图1所示，文章开头所述的一团糟的情况，可能就是对风险没有事先的管理和干预，导致集中爆发或者风险过高，从而给项目整体带来不良的影响。更糟糕的是，打一场没有准备的仗，我们输掉战争的同时也输掉了士气和信心。
如果有事先的管理和干预，项目的风险将会被控制在一个相对稳定的水平，管理起来会容易很多，如图表2所示。即使最后问题还是发生了，但是最起码之前大家对此有预期，知道会发生什么，对团队情绪方面的影响也会小很多。(图1、2)
风险跟踪
我们为项目识别了风险，评估了风险的级别，为重要风险制定了对策，在这些工作之后，还需要对风险进行跟踪。
一般在项目进行周报、月报的时候，要同时进行风险的跟踪和报告。
对风险的跟踪主要集中在以下几个方面：
● 对策跟踪：对策是否按照计划实施了，实施过程中是否有新的风险出现（这里又是一个风险识别的过程）
● 可能性：随着时间的推移或对策的实施，这个风险演变成问题的可能性有什么变化
● 影响：随着时间的推移或对策的实施，这个风险演变成问题的话，问题的破坏力有多大
● 级别：随着可能性和影响的变化，级别也会随之变化
● 风险状态：如果风险级别已经变得很低，不需要再继续处理的话，则关闭这个风险，以后不再跟踪
● 调整风险对策：判断是否需要调整对策方案，如何调整——调整的过程又涉及到新的风险识别活动
在进行风险跟踪的时候，需要注意的是：并非所有的变化都是我们的对策在起作用，有时候可能是市场变化，也可能是客户要求的变化，或者是其他外部环境的变化，让原本的可能性及影响度发生变化。
管理好风险，把项目做出节奏感
风险管理是项目管理的重要组成部分。
作为软件开发的技术人员，通常我们是相信技术的力量的，我们享受解决问题所带来的成就感。对于企业或者组织来讲，团队成员的这种成就感是最“物美价廉”的激励，它能够让项目成功的同时，让每个人都很快乐，让队伍快速成长。
做好风险管理，能够让所有的团队成员清楚的看到，我们在什么时候会面临什么样的挑战，为了以合理的代价达成目的，我们需要在哪些时候、做些什么。
这就好像有一个看不见的敌人，在我们的路上设置了一个又一个地雷，不怀好意的等着看我们被炸得鸡飞狗跳、气急败坏。哪知我们早有准备，虽然紧张但却兴奋地一个一个干掉它！我们跳跃着、踩着既定的节奏，到达了目的地！我们甚至可以轻松的回过头说，虽然有点儿麻烦，但只是小case。
“我喜欢我的同伴们，他们是一群很棒的人，我们谈得来，技术上的事儿我们总能一起找到办法。”
“但是项目是另外一回事儿，有时候真的让人很恼火，我们团队只有3个人，却干着6个人的活儿！”
“我们只有1台调试机，几个团队都要用，每天因为争用调试机打架。”
“忙死了，还要带一帮新人干活，他们什么都不会，光添乱！他们要是早一点儿来我还有时间带他们，现在？算了，我还是加班自己来吧。”
“早干嘛去了，这时候才说要改架构，我们开发都进行一半了！”
“这活儿真没法儿干，客户干嘛总是来指手画脚啊，打乱我们的计划了。”
“我在公司接受了3个月的培训，现在正式加入这个项目了。项目很大，任务很重，据说对公司的前途至关重要，我很兴奋。前辈们很有经验，也很忙，我也想做点儿什么，但是他们好像不太欢迎我加入，有点儿沮丧”。
如果你是一名软件开发者（或任何需要团队合作的工作参与者），上面的话是不是感觉很熟悉？每个人都有干劲儿，大家目标也一致，但是总是有这样那样的问题使我们无法专注于自己的“本职”工作。
问题，问题，那么多的问题！虽然说解决难题能带来成就感，但是相信我，当意料之外的问题组团出现的时候，它们带来的只能是混乱！更糟糕的是，火气、丧气、疲惫感也一起来凑热闹。对于项目，尤其是大项目来讲，这可不是个好现象。
好吧，让我们静下来，想一想，那些问题在成为问题之前，我们真的一点儿都没预料过么？如果能预料的话，是否能够提前做些什么来避免，或者减轻问题的破坏力？退一步讲，最起码让人喘口气，问题别一起出现！要达到上述目的，用一个术语化的说法，就是进行“风险管理”。
通俗的说，风险就是“问题发生的可能性”。所谓问题，就是之前我们提到的各种各样的不希望发生的“闹心事儿”。
风险管理的主要任务是：在问题发生之前，识别它、评估它、做对策，降低其发生的可能性和发生时的危害程度；然后，在对策的实施过程中，进行定期跟踪、再评估、调整对策，以确保问题是可控的，直到安全解决。
风险管理
综上所述，风险管理主要体现在下面几方面：
● 风险识别：找到可能发生问题的地方
● 风险评估：是哪类问题、发生的可能性、发生后的影响度以及危险等级
● 风险对策：什么时间、做哪些工作、能降低风险发生的可能性还是发生后的影响
● 风险跟踪：可能性的变化、影响度的变化、危险等级的变化、风险对策是否需要调整、是否引起新的风险等等
风险管理是软件项目整个生命周期中的常规工作。在项目策划、项目范围变更、项目计划变更、定期项目跟踪时，都要进行风险管理。
风险识别
在软件开发项目中，要识别风险，一个基本方法是“模拟法”——用现有的人员、技术、资源（设备、能够得到的支持等），在项目开始的时点上，审视现有流程上的每一个步骤，思考并预测将会遇到什么问题。这项工作将使我们得到一份风险描述的列表。
对风险列表中的风险进行“合并同类项”处理，尤其是当一个项目涉及到多个团队、较多人，不同的团队和个人提出与他们相关的风险的时候，这种“合并同类项”的处理就显得尤为重要。它可以保证资源的统一调配，最大限度复用，避免各自为政造成的浪费。
风险评估
对风险进行深入的评价，主要分析风险的种类、可能性和影响。
● 风险的种类
一般来讲，所有的风险都可以归结到软件项目的几个要素上去。现在，我们首先来提取这些要素。
什么是项目？通俗的讲就是：在特定的时间内、特定的成本下、完成特定的工作，成果物要质量达标，令用户满意。所以说，项目有下面几个关键的维度：
○ 进度：在什么时间完成
○ 成本：花费多少代价
○ 范围：做什么，做到什么程度
○ 质量：成果物的质量属性（例如千行代码bug数、安全运行天数）
○ 客户满意度：令客户满意
所谓风险的种类，在软件项目中，通常指上述维度的某一个。当然，从市场及企业经营的级别来看，会有另外一套关于种类的定义标准，这里不做深入讨论。
● 可能性：这个风险演变成问题的可能性有多少
● 影响：这个风险演变成问题的话，其破坏力有多大
● 风险级别：根据风险演变成问题的可能性和影响度，形成各风险评级。风险级别越高，越应该得到管理者的重视
下表列举了风险评级的方法(表1)：
首先，量化描述可能性及影响度，然后把风险放到矩阵中的相应位置上，最后根据风险所处的区域，判断是S、A、B、C的哪一个级别。
S级：影响大、发生的可能性大。这样的风险必须进行处理，一定要制定对策降低风险或者规避风险。
A级：影响度在中等程度以上，发生的可能性比较大，或者影响度虽然小，但是发生可能性很高。这样的风险也应该进行处理，制定相应的对策来降低或者规避风险。
B级：影响大，但是发生概率很低。这样的风险不应该消耗太多的管理成本，不必专门制定对策，只需做定期跟踪。
C级：影响小且发生概率低。这样的风险可以暂时不纳入管理体系。
需要注意的是，不同的领域、不同的项目，对风险的影响度和发生可能性的量化标准是不一样的。对风险的容忍度，也就是SABC的判定标准也是不一样的。例如：同样是“发生几率为万分之一的‘死机’”这样的风险。在某些日用消费品中，是完全可以接受的，可以列为C级风险，不予关注。但是在航天项目中，则是绝对不能容忍的，必须以S级来处理。
所以说，任何一个项目都需要为自己量身定做风险判断基准。甚至需要在项目外、组织级进行定义。在组织级定义项目风险判断基准的好处是：同一个组织内，为风险制定统一的量化标准，则不同项目的风险之间具有可比性，为管理和决策提供依据。
因为风险评估对后期的决策有很重要的影响，所以，为慎重起见，有些评估会经与相关人员一起进行几轮的讨论，才能最后确定下来。
风险对策
根据风险评估中得出的风险级别，优先处理S、A级别的风险，并为每一个风险制定专门的对策。
在制定风险对策的时候，我们会发现，风险是可以“转移”的。不同的风险，根据对策的不同可能在属性上有所转移，可能对原有的风险造成影响，也可能会带来新的风险。
下表是对一个风险的识别、评估和对策(表2):
上述对策会降低原有的风险，但是同时会增加一个新的风险，如下(表3)所示：
上述对策就是一个典型的用“成本”换“日程”的例子。如果对策获得认可，就会对开发计划等其他方面造成影响，所有受到影响的部分，在分析影响范围的时候，也要再次回顾已经识别的风险是否会因为这个变化而变化。
在为风险制定对策的时候，需要掌握一个原则：控制风险水平、分散重大风险。
每一个风险都是一个不确定因素，是定时炸弹，尽量不要把太多的炸弹尤其是大炸弹集中在一个阶段解决。分散处理的话，万一问题爆发，控制起来也相对容易一些。
多数情况下风险的对策都不是唯一的，虽然对策本身可能也会带来风险，但是要尽量均衡的考虑对策本身对项目的影响。尽量让项目总的风险水平处于平稳，避免过大的波峰。
如图1所示，文章开头所述的一团糟的情况，可能就是对风险没有事先的管理和干预，导致集中爆发或者风险过高，从而给项目整体带来不良的影响。更糟糕的是，打一场没有准备的仗，我们输掉战争的同时也输掉了士气和信心。
如果有事先的管理和干预，项目的风险将会被控制在一个相对稳定的水平，管理起来会容易很多，如图表2所示。即使最后问题还是发生了，但是最起码之前大家对此有预期，知道会发生什么，对团队情绪方面的影响也会小很多。(图1、2)
风险跟踪
我们为项目识别了风险，评估了风险的级别，为重要风险制定了对策，在这些工作之后，还需要对风险进行跟踪。
一般在项目进行周报、月报的时候，要同时进行风险的跟踪和报告。
对风险的跟踪主要集中在以下几个方面：
● 对策跟踪：对策是否按照计划实施了，实施过程中是否有新的风险出现（这里又是一个风险识别的过程）
● 可能性：随着时间的推移或对策的实施，这个风险演变成问题的可能性有什么变化
● 影响：随着时间的推移或对策的实施，这个风险演变成问题的话，问题的破坏力有多大
● 级别：随着可能性和影响的变化，级别也会随之变化
● 风险状态：如果风险级别已经变得很低，不需要再继续处理的话，则关闭这个风险，以后不再跟踪
● 调整风险对策：判断是否需要调整对策方案，如何调整——调整的过程又涉及到新的风险识别活动
在进行风险跟踪的时候，需要注意的是：并非所有的变化都是我们的对策在起作用，有时候可能是市场变化，也可能是客户要求的变化，或者是其他外部环境的变化，让原本的可能性及影响度发生变化。
管理好风险，把项目做出节奏感
风险管理是项目管理的重要组成部分。
作为软件开发的技术人员，通常我们是相信技术的力量的，我们享受解决问题所带来的成就感。对于企业或者组织来讲，团队成员的这种成就感是最“物美价廉”的激励，它能够让项目成功的同时，让每个人都很快乐，让队伍快速成长。
做好风险管理，能够让所有的团队成员清楚的看到，我们在什么时候会面临什么样的挑战，为了以合理的代价达成目的，我们需要在哪些时候、做些什么。
这就好像有一个看不见的敌人，在我们的路上设置了一个又一个地雷，不怀好意的等着看我们被炸得鸡飞狗跳、气急败坏。哪知我们早有准备，虽然紧张但却兴奋地一个一个干掉它！我们跳跃着、踩着既定的节奏，到达了目的地！我们甚至可以轻松的回过头说，虽然有点儿麻烦，但只是小case。