软件项目失败案例.docx

1、软件项目失败案例软件项目失败案例【篇一：软件项目失败案例】软件工程_成功案例 1 卡拉 ok 点播系统 项目名称： 卡拉 ok 点播系统； 项目功能： 适合酒吧， 歌厅等小型的场所使用的小型局域网卡拉 ok 点播系统； 项目成功经验： 1.目标明确 该项目目标明确是该项目成功的一个关键因素。一开始， 在与客户方面经过友好地沟通， 使得项目目标清晰定义， 即在小型的局域网中使用的卡拉 ok 点播系统。基于明确目标定义， 为以后的开发工作， 包括需求分析， 计划制定， 人员任务分配等等都给予了极大的方便。很明显， 在一个项目开始时， 明确好整个项目的目标是很重要而且是必要的。2.开发人员经验丰富

2、很明显， 开发人员的开发经验丰富与否， 决定着整个项目的进度， 质量， 甚至成功与否。在该项目中， 几个开发人员开发经验丰富， 都有过一到两年的开发经验， 其中两个甚至有开发过类似的项目的经验。后来的事实也证明， 正是由于开发人员的丰富经验，极大地促进了整个项目的进度， 以及质量。3.文档的完备 在我国， 软件工程危机的一个很大的原因在于， 没有形成及时保存文档的习惯。往往， 一个项目结束了， 可是文档就那么几份， 甚至连最基本的需求分析， 计划大纲都不清楚。在进行该项目的过程中， 项目经理充分注意了这个问题。明确要求， 小组开发人员在完成完一天的工作， 一个任务单元时必须完成文档的总结。有了

3、这些文档， 为项目后期的测试工作起了很大的作用。2 远程医疗保健系统 项目名称： 远程医疗保健系统。项目功能： 实现医疗服务的远程实现。项目成功经验： 1.小组分工明确 这个项目的人员不是很多， 只有四个， 如何充分利用有限的项目小组人员是很重要的。该项目中， 项目经理对小组的开发人员进行了明确的分工， 在项目开发的一系列环节中都进行了人员的安排， 例如， 需求的定义， 计划的制定， 代码的编写， 功能的测试，客户的联系等。完备的而又明确的小组分工， 有利于项目的顺利运行。2.充分调动开发人员的积极性 该项目正是调用了开发人员的积极性， 充分激发了开发人员的开发热情， 发挥了开发人员的以往经验

4、， 从而使得项目在开发人员不是很多的情况下， 保质保量地完成了整个项目的开发工作。3.项目经理管理得当（财务， 人事， 风险,时间） 项目经理是一个项目的灵魂。其能力的强弱， 经验的丰富与否直接影响到了项目的开发。该项目中， 项目经理是一个有着丰富的 it 管理经验的人员。在财务的管理， 人事的计划， 时间的安排等方面的良好， 是该项目成功的一个很重要的因素。3 城域网综合资源管理系统 项目名称： 城域网综合资源管理系统。项目功能： 有效的管理网络资源， 包括歌曲， 电影， 课件， 新闻， 提高网络资源的利用率。项目成功经验： 1.需求分析清晰 需求定义， 是整个软件工程的基本前提。没有一个良

5、好的， 明确的， 清晰的项目需求， 开发工作的缺陷是显而易见的。为此， 公司在需求定义方面花了大气力。专门派了一个人员与客户经常保持联系。使得客户的一件能够很及时地反映到软件设计中。整是由于这样， 使得该项目在客户鉴定时很容易就通过了， 完全减少了后期的需求变动的麻烦。2.与客户保持沟通 很明显， 需求是很重要的。如果需求不明确， 或者需求经常变动， 会影响项目的开发工作。而需求的明确与否， 又与跟客户的沟通密切相关。与客户及时有效的沟通， 有利于客户及时的理解， 建议， 修改项目的功能和质量， 也减少了到了项目开发后期， 由于需求的变动， 从而导致项目失败的危险性。该项目中， 项目经理花了很

