几个项目管理的总结

整理家里的旧电脑,翻出来这一篇2005年左右的论文:

 

摘要:本文通过对笔者2003-2005年上半年实施的软件项目的回顾,结合项目管理理论,总结出以前项目管理中的种种不足,并提出解决办法,同时指出今后努力的方向。

 

正文:

笔者就职于一家专业软件公司,该公司多年来为政府、企业提供信息化解决方案,拥有电子政务、电子商务等多个平台。其中电子商务平台经过多年积累,形成了自己的框架产品,笔者带领所在的小组,在该框架产品的基础上,在两年半的时间里,成功实施了多个电子商务案例。在系统学习了项目管理理论之后,回顾这些项目,发现有很多待改进的地方。

 

项目一:2002年底,本集团下属的另一家办公用品电子商务企业决定自行开发一套电子商务系统,以此代替此前从德国购买的某ERP系统,工期只有半年时间,人员只有五人。项目在2002年底开始,2003年7月正式运行,运行的状况让人满意,实践证明该系统是成功的。但实际上,从项目管理的角度来看,该项目的成功却是无法被复制的,其中充满了偶然性和个人英雄主义,从这个角度来看,这是一个失败的项目管理的案例。

首先看项目的启动阶段,先看看项目的组织结构,项目组的五个人中,一个是兼职测试工程师,其余四位是程序员,其中两位分别由系统分析师和架构设计师兼任。那么,项目经理是谁呢?在回答这个问题之前,有必要介绍一下小组成员的行政关系,架构设计师是公司的CTO兼开发部经理,系统分析师是其部门内的一员,但CTO却并未理所当然地担任该项目的项目经理,而是指定了由系统分析师来负责项目。指定的过程很简单,CTO有一天在部门的房间里,对大家口头说:“XXX,公司的这个项目,你来负责吧!”

很显然,这看起来不像是一个正式的任命,而且,察看项目小组的人员结构,几乎每人都身兼数职,项目经理和上司同在一个项目小组,行使项目经理职责的时候必然有较多顾虑,其后就发生过CTO与项目经理就某一个技术问题意见不一致,后来只有采用了CTO的意见,但事实证明在这个问题上项目经理的意见更正确。可以说,作为项目的启动阶段,实际上没有确定好清晰的项目章程,没有足够清晰的职权划分和授权的过程。当然,由于项目成员每个人的努力与互相理解合作,这一点不足在后来项目实施中并未造成太大影响。

接下来进入项目计划阶段,如何确定项目范围呢?由于是给兄弟公司开发业务系统,双方认为互相信任,所以项目范围实际划分地十分粗浅,就是“取代原有的系统,满足兄弟公司需要”。在这里,实际上又埋下了隐患,因为结构上毕竟是两家公司,还是有费用结算的问题,本公司也有其他项目任务,不可能无限期地将人力资源放置在这一个项目上。没有很好的确定项目范围,也就没有比较基准,谈不上对需求变更的管理,项目后期就某一些需求出现扯皮,就是这个原因导致的。

项目执行阶段是一个艰苦的过程,最初的两个多月,大家在进行各种技术准备,接着两个月的设计和出原型,然后这四个程序员连续加班了近两个月,完成了系统的主体部分。整个项目的内部沟通是通畅的,因为这是一个小团队,成员彼此也十分熟悉。但仍然有些问题存在。作为项目经理,以前是开发骨干,由于主要或全部精力均忙于具体技术工作,各种项目管理任务(如:项目分析/评估、项目计划的制定/检查/调整、上下左右的沟通、专业资源调配、项目组织调整、项目财务控制、风险分析/对策等)不可避免地疏于顾及,项目管理的事情几乎“没人做”,导致项目控制的问题“积劳成疾”,进入到项目后期后进展十分吃力。

从质量控制的角度看,该项目的文档相当少,由于工期的压力,很多时候都是脑子里面设计,然后直接编码,兼职的那位测试人员也越来越没办法参与进来,最终离开了团队。因此质量实际控制在每一个程序员手里,而且只有他们自己清楚。每个人确实都很用心,但毕竟经验不足,在这个版本的系统里留下了很多BUG,就是质量控制失败的具体体现。

 

