也谈风险管理

风平浪静,海道平坦似乎谁当船长都胜任,狂风暴雨,暗礁丛生,方显船长总舵本色!风险管理能力就是让你在恶劣环境下,把船顺利渡到彼岸。可操作有价值的风险管理在CMMI圈子里属于稀缺,本文给出了几点提高风险管理效率的方法,开卷有益,静下心来读读吧!

不论是CMMI,还是PMBOK,都将风险管理作为一个重要的内容,还有那本著名的《与熊共舞——项目风险管理》,也介绍了如何开展风险管理的方法和业界案例。但在我所看到的很多项目中,风险管理开展的效果却差强人意,对于原因有各种各样的说法,例如有的说由于大家每天都在忙于交付,没有精力;有的说版本时间都是倒排了,资源也固定了,风险管理没有效果;还有的说团队缺乏契约文化和精细化管理文化……这些的确是也是研发项目中存在的普遍问题,并且这种情况好像短时间内也难以解决,那是否就意味着风险管理对我们没有用,我们就可以不管理风险了?

一、正确的认识风险管理:只是一种方法,它不是万能的

首先,我觉得我们还是先回顾一下什么是风险管理。风险管理是指对未知消极事件(可能影响项目的进度、质量、范围等等不确定因素等)进行主动应对和管理,降低或者消除消极事件对项目的影响。

来看一个场景,项目中最常见的风险:“人力不足,进度紧张,可能导致项目不能按期交付”。当项目经理看到这个风险后,一般会把它记录到风险管理计划中,制定措施,花大量的精力去协调,每周跟踪进展……但这类风险往往会真的发生,变成问题,导致项目延期交付。于是项目经理觉得风险管理没有用,下一个项目做不做都无所谓。当然有这种想法也是人之常情,可我们仔细想一想,这真的是风险管理造成的吗?回到风险管理的定义,风险管理只是一种方法,一种管理风险的方法,目的是降低或消除消极事物对项目的影响,但并不能解决业务上的问题。风险管理能帮你找到更多的人力?能帮你减少客户需求?能帮你延长项目交付时长?答案很明显,风险管理并不能规避所有风险,它不是万能的,业务的问题需要用业务方法去解决。

也谈风险管理
也谈风险管理

这里涉及到了另一个问题,评价风险管理成功的标准是什么?我觉得不是风险是否发生,而是有没有使项目产生预料之外的损失。

二、风险管理需要策略

前几天一个QA同事来找我,咨询如何做好风险管理,她说她们版本比较复杂,涉及与多个其他项目配合。项目组识别出了很多风险,并全部记录在风险管理计划中,每次开项目例会会逐条过,需要花一半的例会时间来跟踪风险,费时费力,但效果却不好。

回想一下,我们在项目中实施风险管理的时也是这样。项目经理召开版本例会,组织各领域人员通过头脑风暴的方式识别风险,生怕遗漏了一条。然后全部记录到风险计划中,并且对每个风险都制定规避措施,应急计划,也不管这个风险是否能够规避。后续每次例会都拿出来跟踪,并补充新识别的风险。项目开始的时候还比较认真的填写和跟踪。到了项目后期,大家忙于处理各种问题,风险管理计划慢慢的就束之高阁了。这样的风险管理效果显然是不好的,但问题出在哪里呢?

大家学习过风险管理,应该知道要进行风险排序,那么排序的原因是什么?是因为项目资源有限(人员,时间,设备等),不可能管理所有风险,所以只能将有限的资源聚焦到高优先级的风险上。这就是一个策略,将有限的资源用于主要的风险上。我们在实施风险管理时同样需要策略。例如上一章中举得那个风险的例子“人力不足,进度紧张,可能导致项目不能按期交付”,如果我们已知这个项目人力无法增加,需求也减不了多少,进度计划无法延期,也就是说这个风险必然会变成问题,那么为什么还要去对其制定规避措施,为什么还要周周去跟踪,花精力去协调,还不如将这部分资源用到其他可以去管理的风险上。对于这个风险,我们能做的就是做好应急准备,尽量减小损失,这就是对于这项风险的策略。

也谈风险管理
也谈风险管理

关键是优先级

策略对于风险管理是非常重要的,但看看我们的风险管理计划,可能恰恰缺少了对风险策略的识别。在识别出一个风险后,版本经理需要根据项目实际情况,先确定每个风险的应对策略,再来有针对性的制定措施。常见的风险管理策略有“规避”,“转移”,“减缓”,“接受”。上面这个例子中使用的就是“接受”的策略,不过“接受”也分为积极的接受和消极的接受。对于那些无能为力的风险,不如潇洒的接受,将有限的资源用到其他能够管理的风险上。当然,项目的情况会不断的发生变化,风险的策略也应随之调整,以聚焦有限的资源。

