论坛首页 综合技术论坛

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

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

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

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

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

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

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

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

---------------------
至此,整个项目风险还是比较大的,我总结有以下几个原因:
1. 项目的目标、业务流程、大体需求是很明确的,但细节需求在项目中前期,整个项目组都是一知半解的,造成后续返工较大,客户和开发人员包括公司领导对质量的意见都较大;
2. 项目从开始到现在领导和项目经理的分工不明确;由于人是凑起来的,大家之前没有合作过不了解;
3. 原型系统出来后,项目经理大部分时间都去解决客户的需求沟通和售前支持了,少部分时间在真正项目开发上;
4. 一直对项目的总体计划和推进情况估计不足,造成项目计划形同虚设,完全是开发人员做到哪算哪;
5. 中前期领导对这个项目不重视,等到元旦后发现问题比较严重,就临时抽调人手进来协助,而刚进来的人一方面不是项目经理想要的人(仍然是新手),另外一方面由于系统的业务性比较强,新手加进来后1-2周内根本不起作用;
6. 测试工程师,派过来的2名测试工程师是后期加进来的,业务都不熟悉,培养的2周后才慢慢熟悉,而且在客户现场,测试工程师根本应付不了客户的问题,即客户讲的需求测试工程师根本不懂或不熟悉;

大致就这些吧。
   发表时间:2013-02-28  
原有系统能扩展不?新的项目对原系统有没有影响?然后就是项目管理那一套
0 请登录后投票
   发表时间:2013-02-28  
至始至终没有看到需求人员的影子..... 
0 请登录后投票
   发表时间:2013-03-01   最后修改:2013-03-01
问一个问题:你在里面是什么角色?

说一点看法:项目经理干嘛去了?别说没时间、别说人员都是新人。这些问题那个项目都存在。难道项目经理也是新人?项目经理不仅仅是执行者和Coder。

说实话,看到了一些以前看见过的场景:领导要求1个月,项目经理就按照一个月画甘特图;然后按照一个月执行,到一个月发觉又是一个神话。。。。
0 请登录后投票
   发表时间:2013-03-06   最后修改:2013-03-15
竞争对手已经出原型,一个月之后可能是一个实现核心功能的真实系统了,而你们只开发出了原型,落后了的可能性很大。明显没意识到风险管理...

领导前期不重视,涉及到签合同问题了,只调4个比较初级的程序员,领导肯定拍脑袋瓜,很多领导如此。

系统粗糙,第一印象没了。呵,前期设计有美工加入很重要,效果明显不同。即使功能不完整,能把核心的界面设计好都不错。

你们的模式似乎可以引入一些敏捷开发的理念,注重个体的能力与沟通,迭代式开发,短周期的计划与成果。由于大部分人业务不太清楚,最好能集中一个办公地方,随时沟通、培训,快速解决问题。

感觉一期的大问题是领导不重视、前期软件设计真没做好,越往后修复所浪费的时间越多。

另外,不是客户说做什么就做什么,项目经理适当与客户沟通沟通,有些功能可以延后。

领导可真是个大问题,我觉得与这个项目相关的领导的责任很大,缺少一个真正能管理项目内部开发的领导。


以上只是个人旁观的观点,也许在当局就很难察觉了。但我还是提几点不太专业的意见:
1、要让领导重视,有一个能够真正管理项目内部开发的经理。
2、防止功能蔓延,非核心的功能放后,客户没让开发的功能千万别做,时间不足只做最基本而能满足需求的功能。
3、加强内部沟通
4、需求、功能开发与客户确认之后再做,防止浪费时间与返工
5、由于客户经常提出新需求,客户很多时候也是拍脑袋说话,需求经常变,所以最好别过早下手
0 请登录后投票
   发表时间:2013-03-13  
chinaagan 写道
原有系统能扩展不?新的项目对原系统有没有影响?然后就是项目管理那一套


原有系统和项目A,由于系统架构不同,无法在原有系统上扩展。简单点说就是大家共用一个数据库,项目A肯定对原有系统有影响,但比较小,在初期方案讨论时已经规避掉了。
0 请登录后投票
   发表时间:2013-03-13  
puyongjun_1989 写道
至始至终没有看到需求人员的影子..... 



项目A在前期有产品部的同事A到客户现场沟通需求,有提交业务需求说明书。但这份文档侧重大体业务流程,并没有提及需求细节和功能细节。而且在coder加入后,同事A反而撒手不管了,或者说抽调去做其他的事情了。因为他认为他的事情已经完成了。

0 请登录后投票
   发表时间:2013-03-13  
minimu 写道
问一个问题:你在里面是什么角色?

说一点看法:项目经理干嘛去了?别说没时间、别说人员都是新人。这些问题那个项目都存在。难道项目经理也是新人?项目经理不仅仅是执行者和Coder。

说实话,看到了一些以前看见过的场景:领导要求1个月,项目经理就按照一个月画甘特图;然后按照一个月执行,到一个月发觉又是一个神话。。。。




我在里面做开发,带几个新人coding

项目经理是同事B兼任的,平时不怎么管事,让我向他汇报。他管n个项目,恰恰项目A重要性又不大,处于半撒手状态。

你提到的场景,要是有英雄主义人物在场,运气好的话就是神话;要是都是菜鸟到最后肯定是一个烂摊子。
0 请登录后投票
   发表时间:2013-03-13  
TO: zhanjia

项目A前期大家都没觉得没啥风险。但当原型系统拿给客户去测试的时候,而且是测试了差不多一个月的时候,才发现问题比较多,这个时候所谓的项目管理CMMI那帮人才介入,但此时进退两难。
因为一方面希望重新梳理软件需求(非业务需求),组织人开始做设计(设计文档+评审);
但另一方面,客户又在催和加一些紧急需求和缺陷。
此刻领导根本没有充分估计到后续的影响和风险,于是选择了2.

到今天为止,迫于质量和稳定性方面的问题,想重新设计,可已经分身乏术了。

美工一直没有,后来不知道从哪里借了一个美工,但没有起到作用,因为始终没有人拍板说要改界面。

最近比较被动,暂时还没有看到缓解的迹象。

---
个人认为,现在应该隔离一段时间,先把设计重新梳理一遍,写下来,评审。再把代码重构,先把系统调整一下,这样以后要调整功能可控一些,扩展性也好。如果继续这样走下去,后面很难维护很难扩展,风险更大。还有就是要把各自的分工明确一下,现在有点乱,职责不清。
0 请登录后投票
   发表时间:2013-03-14  
开发流程上不能搞一刀切,这情况还坚持瀑布模式之有死路一条...
赶紧换成敏捷模式可能还有点希望
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics