【IT168 技术文章】 然后要说的是风险管理。
“风险”这个词很好懂，但不容易精确定义，主要麻烦是它和“问题”之间的关系。简单地说，风险是未发生的问题。这包含两点：
1. 风险中所描述的事情现在还不是问题。
2. 如果不加处理，风险会转化成问题。
比方说，彗星撞地球，使得项目无法继续进行（默哀……），这是一个风险；配置库遭到损坏，导致以前的配置信息丢失，这也是一个风险；而下星期一我要上课不能来，这是一件确定的事情，那就是问题了。当然，大家也有反驳说，如果课程临时取消怎么办，没发生的就不能断定嘛。是的，我承认我说的不严谨，其实这样定义更好：问题是已发生或发生概率极大的风险。
风险会转化成问题，也可能会消失，它消失的原因可能有以下几条：
1. 项目结束，所有风险消失。
2. 由于措施得当，风险被规避。
3. 风险变成问题的必要条件消失，所以风险消失。
比如3月份我可能很忙，导致投入项目时间不足，但如果3月份已经过去，那么风险自然消失。又比如项目资金可能发生困难，但是由于来了一大笔钱，风险也自然消失。
尽管风险确实可能消失，但我们不能够通过虔诚地祈祷来让风险消失，我们需要认真面对这些事情，想出规避的策略。不过，并不是所有风险都需要跟踪，要根据某种原则进行选择（要不然我得每天跑天文台，问他们会不会有流星砸中我们）。这个原则就是风险发生的代价和规避风险的成本的比值必须大于1。
风险的代价一般用风险发生的概率和风险造成的损失的乘积来衡量，而规避风险的成本则是实际的成本估计。例如前面说的彗星撞地球的问题，损失很大，概率极小，而规避成本极大，所以这个比值肯定小于1，于是我们不予理会（听天由命吧）。而配置库的问题则是损失很大，概率比较小，规避成本比较小，比值应该远大于1，所以我们应该好好考虑一下。不过，好像我又不严谨了，就算是严密跟踪风险，有些风险还是要变成问题，所以实际中我们考虑的是规避措施带来的效益和规避风险的成本之间的比值必须大于1，这个效益也就是最可能减少的损失。
理论上来说，我们应该试图跟踪每一个比值大于1的风险，不过实际中我们要讲究一个度，毕竟“提交可以使用的软件”才是我们的最终目标。按一般的经验，我们只关注值得跟踪的风险中代价最大的5～10个，这个根据项目不同而不同。
好了，理论聊了一大堆，实际上我们应该怎么做呢？
为了跟踪风险，我们需要开一个“风险管理会议”来找出所有感兴趣的风险。在这个会议中，大家首先各自用五分钟沉思，想想项目中有哪些风险（这是头脑风暴法的一种形式），并在纸上写下5个自认为值得跟踪而且代价最大的风险（“5”这个数也只是一个经验值，可根据实际情况进行改变），这个步骤叫做发现风险。五分钟后，大家将纸条贴在白板上，会议进入第二步，标识风险。详细分析风险之前，先去掉那些不是风险、不值得跟踪的风险，这是大家都得发表意见的环节。之后，为所有留下的风险按照风险发生的概率和风险造成的损失的乘积排序。为什么不按照规避措施带来的效益排序呢？因为我们还没有制定规避措施，为了简化问题，我们就用这个乘积，这也就是为什么会有第一个不严谨定义的缘故。找出乘积最大的5个风险，这里的“5”也是一个经验值。好了，到了最后也是最重要的时候，我们要开始分析风险。分析风险包括为风险制定详细的规避措施，并估计规避成本、万一风险变成问题后如何解决问题、指定跟踪的负责人、确定开始跟踪风险的日期等，这些分析是由大家群策群力来完成，力求措施既有用又有效。
比如，关于配置库的风险，我们最终是这么分析的：
风险编号：3（仅仅是一个编号，编号的规则可以根据实际情况来定）
开始日期：2月20日
跟踪人：chanjinn（我还没有介绍组里面每个同学的情况呢，尽快补上）
风险描述：配置库可能因为种种原因损坏，导致开发资料丢失。
发生概率：中（有一定的可能性，不算大也不算小）
造成损失：高（我们都比较心疼这些资料）
规避措施：每日备份VSS数据库，并用邮件把备份发给项目组每位同学（我们的配置库比较小，所以这样做没有问题）
解决方法：恢复最近的VSS备份，并尽量收集最近的资料。
分析完毕后，我们将这些风险一个一个抄在便条纸上，并贴在白板上，在便条纸上还有些其它的内容需要预先留着：
关闭日期：如果风险消失，或者变成问题，那么我们就无需继续风险，于是可以将风险关闭。
执行结果：风险关闭时，关闭的原因和最终的执行结果。
OK，这个会议完成。花了不少时间呢，居然前前后后有一个半小时！以后分析风险不能这么慢了，要不然谁还敢做风险的管理。那么以后应该如何更新风险呢？最建议的做法是在每日会议上，每个跟踪人都应该关注自己跟踪的风险，并且及时提出风险跟踪过程中遇到的问题，包括跟踪成本超出预算、风险发生变化、发现新的跟踪方法等，然后至少每周做一次简单的风险管理会议。不过一定要注意，以后的风险管理会议就不需要这么冗繁，直接把三步一次完成就行，时间也是一种成本！
参考文献：
[1] Tom DeMarco，Timothy Lister，与熊共舞：软件项目风险管理，清华大学出版社，2004.3
