paulwong

我做的一个的项目,如何才能顺利的交付(转)

先把项目背景简单说一下,项目A可以认为是在原有业务系统的基础上衍生出来的新需求(派生的新业务),原有业务系统是一个比较大的系统,在公司也是一个拳头产品,卖了几十套,目前也有好几个人在上面维护+二次开发+缺陷修复等(人力资源紧张)。早期公司高层只是说肯定要做这个项目,但由于人力资源的问题迟迟没有决定要开工(还有一个重要原因是领导希望能够签下1-2个典型客户再启动项目A的开发),而仅仅是上销售去那几十家客户那里兜售新业务,吹的天花乱坠的,比较市场有些竞争,需要先拉单子。这些事情是年中的事情。

等到下半年的时候,市场对这个新的业务反应比较强烈,已经有客户说要看原型再签合同,原因是竞争对手已经出原型了。而此刻,公司以为高层决定要即刻启动项目开发,说先把原型做出来,限期一个月。而中层领导还是由于人手紧张,就随便抽调了4个开发人员,一半是1年工作经验以内的新手,就这样匆忙上阵。由于人手有限、时间紧迫、业务需求虽然已经明确,但很多业务细节这4个开发人员都不清楚,只有一个懂业务的但也谈不上精通。

项目计划就定了一个月,基本上按天把计划排好了,1个月后系统原型出来了。但比较粗糙,缺陷也比较多,设计基本没有做,代码质量也比较差。拿去客户那里安装后,客户认为这个系统太粗糙了,【到客户那里,客户就不会认为这是个原型系统了】

至此,按常规项目管理的做法,应该重新梳理真实的客户需求、业务流程和功能设计、架构设计、概要设计。。。。
但事情的发展却不是这样进行的。由于客户迫切系统以周为单位看到项目的进展,于是领导决定就在原型系统上扩展和修改,其结果就是计划制定后很难执行,变成了按周来排计划,主要就是按客户的需求来改。

好不容易在年底前把版本基本上稳定了,但只是业务流程和功能比较温度,缺陷开始收敛了。

但元旦后到客户现场安装测试版本,客户对此版本又提了很多需求变更和新模块。此刻麻烦就比较大了,因为系统的架构灵活性比较差,改起来对原有代码影响比较大,改动范围大。于是又是时间紧张,又是工作量,刚把功能实现,客户就开始催啥时候测试。缺陷一直居高不小,于是决定花2周时间专门修改缺陷。

到现在为止,开发基本完成了。但问题也比较突出:
系统的性能存在问题(有些模块客户的意见很大,但这个从技术上讲,改动会比较大,不是1周能解决的)
系统的稳定性(与1相关)
功能的可用性(有些功能早期按照开发人员的思维来设计的,到客户那里客户提出新的想法,开发时把这种体验需求压住了,但在后续还是要改)
马上要启动二期的需求开发,这个更麻烦

---------------------
至此,整个项目风险还是比较大的,我总结有以下几个原因:

1. 项目的目标、业务流程、大体需求是很明确的,但细节需求在项目中前期,整个项目组都是一知半解的,造成后续返工较大,客户和开发人员包括公司领导对质量的意见都较大;

2. 项目从开始到现在领导和项目经理的分工不明确;由于人是凑起来的,大家之前没有合作过不了解;

3. 原型系统出来后,项目经理大部分时间都去解决客户的需求沟通和售前支持了,少部分时间在真正项目开发上;

4. 一直对项目的总体计划和推进情况估计不足,造成项目计划形同虚设,完全是开发人员做到哪算哪;

5. 中前期领导对这个项目不重视,等到元旦后发现问题比较严重,就临时抽调人手进来协助,而刚进来的人一方面不是项目经理想要的人(仍然是新手),另外一方面由于系统的业务性比较强,新手加进来后1-2周内根本不起作用;

6. 测试工程师,派过来的2名测试工程师是后期加进来的,业务都不熟悉,培养的2周后才慢慢熟悉,而且在客户现场,测试工程师根本应付不了客户的问题,即客户讲的需求测试工程师根本不懂或不熟悉;

大致就这些吧。 

posted on 2013-02-23 23:12 paulwong 阅读(190) 评论(0)  编辑  收藏 所属分类: Project Management


只有注册用户登录后才能发表评论。


网站导航: