上周看到了一组很好的风险过程管理的实例。大概的情况是这样的:
采用了瀑布型生命周期,在需求分析开始时,估算了需求的规模约是1100个功能点。
识别了风险:标题是需求存在不确定性,可能来不及。缓解措施是加强与产品经理的沟通。
需求进行到一半,识别了人力资源风险,人力资源存在短缺,缓解措施是加了一个工程师。
以上风险每周都得到了跟踪。
到上周的情况是:原定需求里程碑已经过去了1周多,识别的功能点约是700多个,不超过800个。项目成员反馈说:主要是产品经理对有一大块功能难以确定,如果项目组说不做,产品经理估计也不会有意见。
单从风险的识别和跟踪看,过程走得不错,但是结果却不好。在规模缩减1/3的情况下,需求里程碑拖期了,这不是很合理。
在培训时,为了推动开展风险和问题管理,常常说到风险和问题管理能够帮项目组撇清责任,万一项目失败,项目组不会承担全部责任。从这一点看,做好风险和问题管理就是对项目组有利的。
但是风险管理过程的首要目的是好的结果。仅仅靠识别风险、跟踪风险是不够的。通过有效而且有力的措施让风险和问题向好的方向发展,也是风险管理的要点。
创新过程的目的也是好的结果。有这样的例子。一个组织在2009年启动了创新活动,鼓励项目试行新过程,开发新特性。到2010年1季度,其中一个项目组的创新申报达到20个以上,每个申报都是一篇文档,其开发人员数量最多时有4位。为方便叙述,将这个项目称为A项目,过程类试行有:标准文档制作计为软件规模;每日构建失败后专人处理;交付包时计划人员的技能升级
在2009年A项目原定每季度进行一次正式基线测试,但由于种种原因,只在2009年底进行了1次正式基线测试。在2010年初开始,陆续有3个项目利用该项目的成果,最多的一个项目识别出46个问题,要求A项目解决,最少的一个项目列出了10多个问题,要求A项目解决。
创新现在很热门,反对创新的话谁也不敢说。但是好结果好的产出应当放在第1位。
过程方法是ISO9000的8大原则之一,我们从来不会否认过程方法的重要性,但更重要的是过程方法的目标是好的结果。过程是为结果服务的。
当然项目的不好结果不一定影响个人的结果。有些员工在过程中展现相关的工作产品,参加各类活动,符合领导的期望,获得领导好评,这样已经达到了个人好结果的目的。这里就出现了项目目标与项目成员目标不一致的情况。
原文见 http://hi.baidu.com/hespr/blog/item/97dbbb8851e1e0bf0f2444b1.html