IT项目管理从某个意义上来说,是风险管理。从理论上讲风险管理可以分为三个部分:风险识别、风险分析和风险解决。 传统的风险管理系统只能帮我们较正规地统计和管理风险,这些系统本身是不能规避或解决任何风险的。在实际操作上,由于可能发生风险的种类很多,处理起来所耗费的人力物力也相当可观。在下列的案例中,我们建议的不是一套昂贵而且全面的风险管理系统,而是一套扼住关键部位,高效且低成本,适合于千万中小企业的小型解决方案。

  一个案例

  在2009年某家在北京海淀区的嵌入式产品公司跟我们讨论项目管理时,该公司的王总监跟我们做了以下沟通。他们项目风险种类可以概略分为四类:

  (1)需求风险 ??对需求理解不够透彻或需求变更频繁;

  (2)人员风险 ??人员生病或离职,一时无法找到替代者;

  (3)技术风险 ??某个关键的技术问题无法快速攻克;

  (4)管理风险 ??管理人员协调能力和执行力能力不足,计划偏差,流程更改和沟通不良等。

  这些风险的发生导致的结果是项目延期和成本大幅攀升。无法有效处理这些风险的两个大问题在于:

  (1)对风险的反应迟钝 ??常常是太晚发现问题,以至于无法弥补或是弥补成本太大;

  (2)对过程难以掌控 ??虽已有既定的流程,但由于人员变动、流程变动、系统出错等问题,很难照着走。

  为了让我们更理解,王总监很生动的解释了以上两个问题。对风险反应迟钝的问题,他说,在做项目计划时为求实际,总会多估个20%到40%的时间。如果项目需求清晰,或是团队做过类似项目,用20%或多些;如果是新项目,或风险因素多便用30%到40%。所以,当某些风险(如,需求变更或人员变动)发生了,一般也未必马上造成项目延期。可是,如果风险发生量继续增加,或是某一两个风险产生较严重的冲击,在某个时刻会过了临界点。难的地方是项目大人员多,是连项目经理也是见树不见林。

  对过程难以掌控的问题,王总监举了个例子。公司的研发制度里规定,为保证需求的准确性,一个需求的变更要经过(1)该项目经理,(2)一位程序员,和(3)该产品经理,等三个关键人审核后才可以进行更改。王总监说:需求变更的过程在逻辑上看似简单,但在实际操作时却不断地发生问题。举例来说,内部沟通主要是以邮件通知的方式进行,需求变更的文档寄来寄去,版本很多,而且邮件总是遗失。另有一次更严重,产品经理因为休假,没能及时查邮件。在等了两天后,因怕误了工期,项目经理便越权要求程序员把代码写了。不巧,产品经理对这需求的更改有他强烈的意见。当他看到在没得到他的同意下把代码写了,火冒三丈,直接在会议中和项目经理吵了起来。

  两个控制风险的原则

  虽然风险总是发生,但如同大多数的公司一样,该公司也不愿意花费太多的精力和时间在这风险管控上,所以在寻求一个低成本又高效的管控方法。王总监和我们在研讨后,使用工具DevSuite基于下列两个原则做了处理。(为避免篇幅太大,以下我们仅把精彩的点列出来。)

  (1)提高项目的可视性

  不论是哪一种风险,其后冲击的基本上是项目本身,延期是常见的结果。如果是对可能发生的风险都一一进行管控,成本必然很高,而且还可能有疏漏。使用燃尽图(Burn Down Chart)可能是针对项目延期有效的解决办法,因为它很大程度地提高了项目的可视性。在实际操作时,我们让团队成员每天对其参与的每一任务都键入下列两项数字:1)该任务花费时间,和2)该任务所剩时间。结果会生了类似如下的燃尽图。

  如图所示,起初这项目被估计是要3480小时完成。大致上来说,一般的研发团队因着人员请假、会议和其他突发事情,平均每人每天只能有六小时花在实际项目工作上。现这项目有七个人参与,估算出来大约需要四个月完成。(也是从2009年11月29日到2010年3月29日,图中红色直立线为起始线,蓝色直立线为终止线。)这图里共有三条曲线。红色号码?/span>表示到现在为止在该项目的总花费时间,红色号码?表示估算的项目剩余时间,红色号码?是到目前为止所花的时间与剩余时间之和的曲线。到了2010年3月21日得到了上面的这个图。到了这,我们发现原本估计的3480总小时数是低估了,更可能的是?所示的3740小时。