在软件开发过程中，经常忽略的一个因素——风险。风险是一把双刃剑，因为风险的另一面就是价值，我们不能因为它的负面影响避而不谈。 与熊共舞：软件项目风险管理 就围绕着风险这个东西展开阐述。

此书作者是一个实践家而不是思想家。在文中他指出了为什么风险管理会给忽略，跟着谈了如何做合理的风险管理。我认为，在现实的环境中，影响风险最关键的还是人，因此作者在序编里面就引用了英国以为思想家William K. Clifford的论文《信仰的论理学》，这篇论文的确提高了此书的思想深度。看到后面，经过反思才觉得这篇论文才最能说明关于风险的问题。一切都是人左右风险，试想一下如果所有人都有风险的意识，那还担心用什么方法去管理吗？所以此书只是风险管理的操作手册，是术，非道！

开宗明义，先定义风险的概念。本书对风险的定义是：（1）未来可能发生的某一事件，该事件将导致不好的结果；（2）不好的结果本身。

我比较喜欢是本书的目录结构，让我们来看看。
第一篇 为什么要进行风险管理？
第二篇 为什么不进行风险管理？（如果向一个尚未做好准备的企业引入风险管理机制，可能产生一些潜在的副作用。）
第三篇 如何进行风险管理？
第四篇 我们的企业甘冒多大风险？
第五篇 如何知道我们的风险管理机制是否有效？

如果没有第二篇，就是一份中规中矩的文章结构。第二篇对于我来说是挺新颖的，一本提倡使用风险管理的书去论述为什么不要使用风险管理，的确是很不错的逆向思维。

本篇中一些反对风险管理的理由：
1。顾客还没有成熟到坦然面对风险的地步。
2。不确定性的范围太广了。
3。不确定性的范围会成为低效的借口。
风险管理告诉：目标只是用于激励员工拿出最高的工作效率；与此同时，在向顾客和管理层作出承诺时，你还需要一个与目标迥然不同的估算计划。
4。“成功管理”时更好的管理方法。
5。缺乏有效实施风险管理所需的数据。
6。孤立的风险管理是危险的。
无论如何，如果一位项目经理的四周充斥着“我能做到”的声音，风险管理对于它是毫无意义的。即使企业没有广泛实施风险管理，你仍然可以在项目中使用风险管理的一些工具和技术，但不要把自己的发现公诸于众。可悲，但现实却是如此！

在最糟糕的企业里，曲突徙薪的建议会遭到惩罚，引火烧身者却不会。

第十一章：风险：描绘所有可能结果及由其引发的相关后果的加权图。

风险管理告诉你：目标只是用于激励员工拿出最高的工作效率；与此同时，在向顾客和管理层做出承诺时，你还需要一个与目标迥然不同的估算计划。

出现偏向某一侧的图形的原因是人们的工作效率也倾向于类似的形状：快速完成任务时，人们容易集中精力；时间拖得越长，工作效率也越低。

第一类风险称为总风险，因为他们将项目作为一个整体看待；第二类风险则成为肇因风险或者成分风险。两者是紧密相关的。总体结果的不确定性是各方面不确定性的直接结果，若干部分的共同作用决定了项目整体的成败。

通过估算器产生的生产模型和风险模型结合就成为了一个总风险模型。

下面是书中一些章节精彩内容的摘录。

第十三章 软件项目的核心风险

5种核心风险：
1。进度安排的先天错误；
2。需求膨胀（需求变化）；
3。人员流式；
4。规约崩溃；
5。低生产率。

其中，只有最后一线是真正与效率相关的，其余4项几乎与你工作的努力程度、你的天分和能力完全无关。之所以强调这一点，是因为有些管理者担心风险管理变成低效率的借口。预先为这些不确定因素做充分准备，正是风险管理的核心。这种预留的空间不是让你为自己的失败开脱；它只是一种储备，只有当某些不确定因素变成实实在在的问题时才能动用。

进度安排错误：
如果没有认真地估算产品的规模，那么你预计的进度就是空中楼阁。如果管理者提出或者接受一个存在严重问题的日程安排，证明他的工作绩效很有问题。应该牢记：项目的超期不应归咎于开发者的低效率。实际上，整个开发团队很可能已经发挥出了最高的工作效率——出了管理者之外。

