项目风险管理

软件项目管理中的风险管理像是把瑞士军刀，高效全能。它是项目全面管理的一部分，风险管理应该与关键的项目实施过程紧密相连，贯穿项目始终。

风险管理

风险管理工具只是辅助，关键是在项目中要有风险意识。我们习惯于处理问题(issue)，但却疏于应对风险(risk)。关于风险和问题如何区别的讨论，不单在国内，在国外也一直没有定论，在英文两者都是problem。一般认为问题(issue)是已经存在的，而风险(risk)则是一种可能性的度量。它包含着不确定性。

风险的两个要素：1.发生的可能性  2.如果发生所带来的事果的严重程度。

风险管理有一套方法论和工具，识别、定性分析、定量分析、应对，以及监控。咱们推崇实用主义，能解决现实问题就行。

风险管理的难点就是识别，包括区分问题和风险。在一个软件项目有天然的乐观者，也有天然的悲观者。比如测试人员常对开发人员说的:怎么能让我们放心呢？项目中每个涉众对不确定的看法不同、容忍度不同，所以风险识别是必须的管理活动。而管理的目的就是提高风险识别的有效性。

风险识别

在实践中常用开会和访谈的形式来识别风险，效果各不相同。主要有以下可能的问题:

  . 识别过程缺少引导。从哪些方面入手？从哪些方向展开？

  . 人的因素。  独立性、经验及对待风险的态度不同等。

 Dr. Kerzner在他的<<项目管理>>中做出总结。他提到依据风险来源来识别风险，大部分的风险分为主观和客观两类：

  1. 客观性风险来源  (经验) 

  典型的客观性风险来源有: 

     。 文件记录的经验教训

     。 项目评估资料 (QA人员统计和稽核的数据)

     。 运营数据 

  2. 主观性风险来源 (专家经验)

     举例来说，常常出现在项目会议，如果开发人员给出一个乐观的评估后，可能有人就会引用之前某个项目的教训。

     经验类的风险没有管理好，就会出现项目越做越小心，缓冲时间越拉越长的问题。

由此可见风险识别的方法有:

  1. 借签以前的风险管理资料

  2. 专家判断  (Delphi法和头脑风暴)

  3. 基于WBS或项目任务列表进行分解

  4. 基于项目需求中较难实现的部分。

个人觉得实践中由项目列表分解和头脑风暴来识别风险是很有价值的方法，既可以培养团队的风险意识，又可以广泛收集风险项目。收集到足够的风险项目，才能做出来准确的分析，才能给出优先级，保证解决真正的风险。

风险的有效识别常常能为项目带来新的突破口，因为风险总是与机会相对。之前就有被临时安排到一个面临高风险的项目的经历，也全靠风险管理才化险为夷。首先要做的就是重新梳理出现存在的问题和风险(这是两个不同的概念，但是管理时要一起考虑。已经发生的问题并不一定是高优先级事务)，然后分析后识别出最高优先级的风险(红色项目)和次要风险(黄色项目), 再对应设定应对策略。将风险应对活动和现有的开发活动一起评估，定义出高优先事务和必要的人员调整方案。每天Review风险矩阵，按需要再调整风险级别和应对策略。在这样高强度的管理之下，项目风险最终被顺利排除。

前面也提到风险管理是一项全面管理活动，在管理过程一定要有全局思维，一个问题点可能是沟通问题、可能是成本问题、也可能是需求问题、也可能是人事问题，但最终都是项目经理的问题。

如果风险止于发现者则不能称为有风险管理，必须是在规范的流程之下，有计划的采取行动，这才算是风险管理的起步阶段。

1. 培养风险意识(Risk Awareness)

需要在开发的各个阶段，训练团队成员能主动发现出风险，然后报告出来并同相关人员进行沟通。整个过程可能缺少流程定义，还没有约束，但它是团队风险文化建立的起点，也是建立风险管理的基础。

2. 初级风险管理

  从风险意识到采取行动将是很大的突破。可以建立起一个基本风险管理流程：

    

风险管理里的术语很多且不统一，所以需要在组织内部制订一份标准来规范日后的应用。

整个风险的识别到追踪是一个反复的过程且在整个项目过程中不断重复(IAMT循环):

很像是戴明环(PDCA)，思想是相似的。

至于完整的风险管理，正如PMI所定义的风险管理知识领域中所涉及的风险管理方式就是完整的风险管理模式。当然还有其它模型:

另外风险管理分为很多层级，从项目层级到企业层级，这个过程中风险的升级过程也需要定义。

3. 风险的属性

在<<Applied Software Risk Management>>中给出一个风险分类方法，视情况自行定义。

以下是一个关于风险分类的参考:

Atrribute	Class
Origin	Internal
	External
Nature	Business
	Technical
Domain	Project
	Process
	Product
Affected	Hazard
	Constraint
	Nominal
	Trivial
	Cost
Affected PA	Requirement
	Design
	Coding
	Testing
	Training management
	Facilities management
	Quality management
	Project management

*选自<<Applied Software Risk Management>>

4.风险的识别和登记

风险被识别出来后(识别的方法参考: 项目风险管理),需要记录下来以便追踪，其中主要要素如下:

Risk ID:  一个唯一标识

Risk probability: 发生的可能性大小。可以使用数值量化0~1, 1为100%会发生。分成几级视情况而定。有一些材料也称为Likelihood.

Risk impact: 一旦发生影响的大小。也可以使用数值量化。一些材料称为Consequence.

Risk exposure: 这个又称为AEN, 表示风险的级别。其值为probability与impact相乘。

Risk origin: 风险的来源。内部或外部，也可以再细分。

Risk category: 风险的分类。

Risk owner: 这个风险的责任人是谁。

一些人也给出4W1H的定义方法如下:

http://www.noweco.com/risk/riske03.htm

5. 风险的应对计划

在项目层级的风险的应对针对具体风险可以有以下策略:

  a. 有没有合适的回避(avoidance)措施？(如改变设计)

  b. 在还没发生时如何减轻(reduction/mitigation) (如增加单元测试)

  c. 风险是否可以转移(transfer)出去? (如外包或需求变更)

  d. 如果这个风险已经发生了采取什么措施减轻影响(Contingency plan)? (如立刻更改使用的库)

针对已识别的风险制定应对计划、安排责任人，指定时间，这些构成风险管理核心表格。

6. 风险追踪

  风险需要定期检讨和更新。可以采用一些可视化的方法，明确的显示出风险的优先级。比如亮灯的做法或风险视图之类的做法。亮灯是针对AEN分成三类，红色为高优先级问题，黄色表示需要谨慎对待的风险，其它风险则为绿色。

更复杂一点的图示如下:

根据80/20原则，主要关注那些高优先级的风险，所以有效地加以区分相当重要。