项目二:2003年底,由于项目一的成功增强了领导层的信心和项目组的威信,加上公司业务拓展的需要,这时候公司决定,将这套系统进行整理包装,作为产品面向小型商贸企业销售,接下来的短短一个多月的时间里,项目组被迫完成了产品包装的任务,产品匆忙上市。然后的一年多的时间里,产品反响较强烈,因为公司采用了超低价策略,来询问的客户很多,购买的也不少,但实施成功的用户却寥寥无几,包装为产品的努力宣告失败。

其实这完全是一个定位失败的例子。我们知道,产品和项目的定位是不一样的。做项目不比卖产品,产品卖出去就是成功,项目要投产才算成功;产品是静态的,项目是动态的;产品质量有问题可以包换、保修,项目一旦失败,时间不能倒流,客户损失的可能就是市场竞争优势和机遇。

对于用户定制的项目,定位相对简单,只要了解到定制用户的使用范围,使用者的知识结构、行业经验、电脑的基本知识及是否用过相关软件即可。特别地,如果是用过相关地软件,一定要了解清楚,哪些操作、功能是必须保留的,哪些操作、功能是可以修改或必须修改的。一旦用户已习惯了某种业务流程、操作方式,是很难更改的,如果定制的项目不遵照用户的习惯进行开发,在软件的运行初期,往往会出现很多意想不到的问题。此外,还必须注意用户方人员流动、组织机构变化造成的影响。

对于产品的开发,定位则相对复杂些。由于产品的使用者是不确定的,是预测的。因而产品的定位显得特别重要。国内的面向中小行业的应用产品,几乎是不存在通用产品的。通用,只相对于某些大行业或某个标准化程度高的行业而言。有些产品,号称是通用产品,既不能使通用领域的用户满意,更不能使专用领域的用户满意,是彻底失败的产品。相反,一些产品,一开始就定位于某个行业,某个细分的行业,反而做的很好,用户量比所谓的通用的产品的用户量还要多。

本项目的失败,就在于把原本只适用于某一家规模较大的电子商务企业的项目,直接应用到很多家规模较小的传统的商贸行业身上去,定位的不同,项目与产品的不同,均为其失败埋下了伏笔。当然公司在这件事情上赚得了一些眼球,那是另一件事情了。

 

项目三:2004年初开始,这个项目小组开始为一家台资电视购物企业实施电子商务系统,其基础就是项目一,或者说项目二中完成的系统。这也是一个很辛苦的项目。原因在于,此前完成的系统,已经累积了很多问题,现在在其基础之上修改,不光暴露老问题,还引发更多的新问题。

首先,是要确定项目范围,但原来完成的系统缺乏文档,对于新的需求,哪些能做哪些不能做,只存在于项目经理或系统分析师脑中,对于变更的控制,别人几乎没法进行。

回头看这段经历,其实解决方法是有的。我们知道,影响计划执行的因素可以分为主观因素和客观因素。客观因素有客户相关风险,外部环境的影响如停电,机器损坏,不能上网等原因。主观因素有:人的因素、技术因素,资源因素。如果项目计划的Breakdown或曰“粒度”不符合实际情况,也是影响计划执行的因素。

设立里程碑,加强项目进度的检查(与进度计划比对)和控制,维护项目计划的严肃性,是规避计划执行风险的一个有效办法。但这是不够的。只有建立合理、实用的计划,计划的执行才会有可能。依照前面所提到的计划编排原则,那计划的执行应是这样进行的。在执行计划A时,应先审查计划B的内容,利用WBS方法,确定计划B的内容是不可再细分,需求在现阶段是否要作进一步的调整,功能点是否要删除、修改、添加等等,然后再确定计划B的具体执行时间,粗略调整由此引发后面的计划的变更。换句话说,也就是,迭代计划B,使计划B更你能满足现实的情况。计划B的具体执行时间已经制定,就是“死的”,不允许作调整,必须想尽一切办法按时、按质完成计划。因为这时计划是比较符合实际的,不能按时按质完成,不是态度问题,就是效率问题。完成计划A,在执行计划B时,迭代计划C……通过执行,迭代,完成整个计划。总之,就是使计划处于相对动态中,不是静态,也不是动态的,频频变化,要避免“项目失控合法化”。

