翻翻自己收藏的电子书，突然发现有这么一本居然还没碰过。书名是《ADDISON WESLEY -Software Project Management in Practice》。大体上看了一下，相当不错。从今天开始先读点感兴趣的--风险控制。

1、风险的定义。

风险就是一些事件或者状况，它们有可能在你的项目的进程中发生，也有可能不发生，一旦发生，会给项目带来严重的不良影响。不要把风险和那些需要在项目中通过管理的途径施加干预的事情相混淆。一个项目经理必须对一些事情进行处理或作出计划，但是它们本质上是不可预知的，这不能算是风险。举个例子，我们都知道软件产品总是会有漏洞，所以必须制定计划来修复它们。类似的，需求的变更总是会发生，所以项目管理需要为这些变更作出准备。这些我们都只是作为普通的事情对待，他们算不上风险。

风险，从另外一个方面来说，是一个很“模糊”的事情--也可能发生，也可能不发生。鉴于此，我们总是理想的认为或者说希望它们不会发生。社会因素和组织因素也常常起到蒙蔽它们的作用。在风险真正到来的时候，往往就是这种态度或认识让项目陷入万劫不复的境地，大的项目尤为如此。不要吃惊，在那些大型项目的管理中，风险管理总是一个好的管理实践的第一步。

风险管理的目标就是看到那些风险，然后让它们对项目的影响达到最小化。风险管理在项目管理中算是一个较新的领域。第一个引入它的是Boehm's tutorial on risk management。从那开始，已经诞生了一批图书来讲有关风险控制的理论。

在我们开始深入讨论风险这个话题之前，让我们再来一个小例子，回味一下风险的有关概念。假想有一台电脑需要一刻不停的提供一个服务。在这个前提下，首先可以想到的一个风险就是--停电。可能会断电，也可能不会。如果确实停电了，即使是一秒，这个服务也会从中“受益匪浅”（重启，数据丢失等等）。如果后果是不可接受的，你就需要一台UPS来进行持续供电，尽可能的减少这种情况的出现带来的损失。如果停电时间还会再长，那你可能需要考虑数据备份的一些问题。当一切风险控制手段到位的时候，即便是停电，甚至停很长时间，也不会对你的系统目标产生多少危害。

从上面这个例子我们看到了什么？

要想管理好风险，就需要额外的投入（UPS等等）。因此只有当为了管理风险而作出的投入低于风险所带来的损失的时候，才应该去考虑它。

管理风险所带来的价值往往难以估算，除非在风险真的发生之后。但这是由风险本身的特性所决定的。不能因为现在还没有带来“价值”而否定风险控制的重要性。

管理风险的第一步就是找出所有可能的风险。一旦你进行了风险预估，你就可以做风险管理计划了。总之，风险的管理包含两个关键点：风险的预估，风险的控制。每一步你都有很多事情去做。如下图：

风险预估，首先需要发现风险，然后分析它们，再为它们排定优先级。在排定优先级的过程中，你找到那些确实需要进行管理的风险。换句话说，优先级的排定过程确定了你能够从你对那些风险的管理中获取最大的收益。在这个过程中，有两点很重要。首先是风险发生的机率；越有可能发生的风险，越要优先考虑。其次是风险的影响；影响越大的风险越要优先考虑。

一种排定优先顺序的方法就是考虑一个风险的发生以及它的后果。后果就是预期的风险所带来的损失。如果我们把风险发生的可能性用Prob(R)来代替，把风险的预期损失用Loss(R)代替，那么风险的曝光量RE(R)可以用下面的等式计算：

RE(R)=Prob(R)*Loss(R)

一旦风险的优先级排定好了，你就该考虑该为它们做点什么了。到底要对哪些风险进行管理，就看你的决策了。这个决定有可能只针对风险列表中处于最顶端的几个风险。

你有可能采取预防或避免之类的做法来对付这些风险。比如如果一个新规格的硬件有可能会引发风险，那么就去采用那些经过实地应用验证万无一失的硬件来替代。当然，这些措施并不是任何时候都合适的--比如，万一你的用户就认那个新硬件呢。在这种情况下，一定要采取合适的手段来控制风险。

对于你选中的每一个风险，你都必须拟定计划来进行管理。风险感是会随着时间变化的，你必须同时监控风险和你的控制风险的计划，进而最小化风险的后果所带来的损失。在一个项目进程中，风险感和风险管理的效果是此消彼长的。因而应该对风险及其管理作出量度。

风险管理可以集成到开发进程中来，就像螺旋式软件开发那样去做。你也可以把风险管理作为一个独立的进程对待，这样你就必须同时理解风险管理与项目的执行之间的关系，如下图所述：

从项目进程中获取风险的评估信息和风险的监控信息，同时还要考虑其他一些因素，进而找出需要进行管理的风险。风险管理活动，从另一方面又对项目施加影响，以降低风险的后果所带来的损失。