如果风险止于发现者则不能称为有风险管理，必须是在规范的流程之下，有计划的采取行动，这才算是风险管理的起步阶段。
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的定义方法如下:
5. 风险的应对计划
在项目层级的风险的应对针对具体风险可以有以下策略:
a. 有没有合适的回避(avoidance)措施？(如改变设计)
b. 在还没发生时如何减轻(reduction/mitigation) (如增加单元测试)
c. 风险是否可以转移(transfer)出去? (如外包或需求变更)
d. 如果这个风险已经发生了采取什么措施减轻影响(Contingency plan)? (如立刻更改使用的库)
针对已识别的风险制定应对计划、安排责任人，指定时间，这些构成风险管理核心表格。
6. 风险追踪
风险需要定期检讨和更新。可以采用一些可视化的方法，明确的显示出风险的优先级。比如亮灯的做法或风险视图之类的做法。亮灯是针对AEN分成三类，红色为高优先级问题，黄色表示需要谨慎对待的风险，其它风险则为绿色。
更复杂一点的图示如下:
根据80/20原则，主要关注那些高优先级的风险，所以有效地加以区分相当重要。
转载请注明出处: http://blog.csdn.net/horkychen
