浅谈风险识别和控制

《浅谈风险识别和控制》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、浅谈风险识别和控制最近部门要求要加强风险预警的力度。确实从更深的角度去帮助项目组挖掘出影响严重的风险。说到风险管理，主要目的是识别潜在问题，保证风险处理活动是有计划并且可以被执行的，从而降低项目或产品在实施过程中遇到的一些不利影响。首先了解一下风险的概念，风险是对项目成功（在计划的期限内，按预定的成本和质量完成项目）产生消极影响的所有不确定因素；那么风险预警，我们可以从进度，成本和质量方面去考虑，去挖掘风险。比如，从项目计划方面去发现风险，当项目计划正式评审前，QA检查项目计划时，对项目经理的裁剪说明，应该注意裁剪理由和裁剪风险的说明。要认真分析项目裁剪理由描述是否充分和项目经理

2、对流程的理解是否到位。如果QA认为理由不充分，需与项目经理进行直接沟通和讨论。通过沟通要让项目经理了解执行此流程的真正目的和裁剪后的风险。如果项目经经理还是无客观理由的情况下执意裁剪流程或活动，可以通过领域总监的沟通，让领域总监去说服项目经理。并向总监说明项目经理和QA对裁剪各自的观点和想法。如果最后还不能说服项目经理，那最后可通过异常报告来向公司领导说明存在的风险。通过此种形式来进行风险预警，其实我们完全是为了挖掘项目更深层次的风险。而不是形式上单单发个异常报告就可以了。刚才讲述的这个案例，更多的依赖QA和项目经理自身的能力来挖掘项目的风险。由于QA和项目经理的能力参差不齐，因

3、此这样的形式会可能使某些项目存在风险漏掉。从而使风险有可能转换为实际问题。针对这种情况，需要从流程上去考虑怎么解决这个问题。我个人觉得风险识别不应该是试图去找所有的问题，而不管它发生的可能性。使用在风险管理策略中的分类和参数，连同已经被识别的风险来源，形成一个风险列表，可以为风险识别提供支持。然后QA和项目经理可采用这个风险列表，去发现项目中的风险。从而保证大家发现风险的标准和依据都是一致。避免漏掉风险。能更好的进行风险预防。风险列表应该被定期评审，因为风险来源以及风险管理策略可能产生变化。为了有效控制和管理可能存在的风险，需要预先定义好跟踪和处理风险的机制。风险中可以接受的标准

4、应该对应于状态，以决定是否需要风险预警。由项目经理和QA针对对风险进行跟踪，当满足风险触发条件时，应及时通知相关干系人并采取相应措施，报告风险防范的执行过程。比如项目组没有按照自动编译流程来进行发布源程序包。那么这样的话，就会存在源程序与程序包的版本可能会存在不一致的情况。从造成非常严重的后果，直接导致发布错误软件版本的风险。通过这个例子也就说明如果不走自动编译，也就触发了风险预警的阀值，即达到了风险预警的条件。那么假如风险一旦发生和即将发生的话，应该如何去降低风险？那么风险管理的一个重要部分是针对每个严重的风险采取什么手段，有些风险的结果是可以被接受的，这些风险可能简单的被接受

5、或者设置为观察状态。我们经常在各种风险管理的书中，会经常看到处理风险的方式有以下选择：l避免风险，在满足用户要求的情况下改变或者降低需求；比如针对性能指标数据达不到要求时，那么可采用在符合用户需求的情况，稍微降低一下非功能的需求要求标准。l控制风险，采取一系列步骤最小化风险；比如，当项目出现技术解决难点时，但是又受到进度的压力。可通过找专家来协助解决难点的方式来解决和想办法，尽量的按照预定的进度去克服解决难点的困难，满足客户上线时间的要求。但是最终结果可能是没有完全解决其中的技术难点。但是经过大家的努力已基本解决技术难点，且基本符合产品发布的要求，保证了按时发布。l转移风险，修改

6、设计要求来降低风险；比如在项目进展中，如果发现非常严重的bug，但是如果完全解决的话，可能需要很长时间，并且对整个系统的质量影响很大，这时大多数情况，我们可能采用尽量少修改代码，把问题的严重性通过转移的手段降到最低。有可能这个问题解决了，但是又带了新的问题。新的问题对客户影响又很小。l接受风险，不采取任何措施接受风险。比如，针对测试部门发现的建议性bug，经过项目组讨论和评审，有些bug为了赶进度可能就不在解决了。而是接受它。这些手段是面对风险经常用到的手段，但是对于项目组内没有能力预防和处理的严重风险，要尽快报告给高层领导。通过高层领导来帮助项目组解决工作中的严重风险。总之，面

7、对风险需要我们根据自己的经验和风险列表，进行风险识别，识别出来的严重风险，一定要及时跟踪和控制，采用各种手段去降低风险的发生。如果我们确实避免不了的风险，需要我们采取各种控制手段把风险降到最低。最终目的是为了项目顺利的交付。