软件项目工程延期的处理案例doc.docx
- 文档编号:13195759
- 上传时间:2023-06-12
- 格式:DOCX
- 页数:25
- 大小:34.17KB
软件项目工程延期的处理案例doc.docx
《软件项目工程延期的处理案例doc.docx》由会员分享,可在线阅读,更多相关《软件项目工程延期的处理案例doc.docx(25页珍藏版)》请在冰点文库上搜索。
软件项目工程延期的处理案例doc
某软件工程工程延期的处理案例
某公司是一家专门从事系统集成和应用软件开发的公司,公司目前有员工50多人,公司有销售部、软件开发部、系统网络部等业务部门,其中销售部主要负责进行公司效劳和产品的销售工作,他们会将公司现有的产品推销给客户,同时也会根据客户的具体需要,承接应用软件的研发工程,然后将此工程移交给软件开发部,进行软件的研发工作。
软件开发部共有开发人员有18人,主要是进行软件产品的研发,及客户应用软件的开发。
经过近半年的跟踪后,今年元旦,销售部门与某银行签订了一个银行前置机的软件系统的工程,合同规定,5月1日之前系统必需完成,并且进行试运行。
在合同鉴定后,销售部门将此合同移交给了软件开发部,进行工程的实施。
王伟被指定为这个工程的工程经理,王伟做过5年的金融系统的应用软件研发工作,有较丰富的经验,可以作系统分析员,系统设计,但作为工程经理还是第一次。
另外工程组还有另外4名成员,1个系统分析员〔含工程经理〕,2个有1年工作经验的程序员,1个技术专家〔不太熟悉业务〕。
工程组的成员均全程参加工程。
在被指定负责这个工程后,王伟制定了工程的进度方案,简单描述如下为:
1〕1月10日~2月1日需求分析
2〕2月1日~2月25日系统设计,包括概要设计和详细设计
3〕2月26日~4月1日编码
4〕4月2日~4月30日系统测试
5〕5月1日试运行
但在2月17日王伟检查工作时发现详细设计刚刚开始,2月25日肯定完不成系统设计,您建议王伟应该如何做?
他在工程的管理中有问题吗?
分析列表:
工程在2.1完成需求分析,在设置检查点的时候,在此是否应该考虑有个点;在工程方案中应该对工程的关键路径进行设置,并依据此路径设置必要检查点。
问题既然已经发生,5.1已成为必定的时间,那么,首先必须对原因进行分析,在之根底之上再进行重新构建,我会考虑对工程范围作些调整,也会作些相应的加班
延期前:
1、5月1日这个日期是如何定下的?
定期Deadline之前是否考虑了公司的研发资源/力量?
2、工程开始前是否做过风险分析?
进度是否是该工程的风险?
3、工程是否有例会?
例会的频度是否与工程的周期相匹配?
例会的议程是否包含对目前工程面临的问题/风险的跟踪?
4、工程组的组成:
工程经理同时又是系统分析员。
工程经理应该懂业务,最好不要当系统分析员,不然会陷入技术细节纠缠不清。
5、工程方案是怎么做出来的?
是否经过工作量的详细估计?
是谁估计的?
应该由具体执行人员估计,再加上技术专家的意见。
6、是否识别出了关键路径?
是否对关键任务进行了重点监控?
7、工程的人力资源是如何获取的?
是否与该工程的难度、进度相匹配?
资源的数量是如何确定的?
是根据工作量确定的吗?
软件开发方案包含了需求分析,这是造成开发方案不准确的最大风险来源,我们的开发方案必须是根据需求分析后,进行工作分解得到的,而我们通常都不能这么做。
我认为需求分析后,再次进行方案调整变更,确定工程的最终时间表,并和领导、客户沟通是最可靠的。
题目:
常见现象李子军〔北京诺德信科技开发zijun.li@nordsan〕
虽然王伟第一次做工程经理,但仅从本文描述来看,并不能完全断定王伟的管理有问题:
1、阶段性的时间延迟是常有的事,资深的工程经理也不能完全控制每个阶段一定遵循预定时间
2、对于需求不明确、业务背景复杂的工程,适当延长需求分析的时间,有利于保证后期设计的准确性和减少需求变更的幅度和次数
3、需求分析是与客户共同开展的,你所做的工作、所花费的时间,客户是有目共睹的,是能够容忍的
4、延误的时间只有从后面几个阶段中挤出来,例如编码和测试同步进行等
5、万不得已,由于客户原因导致工程延期,适当延长工期,是必不可少的,总比开发成果与客户预期相悖要好
为政府实施电子政务工程的案例
公司A是市政府背景很强的股份制企业,机制比较灵活〔shanghai〕,目前该公司的正在进行的一个工程是政府机关的一个Mis系统,现在整个开发全部完成,系统已经试运行2个月左右,目前运行情况比较顺利,但是,目前有几个比较大的问题如下:
1.客户同公司关系特别密切〔毕竟客户是机关〕,不能完全按照合同进展。
2.政府的工作节奏比较慢,在工程实施进程中,严重单方面拖延实施进度,造成工程延期。
〔他们很小的工程决定需要开会讨论〕
3.不可预测的工程变更风险〔机关领导一句话,工程经理就要处理变更需求;可称其为领导人风险〕。
4.客户没有工程周期〔软件工程〕等认识,对合同规定的验收不予回应。
这个需要该公司老总才能协调。
〔工程经理没有这方面的权利〕
工程经理在工程组中本来负责软件开发设计,开发后期被部门经理任命为工程主管,对于客户主关需求变更,工程管理目前沟通的比较好。
但对于一些政策性的变更,那么非常的难处理〔需要必须改动〕,没方法,只有进行变更处理。
该公司应该怎么才能结束该工程呢。
分析列表:
题目:
维护方式丁丁〔mccdingr@hotmail〕
客户是政府机关,单位机制。
不太适应常规的市场经济运营方式。
那就软件公司适应客户吧。
1、列举重要的指标点,让客户确认。
2、在适宜的时间点,把工程由开发阶段过渡到稳定维护阶段。
而且可以收取所谓的验收费用〔运作~~〕
3、抽出原班人马,稳定一个阶段后,指定个人,就在现在做维护和简单开发〔不限期〕,也是保持良好的客户关系,和公司名誉。
这是中国现阶段制度决定的。
在接政府的工程时,干系人分析显得异常重要,一定要有风险分析和应对方案,管理储藏的比例也要增加,同时工程经理的沟通时间提高到95%。
题目:
效劳客户,培养人才贺炜〔西北工业大学ishewei@163〕
以前我们也曾接手这样的两个政府信息化工程,最终通过为对方培养人才脱手的。
最后工程完成后一个月,还偶尔要求我们过去,后来就完全由我们培养的政府自己的技术人员接手了。
题目:
电子政务实施中的效劳意识冷酷到底〔EXOAexoa20**@163〕
电子政务建设必须经历“从无到有,从有到好〞的过程,所以我们在事实电子政务的时候也必须向用户灌输一个这样的理念,明白电子政务的建设需要过程需要时间,如果达成一个这样的共识的话工程的实施相对来说风险会小的很多,所以晓川先生分析的非常的精辟,但是电子政务建设出现了“用而不验〞或“验而不用〞那就是工程组的悲哀,所以实施电子政务工程必须要树立一个效劳意识,工程靠效劳产生利润,而不是单纯的靠产品产生利润!
政府向企业买产品,也要买效劳。
工程应该将设计和实施划分开来,明确设计和实施的区别和界定,这样工程作的轻松,政府用的放心,用户当然也是开心了〔特别是领导,电子政务是很大的业绩〕,总结一句电子政务工程实施要企业要作好定位,效劳才是最能产生利润的。
题目:
关系与商务不能等同陈荣森〔深圳市佳创meid998@21cn〕
与客户关系亲密固然是好事,但不能等同于在做工程时都事事迁就于客户,朋友是朋友,商务是商务,不能等同,否那么会陷入很被动的局面。
建议:
如果客户领导提出变更的想法,你不好意思明说,但你必须每次都向他列举这样的变更会给系统带来很大的变更和变更的困难,以便给提出变更的客户压力,随着压力的积累,客户再次提变更时会有压力而变得谨慎。
我同意晓川先生的说法。
在我国的行政机构中存在的两个突出问题就是领导意志和作风拖沓。
相信在短期内这一现象难以消除。
因此,阶段目标的制定就变得非常重要。
管理水平的提高,往往不在于某项重大制度的变革,而是基于许多细微的、渐进的变化。
因此,在进行阶段目标的设定时,要首先提供让政府各级部门感到方便的功能,使他们逐渐具有兴趣,从而形成一种良性循环,其过程如同微软公司的软件发布一样。
我们做的是一个财务管理软件,在工程初期我们的工程经理做的售前工作,跟客户了解了大体的需求,并且制定了工程方案,而工程方案是一个很笼统的框架性的东西,而我被指派与客户详细的调研需求,整个工程的与客户面对面接触调研需求共3次,第一次我已完全理解客户的需求和意图,而第二次并没有什么实质性的收获,因为客户给我的时间就很少,我们只简单讨论了与客户现存系统的接口问题,第三次谈需求,客户提出了一些需求而针对他的子系统的结构是很难实现的,当时我竭力反对,但反对无效,因为我们的客户分两局部:
转包客户、最终客户。
这还是个二包工程。
而这种很难实现的需求是最终客户提出而转包客户不反对反倒支持。
这样三次需求调研的结果就是得到一个业务逻辑异常复杂的业务模型。
有了详细的业务模型之后,我很快初步估算出代码最少5万行,并且向工程总监通报了情况,但是工程总监认为工程不可能这么简单,也没去与客户沟通。
我只好按着这个需求继续往下进行〔当我与客户做二次需求调研时,我就已经变为工程经理的角色,当然此时我就是工程经理了,而原来的工程经理就是现在的工程总监了〕,当然了,在有了详细业务模型后,我们先设计了软件原型,用了两个星期,这阶段解决了几乎所有的界面组件〔有很强的通用性〕。
然后再与客户讨论原型,不过客户那边的反映很缓慢,光让他确认这个原型就浪费了二十天时间,不过这段时间我也没闲着,开始着想考虑他那个难缠的需求是不是有什么解决方法,结果分析来分析去,最终得出结论,根本不存在什么适宜的解决方案,而这块需求倒底做不做一直困惑我很长时间,其实与客户沟通很不方便,因为我们开发的地点与客户不在一个城市里,对于这样的问题我跟客户在msn上沟通过屡次,客户都不明白我要说的问题的本质是什么,他还是坚持要实现这个需求,结果为此我又努力偿试寻找解决方案。
客户催要一个初步的软件版本,因为但是因业务逻辑的核心问题,我们无法进行业务模块的编码,已经完成的是与业务关系不大的局部。
而此时我又进一步估算,代码量应该有8万行了,因为更细致的架构接口已经有了,也就是说一个完整的框架都有了,估算出的代码行数就比较准了。
8万行代码远远超出了原来的预算,就是去掉与客户不断的争论业务需求的时间都用来写代码,8万行代码也不是这个费用够用的,目前我处在骑虎难下的境地,公司要求我能拿出有利于我们有说服力的证据来,但事实上,客户除了那个比较难缠的需求外,没有更多多余的需求,而我也只对需求做了一些润色,我觉得这是很有必要的,去掉反倒不妥,并没有增加多余的需求。
但就是这样的需求完成他确实需要写8万行代码,如果去掉业务员的功能,我想能精减个一万行代码。
那还有7万呢啊。
公司要求我在尽可能短的时间内先完成一些根本的功能,但我不知道应该如何划分根本功能,在我看来,这些功能都很必要嘛,可以说大局部功能都是紧扣客户需求的,只有少局部可以暂时省掉。
与其说在最短的时候内完成一个根本功能版与客户谈,还不如说在最短的时候内完成软件第一个完整版本〔只缺少很少的一点儿功能〕,短时间肯定没戏。
完成了再跟客户谈价钱吗?
其实这个工程我们是赔大发了,继续做,公司也是支持不下去的。
这个问题难道就无解了吗?
案例太长了,大概了解了一下意思:
我的建议如下:
1.软件开发前期准备做的不到位,工程的准备本钱是永远低于实际操作本钱〔当然在工程完成时间内〕;
2.将用户需求明细在合同中;
3.工程开发的所有功能均按照合同确实定前方案执行,期间用户需求一但有变动,需让用户直接与工程管理人沟通,并明确需求的变动不在我方。
个人建议,请参考!
通过对案例的分析,我们了解到
1、对于工程的需求比较清晰,但是核心业务了解不够,同时还存在不合理需求
2、工程进度控制存在问题,和客户沟通因为2次转包存在一定的弊端,对客户的引导不够
3、对系统根本功能把握不够,其实也是对客户业务不够深入了解
4、工作量估计出现很大出入,导致预算超支
我的建议:
前面有朋友提出加强和客户沟通,确定根本功能等,我再补充一下。
针对客户急需初步版本,我认为可以选取两个业务流程来重点实现,作为demo版本演示给客户以增加客户信心。
另外比较重要的是重新梳理需求,删除自己认为合理但是得不到客户认同的,列出客户重点需求。
根据梳理后得需求重新估计工作量,确定工程预算。
最后就是针对梳理后的需求,进行合理的调整与客户沟通增加投资的问题。
适当采用需求增加导致费用增加的方法,因为案例并没有提到客户对需求的完全确认,这是一个突破口。
让客户对你们有信心,同时你们要显示出自己的实力,最后就是双方的妥协适量增加投资预算,到达工程的最终完成。
1确定客户要的根本模块,并只保障之.
2下狠心的把自己很满意的局部也按实际的客户根本需求情况进行删除.
除非充分与客户沟通,得到新的资源.没其他方法!
题目:
工程执行所需要的人员本钱超出了预算,而且工程已经严重泄后kitty〔南京jiwei1030@163〕
既然是用户型的工程,那就应该好好的利用客户。
其实客户有时自己都不明白自己要做的是什么,要实现的是哪些功能。
所以在前期需求阶段要花费很多的时间与客户讨论,究竟做哪,怎么做,然后达成一致的意见。
这种意见不是口头的,而是要经过双方具体代表性的人物签字确认的。
。
否那么后面的变更会变得不可追溯。
。
题目:
软件的根本功能!
赵宏伟〔东信北邮zhaohongwei@ebupt〕
其实针对一个软件的根本功能完全可以和用户谈判或者讨论来决定的!
在规定好的时间内完成相应的内容!
这样子也是一个工程执行过程中的调整!
你自认为的“在我看来,这些功能都很必要嘛,“这都是你自己认为的并不表示客户真正需求的!
所以在最短的时候内完成一个根本功能版完全可以在自己的控制之下完成呢!
题目:
确认需求唐旭东〔电子zhengwest@163〕
其实对于需求调研工作,我觉得这个是在培养客户,而不是在让客户任意发挥,因为客户不会对自己随口说出的话负责,只是觉得有这个需要,想这么做,在这个时候:
1.我觉得关键是要引导客户,把客户引导到自己的思路上,这样才有助于工程的进展,因为客户在自己心中不会有系统的模型;
2.其次,是要控制需求,抓主要矛盾,把主要的功能先实现,保证在主要的业务上系统能够实现,不会出问题;
3.再次,我觉得原因在于没有完全了解客户的业务,也就是说以前没有这方面的业务经验,对于需要调研那些方面,那些范围,没有在调研前做一个详细的分析和整理;
题目:
精简需求陈晨〔河北保定智能电脑seesunny@126〕
1、最主要的还是要有时机与最终用户沟通。
了解所作工程用户最关心的是那局部。
这局部作完成后等于完成了80%的工作。
2、确定哪些局部不用臆想出来的,把这局部仅仅做个界面,和简单的功能模拟就可以了。
3、如果希望工程成功,建议,不要仅仅看需求文档。
要看用户的工作是否真的非常紧迫的需要某些功能。
如果是没有什么模糊的努力做,如果不是就可以简单带过,功能有了就可以了。
当前最需要做的是把自己需要的工作,理顺出来,看看那些才是最重要的中心环节,这些弄明白了,个人认为可以按步就班的开发了
题目:
一点拙见于先生〔南方数码eolia_yu@126〕
1、看来应该是前期调研补充分的结果,那么现在在时间和资金紧张的情况下,可不可以只考虑客户最急需的局部,而不是自己认为有用的局部,此后在试运行期间完善呢?
2、可以根据工程进展情况,做一份工程实施估算报告,表达出导致紧张的各方面,这样更有说服力,并且一定要和总监与客户三方对话,因为这种情况下客户只认总监。
3、给出新的工程需求、实施方案及困难所在,必要时重新谈价格。
最近遇到了一个版本控制的难题,导致屡次上线后系统大面积瘫痪。
正在进行的工程是一个二期开发工程,一期、二期在一个同一个环境,目前工程内的工作内容有:
对于一期中Bug的修改、更新和对于二期内容的开发。
其中:
一期内容和二期内容有很强的关联性;一期内容的Debug结果要求用户方面测试,测试后及时更新上线;二期开发内容要求分阶段上线。
所以结果导致:
有时一期Debug结果上线后,影响二期开发、已上线内容;有时二期开发内容上线后,影响一期内容,或一期Debug上线内容。
最常见的头疼问题比方:
功能A是一期Debug结果、两个月前开发完成,近日用户测试完成,A功能完成后,Debug开发进程继续。
功能B是二期功能,一个月前开发完成,二期开发进程继续。
在A功能开发完,但未上线的时候,对于A功能相关的类进行了更新。
昨天,用户要求对于A、B功能进行上线,但不能有其他内容上线。
结果:
A功能上线后,由于修改了某二期内容〔已上线〕的公用函数,导致原二期系统瘫痪;B功能上线后,参加了B功能之后开发的代码内容,但是由于DB更新没有进行,导致系统报错。
抽象化一下就是:
N久以前,工程组开发了假设干个功能〔比方20个,其中有复杂的公用类和接口〕,之后继续进行开发〔此时有严格的版本管理〕,之后,用户要求对于其中的1,2,6,8,19号功能上线,结果上线系统瘫痪,但开发,测试环境的测试过程,是最新的结果,包括所有功能,没有任何报错。
分析列表:
〔刚刚按错了,重发〕
案例的工程问题在于将开发管理和产品管理别离开来,或者说没有严格进行产品管理导致。
一般来讲开发人员手头会同时拥有两个版本的开发权限,一个称为trunk分支,又叫做功能变化分支,一个称为bugfix分支,简单理解,trunk会有功能的增加,bugfix没有功能的增加。
案例提到的一期和二期就是bugfix分支和trunk分支的关系,虽然案例中提到严格的版本管理,我分析应该仅仅是指开发库的管理,没有涉及产品库。
其实我们知道版本库应该包括两个:
开发库和产品库。
案例应该加强的是产品库管理。
一期的bugfix正常发布,但是二期的发布应该是对一期bugfix发布的一个merge才正确。
公共库还是统一维护,并且整个作为一条产品线来维护才对。
楼主的工程问题在于将开发管理和产品管理别离开来,或者说没有严格进行产品管理导致。
题目:
版本控制的难题arkingchen〔tnarkingchen@hotmail〕
对公用函数库进行版本区分
一期和二期使用不同版本的公用函数
工程管理需要沟通-wadcom公司案例
-------------------------------------------------------------------------------
Wadcom是一家跨国电信设备公司,在中国设有分支机构。
公司在中国的组织结构如图1所示。
2000年7月,Wadcom公司与中国的运营商A公司签订了全国29个城市的IP设备供货合同,合同总值超过1.5亿元人民币,方案一年完成。
为此,Wadcom公司成立了专门的工程团队,由销售工程经理Harrison担任工程经理。
工程团队的其他成员如表一所示。
工程的干系人还包括A公司在国内29个城市负责确保现场安装环境的工程师,以及A公司聘请的负责系统测试的工程师。
7月20日,Wadcom公司中国区总裁Peter召开了第一次工程大会,开发团队中的Grant和Art以及生产工程经理Nick和订单管理经理Jerry通过参加会议。
会上宣布了工程团队的组建事宜。
随后的一周,Harrison和助手Jane一起完成了工程说明书和工程方案的起草,并提请相关人员确认。
之后,工程正式启动。
工程初期进展得很顺利。
很快,Harrison和Jane就制定出了工程时间方案、资源管理方案和风险管理方案等。
此时,位于美国总部的开发团队工程经理Art提出,希望销售工程师能够提供更多的用户需求细节以便提高开发效率和准确性。
为此,Harrison制定了为期一个半月的每周开发例会,要求Art和售前工程师Bing以及相关人员参加。
紧接着,订单管理经理Jerry告诉Harrison,由于事先没有沟通,出于“零库存〞的考虑,公司没有过多备件,需要延长交货时间。
Harrison与生产工程经理Nick讨论后得知,交货时间可能比预期要晚两个月。
显然,这是无法接受的。
因此,Harrison将此问题提交给Peter。
Peter要求Harrison制定了为期两个月的每周两次的订单状态报告和协调会议,并要求相关的高层经理参加,尽量缩短交货时间。
在即将交货的前两周,在一次和A公司的研讨会上,Harrison突然得知A公司工程中有些辅助的备件现场没有,这将影响施工进度。
无奈之下,Harrison要求系统安装和支持队伍在两周内到现场做实地勘察,并将所需的材料和备件统一上报。
由于工期紧迫,这些辅助备件不得不在国内单独采购。
因而,Harrison需要组织采购工作会议,并设置采购的工作程序。
此外,由于A公司各省局的相对独立性,工程的培训和准备工作比预期更为复杂。
虽然合同中规定了较详细的内容,但Harrison还是不得不参与本应属于A公司的一些具体工作。
最后,所有货物运到安装现场比预期晚了近一个月。
在此期间,工程相关的培训工作也结束了,工程进入现场安装阶段。
Harrison本以为工程前期那些繁杂的会议可以减少了,然而很快他就发现新的问题接踵而来。
由于恰逢国内春节时期,A公司各省局全部封网,工程不能按方案进行。
Harrison需要重新方案各地的实施日期,这给原本紧张的工期又增加了压力。
另外,由于工期的延误,负责施工的技术人员已开始忙其它工程,Harrison还得重新与负责技术支持的经理磋商安排。
经过近3个月的安装和调试,系统开始试运行。
按照合同规定,尾款要等到验收合格才能支付,双方都组织了各自的测试队伍。
3个月后,系统通过测试,工程在2022年9月底结束。
在一些大型工程中,通常涉及的工程人员众多,并且会有多个职能部门参与。
如何将这些职能人员组成一个有效的工程团队,是工程成功的关键因素之一。
管理需要沟通
管理学指出,通常,管理者要用70%的时间用于与人沟通。
而对于工程经理来说,需要花费90%或更多的时间来进行沟通。
就像上文的案例中,Harrison不但要与公司内部的销售、开发、生产、安装、培训等多个部门打交道,还需要与公司外部的客户打交道。
因而,沟通就不是一件容易的事情。
在上面的案例中,由于工程经理在沟通管理方面做得不够,“麻烦〞接踵而至。
先是库存缺乏需要延长交货时间,然后又出现安装现场缺乏辅助备件等问题。
原本工程经理制定好了工程方案,安排好了工程进度,却总是被一些“突发事件〞搞得措手不及,最终还影响了工程进度。
沟通管理的六要素
那么,如何在工程中进行行之有效的沟通管理呢?
一般说来,要从以下六个方面来考虑。
首先,工程经理应该将沟通本身加以方案,也就是要有具体的沟通方案。
虽然在各类工程管理教材中有许多关于沟通管理的论述,但是真正的IT工程环境中,大多没有具体的沟通管理方案,一般都只是简单罗列了工程的干系人。
沟通方案的制定至少要包括以下几个方面:
1、工程干系人的列表。
最好以团队为根底建立干系人列表。
2、确定以团队为根底的工程干系人的信息需求和沟通需求,即何人何时需要何种信息。
一般来讲,由于大的工程沟通渠道实在太多,以团队为根底能够大大减少这种渠道。
3、信息分发的渠道和方式。
对于重要的工程一定要有定期的工程绩效报告和问题状态报告。
4、工程定期会议,最好是每周例会。
这样,工程干系人知道有了问题在何时能够得到讨论和解决,并可防止突发组织会议找不到人的局面。
5、特殊问题的沟通对策。
其次,工程经理要尽量利用好干系人的首次会议,将工程的内容做较为详细的交待,并提请所有干系人对工程可能出现的问题提出建议。
在本案例中,需求不清和备件缺乏的问题如果很快被识别,就不会出现临时组织会议的复杂局面。
因此
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目 工程 延期 处理 案例 doc