“项目”,在二千多年之前就已经存在。着名的埃及金字塔、我国的万里长城都是国际上众人称颂的典型项目。项目管理发展到今天,应用相对成功的领域主要是在土木工程上,现已逐步应用于软件工程、航空、国防、金融、体育等行业。
一般来说,“项目”具有技术复杂,参与的人员还众多,时间又非常紧迫,因此,人们开始关注如何有效地实行项目管理来实现既定的目标。在这里,主要谈谈在软件工程领域中项目管理的运用,也就是项目管理能够给人们提供一种解决问题的思路和方法。
I. 当前项目管理存在的问题
一项调查表明,大约70%的软件开发项目超出了估算的时间,大型项目平均超出计划交付时间20%至50%,90%以上的软件项目开发费用超出预算,并且项目越大,超出项目计划的程度越高。国内绝大多数的IT企业正或多或少地承受着“项目黑洞”的痛楚:项目无法按期完成、项目合作方的工作难以协调、用户需求经常变动、工作质量难以保证。很多企业常常抱怨说,我们的技术实力不比国外差,我们的员工也很努力,但是我们的产品和工作效率为什么总比不上国外?
诸如此类的问题,就是当前软件开发中,实现项目管理实施时带来的问题。虽然,项目管理在土木工程中,项目管理在中国已经实施得十分成熟。但是,软件开发不同于其他产品的制造,软件的整个过程都是设计过程(没有制造过程);另外,软件开发不需要使用大量的物质资源,而主要是人力资源;并且,软件开发的产品只是程序代码和技术文件,并没有其他的物质结果。基于上述特点,软件项目管理与其他项目管理相比,有很大的独特性。其问题的具体表现为:
一、工期失控,计划失控。项目做多,往往会形成一种错觉:不按计划工期完成的项目是正常的;能按计划工期准时完成的,往往是不正常的。这说明,项目的实际工期和计划工期不符,是“家常便饭”。大多数工期延期,很少提前的。工期延期、失控,自然而言会导致计划无法执行;计划无法执行,成本就失控;产品就会变形……
二、项目前期多数出现“没事做”,后期“没人做”。在项目启动后,因为人员的配置,人员的衔接,硬件的配置,客户需求的确定性,一般会造成很多人“ 没事做”。而有些事是必须放在项目前期做的。前期不做,会对中后期有很大的影响。或者放到中后期做,会,要多花几倍的人力、物力。到了项目后期,会出现“ 虎头蛇尾 ”,大量的事情需要人来做,项目的人员又是固定的,其他人因为不了解整个项目,无法“空降”,则只能删除一些事情咯。这样就造成很多事情,没人做,后果可想而知。
三、开发人员心态失控。延期,赶进度;晚上加班。还是延期,星期六也加班吧。
II. 定位问题
有人会问,产品或项目的需求不就是包含了定位,何须重复讲呢。其实,这是一个误区。同样一个需求,在一个中学生中实现和在一个大学生中实现是完全不同的;在一个有经验的群体中实现和在一个缺乏经验的群体中实现是完全不同的。有些项目,由于定位未做好,未开始注定是失败的,无论是需求分析得如何好,编码、测试控制得十分完美,终究逃不过失败这一关。
做软件的都知道,是没有真正的软件。即使是通用做的最好的WINDOWS,也不可能是通用到每一类人,每一个国家,每一个民族的人,通用到那些只有几千人的少数民族。因此,一个项目的定位是十分重要的。
产品和项目的定位是不一样的。做项目不比卖产品,产品卖出就是成功,项目投产才算成功;产品是静态的,项目是动态的;产品质量有问题可以包换、保修,项目一旦失败,时间不能倒流,客户损失的可能就是市场竞争优势和机遇。
III. 项目经理及与开发人员的沟通
项目经理类似于电影中的英雄人物,是项目的灵魂,他的一举一动影响着项目的成败。在危难时刻,优秀的项目经理甚至可以力挽狂澜。众所周知,衡量项目经理一般是以在资质、素质、能力和经验等作为主要的依据,即统筹能力、领导能力、交往能力、处理压力、解决问题的能力和技术能力。但是,个人认为,项目经理的心态才是决定一个项目成败的关键因素。当然,能力和经验也会影响项目经理的心态。
一般出任项目经理,要么是由开发骨干兼任(这在中、小型项目中很普片),要么是由销售或其他部门空降,专职项目经理。这两种方式都有各自的弊端。专职项目经理,专做项目管理而不做任何分析、设计、编码、测试等具体的技术实施工作,就会感觉“没事做”,或是在打杂;开发骨干,由于主要或全部精力均忙于具体技术工作,各种项目管理任务(如:项目分析/评估、项目计划的制定/检查/调整、上下左右的沟通、专业资源调配、项目组织调整、项目财务控制、风险分析/对策等)不可避免地疏于顾及,项目管理的事情“没人做”,导致项目控制的问题“积劳成疾”,后悔莫及。
专职项目经理,在项目管理过程中,一般比较注重对外的联络合作方面,即比较注重和销售、用户,其他部门的协调工作。相反,就会对技术及开发的技术重视不足。在很多情况下,只根据用户、销售确定的功能、工期来安排计划,对相应的技术难点不理解,每项功能所耗费的时间估计出现很大偏差,对每个开发人员的技术、知识水平认识不透彻。因此会造成有些任务需要强制、压迫才能完成,开发人员不是建立在心服口服的情况下完成的。正所谓,上有政策,下有对策。开发人员都是高智商的动物,骗“外行”就更容易了。一般都是采取虚报工作难度,把本来一天能做完的,拖到一个星期,十天才做完;或者把正常要半个月才能做完的工作,在上面“强制”要求下,压缩到一个星期做完,当然拉,其中必然要偷工减料,只有极正常的操作才能会满足要求,对非法操作,特殊情况的处理,项目经理或测试工程师发现一个才处理一个。不能发现的,就等用户去发现。项目的实施情况就可想而知拉。
在这种情况下,必须做到几点:
一、 从开发人员的角度出发,结合市场的角度确定项目的功能,动之以情,晓之以理,尽量使开发人员心服口服地开发某个功能。
二、 由项目组讨论确定每一项功能的开发耗时,以不是通过拍脑袋的方式确定耗时;
三、 加强测试;
四、 加强对开发人员责任心、成就感的教育。 项目管理者联盟文章
技术骨干担任的项目经理,不可避免地存在着“技术崇拜”,尽可能采用新技术。即使是需求明确的功能,由于实现方式有多种路径,一般都是从技术上采取最优的路径,而不是从用户操作方便的角度上选择操作最方便、快捷的路径,用户必须严格按开发人员所预设的操作方式进行操作。说句老实话,用户是不管你用什么技术的,先进或落后的技术都可以,只要能满足用户的需求即可。这种类似闭门造车生产出来的产品,自然就是操作不便,功能差强人意的。还有一种情况是,这种情况一般发生在项目后期,开发产品的情况较多,随着开发的深入,总会发现缺少某些功能,或者某些功能不够强大。项目经理对功能的增加、删除、修改,不是通过集体讨论确定或通过从市场前线人员中了解确定,而是通过凭空想象,拍脑袋来作出决定。特别是对于某些功能的添加,由于项目经理都无法把握用户是否需要这个功能,需要这个功能的程度,因此是很难令开发人员把握此功能的目的。当然,既然大家都无法把握用户是否会用这个功能,那自然是应付式开发。只要过了测试,过了项目经理这一关就OK拉。
初当项目经理的人,经验不足是必然的,这并不是构成产品、项目失败的关键因素,心态才是主要的。新官上任三把火,而且还是怀着“感谢党,感谢组织,感谢领导 ”,有着一颗报恩的心态当上项目经理,自然就事事追求完美,没有缺陷。但是,理想和现实是永远都有很大的差距的。学会取舍才是项目、产品成功的因素,也是项目经理走向成熟的关键。
成熟的项目经理,应确保项目实施中业务参与的全面性、深度和权威性。
在一、二十年前,也许您会经常听到某位大侠单独完成了某种创举,成了人们崇拜的对象。可今天,这种大侠,已经很难有生存空间了。取而代之的是,某军团,又攻克了一座什么样的堡垒。这样,沟通,可以说已经变得无比的重要。在软件业,沟通可以说是快速学习和掌握新知识,达到技术上的更高层次的最佳途径。因此,无论是项目,管理都必须在以人为本的前提下进行,必须重视沟通。
以人为本,指的不只是软件开发人员这一部分。这里的人主要指的是一些与项目有利害关系的一些人,即项目干系人(stakeholders),一般包括客户或者用户、项目团队、项公司的管理层等一些主要的利害关系者。一个项目能否成功,很大程度上取决于能不能分清楚这些项目利害关系者各自对项目的影响,能不能利用好这些人力资源,沟通协调好他们之间的关系。
沟通是掌握各方信息,进行项目决策和项目协调的基础,也是项目管理的基本内容。项目经理最重要的工作之一就是沟通,通常花在这方面的时间应该占到全部工作的75%~90%。良好的交流才能获取足够的信息、发现潜在的问题、控制好项目的各个方面。尽早沟通、主动沟通就是其中的两个原则。总之沟通是一门很重要的学问,在项目管理中也有专门的沟通管理,因而在本文中我们就不再讨论了。
项目经理只有以人为本,重视沟通,才会避免出现以下的情况:客户在检查项目阶段成果时,指出曾经要求的某个产品特性没有包含在其中,并且抱怨说早就以口头的方式反映给了项目组的成员,糟糕的是作为项目经理的你却一无所知,而那位成员解释说把这点忘记了;或者,你手下的程序员在设计评审时描述了他所负责的模块架构,然而软件开发出来后,你发现这和你所理解的结构大相径庭……