管理软件风险,防患于未然

类别:软件工程 点击:0 评论:0 推荐:

 

    我是做软件的,入行也有近10年光景,早些时候写过一些C和汇编,然后玩了几年Delphi,这几年摆弄一些JAVA的东西。积累了一定程序经验以后,就没有太多时间写程序了,大多围绕一个项目,跑前跑后的。工作占去了大部分时间,用我太太的话说,从来没有看到别人像我这么忙的。我太太是学文的,对这行的情况不是很了解,虽然有些同行不很忙,但更多的人,像我一样在透支着大量的智力和体力,在不断地追寻着新奇和变化,当然也还有谋生的因素在里面。

熬夜并不是鲜见的事情,尤其是项目截止日期将至,大家需鼓足干劲,调动起每一个纤细的灵感和智慧,克服一个又一个的困难。当一个项目上线的时候,一缕白发也偷偷上线了。当然,如果能如期完成任务,再大的辛苦也觉得欣慰,可怕的是,时间一天天临近,项目人员却一天天绝望,不得不考虑项目延期了。

伴随着从业人员的痛苦,软件工程、项目管理、过程控制、能力成熟度等知识开始被大家接受,这方面的书也出了很多。我们在理论和实践的碰撞中一步步成长,项目管理就有些模样,至少有了配置管理和版本控制,并引入了里程碑检查。按说理论增强了,控制能力提高了,工作就能更加游刃有余,可事情好像远没有想象的那样美好,生活还是一个字形容“忙”,我太太对我,也就越来越绝望,在她眼里,我对项目的控制,似乎就为零,其实,忙乱的原因,很大部分是由于项目风险控制出了问题。

人的很多快乐得益于反思中的成长,这段时间由于工作的压力变得更大,考虑得也更多了。前些天,朋友送了我一本书,《与熊共舞——软件项目风险管理》(清华大学出版社,2004年3月),不是很厚,我在乘地铁上下班的时候,就看完了,受到一些触动。

 

这几年软件开发的能力确实是提高了,编制的质量越来越好,也可以服务更大的客户群体。97年前后,做过一段医院管理软件,当时哥儿几个坐在一起讨论了几次,方案就定了,之后就开始写程序。主体采用DCOM技术,用delphi 2 开发,还采用了delphi自带的vcs版本控制。vcs的使用培训就进行了很久,还老有人搞错,现在我见到的程序员大多数都会用vss了,还有些能使用clearCase,已不需要太多培训。DCOM的技术当时还非常新,技术资料很少,系统出来以后,发觉技术选形不是很好,系统的时间响应比较慢。现在技术进步了,软件架构和模式的文章,在互联网上非常多,程序分层普遍,也有很多性能优化的方法,这种事情就发生的少了。当然最重要的一个变化是,对设计和文档的要求越来越高,测试也开始引起大家的足够重视,全面提升了软件的品质。

可软件技术的提高,并没有解决软件业忙乱的困境。当我们把更新的软件和技术带给用户的时候,也培养了用户的使用能力和鉴别能力,用户变得成熟起来,需求也更加细致和苛刻,这就对软件的品质提出了更高的要求,开发的时间并不容易省下来。而且,当我们环视四周,软件公司如雨后春笋成长起来。像其他生产过剩的行业,软件行业基本上变成了买方市场,软件提供者间的竞争越来越激烈。在与软件企业的博弈中,客户利用市场优势占据了上峰,软件企业就必须提供更好的产品和更低的价格才能获得订单。这样,留给企业的利润空间变小,企业的风险增大,风险管理就显得更加必要。

那么,企业要怎样才能以更低的成本和更短的时间提供更好的产品呢?规模优势和工业化是解决这个问题不错的思路,可是,中国的软件企业,规模都较小,难以生产出标准化的产品,也就不容易形成规模化和工业化的优势。尤其是,市场形成了一种概念,认为软件是非常具有柔性的产品,是可以随意更改的,这就为实现工业化带来了更多困难。