需求膨胀：
“击中移动的目标”是所有人的问题。打算完全按照现在的要求交付产品，而不允许任何变动，这无异于刻舟求剑。
更合理的逻辑应该是这样的：“你说你想要X；经验告诉我们，在开发过程中需求可能会有些变化，到最后你想要的东西可能跟X稍微有点不同。所以，我们将针对X指定计划，并且允许一定限度的改变。”
限度有多大？按照上世纪90年代中期，美国国防部提出了一组关于运转良好的项目应有的行为方式的量化数据。他们的定量分析结果是：合理的需求变更应该在每月1％以下。如果你的项目有20，000个功能点，为期2年，你就准备完成25000个功能点。（20000×（1.00+24×1％） ＝ 25000）。

人员流失：
要估算人员流式的风险，需要提供下列信息：
◆你公司里技术人员的年平均流动率；
◆对于新进员工的“上手时间”，你最乐观的估计。

过去，我们总是不由自主地建设开发者都是可以随便替换的，新员工马上就可以取代离去的老员工……多么愚蠢的假设。

规约崩溃：
这种与其他不同，它是离散而非连续的。它的结果只有两种：要么发生，要么不发生。
被掩盖的问题一时不会来打扰你，但不是永远。尽管你可以含混地说明一个产品，却不可能含混地构造一个产品。

低效率：
大量的文献资料表明，开发者之间的工作效率存在着相当大的差异。然而，把项目团队作为一个整体来考察时，这种差异将在某种程度上被弱化。
这项因素的影响倾向于相对平衡，像这样趋于平衡的风险只会引入噪音：它会扩大不确定性的范围，却不会使期望结果显著地朝任何一个方向移动。

第十四章 风险发现的详细过程

有时，企业文化会使得我们根本不可能谈论任何真正能够造成麻烦的风险——我们就像愚昧无知的部落原是人一样，以为只要不说出魔鬼的名字就不会招来魔鬼。
在工作中，我们都被迫保持“我能做到”的心态，这也是障碍所在。说出一项风险，就等于一次“我做不到”的表态。风险管理与传统企业文化一些根本的方面有着深刻的冲突。
由于障碍强大，我需要一个开发、固定并得到充分理解的过程，这样员工才有可能开口说出风险的存在。
通过三个倒退的步骤来识别风险。
灾难性后果－》情景－》根源
风险发现过程不应该只在项目启动时进行一次，必须尽量保证它成为项目回顾中不断延续的一部分。
一般来说，这三个步骤应该在同一次会议上进行。但是，每个步骤的技巧是独立的。

第一步，灾难头脑风暴
所谓头脑风暴，是指有计划的集体想象活动：群策群力，发挥集体的创造性，使新的思想得以浮现。
“头脑风暴之父”的经典作品：de Bono, Edward. Lateral Thinking: Creativity Step by Step. New York: Perennial, Harper & Row, 1990.
头脑风暴得用一些小手段来帮助人们度过不可避免的思维短路。
1。以噩梦的形式指明问题：询问所有人，对于这个项目，他们最担心的是什么。如果他们会满身冷汗地从梦中惊醒，梦中的情景会是什么？
2。使用水晶球：假设你拥有一个能够预知未来的水晶球。
3。转换视角：请大家描述他们对项目最好的梦想，然后把这些美梦全都反过来，大家一齐讨论“是什么使美梦不能成真”。
4。寻找不应被责备的灾难。
5。寻找应该被责备的失败，只有当所有相关的人都在场时，这招才有用。
6。设想部分失败。
头脑风暴是快速而猛烈的，所以你应该安排至少一个人来记录所有的意见。一定不要让主持人来负责记录。

第二步，情景构造
根据记录下来的灾难，想想它可能在哪种或者哪几种情景下出现。

第三步，根源分析
根源分析最好由一组人进行。事实上根源分析并不像乍看上去那么轻松。因为“根源”本来就是一个复杂的概念（到哪里才算是找到根源了？）。
有几本经典著作分析了根源这个问题。
Andersen, Bjorn,ed.Root Cause Analysis:Simplified Tools and Techniques. Milwaukee:American Society for Quality,1999.
Gano, Dean. Apollo Root Cause Analysis:A New Way of Thinking, ed. Vicki E. Lee. Yakima, Wash.: Apollonian Publications, 1999.