UML软件工程组织

如何在需求不断变化的项目中取得成功
来自:mypmp 转载:李守京 51CMM.COM
在中国软件行业现状中,恶性竞争比比皆是,而恶性竞争的产生物:合同,导致大中型软件项目中,项目组面临着在时间上,成本上和人力上都不切实际的目标,一个在标准含义上注定要失败的项目;而项目组对于这种项目要做,并且还要尽量做好,同时由于客户成熟度不够,而造成更多的问题。
根据个人的经验,如果照合同中列出的项目范围来做,从狭义的项目范围角度来说是可以完成的,但客户既然付了钱,他将不断努力最大化他的利益,扩充并充实需求的内容,所以项目组面临着项目中从始至终需求不断变化的过程。
在做好基本的需求控制的基础上,既然面对不断变化的需求,就要求项目组对事件的反应要快。
在这种快节奏的项目环境中,充满了太多的不确定因素,成功的按时完成项目就像是一场长距离障碍跑。项目组经常要在没有完整确切的数据情况下决定如何做,项目范围的重点和方向要经常改变,如果软件承包商内部不协调一致,复杂的项目将经常会陷入泥潭,不能自拔。
这种项目中标准的项目管理手段不再适用,它需要很多特别的资源去处理不确定的方面,更有弹性的项目管理手段和反应时间是必要的,灵活的项目管理手段将是此类项目的最终方法。
什么是灵活的项目管理
做过软件项目管理的项目经理的人都知道,在客户的需求和项目组能够提交的成果之间找到一个完美的平衡点不仅仅是一种项目管理手段,而是一种艺术,如果按照标准的项目管理流程,项目可能永远不会完成,比如在合同中或销售环节中承诺,所提供的系统将满足客户在未来几年中的业务需求;但实际上这是不可能的,特别是行业软件项目,中国各个行业处于快速发展的过程中,业务需求不断在增加,如果不在项目和业务需求之间达到平衡,项目将不再是一个利润点,而是一个成本点。这就要求在标准的项目管理手段之外增加一些新的概念和技巧来适应飞速变化的项目环境。
那什么是灵活的项目管理呢?
由于在实际项目的某些方面,标准项目管理方法不再具备有效性和可操作性,所以有些公司试图抛开项目管理标准方法,独立制定符合自己实际的项目管理流程,而在不断尝试的过程中,他们在很多核心管理方面又不得不遵循标准项目管理手段,这就造成了困扰,什么是一种有效而可行的项目管理方法?
所以说,灵活的项目管理不是一种独立的项目管理模式,而是基于标准项目管理基础上的一种很大的发展延伸。就像一个城市的地铁站台,她的基础是标准的,牢固地,就像标准项目管理,而站台和所运行的地铁之间的差距需要根据地铁的实际形状来加以适当的延伸,所以说灵活的项目管理归根结底就是在标准项目管理的基础上的延伸。
计划和实施
当我们谈到项目管理的时候,我们最直接的印象是工作列表和甘特图,或者叫工作时间表或安排,从标准项目管理理论来讲,项目计划是重点,要占项目周期的很大一部分,首先要制定一整套项目计划,包括项目范围计划、项目进度管理计划、项目质量管理计划、项目人力管理计划、项目成本管理计划、项目风险管理计划、项目沟通管理计划、项目配置管理计划、项目变更管理计划等等。而在现实情况下,客户决不允许你在计划阶段花费太多时间,实际上,客户希望看到项目组到现场马上进入编程开发,他才觉得项目组在做事情,不然开发商就是在浪费他们的精力和资金;如果项目经理顶住客户的压力,严格按照标准项目管理流程,将得罪客户,为以后的工作添置很多障碍,有些是致命的。
应用灵活的项目管理,项目管理的重点从计划转移到实施,但不是说项目的范围定义和计划被完全忽略,而是在不完整的需求确认和项目总体计划框架下进入实际开发,在需求不断变化和项目目标渐进明细的情况下灵活的把握项目,将项目始终处于控制范围内。
而且,对于行业软件开发而言,随着业务的变化发展,业务需求和功能需求的不断变更,要求有丰富业务和技术水平的独特专家在项目组中,这些专家不仅仅简单的认为是高级程序员,也不是系统设计人员。具体来说他们是一组人,一组在这个行业摸爬滚打中练就一身过硬业务知识和技术水平的人员。他们对于行业软件这个大的系统里的不同部分具有很多比客户还要深刻的理解和认识,在同一个行业软件领域中,比如针对中小型商业银行的银行软件解决方案,大多数项目在功能上,业务需求上等等方面都有着某些方面的类似性和相同性,在一个新的项目中,这组人不管是在简单或复杂的项目计划情况下都有能力和水平将项目中所有的部分组和在一起,就像事先经过了详细的系统设计一般。
在这种情况下,项目经理面临着一个挑战,项目艰难而有效的实施下去将是项目所能达到的最好效果;面对太多太快的变化导致项目经理手忙脚乱,不知所措将是项目经理所要经历的最坏局面,如果不及时将项目重新纳入正轨,项目将是一场灾难。就行业软件这个领域而言,不要希望这些项目你不会遇到,在现实世界中,你要做好准备,经常性面对这种项目。
灵活的项目管理特点: 内部和外部不确定因素
内部和外部不确定因素是灵活的项目管理的最重点所在,众多的不确定因素导致项目总是处于紧急和高风险的状态下,这就要求项目经理和项目组的独特才能和技术。
内部不确定因素包括那些在项目经理可控制的项目范围内,进度安排内和预算成本内所有的内部可控或不可控的方面。例如:对于数据仓库项目,针对客户在系统某些功能执行时间上的苛刻要求,在1G的数据量以下,系统可以满足要求,但随着可以预见数据量的飞速增加,在一段时间后,系统将不得不面对1G以上的数据处理量,而解决此问题的途径有几种,不论是在项目中解决该问题,还是在维护期解决该问题,项目经理就一定要从项目的各个方面进行权衡,快速找到一个最恰当的方案。
外部不确定因素包括不在项目原始范围内,比如行业发展和竞争需求中所产生的新要求,例如:一个城市商业银行一揽子解决方案的项目,包括核心业务系统、信贷管理系统、国际业务系统、中间业务系统等等,项目经理和项目组业已将客户的需求控制在一定范围内,信贷项目组根据以往的经验,预见到在综合业务系统上线后不久客户将会提出现场信贷功能的需求,但按照现有银行模式,所有数据是大集中在中央数据库中,如果现场信贷的功能要实现,那就不得不要求核心业务系统提供数据源和数据端口,而由于此项功能需求是行业中发展中一项新的功能亮点,现在的核心业务系统不包括此接口,而要增加此功能端口和源就要求核心业务系统要做很多改动,有些是重大改动,如果放在二期来做,客观条件不允许在具有生产数据下进行长时间充分的测试,很可能造成系统的不稳定,而银行系统又需要具备很强的稳定性,还有可能造成银行在结算、冲账这些关键环节上的错误,这个时候项目经理面对的就是外部不确定因素。
这两个方面都是灵活的项目管理方法中必须要考虑的因素,项目经理不得不决定到底如何要解决它们。
对于内部不确定因素,它的风险性对于第一次做此类项目的项目经理是最高的,随着项目经理经验的增加,它的风险性呈现反比例发展。就像世间无绝对一样,风险不可能减小到零,所以,无论你作为项目经理和你的团队做过多少个同类型的项目,也不论之前成功实施的几个项目间和新项目有多么的类似性,永远不要期望项目完全按照你的既定计划来走,没有人会知道会有什么样的事情会在项目中等着你,每一个项目都在考验你的项目管理能力和灵活的项目管理手段。
有些朋友会说:现在中国IT技术人员普遍有种浮躁和易动的心态,一个成熟的项目经理和他所熟悉的,相对成熟的项目团队几乎不存在,人员总在变动,你所说的灵活的项目管理不可能实现,更不用谈内部、外部不确定因素这些具体的东西了。由此话题引出了成熟的项目组织的重要性。
一个行业软件开发供应商如果想在行业中有些名气,就必须在时间上存在足够长,行业背景要有一定程度上的认可度,成功案例要有一定的数量。在攒够这些资本的过程中,企业逐步完成它对于行业软件领域中业务、技术和人员的原始积累,企业由此走向成熟。
我见过一些国内软件企业,在成长的过程中没有实现这些方面的积累,在企业发展到一定规模之后,这些问题凸现出来,有些在短短数月间骤然间消失,有些分崩瓦解到一定程度后稳定下来,艰难的等待第二次辉煌。
这些软件企业成熟度和内外部不确定因素有什么关系呢?很多人看到这里就已经想到,越成熟的企业,项目的内部不确定因素和部分外部不确定因素的风险性越小,因为它已经经历了足够的错误和痛苦,将足够多的不确定因素和不知道因素所造成的风险减小到了很小。
现在谈谈外部不确定因素,外部不确定因素在很大程度上是不受项目经理所控制的,前面所举的外部不确定因素的例子是少数可被控制的因素。将工作重点从项目本身转移到控制外部不确定因素是项目经理成功运用灵活的项目管理的必要手段。
实际上,客户最清楚什么是竞争,不像内部不确定因素,外部不确定因素更多的取决于行业的成熟度,在中国,各个行业都在快速的发展过程中,不论是电信,还是银行,或者是互联网,就拿电信行业来说,GSM正在逐步退出历史舞台,联通2003年推出CDMA,中国移动也推出相应的3G产品体系,而4G的研究也正在进行中;处于这样的竞争条件下的项目,对WCDMA、cdma2000和TD-SCDMA三种主流的3G技术标准的取舍,时间上的紧急性,技术的复杂性等方面都提出了很高的要求。这个时候,标准项目管理在很多方面会遇到很多困难,越来越多的不确定因素将标准项目管理方法的界限从不同的角度延伸,从某一点上开始,你必须找到新的方法去管理你的项目,可能这些方法还没有被前人使用过。
项目计划
计划通常是最痛苦的,耗时的,对于需求频繁变化的项目来说是最没有价值的;在标准项目管理过程中计划是最重要的,没有计划项目经理和项目组将丧失方向和感觉,而对于灵活的项目管理中计划也是重要的,但如何计划才能将计划变成有价值的呢?
对于中小型商业银行的金融项目来说,项目的每一分,每一秒都是重要的,项目是否能多快好省的完成决定了商业银行当年在当地市场的竞争地位,市场变化飞速,如果项目不能及时完成,一步赶不上,步步赶不上。所以商业银行对于项目的期望和要求都很高。
当项目组遵循标准项目管理流程进行项目计划时,客户会说:“我们需要项目尽快完成,不然我们将不能够完成今年的利润目标,并且工商银行在一个月后就推行这几项业务了,我们要在他们之前完成,你们的老总和销售都向我保证过,可以在此前完成。所以不管如何做,你们现在就开始写程序吧” 或 “你们已经做过此类型项目,你们应该知道怎么做,计划只会拖延时间,所以快点开始”。
在种种条件迫使下,项目组不得不在极短的时间内产生行之有效的项目计划后进入开发。甚至没有时间做详细的需求。我们不得不面对这样一个矛盾,一方面,需求频繁的变化导致计划纯属浪费时间,而另一个方面,我们必须做计划。
标准项目管理流程的计划包括大大小小十几二十个计划,从工作列表、甘特图到时间安排、人员选择,成本分析等等方面。我本人不想否定这些计划的制定,这些计划确实能够有效的对项目进行规划和控制,将风险降到最小,成功率升到最大。举例来说:一个商业银行整体解决方案的项目,经过和客户的反复讨论,综合业务系统在保证其原本业务功能的基础上,同时对客户现有系统(如CRM,行长决策,OA,管理系统等)、信贷管理系统和国际业务(包括现有和未来需要的业务功能)提供端口和数据源,将综合业务系统进行必要的改动和优化,对种种情况进行周全的考虑,然后制定一套完整的计划和方案,再进入实施。这样当然最好,但在现实中国社会中,有什么样的银行允许你这么做?
项目活动和成绩
标准的项目管理流程是以项目活动为基础的,也就是说项目按照要做多少事,先做哪件,后做哪件来决定的;当关键的项目活动确定后,资源得以分配,工作量和时间得以估算,次序也就相应排列出来了。标准项目管理通常使用以以前做过的项目所总结出来的通用模版来完成初期的项目计划。
而灵活的项目管理中,计划的制定是通过确定要完成的目标和里程碑,但不具体到详细的任务。新科技或需求不断变化的项目中的项目经理清楚要达到的目标和一定要按时完成的里程碑,他所不清楚地是非常准确的任务,所以在此情况下,制定一个在任务列表的基础上的完整而详尽的项目计划就不切实际了。如果要这样做,只会起到反效果。这大概就是灵活的项目管理和标准项目管理之间微妙而关键的不同。
在灵活的项目管理中,通常有多种方法推进项目并解决项目中出现的问题,项目经理不能以机械的方法按照标准项目管理的方法来实施项目。而有丰富经验的项目组成员也经常对不了解项目性质的项目管理层有抵触。他们不喜欢对不确定的业务功能和系统功能作出承诺,因为他们知道这些需求会改变或正在改变中。可是,他们会对确定要按时完成的里程碑作出承诺,如果项目经理对他们如何做不太多进行干涉。
项目估算和承诺
在此类项目中,项目估算的关键点是相信项目组成员的承诺,而不是从上至下WBS的估算,只要能够实现系统层面上对于客户业务上的运作畅通,换一句话说:是将客户商业运作上的要求在系统中实现,设身处地的在业务层面上为客户着想。
这就要求项目组和客户不得不在整体上进行考虑,然后在细节方面逐步实现需求。在中国软件开发项目中很常见的一个现象是客户和项目组的考虑重点不同,导致误差和困扰。如果项目组和客户在同一个思路上思考,项目的难度会减小很多。这样在计划阶段双方很容易达到共识,而富有技术和业务经验的项目组成员可以更好的发挥他们的优势而达到双赢。
你,作为项目经理可以把重点放在你的优势上,协调、沟通、整合系统,保持它的完整性。
当然,基于此基础上制定计划和进度安排不是个容易的事情,因为系统中的各部分有着千丝万缕的联系,而一个大集成系统中的各系统之间也是相互依靠的。所以所有项目组需要有效的共同工作。
出于这些原因,项目计划的网络图比甘特图在计划中更加有效,更能够展现项目中可实现目标的途径
 

版权所有:UML软件工程组织