我们公司主要提供企业的知识管理和竞争情报解决方案,由于技术比较新,常常需要按照客户的要求进行定制。在接触客户的过程中,客户必然会问你工期的问题,如果时间太长,有可能会把客户吓回去,要知道,现在社会的节奏加快,如果工期短的话,那不就又给自己加了一道紧箍咒吗?技术出身的人常常会有一些英雄主义的色彩,过高估计了自己的实现能力,而销售人员又不太了解开发的过程,当然愿意项目早日完成,于是定下的时间常常会短于正常的工期,这里既然种下了加班的种子,后边自然就会生根发芽了。

《与熊共舞》这本书,提倡对项目风险进行量化估计,并给出了一种称为“风险图”的不确定性描述图形,来预测项目的可能完成时间。“风险图”比主观想象更直接、更科学地表明了风险的范围,使用这个工具,也更容易进行风险分析和防范。

书中,“进度安排的先天错误”被列为项目核心风险的第一条,需要引起足够重视。为了有效降低这个第一风险,我觉得有多种方法可以使用:尽量争取给项目一个比较好的外部环境,通过与用户的沟通及其他手段,为项目争取较充足的开发时间,不要一拍胸脯就把风险留给自己了;要科学估计项目执行中的风险,对人员变动、需求变更等容易引起项目延期的事情要有足够的警惕。如果时间余地比较小,要配置多一些资源,如果资源不够,可能要及早安排加班,避免犯前松后紧的毛病。软件开发过程中的问题层出不穷,你考虑多一点的风险都不一定够用,如果英雄主义情绪旺盛的话,受伤害的还是自己。项目中的其他一些风险和估计风险的办法在书里还有更多的阐述。

激烈的竞争环境给软件开发带来了巨大的挑战,需要企业不断去优化资源,提高效率,推行有效的项目管理方式。巨大的风险带来了挑战也带来了机会,如果能从一次次项目经验中成长起来,企业的竞争能力无疑会增强。书中比较推崇用“增量式”的开发方式来及早发现风险,化解风险,有一定的借鉴意义。当然,增量开发对项目的开发管理提出了更高的要求,也要求项目的开发时间相对比较长一些。具体的开发方式还要根据项目的不同而有所差异, RUP和XP的开发模式,应该是比较好的选择,具体情况还要根据企业的特点而定,并且,开发模式会在企业的发展过程中有所改变和提高。

 

风险管理并不是一个新鲜的课题,可以看看国内这几年发展迅速的保险行业,社会领域的风险概念还是引起了大家的足够重视。但是人们并不是什么保险都买,选择性还是很强的,选择的时候大量考虑了风险和收益的问题,这是一个博弈的过程。

以前我们在项目计划中也会有10%到15%的风险,但执行过程中常常没有给予足够重视,导致项目最后的完成受到影响。没有给予足够重视的潜意识,是不愿意付出这部分的成本,希望能获得更大的收益,有一些侥幸的成分。另一个可能的原因是,企业付不起这部分成本,它甘愿去冒风险,因为如果加上这部分成本,项目就根本无法赢利。

企业需要生存,而且也愿意生存的好一些,国内软件业的现状也常常影响到大家对风险的正视程度,随着企业的成熟,风险管理也会更加正规。但无论如何,风险意识是一定要存在的,并且要想办法防范和规避主要风险,否则触礁的机会就太大了。

我和太太曾经在天黑以后爬到还未完工的19层楼,不巧就遇上了停电,在漆黑一片中,我和她都感到危险,虽然最后摸黑安全地走到楼下,却也出了一头一手的汗。如果把摸黑走下19层楼称为风险的话,对它的规避是可以用较小成本的,有一把手电就行,当然也能用较大成本的规避办法,比如给这个楼装上双路供电。还有一个更节省的办法,我们白天来不就可以了吗?类似的想法还可以延伸下去。我无意提供一种投机的手段来解决风险管理的问题,我是想说,如果我们能多一点风险意识,及早采取一些办法,是能以较小的代价获得更大利益的。如果没有这种意识,你就不可能未雨绸缪,如果没有幸运一直垂青的话,受损失的可能性就比较大了。

风险管理是一种全局意识,管理好了风险,可以避免一些手忙脚乱,少一些救火的事情。项目尽在掌握,我就可以多一点时间陪陪家人,享受生活,我老岳父不远千里寄来的明前茶,也就用不着牛饮,可以慢慢品出味了。

本文地址:http://com.8s8s.com/it/it37106.htm