[与熊共舞]_2_风险发现

摘抄自：与熊共舞-软件项目风险管理（Tom DeMarco、Timothy Lister著，熊节、马姗姗 译）

风险发现过程不应该只在项目启动时进行一次，必须尽量保证它成为项目回顾中不断延续的一部分。在每次风险发现会议开始时，必须正式说明将要采用的步骤，这样就能有效地消除不成文规定的影响。

一般来说，这三个步骤应该在同一次会议上进行。但是，每个步骤的技巧是独立的，所以值得挨个详细的介绍它们：

1. 灾难头脑风暴（指有计划的集体想象活动）：
   1. #记录所有的意见，一定不要让主持人来负责记录，因为风暴是猛烈而且迅速的，必须认真记录。
   2. 以噩梦的形式指明问题：这种做法在某种程度上也有助于消除不成文的规定的影响。询问所有人，对于这个项目，他们最担心的是什么。如果他们会满头大汗的从梦中惊醒，梦中的情景会是什么？
   3. 使用水晶球：如果突然你在能预见未来的水晶球中看到了项目的失败，或者看到你的项目在未来成为最白痴的项目，问问自己：怎么会变成这样那，是什么导致的项目失败？
   4. 转化角度：请大家描述他们对项目最美好的梦想，然后将这些美梦全都反过来，然后大家讨论“是什么让美梦不能成真”，
   5. 寻找不能被责备的灾难：如果没有谁做错事情，项目因为什么而失败？
   6. 寻找应该被责备的失败：询问每一个人，“项目会因为什么而变得面目全非？”。那些可能的原因是我们的责任？那些是用户的责任？那些是管理层的责任？那些是你本人的责任？（只有当所有人都在场，这一花招才有效。）
   7. 设想部分失败：考虑是否有这种可能：项目整体上获得成功，但是某一方特别不满甚至是愤怒。
2. 情景构造：
   1. 面对每个灾难，想想它可能在那种或者哪几种情况下出现。
   2. 有必要--至少是试探性地--估算每种情景出现的可能性。显然，出现可能性极小的情景没有什么价值。但是对于被发现为可能性很低的情景，仍然需要保持警惕：既然有人提出来，那么它--至少对于提出它的人来说--或许并不是微不足道的。
   3. 可以不必再会议上进行，而是由一小组人在稍后进行，这样可以更多的参考经验数据，以判断某个情景是否值得担心。
3. 根源分析：
   1. 现在，可能引发灾难的情景已经摆在你们面前，大家可以一起来找出诱发这些情景的根源了。当这些情景还没有真正出现时，这项工作会容易的多。如果所有这些情景都还只是想像--只是一些可能发生的蠢事--人们就可以大胆地推想他们的原因，并毫不顾忌地用指责的语气说：“我无法想像这种事情发生，除非是哪个白痴在到处放火”，如果灾难还没有发生，这些话会比较容易说出口---哪怕可能成为白痴的人也在同一个房间里。
   2. 对于可能引发灾难性后果的情景，它们的根源就是你需要管理的风险。
   3. 根据分析并不像乍看上去那么轻松。这不仅因为不成文规定的影响，更因为“根源”本来就是一个复杂的概念（到哪里才算是找到根源了？）。这个过程最好是由一组人一起进行。

双赢的选择：

1. 按照双赢理论，项目应该预先找出所有参与者，并要求每个参与者描述所谓的“赢状态”--在他/她看来项目成功的标志。在这种方法论中，项目的需求是以一系列的“赢状态”来描述的。如果一件事没有成功为任何人“赢状态”的一部分，它就不是一向需求。有时--特别是在参与者较多时候--“赢状态”之间会有所冲突，一方的“赢状态”可能给别人的“赢状态”带来了困难，甚至使后者根本无法实现。按照双赢理论，一对彼此冲突或彼此钳制的“赢状态”就代表一项风险。利用这个技巧，你也许会发现用其他方法发现不了的风险。