与熊共舞--软件项目风险管理
1.WHY
名词：
风险：（1）未来可能发生的某一件事，该事件将导致不好的结果（2）不好的结果本身
风险是尚未发生的问题，问题是业已成真的风险。
区分风险管理（管理风险）和危机管理（问题的补救措施）
风险转化：风险发生（具现）了
转化事件，通常不可见，可见的为转化指标，通过指标看转化事件。
风险缓解：“必须在风险转化前做的工作”
风险管理包括：风险发现，暴露分析，应急计划，风险缓解，持续转化控制。
风险管理的理由：
使积极的风险承担成为可能
使风险合法化
使项目向着成功出发
为不确定性划定边界
提供成本的最低保护
能防止隐蔽的责任推诿
能够亡羊补牢
为个人成长提供最大的机会
能防止掩耳盗铃的管理
关注需要关注的地方
2.WHY NOT
反对风险管理的理由：
顾客还没有成熟到坦然面对风险的地步
不确定性的方位太广了
不确定性的范围会成为低效的借口
“成功管理”是更好的管理方法
缺乏有效实施风险管理所需的数据
孤立的风险管理是危险的
可以犯错，但不能不确定
3.HOW
量化不确定性----风险图
极小概率点(N点)，不确定性范围多大
在孤寂必须完成的任务时，大多数软件项目经理做了足够的工作，但是在估计可能必须完成的任务时，他们付出的努力少的可怜
昨天的问题就是今天的风险，所以要建立自己公司、部门的风险数据库
担心项目不是风险管理。
风险暴露：对包容风险所需成本的期望，=损失×可能性
致命风险，风险储备，缓解成本，转化指标，转化监控
每个皮球后面肯定跟着一个小孩---“看到皮球要踩刹车”
风险管理的步骤：
一。通过风险发现过程调查出项目面临的风险
二。确认软件项目所有的核心风险都已出现在你的调查结果中
三。针对每个风险，完成下列“作业”
为风险命名，编号
通过头脑风暴找出这项风险的转化指标（征兆最早出现的那个）
估算风险发生对成本和进度造成的影响
估算风险具象的可能性
计算风险的日程和预算暴露值
判断如果风险开始转化，需要采取哪些应急措施
判断需要在风险转化前采取哪些缓解措施才能保证应急措施不致失效
将缓解措施列入项目的总体计划
将所有细节记入一个模板
四。指出致命风险，将他们列为项目假定
五。假设没有任何风险具现，进行第一次日程估算
六。参考企业内部和业界公认的不确定因素，绘出风险图，（运用RISKOLOGY）
七。用风险图来描述所有的承诺，明确每项预计日期和预算所涉及的不确定性
八。密切监控所有风险的具现情况或终止情况，一旦风险具现，立即执行应急计划;创建工作细分结构
九。贯穿项目始终，持续进行风险发现过程，随时发现后续出现的风险；项目开始时，必须要求参与各方确定产品的净输入、输出数据流
十。在实现任何功能之前，首先进行详尽的设计划分
十一。设计划分完成后，回到工作细分结构，重新估算任务的权重
十二。估算项目的价值，精度应该与成本估算的精度相当
十三。将项目规约中包含的需求细分到元素级别，按照各需求元素的优先级顺序编号
十四。创建增量式交付计划，细分项目为多个版本
十五。为整个产品创建最终的总体验收测试，然后将其分为多个版本验收测试
十六。根据各版本的预期交付日期为他们分配EVR
十七。从项目开始到结束，密切监控所有风险的具现情况或终止情况，一旦具现，立即执行应急计划。
十八。从项目开始到结束，持续进行风险发现过程，随时发现后继风险
日程安排>目标>N
对于我不知道的东西，我知道多少，或者能够知道多少
风险：描绘所有可能结果及由其引发的相关后果的加权图
总风险，肇因风险
生产模型，风险模型
工具：RISKOLOGY,对于多个风险综合
蒙特卡洛效应
所有项目的共同风险（核心风险）：
进度安排的先天错误
需求膨胀（变化）
人员流失
规约崩溃
低生产率
发现风险的过程：
灾难头脑风暴
情景构造
根源分析
风险管理动力学（这章不是很明白）
EVR(挣值运行)
主动增量式开发
增量交付计划：设计蓝图，工作细分结构，版本验收测试
好处：更好地激发士气，更直观体现项目进展，使用户有机会更多参与项目，更好突出项目重点
4.HOW MUCH
投资回报率=（价值-成本）/成本
成本和收益应该在同一精度上指定。
收益计算的步骤
在开发者说明预期成本和日程安排的同时，客户说明预期收益，两者应有同等的精度
在开发者指明成本和日程计算不确定性的同时，客户已相同方式指明收益预测中的不确定性
客户估算系统各组成部分的相对价值，为版本选择、敏感性分析和增量成本收益分析提供基础
管理者比较成本和收益，并考虑各自的不确定性，对项目作出综合评估
项目完成后，管理者核算实际收益，并将核算结果输入事后分析过程
风险取决于价值，死亡之旅往往预期价值偏低
5.WHETHER OR NOT