CMMI on line

有这样的说法：项目管理其实就是风险管理，把风险管理好了，项目也就管理好了。可见风险管理是多么重要啊！

在CMM的时候，还没有专门的PA是针对风险管理的。

CMMI2级的PP这个PA的SP2.2提到要识别风险，但这里的要求还是处于项目级别层次的。3级中的RSKM，已经把风险管理上升到组织层面，组织级需要对风险进行分类、定义风险的属性、制定风险的管理策略等。

RSKM有3个SG，SG1主要就是讲述组织级的要求，而SG2、SG3重点讲述项目如何进行风险管理活动。

 

SG1 Preparation for risk management is conducted.

做好风险管理的准备。

 

SP1.1 Determine risk sources and categories.

决定风险的来源和分类。

 

SP1.2 Define the parameters use to analyze and categorize risks,and the parameters used to control the risk management effort.

定义用来风险的属性，这些属性是用来分析风险、分类风险以及用来进行风险管理的。

 

SP1.3 Establish and maintain the strategy to used for risk management.

建立和维护用于风险管理的策略。

 

用SP1.1到SP1.3，要求逐步深化。SP1.1只要求确定风险来源及分类。SP1.2就要求定义清晰的风险属性，一般来说，风险会有原因、后果、严重级别、发生机率、类别等属性，每个企业可以根据自己需要定义属性。SP1.3所谓的风险管理策略，指得就是风险如何存储、记录、跟踪、采取什么缓解措施等所有关于风险管理的组织级别的要求。

 

SG2 Risks are identified and analyzed to determine their relative importance.

识别风险并分析决定他们的相关重要性。

 

SP2.1 Identify and document the risks.

识别和记录风险。

这里要求以比较正规的方式记录风险。

 

SP2.2 Evaluate and categorize each identified risk using the defined risk categories and parameters,and determine its relative priority.

根据已经定义好的风险分类及属性，评估和分类每一个风险，并决定其优先级。

 

SG3 Risks are handled and mitigated,where appropriate,to reduce adverse impacts on achieving objectives.

风险被管理并且缓解，以减少对项目管理目标的影响。

SG2主要讲的是识别和分析风险，SG3就是要管理风险及采取缓解措施了。

 

SP3.1 Develop a risk mitigation plan for the most important risks to the project,as defined by the risk management strategy.

根据风险管理策略对项目最重要的风险制定风险缓解计划。风险缓解措施是指，降低风险发生机率及风险发生时采取的减低影响的措施。

 

SP3.2 Monitor the status of each risk periodically and implement the risk mitigation plan as appropriate.

周期性地跟踪风险状态，在需要的时候实施风险缓解计划。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

我对CMMI体系不是很熟悉，下面的说法不一定正确。

   CMMI中对风险讲得比较多，好象老外的想法风险和问题是一致的，而我的看法，风险和问题是有本质区别的。

    我们在项目管理过程中，提的最多的是缺陷（或直接叫问题吧，而他们并不一样）而比较忽视风险的识别及管理。

    我在项目管理过程中，也觉得不太好区分：风险、问题、缺陷这几个要素。

    风险：主要应该是管理层、项目经理、QA进行识别及管理。

    问题：来源就很多，可以是我们的test组、也可以是程序员，还有用户，而我们的风险在真正成为现实的时候，也就成为一个问题了。

    缺陷：缺陷和问题有互通，可能问题更广泛些而已。

   我们在从管理的角度看，主要关注的是风险（绩效：重大风险发现率）及缺陷（缺陷密度等）。

    从现实角度看，风险可以让项目直接失败，问题需要增加我们的管理成本、而缺陷直接增加我们的返工成本。

     在实际的工作中，对他们三者虽然都有管理，而他们有都存在相互关联，最关键是他们都和项目成本相关，所以，也是项目管理的重中之重啊。

  

Basestone的回复非常好，我稍微补充一下：

               

风险：就是可能发生的问题，它是还没有发生的，我们需要采取措施去规避，去降低它发生的可能性的，当风险发生了，也就是风险变成问题了，这个时候要降低风险带来的影响。

 

问题：就是确确实实存在的问题，是已发生已发现的，需要去处理的。问题的范围包含缺陷，但一般我们会这样定义问题，问题指项目过程中发现的除了缺陷以外的问题，如文档评审发现的问题、同行评审发现的问题、计划中存在的问题等等。

 

缺陷：一般就是指通过测试软件或者用户使用软件发现的问题。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

  非常感谢张总.

  上面几个概念在工作中一直有点模糊,看了张总的描述,真是清楚多了.

  还需要多多向各位专家学习!