6、大的时间与客户保持联系， 了解客户需求， 这对项目的益处是显而易见的。3.跟踪项目 为什么要跟踪项目？ 有没有这个必要性？ 是不是一种时间的浪费？ 这个项目的成功充分地说明了这个问题。答案是肯定的。有必要进行项目的跟踪。这个项目开发人员有限， 开发资金也不是很充足， 而且加上开发周期短， 技术难度大等因素使得这个项目的开发难度极大。但是， 由于以前公司开开发过类似项目， 同时与以外项目的客户又有经常的沟通， 及时帮助客户进行项目维护。这些都为理解该项目的功能背景， 技术背景，专业背景具备了良好的环境。可以说， 该项目的成功实施， 是离不开前期对以外类似项目的跟踪的。软件工程_失败案例 1 数据

7、语音网络系统 项目名称： 数据语音网络系统 项目功能： 满足家庭用户和集团用户的语音业务及宽带数据业务的需求 项目失败教训： a 领导不力 由于领导的不力， 导致了小组在坚持计划和个人约束方面出问题。虽然有能力的领导是对领导角色的基本的要求， 但是， 能力是多方面的， 包括知识框架， 社交技巧，领导技巧， 沟通技巧， 风险估计等等都是对领导的要求。领导的能力直接决定了整个项目的整体质量。b 时间无限制拖延 时间上的无限制拖延也是该项目失败的原因之一。原本两个月的开发计划， 结果由于开发小组的效率低下， 导致了整个项目时间上的无限制拖延。c 质量低下 软件质量的低下， 无疑也是项目失败的关键原因

8、。由于软件质量的低下， 导致了项目测试阶段的工作量的复杂， 最终导致了项目开发的失败。2 邮政资信管理系统 项目名称： 邮政资信管理系统。项目功能： 管理邮政方面业务的监督和管理， 提高邮政的服务效率。项目失败教训： a 需求内容不明确， 把握不充分 这是我们经常遇到的问题。一方面， 由于客户（需求方） it 知识缺乏， 一开始自己也不知道要开发什么样的系统， 或者懒于系统地整理出来， 经常是走一步算一步， 不断地提出和更改需求， 使得实现方叫苦连天。另一方面， 实现方由于行业知识的缺乏和设计人员水平的低下， 不能完全理解客户的需求说明， 而又没有加以严格的确认， 经常是以想当然的方法进行系统

9、设计， 结果是推倒重来。因此， 需求分析必须注重双方理解和认识的一致， 逐项逐条地进行确认。b 工数估算过少 软件开发的工数估算是一项很重要的工作， 必须综合开发的阶段、 人员的生产率、 工作的复杂程度、 历史经验等因素， 将一些定性的内容定量化。对工数的重要性认识不足，经常用拍脑袋的方式草算， 是最常见的问题。还有， 软件开发经常会出现一些平时不可见的工作量， 如人员的培训时间、 各个开发阶段的评审时间等， 经验不足的项目经理经常会遗漏。同时， 还有如下一些原因也是很典型的： （1） 出于客户和公司上层的压力在工数估算上予以妥协。例如， 客户威胁要用工数更少的开发商， 公司因经营困难必须削减

10、费用、 缩短工期， 最后只能妥协， 寄希望于员工加班。（2） 设计者过于自信或出于自尊心问题， 对一些技术问题不够重视， 或者担心估算多被嘲笑。（3） 过分凭经验。由于有过去的成功经验， 没有具体分析就认为这次项目估计也差不多， 而没有想到这次项目可能规模更大、 项目组成员更多、 素质各异、 新员工很多， 而且是一个新的行业。c 项目组织过小 每个公司都希望以最少的成本完成项目， 人手不足是大多数项目都会面临的问题。还有一种情况是项目组成员的技术水平达不到项目的要求， 公司只能提供这些分配好的技术人员， 或者由于项目经理的失误， 在项目工数估算时没有明确要求技术水平， 寄希望于员工自己努力。还

11、有一些项目经理认为， 在项目启动时不需要高水平的技术人员。开发计划不充分 没有良好的开发计划和开发目标， 项目的成功就无从谈起。开发计划太粗略， 主要反映在以下几个方面： （1） 工作分担（责任范围） 不明确， 工作分割结构（wbs） 与项目组织结构不明确或者不相对应， 各成员之间的接口不明确， 导致有一些工作根本无人负责。（2） 每个开发阶段的提交结果定义不明确， 中间结果是否已经完成， 完成了多少模糊不清， 结果是到了项目后期堆积了大量工作。（3） 开发计划没有指定里程碑或检查点， 也没有规定设计评审期。（4） 开发计划没有规定进度管理方法和职责， 导致无法正常进行进度管理。3 企业客户资

