文件编号：runway-qo-spp-03
版本号：v1.1
目录。1. 风险管理的内容 3
1.1 风险识别 3
1.2 风险分析和优先级 3
1.3 风险管理计划 4
1.4 风险化解 4
1.5 风险监控 4
1.6 11个风险问题列表 5
2. 综合风险管理表 6
2.1 纵向风险 6
2.1.1 立项阶段 6
2.1.2 计划阶段 6
2.1.3 需求分析阶段 9
2.1.4 设计阶段 10
2.1.5 编码阶段 12
2.1.6 测试阶段 12
2.1.7 发布阶段 13
2.2 横向风险 13
2.2.1 组织和管理 13
2.2.2 人员 14
2.2.3 客户 16
2.2.4 承包商 18
2.2.5 产品 18
2.2.6 开发环境 19
2.2.7 外部环境 19
2.2.8 过程 19
3. 最佳实践 22
4. 参考文献 22
5. 历史记录 22
风险管理包括2个部分6个内容，分别是：
风险评估。
风险识别。风险分析。
风险优先级。
风险控制。
风险管理计划。
风险化解。风险监控。
风险以横向（组织管理、人员、客户、承包商等）和纵向（立项、开发、需求、设计等）两种形式贯穿于项目中。
风险识别就是列出各方面潜在的风险列表。有一个很完整的多达120项的进度计划风险列表，但在使用于某个项目时，它必须是依据项目被裁剪的。
风险列表的一个裁剪版本可参考下面的综合风险管理表。
在裁剪出具体项目的风险列表后，使用风险评估表分析风险优先级。
风险评估表的主项是风险暴露量（re，risk exposure），它表明了风险的预期情况，其值等于风险影响的数学期望。
下面是一个实际项目风险评估表的例子，按风险暴露量排序。
注意： 建议风险评估表追踪re最严重的10个风险。
如果某些风险尽管发生概率很小但却是完全不能承受的，应提高其优先级以防冒险。
由最熟悉系统的（几个）人预计概率和损失，rd中给出了一些有益的实践方法。
当全部风险的暴露量之和达到整个项目的50%时，项目正在冒险（seapa）。
确定风险的起因、表现、发生时间、发生位置、如何发生及怎样发生。
确定各个风险化解的手段。
确定执行风险监控的必须资源（人员、过程、制度）。
rd中总结的风险化解的一般方法：
避免风险。转移风险。
购买风险信息。
消除根源。接受风险。
发布风险。控制风险。
记住风险。具体每种风险的化解方法，参考下面的综合风险管理表。
化解风险应该以预防为主，当真正面对风险时往往已经太迟了。
方法简述如下：
制定前10个风险和化解计划的列表；
通过定期和定点检查更新列表（包括添加、删除、排序、更改）；
建立全职的（50人以上项目）或兼职的风险**，但不可以是项目经理。
下面是风险监控表的一个不完整的例子。
对于上表的10个最严重风险，应进行风险化解活动并跟踪其进展；除此之外的低等级风险，不需要进行风险化解，但必须继续跟踪。
以下问题选自seapa的第6章，是由世界各地软件项目经理总结的数据派生而出的。当其中任何一个有否定回答时，都应该进行风险管理。
1. 最高软件经理和客户经理正式委派项目了吗？
2. 最终用户对项目或产品明确表示感兴趣吗？
3. 软件工程组和客户都完全理解需求吗？
4. 客户全面参与了需求定义吗？
5. 最终用户的期望是现实的吗？
6. 项目范围固定吗？
7. 项目组成员的知识结构合理吗？
8. 项目需求固定吗？
9. 项目组成员对将要使用的技术有经验吗？
10. 项目组人员数量足够吗？
11. 所有客户或用户代表都同意项目是重要的而且对项目需求意见一致吗？
注：本章不是专家意见，还需要维护。
以下按纵向和横向划分了两部分风险。
纵向风险在开发过程中分阶段产生，常常具有共生能力（前面一个风险发生后，后面一些风险发生的概率大大上升），因此分析其产生原因和共生性是很重要的。
对下一阶段纵向风险的预防可在各阶段复审时进行。当然，在本阶段初期就必须开始进行风险管理，否则复审时发现可能为时已晚。
低效的立项申请段。
立项申请段没有明确的时间表，没有明确的任务分工，因此常常是效率最低下的阶段，也是最容易挽回进度的阶段。
预防： 由产品工程部和研发部门根据市场需求和产品工期**给出最迟立项时机；
由产品工程部监控和督促立项；
补救： 评估项目时效性，落实或放弃项目；
坚持切合实际的开发进度，避免共生风险；
共生风险： 计划阶段与进度相关的大部分风险；
注意：此处的计划阶段包括了所有阶段的计划行为，包括对计划的细化和调整。
计划、资源和产品定义全凭客户或上层领导口头指令。
这是不成熟企业的贯有作风，一次令人心潮澎湃的会议，诞生了一个毫无保障的项目计划。
预防： 制定相关执行程序和文档（如可行性分析等）；
坚持使用文档化的指令；
相信拨款而非预算；
补救： 评估项目可行性，落实资源或放弃项目；
共生风险： 计划阶段的其他大部分风险，测试阶段的质量低下，人员中的人员薄弱等；
计划是理想状态的。
即使估计是无偏的，使用简单的加法得到的也只能是期望值。
预防： 制定预留缓冲的计划；
考虑可能的需求变更量；
使用接近阶段交付的生命周期；
补救： 重新制定计划；
必要时缩小产品范围以满足进度；
计划漏掉了重要任务。
关键路径上的任务遗漏是计划延期的主要原因之一。
预防： 执行计划复审；
为可能的遗漏预留缓冲期；
使用接近阶段交付的生命周期；
补救： 与用户协商添加必要的任务或推迟到下一版本；
删除其他次要功能以完成此重要任务；
产品规模估计不准。
一个文档化的可测量和修正的估计方法胜过一切主观估计。
预防： 使用科学的而非主观的估计方法；
使用接近阶段交付的生命周期；
补救： 必要时删除次要功能以按时完成；
与以往项目经验比较，进度计划明显不切实际。
humphery：“愚蠢”一词的含义是重复做一件事情，却希望得到不同的结果。
预防： 使用科学的而非主观的进度估计方法；
尊重历史数据和统计数据；
如果进度计划与项目经验不符，必须给出客观充分的理由；
使用接近阶段交付的生命周期；
将计划发送到别的项目组收集意见；
补救： 改正进度计划；
必要时删除次要功能以保证进度；
共生风险： 计划阶段的银弹综合症；
银弹综合症。
新的开发方法、以前积累的库、自动编码和测试工具、新版开发软件、自动配置管理工具……所有需要时间和实践掌握的方法或工具以及只影响局部的单一因素，都可能成为银弹。
预防： 计划复审时识别银弹；
补救： 必要时删除次要功能以保证进度；
共生风险： 计划阶段的与以往项目相比，项目进度明显不切实际。
目标提前但产品范围和可用资源不变。
预防： 变更控制程序中应平衡进度、费用和功能（产品范围）三角形；
补救： 增加可用资源；
放弃提前的目标；
必要时删除次要功能以按时完成；
共生风险： 人员中的“项目后期增加新人”；
过高估计了增强型工具对计划进度的节省量。
银弹综合症中比较容易识别的一种。
预防： 向使用过此工具的人咨询其真实效果；
如果是第一次使用，则不应认为将有节省量；
预留学习熟悉缓冲时间；
补救： 必要时停止使用此工具；
修正计划；
必要时删除次要功能以按时完成；
注意：此处的需求分析阶段包括了以后的需求变更行为。
需求模糊。
预防： 使用需求原型；
邀请用户参与联合开发或复审需求；
需求复审；
引入可测试性评价对需求进行细化；
补救： 邀请用户参与联合开发或复审需求；
复审修正后的需求；
基线已定但需求仍在变化。
实践表明，基线变更30%，项目就会延期80%。（rd）
预防： 由变更委员会复审需求变更；
由用户参与复审基线；
原型法确定基线；
保持基线稳定性；
补救： 将新需求推入下一版本；
必要时删除次要功能以满足新需求；
共生风险： 需求分析阶段的功能蔓延。
需求镀金。
试图击败竞争对手时常犯的错误。
预防： 邀请用户参与需求复审；
向用户咨询业务开展的日程表；
采用接近阶段交付的生命周期，把镀金工作放在最后阶段；
不对镀金工作向用户做承诺；
风险管理 风险沟通指南
附件6.风险沟通指南。近来，在美国和墨西哥等国家陆续发生人感染猪流感病毒疫情，世界卫生组织已宣布此次疫情为 具有国际影响的公共卫生紧急事态 为加强卫生行政部门和疾病预防控制机构的风险沟通应对能力，提高我国公民的自我保护意识，特制定本指南。一 卫生行政部门 疾控部门沟通应对原则与方法。一 基本原则。1...
安全风险基准指南
韶关新丰2012年新建配网。第4标段工程。项目安全基准风险分析表。批准。审核。编写。新丰县鸿兴电业服务有限责任公司。工程项目部。二零一二年八月。目录。01钢管杆 铁塔组立安装作业2 02钢筋混凝土杆组立安装作业3 03杆 塔拉线安装作业5 04横担 金具及绝缘子安装工程作业6 05跨越设施搭设与拆除...
施工安全基准风险指南
施工安全风险基准评估分析表。单位 海南送变电工程 项目名称 五指山供电局35kv水满线 35kv毛道线防风加固改造工程序号。作业任务。作业步骤。危害名称。风险等级分析。建议采取。措施果露。性值。2.1基础部分。一普通基础作业1 线路复测。测量地形对现场不符物理。地形不好。对现场景观有轻度影响。摔伤。...