zhangcb:

Basestone的回复非常好，我稍微补充一下：

               

风险：就是可能发生的问题，它是还没有发生的，我们需要采取措施去规避，去降低它发生的可能性的，当风险发生了，也就是风险变成问题了，这个时候要降低风险带来的影响。

 

问题：就是确确实实存在的问题，是已发生已发现的，需要去处理的。问题的范围包含缺陷，但一般我们会这样定义问题，问题指项目过程中发现的除了缺陷以外的问题，如文档评审发现的问题、同行评审发现的问题、计划中存在的问题等等。

 

缺陷：一般就是指通过测试软件或者用户使用软件发现的问题。

描述得很清晰，谢谢！

在实施CMMI的过程中，我对问题和缺陷始终混在一起，结果在进行问题管理的时候把缺陷也弄了进来，导致问题管理得不伦不类。

我的理解是项目管理的主线就是范围管理＋风险管理，而其他知识领域是去支撑他们来顺利完成项目；

至于项目风险的识别我认为只要是项目干系人，都应该去做的事情，不管是组织级的、还是内部、外部的、或者管理人员、技术人员。在项目的整个生命周期中都会有风险，我们需要及时去识别，使其对项目的伤害最小化。当然在早期的售前或者策划阶段识别风险是很关键的 ^_^

hehe

您好，

这个问题我也很感兴趣。

风险和缺陷的混淆我是在经历了【缺陷预防】的一些实施活动时产生的。

在缺陷识别的时候，我突然感觉很风险识别很像，但是说不出区别来。

也是一些可能发生也可能不发生的导致缺陷的情况。

如果说缺陷是通过测试才能发现的问题，那缺陷预防是不是只针对这类问题进行就可以了？

这如何是好那？

一般来说有风险、问题、缺陷三个概念，每个公司对他们的定义可能不一样，一般这样定义：
1.风险：可能发生的问题，不是一定会发生的，这些可能发生的问题，会影响项目成功，风险未发生之前，要想办法不让它发生，万一发生了，就要想办法降低其影响。当风险发生时，风险就变成问题了。
2.问题：已知已经存在的问题，会影响项目成功，要处理的。问题的范围很广，包括项目管理、计划、计划跟踪、需求、设计、代码中的问题等等。
3.缺陷：一般我们定义为软件做出来后通过测试或者用户使用发现的存于与软件中的问题，从这点看，缺陷也是问题的一种，但我们一般区别来说。

所谓的“缺陷预防”中提到的“缺陷”是什么意思，要看具体的上下文是什么，不是简单的预防“测试发现的问题”。
所有项目基本上都是成本、进度、质量三者的平衡，所有的风险、问题、缺陷都不是全部指向质量的，成本、进度、质量三个方面都会有风险、问题、缺陷，一个项目没有测试出什么缺陷，质量很好，但成本超了，进度慢了，还是没有达到项目的目标，这样的项目可能还是不能算成功的。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

讲的非常透彻,我之前只是对风险和问题了解的比较好,像张老师说的一样,但缺陷总是有些模糊,去别的公司时也发现叫法不一,有的把BUG也叫缺陷,说着说着不对劲,发现双方理解的有偏差,很佩服您的讲解方式

相信对于风险(Risk)大家都比较清楚了。我想补充的是缺陷(Defect)和问题(Issue)一些见解。

缺陷(Defect)一般来说是从产品质量(Product Quality)的角度来描述的。一个项目的缺陷，可以是项目产品本身的缺陷，比如说系统测试出100个Bug，用户验收测试时发现了50个Bug，以及文档审查中发现了若干缺陷，等等;

而问题(Issue)，则主要是从过程质量(Process Quality)的角度来评价。正如张总前面提到的计划(PP)、计划跟踪(PMC)、等等。例如我们前面发现了这么多个Bug/缺陷，但是我们并没有按时按照既定的过程对这些缺陷进行必要的分析研究，甚至没有解决，这就是问题(Issue)。Issue的产生可能会导致Defect的产生.

再说Defect Prevention，其最最终目的预防/避免缺陷。让我们通过DP的一些方法论来分析，进行培训、准备指导文档、准备Checklist等等..这些过程实际上最终还是保证/预防产品的缺陷。

另外，Issue的管理的最终目的是通过过程来保证产品的质量(Product Quality)，从而保证客户对最终产品的满意，以及项目的成功。

---

-=P.CHi=-

最近在写RSKM过程、以前做项目的时候对风险管理的过程控制很少，看了大家对风险这块的描述，让我对这个PA有了更加深入的认识。谢谢大家了。