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

此书作者是一个实践家而不是思想家。在文中他指出了为什么风险管理会给忽略，跟着谈了如何做合理的风险管理。我认为，在现实的环境中，影响风险最关键的还是人，因此作者在序编里面就引用了英国以为思想家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.

双赢的选择

Barry Boehm的双赢螺旋过程模型融合了众多优秀的成果，它结合了

◆螺旋开发生命周期

◆度量方法（特别是COCOMO II）

◆风险管理

◆团队交流的“W理论”

按照双赢理论，项目应该预先找出所有参与者，并要求每个参与者描述所谓的“赢状态”——在他/她看来项目成功的标志。

一队彼此冲突或者彼此钳制的“赢状态”就代表一项风险。

更多的双赢开发模型信息可以参考

第十五章 风险管理动力学

项目通常是在进行到中间时开始偏离航线，那时才是最需要风险管理的时候。问题的肇因总是在那之前出现，但真正发现问题一定实在项目中间，这个阶段称为项目的“报应期”。

第十六章 增量式开发与风险缓解

风险缓解进行投入/产出比分析：风险缓解本身的成本是投入，可能发生的风险因为风险缓解措施的存在而减轻损失的加权估算值是产出。

增量交付计划是由另外三件项目产品共同构成的：

设计蓝图：由于展示需要实现的最低层次的模块和类，以及其间关系的图表。

工作细分结构（WBS）：描述需要完成的任务及其彼此依赖关系的网络。

版本验收测试计划：描述各个版本的产品可以接受哪些测试。 

需要为增量交付计划和与其相关的项目产品加上两条限制。首先，对于横跨多个版本的任务，增量方法允许他们之间有一定的时间重叠。第二，设计蓝图必须展现设计划分的全貌，必须详细到最低的级别。

EVR（earned value running）挣值运行。挣值是用于度量“项目某一特定子集的预期成本”的标准。

第十七章 风险化解的中级策略

即便你做不到，提前开始仍然重要

勇敢的管理和怯懦的管理。毫不犹豫地开始一个项目是勇敢的象征；与此相反，犹豫不决则是怯懦的象征。项目开始得太晚则意味这最高层的管理者缺乏眼光和勇气。

第十八章 价值量化

成本和收益应该在同一精度上指定。

不认真做收益预测和实际收益评估的企业还常常会使用这样一条理由：收益极少，甚至根本不存在。我们有一条通用的经验法则：如果收益根本没有被量化，就当它不存在。

收益计算的五步骤

◆在开发者说明预期成本和日程安排的同时，客户说明预期收益，两者应有相同的精度。

◆在开发者指明成本和日程计算不确定性的同时，客户以相同的方式指明收益预测中的不确定性。

◆客户估算系统各组成部分的相对价值，为版本选择、敏感性分析和增量成本收益提供基础。

◆管理者比较成本和收益，并考虑个子的不确定性，对项目做出综合评估。

◆项目完成后，管理者核算实际收益，并将核算结果输入事后分析过程。

第十九章 价值，另一个不确定性

对于主要目标是提高市场竞争力（而非降低工作成本）的系统来说，收益的确有相当大的不确定性。

如果你听到自己在说“我不知道”，就应该马上切换到不确定性模式，开始画不确定性图。

系统的构建者和客户应该承担对等的责任：构建者保证交付系统，客户保证系统能提供足够的价值。

第二十章 敏感性分析

有必要由系统使用者和客户承担价值估算和十驾价值度量的责任，但是你不能强迫客户承担这份责任，所以必须软硬兼施，威逼利诱。

在项目的尺度方面，系统项目表现出违反经济学的特征：如果将系统的尺度扩大一倍，需要增加的工作量将超过一倍。既然加大产品尺度意味着需要增加更多的成本，那么缩小产品尺度就能够带来更大程度的节省。

目前，开发者还很少意识到“开发更少的软件”理应成为他们的口头禅。

第二十一章  价值对风险的补偿

对于一个给定的项目，我们愿意承担多大程度的风险？答案便是项目所能提供的潜在价值。

死亡之旅项目，人们总是会强调项目的重要性：这项工作极其重要，它需要员工付出最大的努力。但是这句话难以自圆其说：既然这个项目是如此重要，为什么公司不能投入更多的时间和金钱来好好完成它呢？

死亡之旅的共同特征：

一、预期价值偏低。项目的价值太低，以致于普通的方法毫无疑问将导致收不抵支。

二、项目成员之所以甘愿舍弃私人生活，是因为他们相信这样做有利于公司。

三、它们几乎无一例外地以惨败告终。

第二十二章  改进风险管理处方

风险管理就是执行下列步骤，并将其贯穿项目的全过程。

1。通过风险发现过程调查出项目面临的风险。

2。确认软件项目所有的核心风险都已出现在你的调查结果中。

3。针对没想风险，完成下列“家庭作业”

 为风险命名，并提供一个唯一的编号；

 通过头脑风暴找出这项风险的转换指标——风险具现的所有征兆中最早出现的那个；

 估算风险一旦发生可能对成本和进度造成的影响；

 估算风险具现的可能性；

 计算风险的日程和预算暴露值；

 判断如果风险开始转化，需要采取哪些应急措施；

 判断需要在风险转化之前采取哪些缓解措施才能保证应急措施不致失效。

 将缓解措施列入项目的总体计划；

 将所有细节记入记入一个模板；

4。指出项目的致命风险，将它们列为项目假定。执行风险移交仪式，将它们转交给上级；

5。假设没有任何风险具现，进行第一次日程估算。换句话说，估算的第一个步骤是要找出极小概率点N。

6。将项目参数输入到RISKOLOGY，然后，输入你所能找到的所有自定义因素。尽可能地覆盖模拟器中关于核心风险的业界数据，将它们替换为来自你的环境的更可靠的数据。

7。从此时起，用风险图来描述所有的承诺，明确指出每项预计日期和预算所涉及的不确定性。

8。创建一个工作细分结构（WBS），由于展示完成项目所需的所有任务。估算每项任务所需的工作量。只关心任务工作量的相对权重，而不考虑它们的绝对值。这些相对权重将作为输入条件，用于计算EVR度量值。

9。在项目开始时，必须要求参与各方确定产品的净输入/输出数据流。在整个项目日程安排的前12％～15％时间里，你应该能够得到所有净输入/输出数据流的完整定义。项目各方签字认可这些净数据流，这应该被视为一个重要的项目里程碑。

10。在实现任何功能之前，首先进行详尽的设计划分。将设计划分的结果作为输入条件，创建增量式交付计划。

11。设计划分完成之后，回到工作细分结构，重新估算任务的权重，并以在剩下工作重所占的百分比的形式描述每项任务。

12。估算项目的价值，精度应该于成本估算的精度相当。

13。将项目规约中包含的需求系分到元素级别，按照各需求元素的优先级顺序为它们编号。在评定优先级时，对于用户的净价值和技术风险时两个重要的因素。

14。创建增量交付计划，在其中将整个产品系分为多个版本。所有需求元素都必须被分配给某个版本，优先级越高的需求应该在越早的版本中实现。计算每个版本的EVR，将结果记入增量式交付计划。增量式交付计划应该时项目的重要产品之一。

15。为整个产品创建最终的总体验收测试，然后将其分为多个VAT，每个版本都应该有一个对应的VAT。

16。根据各版本的预期交付日期为它们分配EVR。每当一个版本通过VAT时，在同一幅图中画上实际的EVR值。

17。从项目开始到结束，密切监控所有风险的具现情况或终止情况，一旦风险具现，立即执行应急计划。监控EVR的滑行路线及其与预期路线的吻合程度。如果实际路线与预期发生偏差，很可能是有风险出现了。

18。从项目开始到结束，持续进行风险发现过程，随时发现后续出现的风险。

第二十三章  风险管理的检验

无论是风险管理责任人，或者比这更高的地位的人，必须有一种客观的途径来了解风险管理是否真的得以贯彻。

如果风险管理得到了贯彻，并且成为企业文化的一部分，你的项目应该能够通过下列全部或者大部分检验：

1。有一份风险清单。

2。有一个持续进行的担风险发现过程。

3。不确定性图随处可见。

4。项目既有目标值又有估算值。

5。每项风险都有明确的转化指标，并且有不间断的转化监控机制随时留意发现的具现情况。

6。每项风险都有相应的应急计划和缓解计划。

7。每项风险的暴露值都得到了计算。

8。项目的价值有量化估算，并承诺在项目结束之后度量实际获得的价值。

9。项目计划中至少包含一定程度的增量计划。

如果你的企业能够通过上书检验中的6项以上，你考究可以相信：风险管理已经成为了项目的一部分。

抛开轻率的判断，为企业做一个客观的检验，这是让风险管理为你所用的第一步，也是企业走向成熟的一步。