为什么在中国ERP项目80%都失败?
软件开发是一项复杂的系统工程,牵涉到各方面的因素,实际工作中,经常会出现各种各样的问题,甚至面临失败。
如何总结、分析失败的原因,得出有益的教训,对一个公司来说,是在今后的项目中取得成功的关键。
需求内容不明确,把握不充分 这是我们经常遇到的问题。
一方面,由于客户(需求方)IT知识缺乏,一开始自己也不知道要开发什么样的系统,或者懒于系统地整理出来,经常是走一步算一步,不断地提出和更改需求,使得实现方叫苦连天。
另一方面,实现方由于行业知识的缺乏和设计人员水平的低下,不能完全理解客户的需求说明,而又没有加以严格的确认,经常是以想当然的方法进行系统设计,结果是推倒重来。
因此,需求分析必须注重双方理解和认识的一致,逐项逐条地进行确认。
工数估算过少 软件开发的工数估算是一项很重要的工作,必须综合开发的阶段、人员的生产率、工作的复杂程度、历史经验等因素,将一些定性的内容定量化。
对工数的重要性认识不足,经常用拍脑袋的方式草算,是最常见的问题。
还有,软件开发经常会出现一些平时不可见的工作量,如人员的培训时间、各个开发阶段的评审时间等,经验不足的项目经理经常会遗漏。
同时,还有如下一些原因也是很典型的: (1)出于客户和公司上层的压力在工数估算上予以妥协。
例如,客户威胁要用工数更少的开发商,公司因经营困难必须削减费用、缩短工期,最后只能妥协,寄希望于员工加班。
(2)设计者过于自信或出于自尊心问题,对一些技术问题不够重视,或者担心估算多被嘲笑。
(3)过分凭经验。
由于有过去的成功经验,没有具体分析就认为这次项目估计也差不多,而没有想到这次项目可能规模更大、项目组成员更多、素质各异、新员工很多,而且是一个新的行业。
项目组织过小 每个公司都希望以最少的成本完成项目,人手不足是大多数项目都会面临的问题。
还有一种情况是项目组成员的技术水平达不到项目的要求,公司只能提供这些分配好的技术人员,或者由于项目经理的失误,在项目工数估算时没有明确要求技术水平,寄希望于员工自己努力。
还有一些项目经理认为,在项目启动时不需要高水平的技术人员。
开发计划不充分 没有良好的开发计划和开发目标,项目的成功就无从谈起。
开发计划太粗略,主要反映在以下几个方面: (1)工作分担(责任范围)不明确,工作分割结构(WBS)与项目组织结构不明确或者不相对应,各成员之间的接口不明确,导致有一些工作根本无人负责。
(2)每个开发阶段的提交结果定义不明确,中间结果是否已经完成,完成了多少模糊不清,结果是到了项目后期堆积了大量工作。
(3)开发计划没有指定里程碑或检查点,也没有规定设计评审期。
(4)开发计划没有规定进度管理方法和职责,导致无法正常进行进度管理。
设计能力不足 项目组设计人员能力的低下是项目失败的原因之一。
一方面,由于对技术问题的难度未能正确评价,将设计任务交给了与要求水平不相称的人员,造成设计结果无法实现。
另一方面,随着资源外包现象的日益普遍,一些公司经常因工期紧而匆忙将中标的项目部分转包给其他协作公司,这些公司的设计能力如不加仔细评价,就会对整个项目造成影响。
项目经理的管理能力不足 没有及时把握进度。
项目经理自己也不知道项目的状态,下属人员报喜不报忧,害怕报告问题后给自己添麻烦。
进度管理必须随时收集有关项目管理的数据,开发人员总是担心管理工作会增加自己的工作量,不愿配合。
管理人员甚至不知道应该收集哪些数据。
由于没有进行定期的项目评审报告会,表面上进展顺利而实际上隐藏着危机。
管理人员总是轻信下属的报告而没有加以核实。
出现严重问题时,管理人员没有根据现阶段状况重新评价需求分析结果、工数估算、设计结果等就匆忙采取头痛医头、脚痛医脚的措施,致使问题更严重。
以上谈到了项目失败的几方面原因,实际上还有很多原因,很难一一列举。
在这里我们没有篇幅提出如何避免这些问题的对策,但是通过这些原因的列举,希望能激起读者的共鸣。
软件项目失败的主要原因有哪些啊
你很多问题问重复了,梳理下1、什么是项目——项目是为提供某项独特产品、服务或成果所做的临时性努力。
2、什么是项目管理——在项目活动中应用知识、技能、工具和技术以达到项目要求的过程。
项目管理师通过应用和综合比如启动、规划、执行、监控和收尾等项目管理过程来进行。
项目经理是负责实现项目目标的个人。
软件开发项目就是某种软件研发的项目,而软件开发项目的管理就是对正在进行的软件开发过程进行控制和管理的手段。
软件开发项目成果和失败的因素很多,严格把控项目的九大范畴:综合管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理,项目成败由你掌控。
软件开发项目管理的环境有很多,我公司蓝云EasyTrack 是做项目组合管理软件,采用的就是JAVA进行开发,采用的J2EE技术和多层体系架构设计,可以在不同的操作系统、应用服务器和数据库系统的环境下工作,提供与其他各类软件集成接口。
有兴趣可以了解下,深圳蓝云EasyTrack PPM是项目组合管理方案的专家。
什么情况可以称为失败的软件项目?
1平衡原则 在我们讨论软件项目为什么会失败时可以列出了很多的原因,答案有很多,如管理问题、技术问题、人员问题等等,但是有一个根本的思想问题是最容易忽视的,也是软件系统的用户、软件开发商、销售代理商最不想正视的,那就是:需求、资源、工期、质量四个要素之间的平衡关系问题。
需求定义了做什么,定义了系统的范围与规模,资源决定了项目的投入(人、财、物),工期定义了项目的交付日期,质量定义了做出的系统好到什么程度,这四个要素之间是有制约平衡关系的。
如果需求范围很大,要在较少的资源投入下,很短的工期内,很高的质量要求来完成某个项目,那是不现实的,要么需要增加投资,要么工程延期;如果需求界定清楚了,资源固定了,对系统的质量要求很高,则可能需求延长工期。
对于上述四个要素之间的平衡关系最容易犯的一个错误,就是鼓吹多快好省四个字,多快好省,多么理想的境界啊?需求越多越好,工期越短越好,质量越高越好,投入越少越好,这是用户最常用的口号。
多:需求越多越好吗?软件系统实施的基本原则是全局规划,分步实施,步步见效,需求可以多,但是需求一定要分优先级,要分清企业内的主要矛盾与次要矛盾,根据PARETO的80-20原则,企业中的80%的问题可以用20%的投资来解决,如果你要大而全,对不起,你那20%的次要问题是需要你花费80%的投资的!而这一点恰恰是很多软件用户所不能忍受的。
快:真能快起来吗?快是用户、软件开发商都希望的。
传统企业里强调资金的周转情况,软件企业里强调的是人员的周转情况,开发人员应尽快做完一个项目再做另外一个项目,通过快速的启动项目、结束项目来承担更多的项目,来获利。
但是快不是主观的拍脑袋定工期就可以完成的,工期的定义一定要基于资源的状况、需求的多少与质量的需求来进行推算的。
软件毕竟需要一行代码一行代码的写出来,他的工作量是客观的,并非人有多大胆,地有多大产式的精神鼓动就可以短期完成的。
省:省到什么程度?一分钱一分货,这是中国的俗话,他是符合价值规律的。
甲方希望少投入,乙方希望降低自己的生产成本,省到乙方仅能保本的时候,再省,乙方就亏损了。
正视这四个要素之间的平衡关系是软件用户、开发商、代理商成熟理智的表现,否则系统的成功就失去了一块最坚实的理念基础。
企业实施IT系统的首要目标是要成功,而不是失败,企业可以容忍小的成功,但不一定容忍小的失败,所以需要真正理解上述四个要素的平衡关系,确保项目的成功。
2高效原则 在需求、资源、工期、质量四个要素中,很多的项目决策者是将进度放在首位的,现在市场的竞争越来越激烈,产品早上市一天,就早挣一天钱,挣的就比花的多,所以一定要多挣,基于这样一个理念,软件开发越来越追求开发效率,大家从技术、工具、管理上寻求更多更好的解决之道。
基于高效的原则,对项目的管理需要从几个方面来考虑:要选择精英成员 目标要明确,范围要清楚 沟通要及时、充分 要在激励成员上下工夫3分解原则 化繁为简,各个击破是自古以来解决复杂问题的不二法门,对于软件项目来讲,可以将将大的项目划分成几个小项目来做,将周期长的项目化分成几个明确的阶段。
项目越大对项目组的管理人员、开发人员的要求越高,参与的人员越多,需要协调沟通的渠道越多,周期越长,开发人员也容易疲劳,将大项目拆分成几个小项目,可以降低对项目管理人员的要求,减少项目的管理风险,而且能够充分地将项目管理的权力下放,充分调动人员的积极性,目标会比较具体明确,易于取得阶段性的成果,使开发人员有成就感。
作者主管过的一个产品开发项目代号为SB,该项目前期投入了5人做需求,时间达3个多月,进入开发阶段后,投入了15人,时间达10个月之久,陆续进行了3次封闭开发,在此过程中经历了需求的裁剪、开发人员的变更、技术路线的调整,项目组成员的压力极大,大家疲惫不堪,产品上市时间拖期达4个月。
项目完工后总结下来的很致命的一个教训就是应该将该项目拆成3个小的项目来做,进行阶段性版本化发布,以缓解市场上的压力,减少项目组成员的挫折感,提高大家的士气。
4实时控制原则 在一家大型的软件公司中,有一位很有个性的项目经理,该项目经理很少谈起什么管理理论,也未见其有什么明显的管理措施,但是他连续做成多个规模很大的软件项目,而且应用效果很好。
作者一直很奇怪他为什么能做的如此成功,经过仔细观察,终于发现他的管理可以用紧盯2字来概括,即每天他都要仔细检查项目组每个成员的工作,从软件演示到内部的处理逻辑、数据结构等,一丝不苟,如果有问题,改不完是不能去休息的。
正是在他这种简单的措施下,支撑他完成了很多大的项目,当然他也是相当的辛苦,通常都是在凌晨才去休息。
我们并非要推崇这种做法,这种措施也有他的问题,但是,这种实践却说明了一个很朴实的道理:如果你没有更好的办法,就要辛苦一点,实时控制项目的进展,要将项目的进展情况完全的实时的置于你的控制之下。
上述的方法中对项目经理的个人能力、牺牲精...
软件开发失败的原因是什么?
百分百网站是2007年9月开始制作的一个求职招聘网站项目,客户为黑龙江国信通信公司。
在2008年2月,我们与客户协商,终止此项目开发,我们不再继续做这个网站,他们也不再支付剩余的款项。
直白一些地说,就是百分百网站项目是以失败告终的。
这些天,我想了一些这个网站为什么会失败,原因何在?思来想去,主要归结出以下几点: 1. 老生常谈,需求分析问题。
虽然我们不断在谈需求分析的重要性,我也相信每个人都知道需求分析的重要,但到了真正开始做网站的时候,想的更多地是尽快的投入 到项目的开发中,而忘记了或忽视了需求分析。
百分百网站失败的重要原因,与其说是客户的需求不断变化,倒不如说是我们开发人员对项目的需求分析没有做好, 而且可以说是需求做的很有问题。
客户没有提任何要求,我们只需按我们的想法来开发就行,刚开始还以为这很好,给了我们充分自由发挥的空间。
随着项目开发的 进行,我们逐渐发现越来越多的问题出来了,尤其是到了给客户验收时,客户就会提出这样或那样的要求。
最后的结果就是:我们做的,并不是客户真正需要的,而 客户真正需要的要求,我们并没有做。
为此,我提出一条解决途径,在项目正式开始之前,一定要把客户需求弄清楚,需求除用文字表述外,最好做一些展示效果页面,让客户清楚直观地看到做成后网站的效果。
当然为保证项目进度,效果页面做的要适量,可以只做一些重要的核心的功能页面。
2. 对项目没有正确的认识,没有做好长期开发(超过两个月)的思想准备。
项目开发前期,每个成员都是充满激情,斗志满满,但随着项目开发时间的推移,项目成员 的开发热情逐渐低落。
要知道,我们小组并不是只能做两个月就能做完的小项目,也并不是每个项目都能在两个月内做完,尤其是在采用新的技术时。
因此,我希望在项目开发前,每个项目成员都应该对项目有个整体认识,并作好长期开发的准备,尤其是做规模大一些的项目。
3. 对项目组情况认识不清楚,项目进度管理没有做好。
项目开始时,做了一个项目进度表,三天做完模块A,两天做完模块B。
到了项目真正开始时,才发现项目成员 对ASP.NET技术并不熟悉,于是花几天时间学习新技术,再花几天时间练习练习,项目时间已经延后了N天了。
在此,我真心地希望以后的项目负责人在做项目前,一定要对项目成员的水平有个正确的认识,并为项目开发做好各方面的充分的准备。
如果是采用新的技术开发,最好安排出几天用来学习、熟悉新的技术。
4. 项目质量管理没有做好。
为了赶进度,我只是简单地问项目成员的开发情况,看一看做的页面效果。
到了项目测试时,发现部分功能有问题,再看代码,开发的非常混乱,没有一行注释,很难进行修改。
在此,我借用陈旭东提的一个想法:一个项目除有一个项目负责人之外,再配备一个监督人员,其职责主要有: 一、做需求分析时,他和项目负责人一起与客户谈需 求,一起负责写成需求分析文档(这可以保证需求的完整性与正确性)。
二、监督项目进度,对项目开发人员进行督促,并负责向小组委员会汇报。
(这可以保证项 目的进度) 三、监督项目质量,对已经开发出的产品进行测试,有问题及时反馈。
(保证项目的开发质量) 四、不参与项目开发(主要考虑是避免分散精力)。
当然 这只是一个想法,可行性有待验证。
5. 最后一点,也是最重要的一点,作为项目负责人的我,没有做好项目负责人应尽的职责。
对我来说,写这部分是最困难的,我知道我不可能真正地写的客观,只能力 求写的客观。
项目开发中,我没有合理地进行项目分工,徐彬写的系统后台的需求,却由韩冬妮来做,汪浚琼写的个人求职的需求,却由徐彬来说,而且每个开发人 员的职责界定的也不够清楚。
另外,由于上个学期的课程比较多,考试也多,不懂得时间的有效安排,以至于有时因为自己的原因,而没有尽到项目负责人应尽的责 任,甚至推迟项目进度。
在此,我表示深深的自责,同时,也希望未来的项目负责人能够有足够的时间与精力来负责项目,如果能有一些管理或协 调组织方面的经验,那就再好不过了。
至于技术,我的看法是项目负责人不必是技术最好的,他的主要责任不是模块开发,而是将几个单个的开发人员变成团结的开 发团队,有效地协调并组织项目的开发。
项目收获: 俗话说,有得必有失,有失也必有得。
虽然项目中存在着许许多多的问题,虽然项目以失败而告终,但相信每个项目开发人员也会多多少少有一些收获。
下面,我抛砖引玉,说一说我自己在项目中的一些收获:考试大编辑整理 1. 对ASP.NET技术有了更加深入的认识。
以前只是学习了这项技术,在这个项目过程中,真正在实践中使用这项技术来进行开发。
2. 作为项目负责人,我也深刻地体会到负责人不是高高在上,而是一种责任,是对客户的责任,也是对所有项目开发人员的责任。
同时,我也认识到了项目管理的重要,没有科学的项目管理,很难并学会了一些项目管理的方法。
3. 以上的错误总结,从另一个角度上来说,也是我的一种收获,而且我想这次项目失败的过程与经历也是一笔无价的财富。
项目失败原因是什么?
.为什么要讨论失败 大家都知道,失败是成功之母。
著名的哲学家Karl Popper说:知识实际上是通过失败,而不是通过成功来获得的。
牛顿的理论被爱因斯坦的理论所补充是因为牛顿理论不能解释某些现象,而爱因斯坦的理论正在被更新。
在通常的实践中也是如此。
当关于为什么会失败的根本原因(理论)被发现以后,其他人就可以采取行动防止类似的失败重演。
许多具有新闻价值的项目失败(包括生命或者重要资源的损失的失败)最后都有一个公开结果的调查或者研究。
然而大多数失败并没有得到完全的调查,尽管需要如此。
对于项目失败的分析是基于学习和提高的精神。
2.什么是项目失败 任何失败都不是孤立发生的,也就是说,失败实际上是从一个特定的系统产出。
从这个意义上来说,所有的失败都是系统失败。
广义地说,一个系统如果符合下面两种情况之一它就会失败。
_导致项目失败的两种情况 ①它不满足系统所包含的管理者、用户,或者其他受影响的项目干系人的要求。
项目失败通常意味着不能满足成本、工期安排、绩效、质量、安全或者相关的目标要求。
②它产生了那些参与系统的项目干系人不想要的结果。
一个失败的项目不能满足用户或者开发者的期望,或者结果比他们所期望的更糟糕。
_项目失败的标准可以从以下两个角度观察 ①当一个已经确定了价格的项目成本超标时,开发者必须承担额外的成本,遭受利润损失或者利润减少。
从开发者的角度来看,项目是失败的。
②项目最终产品不能被接受或者使用,尽管它是按照工期,在预算范围内,根据规范交付。
这是用户或者其他的项目接受者所经历的项目失败。
这两种失败,即项目开发者失败和项目用户失败可能是互相排斥的。
就是说有一方失败,可能使另外一方得到好处。
比方说,一个失败的项目,项目开发者破产了。
但是他的用户或者反运作人,从项目当中赚取大量的利润。
当然,这两种失败也可能是一致的,如一个建筑物倒塌所引起的生命损失,对所有人来说都是一个失败。
3.造成失败的原因 有些失败是不可避免的,因为它们超出了人力所能预期、避免或者影响的范围。
这种类型的失败源于天气或者劳动力问题、难以解决的技术难题以及其它不可预见或者不可控制的外力。
但是,这并非是大量项目失败的原因。
相反,失败通常是由于“缺陷”引起的,这些缺陷存在于: _项目和用户组织——态度、实践和结构。
_项目最终产品——硬件、软件和组成部件。
这些缺陷通常是相互联系的。
例如,尽管硬件失败是因为部件和程序的缺陷,但这些缺陷通常可以追溯到设计时的失误,接下来又可以追溯到在设计和管理过程上的失误,这些失误使得错误没有纠正就过关了。
也就是说,计划和控制项目的系统,即项目管理系统内的缺陷可能允许和导致低劣的设计、糟糕的质量控制、不充分的检查,最后导致最终产品本身的失败(“硬件”或者“部件”的失败)。
【案例】 1986年“挑战者号”航天飞机的失败和它的七个宇航员的丧生,尽管是不完美的硬件设计直接导致了这起爆炸,但根本原因是项目组织中不称职的有缺陷的管理,它们让设计错误未加改正就通过了。
挑战者号事故的直接起因是有缺陷的O型环——火箭助推器上的封条,就是它们使得热废气泄漏并触发了外部燃料箱的爆炸。
然而,大家都知道而且有明确文献记录说这种封条在某些温度下的表现很糟糕,这样就会对飞行安全造成严重的威胁。
在悲剧发生的当天,有好几位工程师警告说封条可能会失效,但这些警告没有引起人们的注意,仍然做了升空决定。
先前保留并非最优化的封条并批准发射的决定是全然不顾警告的管理决策,它忽略了大量的反面信息。
很容易就可以得出这样的结论:事故是有缺陷的管理系统的产出。
如何对软件项目进行可行性分析
可行性分析与需求分析可行性分析是要决定“做还是不做”。
需求分析是要决定“做什么,不做什么”。
即使可行性分析是客观的、科学的,但决策仍有可能是错误的。
因为决策者是人,人会冲动,有赌博心态。
如果可行性分析表明做某件事的成功率是10%,失败率是90%,倘若该事情的意义非常大,决策者也许会一拍脑袋:“豁出去,干!”于是这世界就多了一份极喜与极悲。
4.1节讲述可行性分析的四大要素:经济、技术、社会环境和人。
目前国内很多软件公司做系统集成项目,如果谈谈系统集成项目的可行性分析将很有意思。
可是那些系统集成项目大多是政府机构的,由于软件行业尚不规范并且客户方存在腐败现象,所以业内流传“没有做不了的系统集成项目”。
软件公司的注意力几乎全集中在“如何拿到项目订单”以及“拿到订单后如何蒙混过关”上,使我丧失了卖弄“可行性分析”的机会。
既然不能正面指点一个人如何做好事,那么就规劝他不要做坏事吧。
4.2节讲述可行性分析案例——投资软件公司失败的教训。
作者本来没有资格谈论投资,但事有凑巧:近一年来我关闭了一个亏损30万元的软件公司(我自己的);休克一个年亏损200万元的软件公司(朋友的);扼杀一个200万元的投资方案(陌生人的);踩灭一个处于萌芽状态的100万元的投资设想(熟人的)。
鉴于现在比较富有的民营企业渴望投资软件行业的越来越多,值得谈谈这方面的可行性分析。
我将讲述亲身经历后的感受,提一些建议。
不论是为客户做软件项目还是为自己做软件产品,都要进行需求分析。
需求分析最恼人之处是难以在项目刚启动时搞清楚需求,如果在项目做了一大半时需求发生了变化,那将使项目陷入困境。
4.3节解释需求分析为什么困难,4.4节讲述如何进行需求分析。
本章的需求分析均不涉及编程,所以不考虑结构化、面向对象等分析方法。
4.1可行性分析的要素做可行性分析不能以偏盖全,也不可以什么鸡毛蒜皮的细节都加以权衡。
可行性分析必须为决策提供有价值的证据。
联想集团领导人柳传志曾说:“没钱赚的事我们不干;有钱赚但投不起钱的事不干;有钱赚也投得起钱但没有可靠的人选,这样的事也不干。
”柳传志为决策立了上述准则,同时也为可以行性分析指明了重点。
一般地,软件领域的可行性分析主要考虑四个要素:经济、技术、社会环境和人。
本节只是泛泛地解释这四个要素,旨在建立全局分析的观念。
4.2节将结合案例围绕上述要素进行重点分析与评注。
4.1.1 经济经济可行性分析主要包括:“成本——收益”分析和“短期——长远利益”分析。
1一、成本——收益分析成本——收益分析最容易理解,如果成本高于收益则表明亏损了,如果成本大大高于收益那就亏大了。
商人都不喜欢做吃亏的事情。
有些商店成天贴着“最后一天跳楼大拍卖”的标语,意思是:我准备吃大亏让你占便宜,同志,你快上钩吧。
如果是为客户做软件项目,那么收益就写在合同中。
如果是做自己的软件产品,那么收益就是销售额。
人们在预估产品销售额时常常过分乐观而犯下大错。
那些对你的产品说恭维话的人并不见得就是要买货的人,俗话说“嫌货才是买货人”。
当你没碰到一个挑刺的人而感觉这产品好得会让你发大财时,就要做好会破产的心理准备。
如果做的是小本生意,那可得对成本进行细算。
软件的成本不是指存放软件的那张光盘的成本,而是指开发成本。
要考虑的成本有:(1)办公室房租。
(2)办公用品,如桌、椅、书柜、照明电器、空调等。
(3)计算机、打印机、网络等硬件设备。
(4)电话、传真等通讯设备以及通讯费用。
(5)资料费。
(6)办公消耗,如水电费、打印复印费等。
(7)软件开发人员与行政人员的工资。
(8)购买系统软件的费用,如买操作系统、数据库、软件开发工具等。
有些老板买盗版的系统软件,却按市场价算成本,可从美国佬那里赚一笔。
(9)做市场调查、可行性分析、需求分析的交际费用。
(10)公司人员培训费用。
(11)产品宣传费用。
如果用Internet作宣传,则要考虑建设Web站点的费用。
(12)如果客户是政府部门,还要充分考虑用于吃喝玩乐、行贿的费用。
(13)如果公司的风水不好,会有很多莫名其妙的管理费。
每戳一个红艳艳的公章都要化一把钞票。
二、短期——长远利益分析人们喜欢吃着碗里的、看着锅里的,还想着别人家里的。
短期利益和长远利益兼得是人们梦寐以求的事。
在商业上,这等好事可不会轻易降临。
短期利益容易把握,风险较低。
国内软件公司经常出现一窝蜂地去做信息管理系统、多媒体光盘、系统集成项目或Internet服务。
每当我们沉迷于短期利益不思进取时,应该好好回忆童年时代那些伟大的抱负,给自己一些激励。
长远利益难以把握,风险较大。
能为了长远利益不惜短期亏损的人,要么是雄心勃勃的将帅之才,要么是“纸上谈兵”、“眼高手底”的那一类庸人。
国内目前有不少Internet企业,只投入不产出。
为了成就将来的霸业,甘愿现在拼财力、比耐性。
最后存活下来的几个公司将瓜分市场。
那些为长远利益奋斗的人们,你们可得把长征的路途走完啊,千万别让事业中途夭折。
24.1.2...
转载请注明出处51数据库 » 中国 软件 项目 为什么失败