tom_lt:
遇到的失败项目比较多！让人郁闷！！
仔细分析原因，主要在于：
1.项目开始需求不明确。领导决定动手，就开始启动项目，造成和客户需要差距太大，导致失败；
2.需求变更没有控制。客户提出新的需求，或者改变原来的需求，没有一个好的控制流程，没有人把关，程序员也可以接受客户的要求，导致功能越来越复杂，进度和质量严重失控，被客户赶走！
3.自己太随意。开发人员自作聪明，认为客户会需要某个功能，未和客户协商，就增加了一些额外的功能，导致进度拖延，客户不满意。
4.用户原因。用户提出了需求，功能很多，要求你在不可能的时间内完成，我们只能加班加点，最初还能坚持，时间一长，工作效率和精神状态都低了下来，进度拖延得更多。
Jinq0123:
如果说超时是失败，那我就没成功过，除了一些一个月之内的超小型项目。
主要是计划太雄心勃勃。
我的一个朋友说计划应该有点挑战性。
但我现在的体会是需要历史项目的统计数据才能订出合理的计划。
sythree:
和大家差不多。
有一个是市场部对客户承诺太多，需求变更太厉害了。
还有一个内部转包的项目比较可惜，开始不太重视，后来技术高层屈服于管理高层，对设计做了较大的更改，没有验证，结果出了几个大的性能错误。当是就感到很窝囊，一气之下换了个部门。
komantian:
失败的定义：用户拒绝接受
成功的定义：按时交货，客户接受
我的第一个日本项目，状态编程可以，不懂日语，程序员身份，当时这个团队都很厉害，美誉为梦之队，最后项目重做，投入了5倍于原定计划的人月数，也就是作了25个人月，项目无法联合调试，可以运行了，毛病百出，别说客户，我自己都不想要；事后总结：公司因为其它项目的原因，我们更换了3个项目负责人，导致指挥和仕样理解都有偏差，公司为了造成没有更换项目负责人假象，要后来的项目负责人一直使用前任的邮件帐号，造成客户不知情，对后来人的提出问题很生气，认为已经讲过了，造成沟通效果越来越差；程序员因为语言问题，只能了解自己的问题，不清楚全局的要求，因为项目负责人的更换，内部要重新磨合交流了解，最后每个人都完成了，却无法联合调试。公司的负责人应当负责。我作为程序员也因为其它项目原因，在这个项目组3进3出，当然我的责任现在想起来也不好受，我没有坚持自己的要求，盲目服从上级，在第二次更换项目负责人的时候，我应该挺身而出，但我没有。
至少在半年时间里，我的情绪都没有恢复。
失败会给你很多经验，从此我做项目都非常谨慎，反复推演各种情况，避免重蹈覆辙。我对项目中的BAD SMELL现在很敏感，发现一点不对头，立刻行动起来，坚决的解决它再前进。
值得庆幸的是这是我的目前唯一的一个失败的项目，我后来做到项目经理，大小也作了7、8个项目，有的也很大，在全国部署的项目，从失败中我获益匪浅。
ntchengl:
欧当作程序员参与的项目，就算是输了，关系也不大。
欧主持的两个项目，最后都算是成功了，但是都很坎坷。
这两个项目是这样的：
第一个项目是半道接手的，前任已经做过了需求分析。说实在的，只是去调研过了，需求分析的成果，我基本没有看到。但是时间仓促，最后扭转乾坤了。虽然这个项目托了3-4个月，但是责任不在我。第一我不熟悉业务，有个熟悉的过程；第二原先的需求调研不充分，错误地估计了工期。说实在的，我只算是延误了2个月。
第二个项目是香港的，做了10个月。这个项目算是输了，但是不算我输了。项目初期调研的时候，欧去不了香港，去了一个不懂业务的人调研，调的还不如半吊子。我没看到合同条款，公司就签合同了。只是从香港的客户那里看到了合同，而且不是最终合同。这个合同的附件只有两页：我们写的是广告宣传上面的牛B话，客户的要求也是模棱两可。我真不想做这个项目，可是没办法。这个项目我也是重新调研，质量完成得还算可以吧，客户的要求太高了，我们的合同签的我哑口无言。最后完成了，原计划3个月，实际做了10个月。最重要的原因，是市场部不调研就错误地认为3个月才能完成。
这两个项目都是差在需求分析上面，都不是我做的。说实在的，最终能做出来，还多亏了我呢。
我做的需求分析，自己主持的项目，都是比较小的，基本没问题。
clamp_chen:
成功和失败只是简单的二分法，很多时候都是介于两者之间的，既不是完全
的成功也不是完全的失败。
影响的因素不单是技术层面的，还有管理层面的，市场层面的。
说不定一个开发的很差的系统却赚了不少钱，而一个开发的很好的系统却
利润很薄。哪个项目比较成功呢？
我最近有这样一个想法，就是软件系统要引入质量等级的概念，就象传统
制造业一样，有一级品、二级品、三级品等等。
我曾经做过两个项目，第一个项目的时候经验不是很足，一开始需求就做
的很不仔细，也不知道如何控制客户需求，人手也只有两个技术人员，但
是还有一个市场人员支持，不过那时很有热情，紧赶慢赶了两个月就交付
了，然后就是根据客户需求不断地调整，调整了大半年才基本稳定了。
从技术层面评估这个系统很差，无论是可重用性还是易用性都很差，如果
换个人接手肯定气死了，我们后来也一直有把它重新架构的考虑，但由于
种种原因一直没有实现。
但是如果换个角度评判，这个项目其实很不错。
第一：客户满意度很高。（支持的市场人员很会拉关系，而且客户原来的
操作确实很烦琐，我们的系统虽然不太好用，但是还是为他节省了大量的
时间，另外，我们的响应很及时，经常是一个电话就到现场，直接改掉。
因此无论是客户的领导还是实际的操作者都比较满意，后来还给了我们公
司一个更大的项目）
第二：公司利润很好。（因为只有两个人，成本很低……而且拉来了后
面的项目，好处很多）
后来有一个项目，经验比以前增加了很多，对软件工程也知道了不少。
客户方面也比较严谨，有专门的懂技术的用户代表配合。整个开发团队
也很齐整，设计、开发、测试都有，应该说人力还是很充分的。
任务是将原来的一个系统升级，并附加一些新的功能（原来的系统其实
很类似于我上面提到的项目，架构很差，在不断的往里面塞功能以后现
在再也塞不进去了，因此必须重做）。
从技术层面上来说这个项目还是完成的不错，基本上按质按量完成了，
但是总体上来说做的很辛苦，客户层面的满意度也比较一般，因为主要
是改善了内部架构，对于用户看到的是只增加了部分扩展功能，而且由
于架构的差别，原先用户熟悉的界面和操作习惯难免有改变，虽然我们
已经充分考虑了这一点，但是不改是不可能的。
所以，结果如下：
第一：客户满意度一般。（对于领导来说，只是一个系统的升级，增加
了一些功能而已，对于操作者来说，需要花费时间来重新熟悉新的系统，
而且由于我们的质量控制比较严格，用户变更都需要讨论通过，签字确
认，然后再开发，发布新的版本，导致周期比较长。所以给实际操作人
员的印象是我们还不如原来的开发者：（（（）
第二：公司利润很薄。（客户方的用户代表比较懂技术，因此对于一些
细节的地方把关很严，而这些地方耗的人力往往比主要功能还要多。而
整个系统的报价对于升级的功能模块报的比较低，对于新开发的模块报
的稍高一些。但是由于原有系统数据导入等问题，实际上是对原有功能
模块的重新开发更花费时间。虽然用户代表比较了解，但是他也只能帮
我们说说好话，不可能多发钱给我们。）
做软件做到这个份上，实在是很郁闷啊
ezlz:
一个数据仓库的项目
集成方、客户方、合作伙伴方，
整个团队二百多号人呢，
去年四月份做需求分析，
三方人员做事都很卖力，
十月份项目启动，
一切步骤都有条不紊的进行着，
但十二月底项目被宣布无限期终止，
致使集成方和合作方共有NN多人失业，
这是一个很很特殊的原因，
因为客户高高高层的人事变动，
这个上几亿的要持续五年的案子就此不了了之了。
有意思吗？
w102272:
我说一个失败的项目吧，不同的是我们是作为甲方的面目出现的，
去年10月份该项目启动，共投资300万，计划在3个月完成产品雏形，5个月稳定化，6-7月产品化。我负责技术。
但高层实际投入不足150万RMB.总经理被迫在各方面严格控制成本。在开发部门，我们采用了自己设计，开发外包，不建立大规模团队的方式来压缩成本。
需求和设计都很成功，但不幸的是，外包方是由总经理直接指定的，而总经理本人对技术并不了解多少。
大约出于利益，面子？合作方屏蔽了我们一切对项目监控的努力。拒绝提供开发人员名单，拒绝我们和任何开发人员直接沟通设计和需求。拒绝我们参与程序测试和模块设计过程。甚至拒绝了我们愿意保持原合同费用不变，由我们这方付费派开发人员参与他们开发过程的请求。只是不断对我们说，我们一直在努力，靠！！！
而我们制订的计划，需求，设计，进度控制等就在不知不觉中变成了废纸。
在开发到1.5月，3个月的时候，我们向公司两次提议更换合作方，但这个提议和计划无人理睬。最终随着时间流逝，无人再有兴趣和胆敢提出这样的建议了。作为开发方的软件公司固然有自己的困难，但甲方是孙子，乙方变成了爷，这种事情大家没怎么遇到过吧？呵呵。
在历时10个月的的漫长谈判和拉锯战后，对方终于提交了一个很不稳定，bug成批的产品。将原来的3－5个月开发时间拉长到了10个月，并在这个过程中不断提出追加开发费用的要求，极度延误的开发周期最终影响了产品第一季度的销售。
在11个月后，我终于得到了这个产品的源程序，并开始着手组织人重新改写。按目前的进展看，事实上合理组织下，2.5×3人月足以开发出这个产品来。
项目本身目前还不算失败，但带来的潜在损失无疑是极其惨重的。我们失去了市场先机，浪费了大量的精力和时间，没有得到一个理想中满意的产品。
最终没有人是满意的！！！
市场部门不断反馈产品的错误，并开始在客户服务方面不断花费成本
投资者开始少花钱的得意洋洋，慢慢转变为更多对经营的参与，控制和不满
总经理的经营能力被置疑，并蒙受了资方巨大的压力（尽管目前情况在好转）
外包方在10个月漫长开发中也最终没有得到他们满意的开发费用，而且显而易见，本来3-5个月的开发有很多的赢利，并可以进一步谈判分享市场的事情，变成了漫长的开发过程中，耗尽了开发费用，亏损，和开发团队的分崩离析（据我后期的了解）
公司负责项目进度，策划和质量保证的MBA在种种不规范的打击下辞职而去
技术部门则在慢慢收拾这个烂摊子，并在承受各方合理不合理的置疑：软件设计肯定有问题，写得肯定有问题(事实上是外包方)，开发计划肯定有问题，管理肯定有问题(事实上老板和总经理直接操纵了整个事情)。若不是为了整个经营团队的利益（也包含我个人在内）不至于丧失殆尽，以及认为事情还可以补救，恐怕我这里的技术团队能保留多少还很难说。
高层的无知30% 项目经理的无能50% 程序员20%，需求及详细分析不够，缺乏时间和人才等等，我认为均不是导致该项目失败的关键因素。你果真以为高层无知吗？而作为投资者或管理者而不是专业人员，要求他们事事都象你那样明白也没有道理。
失败的原因是我们不懂软件工程？个人不够优秀？计划和产品不合理？
利益不均衡，决策不规范，组织和权力架构混乱，各方缺乏足够的诚信等才是导致问题的根源。
回首这些事情，唯一能作的只是叹叹气而已，作过这么多项目，对这些风险早都不陌生了。只是又想起了英国首相丘吉尔说过一句名言，"没有永恒的朋友，没有永恒的敌人，只有永恒的利益"。这不是伦理，而是规律。任何公司的态度和行动，都是从自身利益最大化的角度出发的，而不是从良心、利他、合作、双赢、诚信角度出发的。
软件工程？哎，真是无能而脆弱的软件工程呀。
或许还有一种可能性，就是软件产品只是项目总投资的一小部分，大约只占300万投资的30%左右，换算实际投资150万RMB的(50万左右，按最终7个月得到最终产品的周期看，最小开发开支应该是3人*7月*每开发人员平均1万RMB=21万)，加上我方和对方的设计成本＋管理成本＋不可预测费用，应该是刚刚好。但开发方错误估计了这里的含金量，也不相信未来的合作能带来更大的收益，因此把所有的精力都用在和我们讨价还价，宁愿项目失败也要拼命先捞一把？
又或许外包方开发公司只是一个无能之辈或皮包公司，并没有动用有效的开发力量来开发产品。
又或许项目背后充满了我所不了解的暗箱操纵？
这恐怕是我很难再搞明白的事情了。哎...
ziwuxian:
一、不能产品化。大多数软件公司都是小作坊，很难针对某一方面形成强势产品，只能由客户摆布，提取需求不专业。上一个项目积累的知识往往很少能用到下一个项目。
二、一个人担任太多角色。让编代码的做系统分析，做编码，做测试；让测试人员编代码，做系统分析，做测试；让系统分析员做分析，做市场，做编码；让市场人员写需求等等。即是让一方面的专家做多方面的工作，而其他方面他是一知半解或者根本不会。
三、时间问题。估计80％或者更高的项目不能按时完成，在我们公司估计是99.99％不能按时完成，甚至很多是原定的2倍。原因有很多方面。
四、公司管理太差。没有形成上下共享资源，沟通的作用。高层毫无计划地不断往下扔任务，总经理接到就往项目经理上扔，项目经理往程序员上扔，造成
下级不断的接任务，毫无喘气的时候，很快一栋楼的根基压断了，接着后果可想而知。
五、没形成规范。过了CMM又如何，只是撑撑门面。项目根本没按着CMM走。高层说，现在竞争激烈，管不了那么多。软件工程也只是挂在嘴边而已。
....
实在太多，没空说了，说了好像起的用处也不大。反正提了意见，领导也不见
得就听取，说不定摆你一刀，说我管理不行，不怕我炒了你....#$%#@
mis98ZB:
感觉就像是在说我们现在这个项目一样。
当然，有一点不同是我这个部分的人员基础比较差。
我们这个项目是一个对日软件外包项目，
规模比较大，
就我负责的这一部分的手写代码量就达到了87,000行。
而我负责这个部分不到总体的十分之一。
就这么大一个项目，
小日本居然使用瀑布模型进行开发，
大开形式化的软件评审会，
并且充分的向我们展示文档过度的一切特征……
由于不是构架优先，
重要的基础性代码不能及早的提交给我们，
我们提交的局部的构架也不受日方的重视；
而由于工期的要求，
我们就在空中楼阁中做出一大堆无根草一样的程序。
直到UT开始，
早期埋下的火药开始被接二连三的点着了……
一个月之内，
我负责这部分的共通函数的仕样书从1.0版狂飙至2.9版，
每个0.1的增长都是影响着87,000行代码的大地震……
三十多个至关重要的输入record也是改的天翻地覆……
而大量的附属文档也是疯狂地修改……
地狱啊！！！
想想两个月之前，
我还在开玩笑说项目失败的五大特征已经有三个浮现了，我们的项目快要及格了，
没想到今天马上就要成为现实了。
redguardtoo:
我也来说说我的经历，也是给小日本开发的。
首先楼上的原文引用
"由于不是构架优先，
重要的基础性代码不能及早的提交给我们，
我们提交的局部的构架也不受日方的重视；
而由于工期的要求，
我们就在空中楼阁中做出一大堆无根草一样的程序。"
同样的毛病，我就不多说了。
不过由于我能力比较强，和我联系的那个日本人比较弱，而且从一开始的设计都是我做的，所以这还不是个问题。
至于代码质量，由于我一开始就坚持了人盯人战术，每个人都要白盒测试，测试要给我review并记录的原则。所以代码的质量还是可靠的，也按时完成了编码。
麻烦的是小日本要我自己把这个库集成到那个系统中，但是不给我系统的文档，只有一大堆系统源代码，而且那堆系统代码竟然编译失败了，而小日本也不清楚为什么失败，而且也说不准集成在哪里！天哪！
然后是日本人要结婚，我要度一个假期，电话联系听不清对方讲什么。email联系也在捣浆糊。
最后日本人在我的反复劝说下装上了MSN messenger，每天实时遥控我，我去钻研那堆该死的代码。总算集成进去了，工作也算完成了。
当日本人通过Msn Messenger告诉我，“xx，我现在才明白communication是很重要的....(因为在开始项目前我给他大讲了一通communication的重要，他很不以为然，事实上我当然不是空穴来风）”
我听着那个小日本的长篇大论，心里明白我在这家公司肯定是呆不长了，我心里想，你是明白了这个道理，但是我可付出了巨大的代价。
gu_gth:
:不明确的需求分析，项目经理为了讨好客户，对客户提出的需求言听必从，但对这改动将要对哪禧模块将会产生影响，那系模块将要发生变动，客户的需求是否合理不重视，对需求变动的控制太少，力度不够！客户的需求是否合理不重视，随软件过程中需求的不断变更，构架越来越脆弱。
2：分析设计工作的欠缺，不说分析设计的方法，很少有公司对公用函数，专用函数，清晰的函数接口，各模块，各函数件的调用关系，模块间的依赖关系做出明确的划分，对于小的项目，如果程序员还能记得，会从通用函数库里调用，如果不记得，或程序员是个新人，不辛发生了，他又重写了另外一个函数，出现了2个副本！
漫漫的，但代码重的逻辑错误是很难看的，为性能、编码质量、可维护性打下隐患！
3：项目的风险，不可否认，每个项目都有一些未使用过的技术，对新技术没做过原形测试，等到了那个阶段是，发生了瓶紧，整个项目都停了，或是先做出一些垃圾，等有经验后再推倒重干！
4：管理上的问题，向莫过程中以来程序员间的交流，但程序员间的交流往往造成信息的损失，导致产品质量问题！编码的风格统一！
ylg007:
经历过两个项目.
1、半途接手一个项目，项目已有一年有余，可是却没有一份像样的需求分析，甚至连业务流程图也不见踪影。拿着一套不能并不成熟的产品到客户哪里实施。可想而知在没有进行调研的情况下，修修补补最终不了了知。经历的第一个项目失败告终。经验：开发模式的项目没有精确完整正确的需求是没法完成一个项目的。
2、第二个项目已完成。按照上楼的说法，我做为客户方认为项目是三等品.基本满足我们的要求。开发方对供应链系统有成熟的产品，并对企业做了一次管理思想的培训，叫业务重组（bpr）吧。开发方不是调研我们在正做什么，而是以老师的身份告诉我们如何管理一个像我们这样的企业。可想而知开发方对业务的熟悉程度。项目实施过程中程序的问题很少，但是为项目却是三等品。因我公司高层在开发费用方面的原因，不合理的缩短了项目时间。致使一些模块没有得到使用。本应完美的项目却只能评及格。影响项目品质的原因还有关键业务部门的人员素质，公司本身的企业管理现状。因关键业务部门不积极配合，基础资料的准备就占了项目三分之二的时间。
遇到的失败项目比较多！让人郁闷！！
仔细分析原因，主要在于：
1.项目开始需求不明确。领导决定动手，就开始启动项目，造成和客户需要差距太大，导致失败；
2.需求变更没有控制。客户提出新的需求，或者改变原来的需求，没有一个好的控制流程，没有人把关，程序员也可以接受客户的要求，导致功能越来越复杂，进度和质量严重失控，被客户赶走！
3.自己太随意。开发人员自作聪明，认为客户会需要某个功能，未和客户协商，就增加了一些额外的功能，导致进度拖延，客户不满意。
4.用户原因。用户提出了需求，功能很多，要求你在不可能的时间内完成，我们只能加班加点，最初还能坚持，时间一长，工作效率和精神状态都低了下来，进度拖延得更多。
Jinq0123:
如果说超时是失败，那我就没成功过，除了一些一个月之内的超小型项目。
主要是计划太雄心勃勃。
我的一个朋友说计划应该有点挑战性。
但我现在的体会是需要历史项目的统计数据才能订出合理的计划。
sythree:
和大家差不多。
有一个是市场部对客户承诺太多，需求变更太厉害了。
还有一个内部转包的项目比较可惜，开始不太重视，后来技术高层屈服于管理高层，对设计做了较大的更改，没有验证，结果出了几个大的性能错误。当是就感到很窝囊，一气之下换了个部门。
komantian:
失败的定义：用户拒绝接受
成功的定义：按时交货，客户接受
我的第一个日本项目，状态编程可以，不懂日语，程序员身份，当时这个团队都很厉害，美誉为梦之队，最后项目重做，投入了5倍于原定计划的人月数，也就是作了25个人月，项目无法联合调试，可以运行了，毛病百出，别说客户，我自己都不想要；事后总结：公司因为其它项目的原因，我们更换了3个项目负责人，导致指挥和仕样理解都有偏差，公司为了造成没有更换项目负责人假象，要后来的项目负责人一直使用前任的邮件帐号，造成客户不知情，对后来人的提出问题很生气，认为已经讲过了，造成沟通效果越来越差；程序员因为语言问题，只能了解自己的问题，不清楚全局的要求，因为项目负责人的更换，内部要重新磨合交流了解，最后每个人都完成了，却无法联合调试。公司的负责人应当负责。我作为程序员也因为其它项目原因，在这个项目组3进3出，当然我的责任现在想起来也不好受，我没有坚持自己的要求，盲目服从上级，在第二次更换项目负责人的时候，我应该挺身而出，但我没有。
至少在半年时间里，我的情绪都没有恢复。
失败会给你很多经验，从此我做项目都非常谨慎，反复推演各种情况，避免重蹈覆辙。我对项目中的BAD SMELL现在很敏感，发现一点不对头，立刻行动起来，坚决的解决它再前进。
值得庆幸的是这是我的目前唯一的一个失败的项目，我后来做到项目经理，大小也作了7、8个项目，有的也很大，在全国部署的项目，从失败中我获益匪浅。
ntchengl:
欧当作程序员参与的项目，就算是输了，关系也不大。
欧主持的两个项目，最后都算是成功了，但是都很坎坷。
这两个项目是这样的：
第一个项目是半道接手的，前任已经做过了需求分析。说实在的，只是去调研过了，需求分析的成果，我基本没有看到。但是时间仓促，最后扭转乾坤了。虽然这个项目托了3-4个月，但是责任不在我。第一我不熟悉业务，有个熟悉的过程；第二原先的需求调研不充分，错误地估计了工期。说实在的，我只算是延误了2个月。
第二个项目是香港的，做了10个月。这个项目算是输了，但是不算我输了。项目初期调研的时候，欧去不了香港，去了一个不懂业务的人调研，调的还不如半吊子。我没看到合同条款，公司就签合同了。只是从香港的客户那里看到了合同，而且不是最终合同。这个合同的附件只有两页：我们写的是广告宣传上面的牛B话，客户的要求也是模棱两可。我真不想做这个项目，可是没办法。这个项目我也是重新调研，质量完成得还算可以吧，客户的要求太高了，我们的合同签的我哑口无言。最后完成了，原计划3个月，实际做了10个月。最重要的原因，是市场部不调研就错误地认为3个月才能完成。
这两个项目都是差在需求分析上面，都不是我做的。说实在的，最终能做出来，还多亏了我呢。
我做的需求分析，自己主持的项目，都是比较小的，基本没问题。
clamp_chen:
成功和失败只是简单的二分法，很多时候都是介于两者之间的，既不是完全
的成功也不是完全的失败。
影响的因素不单是技术层面的，还有管理层面的，市场层面的。
说不定一个开发的很差的系统却赚了不少钱，而一个开发的很好的系统却
利润很薄。哪个项目比较成功呢？
我最近有这样一个想法，就是软件系统要引入质量等级的概念，就象传统
制造业一样，有一级品、二级品、三级品等等。
我曾经做过两个项目，第一个项目的时候经验不是很足，一开始需求就做
的很不仔细，也不知道如何控制客户需求，人手也只有两个技术人员，但
是还有一个市场人员支持，不过那时很有热情，紧赶慢赶了两个月就交付
了，然后就是根据客户需求不断地调整，调整了大半年才基本稳定了。
从技术层面评估这个系统很差，无论是可重用性还是易用性都很差，如果
换个人接手肯定气死了，我们后来也一直有把它重新架构的考虑，但由于
种种原因一直没有实现。
但是如果换个角度评判，这个项目其实很不错。
第一：客户满意度很高。（支持的市场人员很会拉关系，而且客户原来的
操作确实很烦琐，我们的系统虽然不太好用，但是还是为他节省了大量的
时间，另外，我们的响应很及时，经常是一个电话就到现场，直接改掉。
因此无论是客户的领导还是实际的操作者都比较满意，后来还给了我们公
司一个更大的项目）
第二：公司利润很好。（因为只有两个人，成本很低……而且拉来了后
面的项目，好处很多）
后来有一个项目，经验比以前增加了很多，对软件工程也知道了不少。
客户方面也比较严谨，有专门的懂技术的用户代表配合。整个开发团队
也很齐整，设计、开发、测试都有，应该说人力还是很充分的。
任务是将原来的一个系统升级，并附加一些新的功能（原来的系统其实
很类似于我上面提到的项目，架构很差，在不断的往里面塞功能以后现
在再也塞不进去了，因此必须重做）。
从技术层面上来说这个项目还是完成的不错，基本上按质按量完成了，
但是总体上来说做的很辛苦，客户层面的满意度也比较一般，因为主要
是改善了内部架构，对于用户看到的是只增加了部分扩展功能，而且由
于架构的差别，原先用户熟悉的界面和操作习惯难免有改变，虽然我们
已经充分考虑了这一点，但是不改是不可能的。
所以，结果如下：
第一：客户满意度一般。（对于领导来说，只是一个系统的升级，增加
了一些功能而已，对于操作者来说，需要花费时间来重新熟悉新的系统，
而且由于我们的质量控制比较严格，用户变更都需要讨论通过，签字确
认，然后再开发，发布新的版本，导致周期比较长。所以给实际操作人
员的印象是我们还不如原来的开发者：（（（）
第二：公司利润很薄。（客户方的用户代表比较懂技术，因此对于一些
细节的地方把关很严，而这些地方耗的人力往往比主要功能还要多。而
整个系统的报价对于升级的功能模块报的比较低，对于新开发的模块报
的稍高一些。但是由于原有系统数据导入等问题，实际上是对原有功能
模块的重新开发更花费时间。虽然用户代表比较了解，但是他也只能帮
我们说说好话，不可能多发钱给我们。）
做软件做到这个份上，实在是很郁闷啊
ezlz:
一个数据仓库的项目
集成方、客户方、合作伙伴方，
整个团队二百多号人呢，
去年四月份做需求分析，
三方人员做事都很卖力，
十月份项目启动，
一切步骤都有条不紊的进行着，
但十二月底项目被宣布无限期终止，
致使集成方和合作方共有NN多人失业，
这是一个很很特殊的原因，
因为客户高高高层的人事变动，
这个上几亿的要持续五年的案子就此不了了之了。
有意思吗？
w102272:
我说一个失败的项目吧，不同的是我们是作为甲方的面目出现的，
去年10月份该项目启动，共投资300万，计划在3个月完成产品雏形，5个月稳定化，6-7月产品化。我负责技术。
但高层实际投入不足150万RMB.总经理被迫在各方面严格控制成本。在开发部门，我们采用了自己设计，开发外包，不建立大规模团队的方式来压缩成本。
需求和设计都很成功，但不幸的是，外包方是由总经理直接指定的，而总经理本人对技术并不了解多少。
大约出于利益，面子？合作方屏蔽了我们一切对项目监控的努力。拒绝提供开发人员名单，拒绝我们和任何开发人员直接沟通设计和需求。拒绝我们参与程序测试和模块设计过程。甚至拒绝了我们愿意保持原合同费用不变，由我们这方付费派开发人员参与他们开发过程的请求。只是不断对我们说，我们一直在努力，靠！！！
而我们制订的计划，需求，设计，进度控制等就在不知不觉中变成了废纸。
在开发到1.5月，3个月的时候，我们向公司两次提议更换合作方，但这个提议和计划无人理睬。最终随着时间流逝，无人再有兴趣和胆敢提出这样的建议了。作为开发方的软件公司固然有自己的困难，但甲方是孙子，乙方变成了爷，这种事情大家没怎么遇到过吧？呵呵。
在历时10个月的的漫长谈判和拉锯战后，对方终于提交了一个很不稳定，bug成批的产品。将原来的3－5个月开发时间拉长到了10个月，并在这个过程中不断提出追加开发费用的要求，极度延误的开发周期最终影响了产品第一季度的销售。
在11个月后，我终于得到了这个产品的源程序，并开始着手组织人重新改写。按目前的进展看，事实上合理组织下，2.5×3人月足以开发出这个产品来。
项目本身目前还不算失败，但带来的潜在损失无疑是极其惨重的。我们失去了市场先机，浪费了大量的精力和时间，没有得到一个理想中满意的产品。
最终没有人是满意的！！！
市场部门不断反馈产品的错误，并开始在客户服务方面不断花费成本
投资者开始少花钱的得意洋洋，慢慢转变为更多对经营的参与，控制和不满
总经理的经营能力被置疑，并蒙受了资方巨大的压力（尽管目前情况在好转）
外包方在10个月漫长开发中也最终没有得到他们满意的开发费用，而且显而易见，本来3-5个月的开发有很多的赢利，并可以进一步谈判分享市场的事情，变成了漫长的开发过程中，耗尽了开发费用，亏损，和开发团队的分崩离析（据我后期的了解）
公司负责项目进度，策划和质量保证的MBA在种种不规范的打击下辞职而去
技术部门则在慢慢收拾这个烂摊子，并在承受各方合理不合理的置疑：软件设计肯定有问题，写得肯定有问题(事实上是外包方)，开发计划肯定有问题，管理肯定有问题(事实上老板和总经理直接操纵了整个事情)。若不是为了整个经营团队的利益（也包含我个人在内）不至于丧失殆尽，以及认为事情还可以补救，恐怕我这里的技术团队能保留多少还很难说。
高层的无知30% 项目经理的无能50% 程序员20%，需求及详细分析不够，缺乏时间和人才等等，我认为均不是导致该项目失败的关键因素。你果真以为高层无知吗？而作为投资者或管理者而不是专业人员，要求他们事事都象你那样明白也没有道理。
失败的原因是我们不懂软件工程？个人不够优秀？计划和产品不合理？
利益不均衡，决策不规范，组织和权力架构混乱，各方缺乏足够的诚信等才是导致问题的根源。
回首这些事情，唯一能作的只是叹叹气而已，作过这么多项目，对这些风险早都不陌生了。只是又想起了英国首相丘吉尔说过一句名言，"没有永恒的朋友，没有永恒的敌人，只有永恒的利益"。这不是伦理，而是规律。任何公司的态度和行动，都是从自身利益最大化的角度出发的，而不是从良心、利他、合作、双赢、诚信角度出发的。
软件工程？哎，真是无能而脆弱的软件工程呀。
或许还有一种可能性，就是软件产品只是项目总投资的一小部分，大约只占300万投资的30%左右，换算实际投资150万RMB的(50万左右，按最终7个月得到最终产品的周期看，最小开发开支应该是3人*7月*每开发人员平均1万RMB=21万)，加上我方和对方的设计成本＋管理成本＋不可预测费用，应该是刚刚好。但开发方错误估计了这里的含金量，也不相信未来的合作能带来更大的收益，因此把所有的精力都用在和我们讨价还价，宁愿项目失败也要拼命先捞一把？
又或许外包方开发公司只是一个无能之辈或皮包公司，并没有动用有效的开发力量来开发产品。
又或许项目背后充满了我所不了解的暗箱操纵？
这恐怕是我很难再搞明白的事情了。哎...
ziwuxian:
一、不能产品化。大多数软件公司都是小作坊，很难针对某一方面形成强势产品，只能由客户摆布，提取需求不专业。上一个项目积累的知识往往很少能用到下一个项目。
二、一个人担任太多角色。让编代码的做系统分析，做编码，做测试；让测试人员编代码，做系统分析，做测试；让系统分析员做分析，做市场，做编码；让市场人员写需求等等。即是让一方面的专家做多方面的工作，而其他方面他是一知半解或者根本不会。
三、时间问题。估计80％或者更高的项目不能按时完成，在我们公司估计是99.99％不能按时完成，甚至很多是原定的2倍。原因有很多方面。
四、公司管理太差。没有形成上下共享资源，沟通的作用。高层毫无计划地不断往下扔任务，总经理接到就往项目经理上扔，项目经理往程序员上扔，造成
下级不断的接任务，毫无喘气的时候，很快一栋楼的根基压断了，接着后果可想而知。
五、没形成规范。过了CMM又如何，只是撑撑门面。项目根本没按着CMM走。高层说，现在竞争激烈，管不了那么多。软件工程也只是挂在嘴边而已。
....
实在太多，没空说了，说了好像起的用处也不大。反正提了意见，领导也不见
得就听取，说不定摆你一刀，说我管理不行，不怕我炒了你....#$%#@
mis98ZB:
感觉就像是在说我们现在这个项目一样。
当然，有一点不同是我这个部分的人员基础比较差。
我们这个项目是一个对日软件外包项目，
规模比较大，
就我负责的这一部分的手写代码量就达到了87,000行。
而我负责这个部分不到总体的十分之一。
就这么大一个项目，
小日本居然使用瀑布模型进行开发，
大开形式化的软件评审会，
并且充分的向我们展示文档过度的一切特征……
由于不是构架优先，
重要的基础性代码不能及早的提交给我们，
我们提交的局部的构架也不受日方的重视；
而由于工期的要求，
我们就在空中楼阁中做出一大堆无根草一样的程序。
直到UT开始，
早期埋下的火药开始被接二连三的点着了……
一个月之内，
我负责这部分的共通函数的仕样书从1.0版狂飙至2.9版，
每个0.1的增长都是影响着87,000行代码的大地震……
三十多个至关重要的输入record也是改的天翻地覆……
而大量的附属文档也是疯狂地修改……
地狱啊！！！
想想两个月之前，
我还在开玩笑说项目失败的五大特征已经有三个浮现了，我们的项目快要及格了，
没想到今天马上就要成为现实了。
redguardtoo:
我也来说说我的经历，也是给小日本开发的。
首先楼上的原文引用
"由于不是构架优先，
重要的基础性代码不能及早的提交给我们，
我们提交的局部的构架也不受日方的重视；
而由于工期的要求，
我们就在空中楼阁中做出一大堆无根草一样的程序。"
同样的毛病，我就不多说了。
不过由于我能力比较强，和我联系的那个日本人比较弱，而且从一开始的设计都是我做的，所以这还不是个问题。
至于代码质量，由于我一开始就坚持了人盯人战术，每个人都要白盒测试，测试要给我review并记录的原则。所以代码的质量还是可靠的，也按时完成了编码。
麻烦的是小日本要我自己把这个库集成到那个系统中，但是不给我系统的文档，只有一大堆系统源代码，而且那堆系统代码竟然编译失败了，而小日本也不清楚为什么失败，而且也说不准集成在哪里！天哪！
然后是日本人要结婚，我要度一个假期，电话联系听不清对方讲什么。email联系也在捣浆糊。
最后日本人在我的反复劝说下装上了MSN messenger，每天实时遥控我，我去钻研那堆该死的代码。总算集成进去了，工作也算完成了。
当日本人通过Msn Messenger告诉我，“xx，我现在才明白communication是很重要的....(因为在开始项目前我给他大讲了一通communication的重要，他很不以为然，事实上我当然不是空穴来风）”
我听着那个小日本的长篇大论，心里明白我在这家公司肯定是呆不长了，我心里想，你是明白了这个道理，但是我可付出了巨大的代价。
gu_gth:
:不明确的需求分析，项目经理为了讨好客户，对客户提出的需求言听必从，但对这改动将要对哪禧模块将会产生影响，那系模块将要发生变动，客户的需求是否合理不重视，对需求变动的控制太少，力度不够！客户的需求是否合理不重视，随软件过程中需求的不断变更，构架越来越脆弱。
2：分析设计工作的欠缺，不说分析设计的方法，很少有公司对公用函数，专用函数，清晰的函数接口，各模块，各函数件的调用关系，模块间的依赖关系做出明确的划分，对于小的项目，如果程序员还能记得，会从通用函数库里调用，如果不记得，或程序员是个新人，不辛发生了，他又重写了另外一个函数，出现了2个副本！
漫漫的，但代码重的逻辑错误是很难看的，为性能、编码质量、可维护性打下隐患！
3：项目的风险，不可否认，每个项目都有一些未使用过的技术，对新技术没做过原形测试，等到了那个阶段是，发生了瓶紧，整个项目都停了，或是先做出一些垃圾，等有经验后再推倒重干！
4：管理上的问题，向莫过程中以来程序员间的交流，但程序员间的交流往往造成信息的损失，导致产品质量问题！编码的风格统一！
ylg007:
经历过两个项目.
1、半途接手一个项目，项目已有一年有余，可是却没有一份像样的需求分析，甚至连业务流程图也不见踪影。拿着一套不能并不成熟的产品到客户哪里实施。可想而知在没有进行调研的情况下，修修补补最终不了了知。经历的第一个项目失败告终。经验：开发模式的项目没有精确完整正确的需求是没法完成一个项目的。
2、第二个项目已完成。按照上楼的说法，我做为客户方认为项目是三等品.基本满足我们的要求。开发方对供应链系统有成熟的产品，并对企业做了一次管理思想的培训，叫业务重组（bpr）吧。开发方不是调研我们在正做什么，而是以老师的身份告诉我们如何管理一个像我们这样的企业。可想而知开发方对业务的熟悉程度。项目实施过程中程序的问题很少，但是为项目却是三等品。因我公司高层在开发费用方面的原因，不合理的缩短了项目时间。致使一些模块没有得到使用。本应完美的项目却只能评及格。影响项目品质的原因还有关键业务部门的人员素质，公司本身的企业管理现状。因关键业务部门不积极配合，基础资料的准备就占了项目三分之二的时间。
扫一扫
2179
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