12、料管理系统 项目名称： 企业客户资料管理系统。项目功能： 负责企业自身的客户的资料的管理， 分析， 提取， 提出实用方案。项目失败教训： a 设计能力不足 项目组设计人员能力的低下是项目失败的原因之一。一方面， 由于对技术问题的难度未能正确评价， 将设计任务交给了与要求水平不相称的人员， 造成设计结果无法实现。另一方面， 随着资源外包现象的日益普遍， 一些公司经常因工期紧而匆忙将中标的项目部分转包给其他协作公司， 这些公司的设计能力如不加仔细评价， 就会对整个项目造成影响。b 项目经理的管理能力不足 没有及时把握进度。项目经理自己也不知道项目的状态， 下属人员报喜不报忧， 害怕报告问题后给自己

13、添麻烦。进度管理必须随时收集有关项目管理的数据， 开发人员总是担心管理工作会增加自己的工作量， 不愿配合。管理人员甚至不知道应该收集哪些数据。由于没有进行定期的项目评审报告会， 表面上进展顺利而实际上隐藏着危机。管理人员总是轻信下属的报告而没有加以核实。出现严重问题时， 管理人员没有根据现阶段状况重新评价需求分析结果、 工数估算、 设计结果等就匆忙采取头痛医头、 脚痛医脚的措施， 致使问题更严重。4 电子印花分色系统 项目名称： 电子印花分色系统。项目功能： 该系统集计算机、 激光、 电子等高科技技术于一体， 支持高速、 高质量图像生成与编辑和印花工艺处理， 是一套稳定性高、 功能完备、 易于

14、扩充、 操作快速简便的已达到国际先进水平的开放式电子印花分色系统， 是国内唯一集样稿扫描， 花样设计与编辑， 云纹处理， 连晒输出等多功能于一体的具有自主版权的集成化系统 项目失败教训： a 开发商和客户的关系 本来开发商和客户之间是软件产品的提供者和使用者之间的关系,一个卖东西,一个买东西,两者之间的关系是平等的,公平交易,童叟无欺,这才是两者之间的正常合理的关系,可是现在呢? 现在开发商和用户之间的关系是严重不平等的,开发商为了 得到订单,往往委屈求全,放弃自己应该坚持的原则,在竞标时相互压价,甚至采用某些不够光明正大的手段来得到订单,自己把自己放到了 一个被动的地位.许多开发商都有这样的

15、口号 以客户为中心 ,他们不仅是这样说的,而且也是这样做的,问题是,一种不平等的关系,能够长期坚持下去吗?我从网上看到说,某个项目 竞标,某开发商提供的标书有一大箱子,需要两个人才能抬到会场上.请问,这种标书有谁会看呢?难道开发商连这点起码的常识都没有了吗?既然没有人看,那么为什么要写呢?难道开发商真的以为客户会傻到不知道你在欺骗他吗?那么写这种标书欺骗的是谁呢?恐怕是自己欺骗自己吧! 开发商怕得罪客户,却没有认识到有时和客户冲突是不可避免的,客户怕开发商来欺骗自己,于是一次一次进行试探,开发商越让步,客户越认为自己受到了欺骗.开发商的让步往往换不来客户的信任,而是换来了 客户的更加不信任.由

16、于开发商自己不相信自己,自己欺骗自己,最后也无法得到客户的信任. 毕竟软件开发是由开发商来完成的,那么就应该也必须由开发商来决定项目的进展和内容,可是现在却往往由于客户的压力而妥协,放弃自己的原则,这样来做软件开发,能成功 吗?失败是必然的,成功才是侥幸. 结论就是,在软件开发中,应当以开发商为中心,而不是以客户为中心,客户的意见只是参考和借鉴,而不是金科玉律,不应该害怕和客户发生冲突,而应该分析冲突产生的原因,把冲突看成问题的征兆,而不是单纯来消除冲突本身. b 销售人员和技术人员之间的关系 一个人担任的角色不同,他考虑问题自然会更多考虑到自己的切身利益,至于这样做可能会给同事带来的麻烦,就

