别说你懂项目管理

 

原作者:刘磊

 

【导读】先画蓝图，再搭积木，像管理工程一样进行软件开发项目管理。今天的软件开发者，更应该是一个工程师，而不是艺术家。

　　先画蓝图，再搭积木，像管理工程一样进行软件开发项目管理。今天的软件开发者，更应该是一个工程师，而不是艺术家。

 

　　Walker Royce认为，今天的软件开发者，更应该是一个工程师，而不是艺术家。

 

　　先画蓝图，再搭积木，像管理工程一样进行软件开发项目管理……这样的话我们早已经不是第一次听到，但是软件企业，尤其是国内的软件企业，真正能把软件开发项目像工程一样管理起来的有多少?大多数的软件企业依然处在一个需求→开发→需求→变更→需求→再变更……交付→变更……的可怕流程当中，过程缺乏有效的项目管理、质量控制、变更管理、发布管理、知识管理……正是管理流程的混乱导致了软件开发项目的失控，乃至失败。

 

　　尤其是国内众多软件公司正在与印度软件公司争夺欧美市场的今天，用中创软件董事长景新海的一句话说就是，“我们再也不能做高科技的‘农民’了!这样很危险。”这与Rational亚太区总经理Walker Royce在IBM2005开发者大会上所说的一句话异曲同工，“今天的软件开发者，更应该是一个工程师，而不是艺术家。”

 

　　从农民到工程师

 

　　软件企业里“高科技农民”的具体表现是什么?

 

　　无外乎以下几点:首先，没有项目管理意识。很少有农民会把自己的种植过程当成一个项目来运作，比如花时间去想今天种哪一亩地，或者明年种什么作物，又或者种植过程中家里人怎么分工，其往往是按照春种秋收等老经验，家里人也是谁想插秧就插秧，谁想耕地就耕地……没有明确的分工。Walker Royce所说的艺术家也是如此，灵感来了就大笔挥毫，没有什么工作计划。

 

　　但是软件开发假若如此，后果便会非常可怕。大型软件编程的工作复杂程度可谓千头万绪，假若没有项目管理，人员配置的混乱会大大降低软件开发的效率，也会增加出错率;没有工作计划，没有里程碑时间的控制，整个项目的时间将无法预估，而一旦超时，对于软件公司来说就意味着项目利润的逐渐流失;目标的不明确后果更糟，很可能最后的软件货不对版。

 

　　对此，国内的大多数软件企业，已经有很多通过了CMM或者CMMI的等级认证，像东软、摩托罗拉软件开发中心等还达到了CMM5级，由于CMM(软件开发成熟度模型)的要求，这些企业或多或少都有自己的软件开发管理流程，也已经开始用项目管理的理念来进行软件开发工程的管理。然而直到今天，用户依旧在抱怨开发周期太长，软件企业也依旧如此……

 

　　其次，缺乏质量控制和变更管理。老天爷说变就变，农民很难预测，如果遇上冰雹或是霜冻，也只能自叹倒霉。但是软件开发项目动辄上百万，程序上千万条，假若由于过程中的质量控制出现问题而倒回来追溯，如果没有变更管理工具的帮助，这几乎是不能实现的任务。还有假若在开发途中不能及时进行质量控制，比如喷喷农药什么的，最后发现问题，或者干脆到交付之后再发现问题，即使可以补救，也会耗费大量的人力、物力。据笔者所知，一些软件企业的项目本来利润就不多，就是由于经历了这样的返工，而导致成本无法收回。

 

　　最后，是知识管理。就像一个壮劳力可以把家里所有的活都一肩挑一样。软件开发项目组经常会有这样的“软件天才”出现，结果软件开发组往往可以依赖此人的能力，无论是创意、开发、测试……他都要参与，但是假若此人离开，此软件开发组的水平便会急剧下降……记得国内某著名软件开发中心的主管曾经说过，“我们最担心的不是钱的问题，而是人的问题，往往有人离开的时候，就会带走我们的大量资源。”这就是知识管理没做好的极端情况。

 

　　因此把软件开发项目从无序的开发过程变成可控的，可追溯的，经验可以循环复用的项目管理下的软件工程，才是软件开发的成功之道。

 

　　增量式改进

 

　　但是引进项目管理来管理软件工程并非一试就灵，国内企业实施项目管理，最终不见成效的也不少，因为，项目经理从中发现，根本没办法把各方面资源都管理起来。

 

　　Walker Royce坦承，在Rational的内部他们也曾遇到过这样的挑战，今天的IBM也是如此，他们也面临怎样把很多互相之间没有联系、互相之间有很大不同的软件资产或者一些系统能够放到一起，成为一个更有用的东西的问题。“所以我会建议人们使用我们在内部自己采用的一些方法，就是所谓的增量式改进，不是把原有系统全部推倒重来，而是站在一个生命周期最后往前看，看看怎样发表、怎样测试、怎样去改进这样一些软件的资产。”

 

　　他认为，要实现项目管理的成功，企业必须要把目光关注在三个主要的方面上，一个是项目管理，另外一个是发布管理，还有一个是变更管理，做好这三项最基本的内容，才可以保证项目成功。“只有做好这三项最基本的内容，才可以提升到更高层次，比如范围管理、需求管理等等。做好这两点再往上一层就是项目的资产管理，一层层往上走。很多企业犯的错误就是一下子改变太多东西，实际上一下子变的太多就很有可能导致失败。另外，一个常见失败的模式就是很多企业是从需求管理入手，因为需求管理是很多企业的一个薄弱环节，他们试图用一个全新的手段来管理他们的需求，但是在其他的管理手段，比如变更管理、发布管理等没有做好的时候，他们没有办法区别新的办法和他们以前的管理办法有什么区别，所以我建议从变更管理、从发布管理等去入手，这样比较容易让企业去度量，看看做了改进之后是否比以前做得更好。”

 

　　但是从另一方面看，参与此次大会的一些演讲者也提出，在做项目的时候，尽管项目团队必须要遵循一个正式的流程，但是在与用户的交流过程中，他们可能不相信你采用的流程，不相信你的流程可以交付出这种高质量的产品，因此一种新的趋势是要把传统的产品改变成交互式的产品，让用户看到交互的结果，在这个过程中，可以获取用户的反馈，这样才可以真正开发出让用户满意的软件。

 

　　也就是说，从业务的角度来讲，软件开发正在从基于文档的开发转向交互式开发。因为增量式的开发存在交互，工程师可以知道交给客户的东西是否真正可以满足客户的要求。这样可以得到他们的直接反馈，如果开发不可以满足业务的要求，就可以马上取消，从而保证软件开发可以帮助推动用户的业务发展。

 

　　记者手记

 

　　软件开发需要变成软件工程，开发者要变成软件工程师，这是公认的趋势。但是看到IBM本次开发者大会将项目管理作为重点，笔者心里也在嘀咕，是否每个开发者都必须要懂项目管理?人们经常把出色的程序员称之为“技术的疯子”，因为他们往往对技术狂热，但是却对管理漠视。难道要他们也来学习一下项目管理?

 

　　IBM大中华区软件部市场总监左洪认为这很自然，“之所以在开发者大会上谈论项目管理，是因为对于中国软件工程师来说，我们不仅仅希望他们在这里得到技术上的交流，也希望他们在盖房子之前，就有一个蓝图在心里，而不是糊里糊涂地去做。”

 

　　所以，在软件开发团队当中，除了中层项目经理需要用项目管理来管理项目推进以外，普通的开发者，也要在大脑里接受项目管理的经验，这样，用项目管理来管理企业的效果才能更好地显示出来。