软件项目管理中的风险管理像是把瑞士军刀，高效全能。它是项目全面管理的一部分，风险管理应该与关键的项目实施过程紧密相连，贯穿项目始终。
风险管理
风险管理工具只是辅助，关键是在项目中要有风险意识。我们习惯于处理问题(issue)，但却疏于应对风险(risk)。关于风险和问题如何区别的讨论，不单在国内，在国外也一直没有定论，在英文两者都是problem。一般认为问题(issue)是已经存在的，而风险(risk)则是一种可能性的度量。它包含着不确定性。
风险的两个要素：1.发生的可能性 2.如果发生所带来的事果的严重程度。
风险管理有一套方法论和工具，识别、定性分析、定量分析、应对，以及监控。咱们推崇实用主义，能解决现实问题就行。
风险管理的难点就是识别，包括区分问题和风险。在一个软件项目有天然的乐观者，也有天然的悲观者。比如测试人员常对开发人员说的:怎么能让我们放心呢？项目中每个涉众对不确定的看法不同、容忍度不同，所以风险识别是必须的管理活动。而管理的目的就是提高风险识别的有效性。
风险识别
在实践中常用开会和访谈的形式来识别风险，效果各不相同。主要有以下可能的问题:
. 识别过程缺少引导。从哪些方面入手？从哪些方向展开？
. 人的因素。 独立性、经验及对待风险的态度不同等。
Dr. Kerzner在他的<<项目管理>>中做出总结。他提到依据风险来源来识别风险，大部分的风险分为主观和客观两类：
1. 客观性风险来源 (经验)
典型的客观性风险来源有:
。 文件记录的经验教训
。 项目评估资料 (QA人员统计和稽核的数据)
。 运营数据
2. 主观性风险来源 (专家经验)
举例来说，常常出现在项目会议，如果开发人员给出一个乐观的评估后，可能有人就会引用之前某个项目的教训。
经验类的风险没有管理好，就会出现项目越做越小心，缓冲时间越拉越长的问题。
由此可见风险识别的方法有:
1. 借签以前的风险管理资料
2. 专家判断 (Delphi法和头脑风暴)
3. 基于WBS或项目任务列表进行分解
4. 基于项目需求中较难实现的部分。
个人觉得实践中由项目列表分解和头脑风暴来识别风险是很有价值的方法，既可以培养团队的风险意识，又可以广泛收集风险项目。收集到足够的风险项目，才能做出来准确的分析，才能给出优先级，保证解决真正的风险。
风险的有效识别常常能为项目带来新的突破口，因为风险总是与机会相对。之前就有被临时安排到一个面临高风险的项目的经历，也全靠风险管理才化险为夷。首先要做的就是重新梳理出现存在的问题和风险(这是两个不同的概念，但是管理时要一起考虑。已经发生的问题并不一定是高优先级事务)，然后分析后识别出最高优先级的风险(红色项目)和次要风险(黄色项目), 再对应设定应对策略。将风险应对活动和现有的开发活动一起评估，定义出高优先事务和必要的人员调整方案。每天Review风险矩阵，按需要再调整风险级别和应对策略。在这样高强度的管理之下，项目风险最终被顺利排除。
前面也提到风险管理是一项全面管理活动，在管理过程一定要有全局思维，一个问题点可能是沟通问题、可能是成本问题、也可能是需求问题、也可能是人事问题，但最终都是项目经理的问题。
转载请注明出处: http://blog.csdn.net/horkychen