17、管不了 那么多了 .在开发商内部,销售人员和技术人员之间的关系也非常奇特.在许多公司,为了 提高销售人员的工作积极性,对销售人员采用提成的方式进行奖励,而将底薪定得很低,这样一来,销售人员为了 拿到项目的订单,往往会屈从于客户的压力,许下许多难以兑现的诺言,或者由于对于技术的不了解而随意答应客户的要求.等到合同签订完毕,进入项目开发阶段时,客户会拿这些诺言来要求开发人员进行兑现,结果是开发人员非常被动,对销售人员怨气冲天,于是告诉客户这些要求无法满足,而客户也勃然大怒,你们这些人怎么一拿到钱就变了 脸了 呢?问题就是,由于销售人员不考虑技术人员将来的实现,从而许下了 过高的诺言,这样做的结果也

18、许可以拿到订单,可是由于销售人员和技术人员的口径不一样,最后客户无所适从,感到自己受到了 欺骗,接着将一腔怒火发到了技术人员头上,两者之间的合作和信任关系逐渐变成了对抗和欺骗的关系. 销售人员和技术人员应该是一个自行车的两个轮子,他们的关系必须是相互合作,相互支持的,而不应该是互相拆台,相互对抗的,一旦他们之间相互对抗,那么就会给整个公司的声誉带来灾难性的后果. c 项目管理者和开发人员之间的关系 项目管理者和开发人员之间的关系,本来应该是相互团结,相互帮助,共同面对问题的关系,可是许多项目管理者把这种关系扭曲成了管理与被管理的强制性关系,用种种规章制度,种种管理方法来强迫开发人员接受,把自己

19、放到了 开发人员的对立面,和开发人员离心离德,甚至还美其名曰 量化管理,科学管理 .在这种糟糕的管理下,开发人员没有任何办法,要么被动接受糟糕的管理,要么辞职以抗议.一旦一个项目发生了 这种情况,它想成功就非常难了. 这种问题原来并不明显,现在随着各种 mba,印度经验,软件工厂等似是而非的理论的泛滥,许多人,尤其是许多根本不懂软件开发的管理者,更加变本加历,用近乎苛刻的手段来加强对开发人员的管理,提出种种令人发笑的量化指标来对开发人员进行度量,还加上理论的依据,对于敢于反抗他们这种做法的开发人员,一律以开除来解决问题,造成的一个非常荒诞的现实就是,许多公司里宁愿使用刚刚毕业没有任何经验的学生

20、,不要有工作经验的工程师,美其名曰:易于管理,哈,容易上当受骗而已.请问,在这种管理者和开发人员之间的关系作用下,软件项目有可能获得成功吗? 项目管理者和开发人员并没有本质的区别,他们只是所处的岗位不同,担任的责任不同而已,在软件开发的问题上,尤其在具体的技术细节上,往往管理者不甚精通,如果他不能吸纳开发人员的智慧,而是自己一个人拍脑袋来做决策,那么失败就在眼前了.【篇二：软件项目失败案例】摘要每一次成功的产品发布背后都有数不清的失败尝试，而这也正是科技进步的方式。那么在2015年，业界最大的失败案例都有哪些呢？转播到腾讯微博腾讯数码讯（肖恩）2015年对于整个科技产业而言是非常重要的一年，我

21、们看到厂商和开发者们不断推出配备最新技术的产品。但在拥抱未来的过程当中，新的思路并不总是奏效的。每一次成功的产品发布背后都有数不清的失败尝试，而这也正是科技进步的方式。那么在2015年，业界最大的失败案例都有哪些呢？微软的部署策略转播到腾讯微博微软在今年所需要的是推出新产品的透明度，或者说改变现有产品。onedrive和windows令人费解的策略让用户难以去理解微软的动机，这也最终导致了这家科技巨头在这些领域里信誉的减损。在承诺所有office 365用户都可获得无限制的云存储空间之后，微软却又改口了，甚至试图调低免费onedrive用户的存储空间，而这引发了用户的强烈不满。一开始，微软把相

