标签：
软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目不能实现。如果对项目进行风险管理，就可以最大限度的减少风险的发生。
项目风险管理是指为了最好的达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术。项目风险管理的目标是使潜在机会或回报最大化，使潜在风险最小化。风险管理涉及的主要过程包括：风险识别，风险量化，风险应对计划制定和风险监控，如图1所示。风险识别在项目的开始时就要进行，并在项目执行中不断进行。就是说，在项目的整个生命周期内，风险识别是一个连续的过程。
（1）风险识别：风险识别包括确定风险的来源，风险产生的条件，描述其风险特征和确定哪些风险事件有可能影响本项目。风险识别不是一次就可以完成的事，应当在项目的自始至终定期进行。
（2）风险量化：涉及对风险及风险的相互作用的评估，是衡量风险概率和风险对项目目标影响程度的过程。风险量化的基本内容是确定那些事件需要制定应对措施。
（3）风险应对计划制定：针对风险量化的结果，为降低项目风险的负面效应制定风险应对策略和技术手段的过程。风险应对计划依据风险管理计划、风险排序、风险认知等依据，得出风险应对计划、剩余风险、次要风险以及为其它过程提供得依据。
（4）风险监控：涉及整个项目管理过程中的风险进行应对。该过程的输出包括应对风险的纠正措施以及风险管理计划的更新。
每个步骤所使用的工具和方法：
l 对风险管理价值的认同——对组织管理、项目干系人（内部或外部）、项目管理和项目成员来说，在项目风险管理上的投入是有潜在正面回报的。因而项目风险管理应该被认为是极富价值的。
l 个人承诺/责任——项目参与者和干系人都应该愿意承担进行风险相关活动的责任。风险管理实际上是每个人的分内事。
l 开诚布公的沟通——每个人都应该参与到项目风险管理过程中。相对于积极处理和有效决策，任何隐藏风险的行为或态度都会降低项目风险管理的效率。
l 组织级的承诺——组织级的承诺只有在风险管理与组织的目标和价值一致时才能建立。和其他项目管理原则相比，项目风险管理需要更高级别的管理层支持，因为一些风险的应对需要比项目经理更高级的管理层批准或采取行动。
l 量化项目上风险管理的投入——项目风险管理活动应该和组织对于项目目标价值的判定，风险本身的程度、规模，以及其他组织级制约因素相一致。特别是，进行项目风险管理所需的成本应该和风险管理能给项目及组织带来的价值相对应。
l 与项目管理整合——项目风险管理并非独立存在于其他项目管理过程之外。成功的项目风险管理需要和其他项目管理过程的正确执行进行整合。
以上这些关键成功因素如下图所示
项目经理在风险管理过程中有着独一无二的作用。项目经理对交付一个完全符合预定目标的成功项目承担整体责任；项目经理对项目的日常管理负责，包括进行有效的风险管理。项目经理的职责包括：
l 鼓励高层管理者支持项目风险管理活动的进行。
l 与干系人协商确定项目风险的可接受程度。
l 编制和审批风险管理计划。
l 在项目中推动项目风险管理过程。
l 在项目团队、高层管理者和其他干系人中对风险进行开诚布公的沟通。
l 参与项目风险管理过程中的方方面面。
l 在落实行动前审核风险应对和相应的行动计划。
l 在风险发生时，批准启用项目应急储备来应对已识别风险。
l 监督分包商和供应商的风险管理。
l 定期向主要干系人汇报风险的状态，提供恰当的决策建议，以及为维持一定的风险水平应采取的措施。
l 在适当的时候将已识别的风险提升到高层管理层面，包括那些在项目经理权力或掌控范围之外的风险、需要项目以外的其他输入或行动的风险，以及需要动用管理储备的风险。
l 监督项目风险管理过程执行的效率、效果。
l 审计风险应对的有效性并记录经验教训。
1、软件项目中的风险
软件项目的风险无非体现在以下四个方面：需求、技术、成本和进度。IＴ项目开发中常见的风险有如下几类：
（1）需求风险
1.需求已经成为项目基准，但需求还在继续变化；
2.需求定义欠佳，而进一步的定义会扩展项目范畴；
3.产品定义含混的部分比预期需要更多的时间；
4.在做需求中客户参与不够；
5.缺少有效的需求变化管理过程。
（2）计划编制风险
①计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；
②计划是优化的，是"最佳状态"，但计划不现实，只能算是"期望状态"；
③计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上；
④产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大；
⑤完成目标日期提前，但没有相应地调整产品范围或可用资源；
⑥涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。
（3）组织和管理风险
①仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；
②低效的项目组结构降低生产率；
③管理层审查 决策的周期比预期的时间长；
④预算削减，打乱项目计划；
⑤管理层作出了打击项目组织积极性的决定；
⑥缺乏必要的规范，导致工作失误与重复工作；
⑦非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。
（4）人员风险
①作为先决条件的任务(如培训及其他项目)不能按时完成；
②开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；
③缺乏激励措施，士气低下，降低了生产能力；
④某些人员需要更多的时间适应还不熟悉的软件工具和环境；
⑤项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低；
⑥由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作；
⑦不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性；
⑧没有找到项目急需的具有特定技能的人。
（5）开发环境风险
①设施未及时到位；
②设施虽到位，但不配套，如没有电话、网线、办公用品等；
③设施拥挤、杂乱或者破损；
④开发工具未及时到位；
⑤开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具；
⑥新的开发工具的学习期比预期的长，内容繁多。
（6）客户风险
①客户对于最后交付的产品不满意，要求重新设计和重做；
②客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；
③客户对规划、原型和规格的审核 决策周期比预期的要长；
④客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更；
⑤客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长；
⑥客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。
（7）产品风险
①矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；
②开发额外的不需要的功能(镀金)，延长了计划进度；
③严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；
④要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作；
⑤在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；
⑥开发一种全新的模块将比预期花费更长的时间；
⑦依赖正在开发中的技术将延长计划进度。
（8）设计和实现风险
①设计质量低下，导致重复设计；
②一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能；
③代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；
④过高估计了增强型工具对计划进度的节省量；
⑤分别开发的模块无法有效集成，需要重新设计或制作。
（9）过程风险
①大量的纸面工作导致进程比预期的慢；
②前期的质量保证行为不真实，导致后期的重复工作；
③太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发；
④过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作；
⑤向管理层撰写进程报告占用开发人员的时间比预期的多；
⑥风险管理粗心，导致未能发现重大的项目风险。
针对软件项目中的风险管理问题，不少专家、组织提出了自己的风险管理模型。主要的风险管理模型有：Boehm模型，CRM模型和SERIM模型。
1 Barry Boehm模型
模型：RE=P (UO)*L (UO)
其中RE表示风险或者风险所造成的影响，P(UO)表示令人不满意的结果所发生的概率，L(UO)表示糟糕的结果会产生的破坏性的程度。Boehm思想的核心是10大风险因素列表。针对每个风险因素，都给出了一系列的风险管理策略。在实际操作时，Boehm以10大风险列表为依据，总结当前项目具体的风险因素，评估后进行计划和实施，在下一次定期召开的会议上再对这10大风险因素的解决情况进行总结，产生新的10大风险因素表，依此类推。
2 SEI的CRM(Continuous Risk Management)模型
SEI
CRM模型的风险管理原则是：不断地评估可能造成恶劣后果的因素；决定最迫切需要处理的风险；实现控制风险的策略；评测并确保风险策略实施的有效性。CRM模型要求在项目生命期的所有阶段都关注风险识别和管理，它将风险管理划分为五个步骤：风险识别、分析、计划、跟踪、控制。
3 SERIM(Software Engineering Risk Model)模型
SERIM从技术和商业两个角度对软件风险管理进行剖析，考虑的问题涉及开销、进度、技术性能等。它还提供了一些指标和模型来估量和预测风险，由于这些数据来源于大量的实际经验，因此具有很强的说服力。
MSF 风险管理原则提倡前摄的风险管理、持续的风险评估以及项目或操作生命周期的决策集成。风险应该被持续地评估、监控和积极地管理，直到被解决或是转化为可以处理的故障为止。图1中描述的MSF 风险管理原则定义了项目团队管理现有风险、计划、执行风险管理策略以及为企业获取知识过程中的六个逻辑阶段。
MSF 风险管理过程的六个阶段是：
?识别
?分析和分级
?计划和调度
?跟踪和报告
?控制
?学习
风险识别让个体可以发现风险，进而使项目团队意识到潜在的故障。作为风险管理过程的输入，风险识别应该尽可能早的执行，并在项目的生命周期中频繁地重复。
风险分析将风险识别过程中发现的特定项目风险估计量或数据转化为一种可被项目团队用来确定优先决策的形式。风险排序让项目团队可以负责项目资源从而对最重要的风险进行管理。
风险计划提取风险分析中获得的信息并用其明确表达策略、计划和工作。风险调度可以确保计划被认可并融入标准的日常项目管理进程和基础设施中，从而确保风险管理作为团队日常工作的一部分执行。风险调度明确地利用项目计划与风险计划关联。
风险跟踪监控特定风险的状况以及它们各自工作计划中的进展情况。风险跟踪也包含监控变化风险的概率、影响、暴露程度以及其他因素，这些变化可能改变优先级或风险计划、项目特性、资源或是进度表。风险跟踪从风险等级的角度定义风险管理过程在项目中的可见度，这与标准业务项目管理过程任务完备化的角度恰恰相反。 风险报告确保团队、发起人和投资人明白项目风险的状态并管理它们的计划。
风险控制是执行风险工作计划和相关现状报告的过程。风险控制也包含项目变化控制请求的初始化，而风险状况或风险计划的更改可能导致项目特性、资源或进度表的更改。
风险学习使知识和相应项目案例及工具正式化，并在团队和企业内部以可再度使用的形式提取知识。
注意，这些阶段属于逻辑阶段，对于任何给定的风险，您都并不需要严格地遵循这些阶段。项目团队将经常在识别-分析-计划三步中循环往返，而仅仅周期性地进入学习这一阶段来为企业捕获知识。
SG 1 进行风险管理准备
建立并维护用于识别、分析和缓解风险的战略。这个战略一般编写成项目风险管理计划。风险管理战略处理的是适用于控制风险管理大纲的具体措施、资源和管理方法；包括对风险来源、风险分类方案以及风险的评价、界定和控制参数等的策划。相应的惯例：
风险的来源是多方面，对于IT项目的风险比较常见的来源是不确定的需求，人员流动，使用新技术，不合理的进度，开发人员技能不足等方面的内容。风险的类别也是多方面的，比较大的分类可以分为项目管理类的风险，业务风险，技术类风险等。注意确定风险来源和分类的目的一方面是提供一种收集和归纳风险的机制，以确保风险能够引起管理者的关注。一方面的不同的风险类别和来源所具备的风险概率，影响，干系人，风险阈值等基础参数可能是不一样的。
定义风险的参数主要是要确定风险的定义，评估和排序的准则。里面有一个重要的内容就是确定各类风险的阈值。风险的阈值是给出风险的监督和控制点，当风险最终评估影响超过阈值的时候就必须要考虑实施风险缓解计划。风险缓解计划的实施可以是在我们评估的关键风险立刻实施，一种就是虽然现在还不是关键风险，但是如何风险超过了阈值就必须要实施缓解计划。
对应SP1.3的内容可以直接理解为风险管理计划，该计划应该是项目计划的重要组成部分。风险管理计划需要定义项目风险管理小组的成员，项目采用的风险参数，风险识别的方法和工具，项目可能会采用的风险缓解策略，项目如何对风险进行监控等内容。
SG 2 识别和分析风险
识别风险并对其进行分析，以确定它们的相对重要性。风险的程度影响到为处理风险而进行的资源分配和确定何时需要相应的管理者关注。对风险进行分析也就是给内部和外部来源的风险加上标识，然后评估每个风险，确定其发生的可能性和后续结果。根据已建立的风险分类办法和针对风险管理战略拟订的判据确定风险的类别，将为风险的处理提供所需的信息。可以把相关的风险分组，以便有效地处理风险和使用风险管理资源。相应的惯例:
风险的识别有多种方法，头脑风暴，调查表，风险检查单，风险库等都是可以考虑的内容。对于产品和技术的风险一定要借助于WBS工作分解结构来识别。在风险识别阶段我们就会形成风险登记册，要完成风险的名称，来源，类别等基本风险属性的录入。
在SP2.2主要是PMBOK中谈到的风险定性分析的内容。主要是要确定每个风险的影响，风险值=风险发生的概率*风险产生的影响。对我们识别的每个风险都应该得到最终风险值然后对风险进行优先级排序。在定性风险分析中引入了风险概率影响矩阵，组织和项目都可以根据概率影响矩阵来定义风险值在哪个范围即是项目关键风险。当一个风险被评估我项目关键风险后就必须要考虑对风险进行应对和缓解。
SG 3 缓解风险
处理风险并且在适当时缓解风险，从而降低对实现项目目标的不利影响。
处理风险的步骤包括提出风险处理意见、监督风险和在规定的阈值被超出时执行风险处理活动。针对所选择的风险拟订并实施缓解风险的方案，主动降低风险发生时的潜在影响。这类方案可能包括用于处理所选风险万一发生时的影响的应急方案，这与缓解风险的意图无关。用于启动风险处理活动的判据、闽值和参数由风险管理战略规定。相应的惯例：
风险管理战略规定的判据、阈值和参数用于确定在什么时候需要采取风险处理行动。风险缓解计划只是针对项目的关键风险，对于一般风险仅进行监督即可。对于风险的应对常用的措施有减轻，接受，规避，转移等，建议对于关键风险要有一种以上的缓解应对方法。在SP3.1中要确定风险的级别和阈值，它们指出风险在什么情况下将变得不可接受并且将启动风险处理行动。另外风险缓解计划中还需要包括如何风险转变为问题后的应急处理方法。
风险缓解计划的实施需要定义缓解计划的实施负责人，定期跟踪在缓解计划实施后风险是否得到了缓解。风险的发生概率和影响程度是否得到了降低。有了这些跟踪和重新评估，就可以对风险状态和优先级进行重新更新。
三级对风险管理要求是风险管理已经上升到组织级，组织有对风险管理规程，风险参数的标准定义，项目可以裁剪。另外组织会形成相应的风险库供项目识别风险使用。四级要求对风险进行量化管理，需要量化到风险管理的子过程，如风险识别，风险分析等子过程。对风险分析应该采用一些敏感度分析，蒙特卡洛模拟等量化风险分析的方法。
1 风险管理要趁早。海恩法则说：任何不安全事故都是可以预防的。而防患于未然的代价显然要好过亡羊补牢，良好的风险管理规划是项目成功的一个保障；
2 不要忽视参考以前相关的项目经验。项目管理本来就是一个积累的实践过程，“前车之鉴，后车之师”，以前的项目，无论是从风险识别还是风险应对都能给现在的项目一些启示和经验；
3 要充分考虑项目成员对风险的态度。风险管理不是项目经理一个人的事，需要全员的参与，而不同成员对风险的态度往往也会在某种程度上决定风险应对的措施。对于风险追逐型的组员，就要考虑其对风险的分析和认识是不是偏于乐观，同时也不能由于某些风险保守型成员对风险的态度而止步不前；
4 借助相关的风险管理工具。如 GS risk，Deltek Risk+等。其中 RPM 通过为风险和响应集中编目，并生成措施或任务来识别与记录项目有关的问题并做出相应，从而能够提供从计划，监控到控制阶段过程有效的风险管理，同时其强大的风险数据库还可以为项目风险提供模板。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
希望对您公司企业信息化IT架构与管理有帮助。 其它您可能感兴趣的文章：
企业项目化管理介绍
智能企业与信息化之一
由企业家基本素质想到的
敏捷软件质量保证的方法与实践
构建高效的研发与自动化运维
IT运维监控解决方案介绍
IT持续集成之质量管理
人才公司环境与企业文化
企业绩效管理系统之平衡记分卡
企业文化、团队文化与知识共享
高效能的团队建设
餐饮连锁公司IT信息化解决方案一
如有想了解更多软件研发 , 系统 IT集成 , 企业信息化，项目管理，企业管理 等资讯，请关注我的微信订阅号：
作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。
标签：
原文地址：http://www.cnblogs.com/wintersun/p/5468004.html