该项目的质量控制也是问题一大堆,到了项目后期,主要是在进度和软件质量取得一个平衡点。在实际的项目质量管理中,质量管理总是围绕着质量保证(Quality Assurance)过程和质量控制(Quality Control)过程两方面。随着项目的深入,环境各方面的变化,具体实现总是和原先的设计或多或少地出现偏差。这是很正常,不必惊慌。原则上是,能不修改则尽可能不修改。实在要修改,则只要不是原则性的错误,尽量不要推倒前面所做的一切,重新做,毕竟以前做的时候也是考虑了方方面面的因素的,现在出现的问题只是在某方面考虑不周而已,一切都作废,太浪费了。还有,要是数据库字段已存在,除非万不得已,千万不要修改数据库字段,实在不行就添加字段。因为已经存在的字段,很有可能已被软件开发小组的其他成员在使用,不要因为一个人的修改而令其他人也要跟着做相应的修改。最后,软件界面的修改要慎重,界面的修改很容易使人忽略修改相应的内容,造成软件大问题没有,小问题一大堆。要尽量避免出现以下两种情况:一,不顾进度、成果,尽量修改,务必做到尽可能和预设功能一致;二,为了尽快完成项目,以时间点为准,做些表面修改,也就是不负责任的修改,以求尽快完整,早日解脱这个项目的苦海。这种情况,在该项目管理过程中,出现波折,有大量、频繁的修改的项目,出现得特别多。

 

项目四:2004年十一月开始,项目组开始为一家港资电视购物企业提供信息化解决方案。这次,项目经理开始担任半个销售的职责,项目前期合同制定等事情全权负责,这是一个启动/计划阶段变更频繁的例子,同时也是一个给项目经理定位错误的例子。

该项目销售合同中包含关于项目实施进度方面的承诺。合同签订的时候,客户可能处于稳妥的目的,对进度要求寸步不让。合同中承诺在合同签订之后的2个月内整个系统交付使用。而根据公司的项目经验,从设计方案编写、方案一轮又一轮的会审、到订货、收货、安装、调试等一系列的工作最起码也得三个月的时间。而后来项目经理通过和客户了解又发现,客户方面需要准备的现场环境远远不可能在2个月内准备就绪,譬如:选择哪家电信运营商来提供外线接入还没有决定,新增的设备要放置在哪里的机房也没有最终确定……在这种情形下,项目经理在被正式任命之后的首要事情就是分析实际情况,去劝说客户同意修改合同中关于项目实施进度计划的部分内容,签订第一份项目变更文件。

其实根据PMI的《项目经理知识体系指南》及对项目管理专业人员技能的要求可以看出,项目的优势更加集中在对项目的计划和实施上面。而合同签订之前的主要工作着重于客户关系管理、市场分析、商务管理、合同谈判等方面,这些并非项目经理的优势所在。

比较合适的方式是:

1、 合同签订之前的工作由销售经理主导,由商务经理、技术支持、项目经理等相关人员配合来完成;

2、 项目经理负责从合同签订起,按照合同实施客户项目,并得到客户验收这一过程中所包含的工作;

3、 项目实施结束、项目产品正式交付客户之后,对于项目产品的支持服务则交给专门的客户服务团队完成。

项目经理是否参与合同签订之前的活动,取决于这种参与是否能对客户合同的成功签订和客户项目的成功实施提供帮助。

本项目中,如果配备了销售经理的角色,项目经理配合他进行售前活动,相信效果会好很多。

作者: Ben

IT、电商、零售、医药行业混迹多年的理想主义者。

《几个项目管理的总结》有一个想法

  1. 终于开始更新啦,不过还是以前的文字。隔行如隔山,不过看得出来,你是个认真做事情并勤于思考的人

评论已关闭。