22、关的页面从运营商所使用的宣传册中拿掉，并称所谓的“无限”并非真正的无限。他们竟然表示，部分在onedrive中存储了大量内容的用户对他们的云服务造成了太大负担。虽然他们随后对责怪用户的行为道了歉，但这并不意味着无限制存储空间会再次归来。随后，onedrive for business团队很快也发出了类似的致歉，称只有特定的office 365商务版、企业版或教育版用户才会获得无限制的云存储空间。微软为windows 10所制定的策略同样引发了争议。在开放下载之后，用户担心windows 10会在后台收集太多的信息，从而影响用户隐私。有的人还批评微软以一种高压策略强迫用户升级windows 10

23、。如果微软可以坦诚自己的策略、动机和意图，那他们就可以避免早期的批评声音，甚至获得更多的忠实用户。比如说，他们可以让用户选择是否升级到windows 10，而不带任何隐藏动机，提供详细的升级内容介绍，并让用户来控制和选择数据收集的方式。操作系统的公开测试项目转播到腾讯微博在今年，苹果和微软等软件巨头都纷纷邀请用户参与到自家软件的测试当中。微软的windows insider preview项目会对新的windows 10版本进行公开测试，而苹果的public software program则允许用户尝试未发布的os x 10.11 el capitan版本。参与到这些项目当中的用户会被要求报

24、告自己的体验、漏洞和问题，作为交换，他们也获得了抢先尝试最新功能的机会。但是，这些项目都把加快发布进度放在了质量控制之前。即便是结束beta测试并公开发布之后，这些软件通常也会包含瑕疵和漏洞。比如说，早期的非beta版os x el capitan并未修复wi-fi、邮件和其他连接问题，windows 10的最新版本在运行word时也存在问题。如果这些问题和第三方软硬件有关，那可能还情有可原，但是，os x的软件问题存在于苹果自己的邮件应用，windows 10的升级影响的也是微软自己的硬件和软件，这就有点说不过去了。在beta软件的世界里，一款软件的beta阶段何时结束、最终发布何时开始经常

25、都是难以判断的，不过这或许就是把软件作为一种服务模式的风险。至少苹果和微软都表现出了他们愿意聆听用户反馈的心态。联网家居没能连接现实转播到腾讯微博苹果的homekit原本应该把联网家居和自动化办公变为现实，可现实是，物联网领域的碎片化问题依然没有得到解决就像是谷歌曾经推出过的androidhome一样，苹果的homekit并未把物联网带到主流。虽然市面上的物联网产品五花八门，但它们却并不总是能够彼此进行交流，用户通常需要独立的中枢、插件和应用来对其进行管理。联网办公或联网家居原本应该一款应用搞定一切，但在目前的物联网领域，这可能还是个奢求。物联网的基础概念的确是合理的，但想要让物联网蓬勃发展，

26、厂商们必须达成一个统一的标准。智能手表不智能转播到腾讯微博智能手表是今年另一种让人担忧的联网设备。随着apple watch的发布，许多人都把2015年冠上了“智能手表年”的称号，但即便apple watch的确比竞争对手更成功，这个所谓的“智能手表年”其实很难站得住脚。除了看时间和阅读通知以外，许多用户都并不确定自己是否需要一支智能手表，且学习新的手势和交互方式也非常复杂。此外，智能手表的使用现在还引发了礼仪上的挑战。虽然你不必掏出手机就能查看到手机收到的通知，并判断是否需要立刻回复，但在别人面前一直看手表也是一种不礼貌的行为。我们在今年还看到了一些“产品灾难”。lg的watch urban

27、e 2原本将成为首款支持4g lte的android wear智能手表，但由于产品本身在生产阶段暴露出的问题，lg最终决定终止它的发售计划。存储空间的需要转播到腾讯微博三星今年推出的galaxy系列旗舰手机都放弃了对于microsd卡的支持，这让不少用户感到十分不满。实际上，htc在两年前也有了类似的经历：他们在2013年推出的htc one也没有microsd卡槽，但由于用户批评之声太高，他们在新一代的htc one m8当中又带回了microsd卡槽。由此可以看出，苹果可不是那么好学的。但是，三星放弃microsd卡支持的决定似乎要比iphone的存储选择更容易让人接受，因为galaxy

