【导读】先画蓝图,再搭积木,像管理工程一样进行软件开发项目管理。今天的软件开发者,更应该是一个工程师,而不是艺术家。 先画蓝图,再搭积木,像管理工程一样进行软件开发项目管理。今天的软件开发者,更应该是一个工程师,而不是艺术家。
Walker Royce认为,今天的软件开发者,更应该是一个工程师,而不是艺术家。
先画蓝图,再搭积木,像管理工程一样进行软件开发项目管理……这样的话我们早已经不是第一次听到, 但是软件企业,尤其是国内的软件企业,真正能把软件开发项目像工程一样管理起来的有多少?大多数的软件企业依然处在一个需求→开发→需求→变更→需求→再 变更……交付→变更……的可怕流程当中,过程缺乏有效的项目管理、质量控制、变更管理、发布管理、知识管理……正是管理流程的混乱导致了软件开发项目的失 控,乃至失败。
尤其是国内众多软件公司正在与印度软件公司争夺欧美市场的今天,用中创软件董事长景新海的一句话说 就是,“我们再也不能做高科技的‘农民’了!这样很危险。”这与Rational亚太区总经理Walker Royce在IBM2005开发者大会上所说的一句话异曲同工,“今天的软件开发者,更应该是一个工程师,而不是艺术家。”
从农民到工程师
软件企业里“高科技农民”的具体表现是什么?
无外乎以下几点:首先,没有项目管理意识。很少有农民会把自己的种植过程当成一个项目来运作,比如 花时间去想今天种哪一亩地,或者明年种什么作物,又或者种植过程中家里人怎么分工,其往往是按照春种秋收等老经验,家里人也是谁想插秧就插秧,谁想耕地就 耕地……没有明确的分工。Walker Royce所说的艺术家也是如此,灵感来了就大笔挥毫,没有什么工作计划。
但是软件开发假若如此,后果便会非常可怕。大型软件编程的工作复杂程度可谓千头万绪,假若没有项目 管理,人员配置的混乱会大大降低软件开发的效率,也会增加出错率;没有工作计划,没有里程碑时间的控制,整个项目的时间将无法预估,而一旦超时,对于软件 公司来说就意味着项目利润的逐渐流失;目标的不明确后果更糟,很可能最后的软件货不对版。
对此,国内的大多数软件企业,已经有很多通过了CMM或者CMMI的等级认证,像东软、摩托罗拉软 件开发中心等还达到了CMM5级,由于CMM(软件开发成熟度模型)的要求,这些企业或多或少都有自己的软件开发管理流程,也已经开始用项目管理的理念来 进行软件开发工程的管理。然而直到今天,用户依旧在抱怨开发周期太长,软件企业也依旧如此……
其次,缺乏质量控制和变更管理。老天爷说变就变,农民很难预测,如果遇上冰雹或是霜冻,也只能自叹 倒霉。但是软件开发项目动辄上百万,程序上千万条,假若由于过程中的质量控制出现问题而倒回来追溯,如果没有变更管理工具的帮助,这几乎是不能实现的任 务。还有假若在开发途中不能及时进行质量控制,比如喷喷农药什么的,最后发现问题,或者干脆到交付之后再发现问题,即使可以补救,也会耗费大量的人力、物 力。据笔者所知,一些软件企业的项目本来利润就不多,就是由于经历了这样的返工,而导致成本无法收回。
最后,是知识管理。就像一个壮劳力可以把家里所有的活都一肩挑一样。软件开发项目组经常会有这样的 “软件天才”出现,结果软件开发组往往可以依赖此人的能力,无论是创意、开发、测试……他都要参与,但是假若此人离开,此软件开发组的水平便会急剧下 降……记得国内某著名软件开发中心的主管曾经说过,“我们最担心的不是钱的问题,而是人的问题,往往有人离开的时候,就会带走我们的大量资源。”这就是知 识管理没做好的极端情况。
因此把软件开发项目从无序的开发过程变成可控的,可追溯的,经验可以循环复用的项目管理下的软件工程,才是软件开发的成功之道。
增量式改进
但是引进项目管理来管理软件工程并非一试就灵,国内企业实施项目管理,最终不见成效的也不少,因为,项目经理从中发现,根本没办法把各方面资源都管理起来。
Walker Royce坦承,在Rational的内部他们也曾遇到过这样的挑战,今天的IBM也是如此,他们也面临怎样把很多互相之间没有联系、互相之间有很大不同 的软件资产或者一些系统能够放到一起,成为一个更有用的东西的问题。“所以我会建议人们使用我们在内部自己采用的一些方法,就是所谓的增量式改进,不是把 原有系统全部推倒重来,而是站在一个生命周期最后往前看,看看怎样发表、怎样测试、怎样去改进这样一些软件的资产。”
他认为,要实现项目管理的成功,企业必须要把目光关注在三个主要的方面上,一个是项目管理,另外一 个是发布管理,还有一个是变更管理,做好这三项最基本的内容,才可以保证项目成功。“只有做好这三项最基本的内容,才可以提升到更高层次,比如范围管理、 需求管理等等。做好这两点再往上一层就是项目的资产管理,一层层往上走。很多企业犯的错误就是一下子改变太多东西,实际上一下子变的太多就很有可能导致失 败。另外,一个常见失败的模式就是很多企业是从需求管理入手,因为需求管理是很多企业的一个薄弱环节,他们试图用一个全新的手段来管理他们的需求,但是在 其他的管理手段,比如变更管理、发布管理等没有做好的时候,他们没有办法区别新的办法和他们以前的管理办法有什么区别,所以我建议从变更管理、从发布管理 等去入手,这样比较容易让企业去度量,看看做了改进之后是否比以前做得更好。”
但是从另一方面看,参与此次大会的一些演讲者也提出,在做项目的时候,尽管项目团队必须要遵循一个 正式的流程,但是在与用户的交流过程中,他们可能不相信你采用的流程,不相信你的流程可以交付出这种高质量的产品,因此一种新的趋势是要把传统的产品改变 成交互式的产品,让用户看到交互的结果,在这个过程中,可以获取用户的反馈,这样才可以真正开发出让用户满意的软件。
也就是说,从业务的角度来讲,软件开发正在从基于文档的开发转向交互式开发。因为增量式的开发存在 交互,工程师可以知道交给客户的东西是否真正可以满足客户的要求。这样可以得到他们的直接反馈,如果开发不可以满足业务的要求,就可以马上取消,从而保证 软件开发可以帮助推动用户的业务发展。
记者手记
软件开发需要变成软件工程,开发者要变成软件工程师,这是公认的趋势。但是看到IBM本次开发者大 会将项目管理作为重点,笔者心里也在嘀咕,是否每个开发者都必须要懂项目管理?人们经常把出色的程序员称之为“技术的疯子”,因为他们往往对技术狂热,但 是却对管理漠视。难道要他们也来学习一下项目管理?
IBM大中华区软件部市场总监左洪认为这很自然,“之所以在开发者大会上谈论项目管理,是因为对于中国软件工程师来说,我们不仅仅希望他们在这里得到技术上的交流,也希望他们在盖房子之前,就有一个蓝图在心里,而不是糊里糊涂地去做。”
所以,在软件开发团队当中,除了中层项目经理需要用项目管理来管理项目推进以外,普通的开发者,也要在大脑里接受项目管理的经验,这样,用项目管理来管理企业的效果才能更好地显示出来。