三、风险管理方式也要与时俱进

研发项目常见的风险管理方式是使用风险管理计划模板,要么就是项目经理自己用excel做一个表单进行跟踪,也有的公司用IT系统来管理风险,但不管哪种方式,都是将所有风险记录下来,定期在项目例会上跟踪。自从敏捷开发模式风靡后,研发项目的项目管理方式发生了很多变化,例如管理用的表格少了,站着开的会多了,干净的玻璃没了……但风险管理的方式却没变,这与敏捷下的项目管理方式产生了一定的冲突,风险管理实施起来变得更加困难了。

我跟某家通过CMMI5级的印度公司的专家进行过几次交流,从交流中得知他们也遇到敏捷对传统项目管理方式的冲击,正在研究CMMI与敏捷的融合。我们也从他们那里也学到了一些思路。例如他们使用了一个“风险管理严格度”的概念,也就是对于不同的风险,采取不同严格程度的管理。比如可以将风险分为“短期风险”和“长期风险”。

“短期风险”就是能在24小时内或在一轮迭代中被解决的,且影响较小的风险,对于这种风险,可以不必按正式的风险管理方式管理,此风险可不记录在风险管理计划中,只需要通过项目组状态墙,简单事务跟踪,每日站会等方式,由子项目组或迭代开发小组自己去跟踪解决。

“长期风险”包括任何关于关键资源有效性的风险;所有涉及外部依赖的风险,其关闭日期较长的风险;任何直接影响项目交付的质量,技术和进度的风险。总的来说就是风险优先级比较高的风险,由于这类风险会对项目产生较大影响,则需记录到风险管理计划中,严格的记录和管理。

这种管理方式既符合CMMI模型中定义的风险管理要求,又满足我们现有的敏捷管理方式,还能聚焦版本内有限的资源。

四、风险可以更精细的管理

再看看前面项目组遇到的那个问题,“识别出了很多风险,全部记录在风险管理计划中,每次开项目例会都会逐条过,几乎要花一半的时间来跟踪风险”。先问一个问题,是否每个风险都需要在例会上跟踪?有人会说,在制定风险管理计划时会定义风险的优先级(发生概率×影响程度),然后按优先级进行风险排序,先跟踪优先级为“高”的风险。但如果优先级为“高”的风险也很多,怎么办?

我们知道,项目中不同阶段一般会受不同风险的影响,例如人力不足的风险,在项目早期阶段(如系统分析与设计)如果发生往往影响不大,但在后期的开发、测试阶段就很致命了,还有类似需求不稳定这类的风险也是一样。所以并不是所有风险都必须从头跟到尾的,风险的规避措施也不是从项目一开始就要实施的。但有人可能会说,如果不一直跟踪,可能会遗漏。这时我们需要更加精细的对风险进行管理,如为风险设置阈值((yù zhí)),定量化的进行管理。

我们将一个触发风险即将变成问题的临界值称为阈值,可以将阈值作为风险发生的警戒线。再来看看这个“人力不足,进度紧张,可能导致项目不能按期交付”的风险。对于这个风险需要管理的是“不能按期交付”,也就是进度延期。当然项目延期不会是在最后一天才知道,在项目过程中也会有所表现,如果被我们及时发现,那么还可以实施一些措施来补救和追回。这时就可以为这个风险设置阈值,例如将项目进度偏差设为15%,即如果在项目过程中进度延期超过15%,项目组就需要采取应急措施,否则可能导致项目最终不能按期交付。然后将这个度量项加入到项目的度量系统中,并定期监控度量数据,一旦达到阈值,立即采取措施。当然并不是所有的风险都能设置阈值,定量化的管理也会带来一些管理上的成本,这需要我们结合项目具体情况来综合考虑。还有阈值设置为多少,这也是一个问题,这需要组织级持续收集,建立风险管理的经验、数据库,为项目使用提供依据。

也谈风险管理
也谈风险管理

上述这几点是我个人认为可以提高风险管理效率的方法,当然还有很多其他的方法,例如共享风险管理案例、风险管理IT化等。但不管用什么方法,风险管理的效果还是取决于我们是否想管好风险,是否动手去做。

发表评论

登录后才能评论
服务中心
服务中心
联系客服
联系客服
返回顶部