28、s6和note 5系列的起始存储空间为32gb，而iphone依然还在沿用16gb的起始存储空间。考虑到用户们会越来越多地使用手机进行多媒体内容消化，或是拍摄高分辨率照片和视频，16gb的空间可能很快就会被占满。上网本复活转播到腾讯微博随着平板电脑的流行，曾经风靡一时的上网本被推到了淘汰的边缘。但微软和他们的合作伙伴却希望发起一场上网本的复兴，以此在教育市场挑战chromebook的崛起。近期问世的上网本都配备了更强大的英特尔凌动处理器，同时也把慢速机械硬盘换成了更快的固态硬盘。这虽然听上去很棒，可你必须承受硬盘空间大幅降低所带来的麻烦。比如说，从前的笔记本可能有160gb的硬盘空间，而如今的

29、机型可能就只有32gb了。微软和oem厂商都并未使用古老的上网本称号，相关的产品也获得了一些新的功能，但由于windows 10和厂商预装的垃圾软件的存在，用户可用的存储空间就更少了。且和chrome os不同的是，windows 10是一款完全基于本地存储内容工作的操作系统。由于chrome os对有限的硬件资源有着更好的管理，chromebook可能是廉价笔记本领域里更值得购买的选择。转播到腾讯微博【篇三：软件项目失败案例】一个软件项目的失败案例，希望能给大家带来帮助 时间：2014-06-04作者：点击：评论：字体：|最近有一个新的项目团队在开发一个新的功能，并且决定尝试用scrum，非

30、常有幸被邀请加入，担任scrummaster。一开始的时候一切似乎都很顺利，我们召开了一次项目的启动会议，请负责的产品经理明确对结果的期望，并且进一步确定了po的职责。更让我觉得好的是，由于这个项目的产品设计人员和专职的测试人员都在国外，为了确保质量，大家都同意本地的开发团队(都由开发人员组成，没有测试人员)不仅要关注代码开发，同时也要承担测试任务。国外的测试人员将作为po的助手，帮助对结果进行验收测试，而产品设计人员帮助po细化需求，为产品的backlog。而且，一个初步的产品backlog已经建立，包含了希望交付的功能，虽然不是标准的用户故事的格式，但应该还是ok的。一切看来，都很顺利，没

31、想到，执行到第三个sprint的时候，国外负责这个功能的产品经理突然要和po，还有我一起开一个电话会议，提出项目在11月中旬需要发布一个版本，以便让一些用户能够尝试使用，给出反馈，这本身不是问题，真正的问题是，在会后，突然发出邮件，决定停止计划会议，每日例会，回顾会议等等，也就是停止一切scrum的相关实践，作为scrummaster，从我的角度，这无疑是宣布了scrum尝试的失败!所以，我也花了一些时间反思这个项目，为什么会失败?项目中影响scrum实施的因素有利因素不利因素一开始得到了高层管理层的支持团队中有人参与过scrum项目，有scrum的经验团队有4人组成，技术经验都很丰富之前已经

32、做了较长时间的技术研究，团队对功能的理解比较充分除了一个人有过scrum项目经验，其他人都没有参加过相应的培训，而项目开始后，也没有安排时间进行一个初步的介绍(非常失败)团队里大多数人并不理解为什么要用scrum，只是被要求用scrumpo在另一个城市，而且很忙，没有足够的时间维护产品backlog，和团队沟通产品设计人员远在另一个国家，不利于具体需求细节的沟通导致失败的原因动机不清对于为什么要用scrum，希望scrum的实践帮助解决什么问题，或者对scrum的期望是什么，没有想清楚，这样会导致当在项目过程中遇到困难的时候，对最初的决定产生怀疑;职责不明对于sprint的目标，产品backlog中的优先级设置，除了po，国外的产品设计人员也会进行调整，并且没有和po进行充分的沟通，导致目标不清，需求不明，从而给沟通带来极大的混乱;缺乏培训团队成员一开始的时候没有安排时间