E供职于一家从事军品软件开发的民营企业,客户一般为国家或者军方背景的公司和机构。这些客户(甲方)由于具有绝对的资金和资源优势,并且有着十分广阔的供应商来源,加上半个世纪以来的形成的体制内的权威传统,在对待自己的供应商(乙方)时态度常常十分粗暴,不允许讨价还价,遇到问题也没有商量的余地。这些因素决定了甲乙关系中,甲方处于绝对的强势,而乙方处于绝对的弱势,这对乙方公司开展项目的项目经理来说,简直更是个噩梦。
E供职的这家公司属于典型的职能型组织结构,项目经理只能是个项目联络员的角色,但既然负责项目,哪怕是零权限,也得承担起责任,至少承担痛苦。
这里对一个刚刚交付不久的项目进行描述,对其中的现象和问题进行分析,由于这些问题可能具有普遍性,所以期望通过抛装引玉,引发大家的思考,为同类问题和项目寻求解决方案。
2014年10月,甲乙双方开始针对项目进行接触,甲方提供了《技术协议》,技术协议对项目的功能和性能做出了规定,但规定十分笼统和简陋。乙方基于甲方提供的《技术协议》对项目的规模和开发工作量进行了评估,评估方法也相对初级,结论是投入3个人力,3个月时间可以完工。乙方基于这个评估向甲方提供了报价,并最终拿到了项目的合同。
乙方于2014年11月正式启动项目,并立即开始了《系统需求规格说明书》的编写,过程中上门与甲方面对面沟通若干次,邮件沟通若干次,反反复复修改无数稿,并于2014年的最后一个工作日进行了内部预评审,为客户正式评审做准备。同时不停协调甲方评审《需求规格说明书》的时间,几次最后决定仍被放鸽子。
经过几番折腾,在2015年1月中旬的一天,乙方终于等来了甲方的评审团,这个评审团包括1个总设计师,1个项目办人员和5个技术负责人员,经过4个小时的激烈讨论,在提出若干整改意见之后宣布评审通过。
甲方是按照瀑布模型对乙方的项目开发工作进行要求的,但在需求文档等待评审的间隙,乙方并行完成了系统设计文档的编写。
问题是,截至需求文档通过评审为止,甲方都没能提供系统必须的和甲方自研系统之间的接口协议,甲方的意见是先做可以做的。
在设计文档完成之后,甲方团队迅速开始了系统的编码工作,用了6周的时间,在2015年3月中旬完成了用户界面相关的功能,到此为止,乙方团队已经花掉了3个半月的时间,除掉中途的春节放假,事前评估的3个月时间已经用完了。
就在这个时候,甲方提供了一版34页的系统接口协议,乙方团队加班加点,用了2周的时间将接口协议实现并集成了系统中。
然后甲方发布了接口协议的更新版本,这个更新版本有48页,经过分析发现,与其说这个是更新版,不如说是个全新版,因为这个版本推翻了上个版本中90%的ICD。又经过2周的时间,新版本ICD被实现和集成到系统中,这时候时间已经到了2015年4月中旬,超出预期4个月。
接下来,应甲方的要求,乙方奔赴甲方公司进行了系统最新状态的演示,甲方提出了一些修改意见和一些针对业务的细化意见,并说明仍然有部分需求尚不清楚。针对客户的这些需求,乙方又花了4周时间完成了变更和功能增加。此时,时间已经到了2015年5月中旬,超出预期5个月。
客户的变更单又来了,此处花去两周时间。
接下来,客户要求系统联调了,从此乙方团队开始了出差的日子。
从2015年5月底开始的26周时间中,乙方按照甲方的要求一直两地奔波,大部分时间在甲方的实验室度过,这期间出现的现象有以下几类:
(1)需要联调计划好的某设备(甲方自研)时,突然发现该设备的负责人(甲方人员)出差了;
(2)需要联调B设备(甲方自研)时,临时才知设备因故障返厂维修了;
(3)需要调试某设备(甲方自研)时,甲方上级单位通知开会,乙方人员回宾馆自己玩;
(4)联调某设备(第三方承制)时发现数据对不上,排查三天,最后发现甲方提供给我方和第三方设备承制商的接口协议不一致;
(5)联调某设备(甲方自研)是数据不对,经排查可以认定是甲方开发人员的编程错误造成的,可是甲方人员坚持自己是对的,而该成员具有一定的背景,别人不好反驳,所以负责人向乙方要求通过乙方的修改来保证联调结果的正确。
由于各种奇葩的状况不断,用了足足26周的时间才完成系统的联调,何其漫长!这时,时间已经到了2015年11月月底。超期7个多月。
2015年12月21日,这是个伟大的日子,这天,在各种斡旋之下,客户通过了该系统的验收评审。然而,前提是乙方在评审中声明,在甲方提出修改要求时,乙方需要配合。
一个评估为3个月的项目在经过14个月的癫狂之后,终于平静下来。这期间甲方提供的书面更改单25份,口头更改随时进行,从头到尾,唯一不变的就是变更。
在这个项目之后,乙方公司拒绝了甲方的新项目,这算是这个而失败项目的一个教训!
E作为一个零权限的项目联络员,全程忍受了这个项目中的全部尴尬和痛苦,然而却无能为力,相关的职能经理也无能为力,项目始终在失控中运行。
最后甲方基本满意,乙方崩溃了!
|